Subject: [MMUSIC] Getting the SDP right for draft-ietf-dccp-udpencap-07.txt

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 30 Mar 2011 15:35:02 +0200

draft-ietf-dccp-udpencap-07.txt

We have a short presentation for the MMUSIC meeting on Friday on the 
above draft. The draft defines support for a UDP Encapsulation for NAPT 
traversal.

This draft has completed DCCP WGLC, and had one hanging issue that 
needed to be resolved, concerning the way it updates SDP for DCCP [RFC5762].

The basic questions are:

Is there an "easy" way to define SDP that would also allow it to be used 
on a UDP host that doesn't allow native DCCP?

- How do you signal a server that supports both native and 
UDP-encapsulated DCCP?

- In the build-up to Friday's meeting, we'd really welcome discussion to 
help  progress this.

The options described in the slides are illustrated by two examples:

Signalling that uses a new proto in SDP m= line to indicate DCCP, plus
the SDP connection-oriented media extensions [RFC 4145], as per current
draft.

v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x5254505
a=dccp-in-udp:9999
a=setup:passive
a=connection:new

or a new m= proto value.

v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP-UDP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=setup:passive
a=connection:new
a=dccp-udp-port:9999

Please see the slides/draft for details:
http://www.ietf.org/proceedings/80/slides/mmusic-8.pdf

Best wishes,

Gorry & Colin

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 31 Mar 2011 14:58:42 -0400

> - How do you signal a server that supports both native and 

Unfortunately, I think the answer to both these questions is probably ICE, with new ICE candidate types both for IP-layer DCCP and for DCCP-in-UDP.

On the plus side, this would also allow an alternative RTP-in-DCCP/RTP-in-UDP offer, which seems like it would greatly improve the possibility of an evolutionary transition to using DCCP.

Supporting ICE for DCCP-UDP would also allow it to use ICE's full suite of connectivity establishment, thus allowing DCCP connections where both peers are behind NATs (for reasonably friendly NATs, or using TURN).

> m=video 5004 DCCP/RTP/AVP 99
[omitted...]
> a=dccp-in-udp:9999

This will fail for any existing systems that support RFC5762 DCCP/RTP/AVP, since in SDP unknown parameters are ignored.

> m=video 5004 DCCP-UDP/RTP/AVP 99

This seems better, though I'd name it UDP/DCCP/RTP/AVP following existing proto stacking practice.

--
Jonathan Lennox
[email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2011 22:37:10 +0200

Hi

I have taken a look at the draft and have some general comments, and 
then answers to your questions below subsequently:

- Having ICE left for further work when the mechanism is intended to 
allow for NAT traversal does not seem like a good idea. As the draft 
itself notes, the current solution only works for some NAT scenarios. 
Furthermore, the current proposal will most likely lead to problems 
(inconsistencies at the very least) if you were to add ICE support later 
on. I think we need to tackle the ICE issue now to ensure a complete and 
consistent design and solution.

- The "m=" line is what provides the transport protocol in SDP, and we 
should stick with that. This would enable us to use SDP Capability 
Negotiation (RFC 5939) to negotiate between different transports (like 
DCCP-STD and DCCP-UDP). It will also avoid some NAT traversal/ICE issues 
by keeping the port number to the "m=" line (and hence allow us to use 
normal ICE procedures). DTLS-SRTP (RFC 5764) for example is illustrative 
here and would suggest we use something like UDP/DCCP/.... for DCCP-UDP 
and simply stick with DCCP/... for DCCP-STD.

- We should stick with standard comedia operation (RFC 4145). The 
offending part here is the current semantics for the proposed 
"dccp-in-udp" attribute which says that its presence indicates that the 
offerer is listening for DCCP-UDP connections. This issue goes away if 
we follow the above proposal, and hence get rid of the "dccp-in-udp" 
attribute.

More below

> on a UDP host that doesn't allow native DCCP?
Yes - define a "UDP/DCCP/...." transport.

> - How do you signal a server that supports both native and
Use SDP Capability Negotiation (RFC 5939)

> a=dccp-service-code:SC=x52545056
I'd suggest a new proto value and use "UDP/DCCP/..." for consistency 
with other transports.

Thanks

-- Flemming
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 31 Mar 2011 17:01:12 -0400

(I had this composed before I saw Fleming's e-mail; I mostly agree with him.)

[omitted...]
> a=dccp-in-udp:9999

This will fail for any existing systems that support the RFC5762 DCCP/RTP/AVP, since in SDP unknown parameters are ignored.

--
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 31 Mar 2011 17:10:16 -0400

On Mar 31, 2011, at 10:37 PM, Flemming Andreasen wrote:

This is the one point on which I disagree -- this is a choice of alternate transports, so it's more like ICE than CapNeg, it seems to me.

To be sure, in choosing between alternate proto values for the m= line there's an overlap here, since proto is overloaded with both transport and profile.

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2011 23:58:29 +0200

On 3/31/11 11:10 PM, Jonathan Lennox wrote:
> This is the one point on which I disagree -- this is a choice of 
> alternate transports, so it's more like ICE than CapNeg, it seems to me.
>
I think it depends on what you are trying to do: Negotiate use of a 
mechanism that both sides support or find a mechanism that can establish 
connectivity as verified by ICE. It's probably quite reasonable to 
support both scenarios. RFC 5939 Section 3.7 has a bit more text around 
this btw.

More discussion/opinions on this point would be useful.

Thanks

-- Flemming

> To be sure, in choosing between alternate proto values for the m= line 
> there's an overlap here, since proto is overloaded with both transport 
> and profile.
>
> --
> Jonathan Lennox
> [email-masked] <mailto:[email-masked]>
>
>