See in-line on dccp-service-code.
Gorry
On Wed, 15 Jun 2011, Miguel A. Garcia wrote:
A quick review of Section 5 of this document:
- I think it is a good idea to clearly indicate which SDP attributes are
newly created and which ones are reused from other RFCs. I therefore
recommend to add the following sentences somewhere to the corresponding
sections:
5.3:
RFC 4145 [RFC4145] defines the "setup" attribute whose purpose is to indcate
which of the end points should initiate the connection establishment. This
document reuses the "setup" attribute to similarly indicate which end point
initiates the DCCP-UDP connection establishment.
5.4:
RFC 5245 [RFC5245] defines the "candidate" attribute whose purpose is to
provide one of many possible candidate addresses for communication. This
document reuses the "candidate" attribute to indicate native or encapsulated
candidate addresses
[After re-reading this I note that this section speaks of "native" DCCP
whereas there was an earlier suggestion that this should be called
"DCCP-STD", Colin and I should ensure this is consistent in the next
revision.]
- In 5.2 last paragraph, I am missing some normative statements, for example:
If RTCP is multiplexed with RTP, endpoints MUST encode the DCCP port used for
RTCP in the "rtcp" attribute specified in RFC 3605 [RFC3605]. An SDP offerer
MAY indicate its willingnes to multiplex RTP and RTCP onto a single DCCP port
by adding an "rtcp-mux" attribute as specified in RFC 5761 [RFC5761]. If the
answer also includes the "rtcp-mux" attribute (as per RFC 5761 [RFC5761]),
then RTP and RTCP are multiplexed onto a single DCCP port, otherwise separate
DCCP ports are used for RTP and RTCP. In each case, only a single UDP port
is used for the DCCP-UDP encapsulation.
- I didn't find any description of the "dccp-service-code". However, it is
written in the examples in Section 5.5. Is this a leftover from a previous
version of the document?
I suggest a couple of lines to be clear to anyone composing SDP:
RFC 5762 [RFC5762] defines the "dccp-service-code" attribute whose purpose
is to identify the intended service/application to process a DCCP
connection request [RFC5595]. The "dccp-service-code" attribute is the
same for both DCCP-STD and DCCP-UDP encapsulations.
- I agree with your comment at the end of Section 5.5 indicating that an
example using ICE would be beneficial.
So, as soon as we have this, I think we can then finalise the text!
- Section 7.3. There are two references pointing to Section 5.1 in the
document, but they should actually point to Section 5.2
Noted, will fix.
- I think the following references should be made normative: ICE-TCP,
RFC3264, RFC 4566, RFC5245, RFC5761
Seems OK to me, I'll see if Colin agrees.
BR,
Miguel
On 15/06/2011 9:42, Pasi Sarolahti wrote:
Hi,
In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram
Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal
(DCCP-UDP)"). This draft has parts related to the work done in MMUSIC
(especially Section 5), and it was presented in the MMUSIC meeting in last
IETF. The authors have modified the text based on the input received, and
we are now looking for volunteer(s) from MMUSIC to review whether the new
text (mostly in Section 5) looks ok, before moving forward with the draft.
The draft can be found at
http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08
- Pasi
_______________________________________________
mmusic mailing list
mmusic@xxxxxxxx
https://www.ietf.org/mailman/listinfo/mmusic
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
