Subject: [MMUSIC] Transport tag used for DTLS/SCTP over ICE

From: Roman Shpount <[email-masked]>
Date: Thu, 15 Sep 2016 20:08:28 -0400

Hi All,

Currently, in
https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-17#section-12.2 it
states that "UDP/DTLS/SCTP" transport should be used with udp ICE
candidates and "TCP/DTLS/SCTP" should be used with tcp ICE candidates. What
should be used in cases when both udp and tcp ICE candiates are provided?

I see three options here:

1. We can state that when DTLS/SCTP is used in combination with ICE, the
protocol tag should match the transport used for default ICE candidate
(candidate specified in c= and m= lines). This option has the highest
chance of being backwards compatible (do we care?), but has the downside,
that selected transport can change in the re-Invite sent at the end of ICE
negotiation, if default candidate changed from udp to tcp or vice versa.

2. State that we always specify UDP/DTLS/SCTP when ICE is used. This has a
problem that transport specified does not match the address and port
specified in c= and m= line, so anything looking at these data will be
mislead (once again, do we care?).

3. Define ICE/DTLS/SCTP protocol. Downside is that no information is
provided about which protocol is used by address specified in c= and m=
line. Upside this can also serve as an indicator that ICE is required for
this connection to work and legacy connections will not be accepted
(RTCWeb).

I personally like the combination of 1 and 3 where 3 is used when ICE is
required (RTCWeb) and 1 is used when legacy interop is needed.

The same issue applies to UDP/DTLS/SAVPF and TCP/DTLS/SAVPF, so if a
resolution was already reached for this, we should probably do the same
here. If there were no resolution, then I think, our current decision
should affect other ICE based protocols as well.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Sep 2016 12:10:34 -0400

On 9/15/16 8:08 PM, Roman Shpount wrote:
> Hi All,
>
> Currently, in
> https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-17#section-12.2
> it states that "UDP/DTLS/SCTP" transport should be used with udp ICE
> candidates and "TCP/DTLS/SCTP" should be used with tcp ICE candidates.
> What should be used in cases when both udp and tcp ICE candiates are
> provided?
>
> chance of being backwards compatible (do we care?), but has the
> downside, that selected transport can change in the re-Invite sent at
> the end of ICE negotiation, if default candidate changed from udp to tcp
> or vice versa.
>
> 2. State that we always specify UDP/DTLS/SCTP when ICE is used. This has
> a problem that transport specified does not match the address and port
> line. Upside this can also serve as an indicator that ICE is required
> for this connection to work and legacy connections will not be accepted
> (RTCWeb).
>

Since ICE is effectively another layer in the protocol stack I like the 
idea of indicating it in the <proto>.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2016 17:41:10 +0000

Hi,

I think we had this discussion a couple of years ago, and the outcome was to use "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP".

We should remember that, when the initial offer is sent, it is yet not known whether ICE will be used - unless we mandate support and usage of ICE, that is.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 16 September 2016 19:11
To: [email-masked]
Subject: Re: [MMUSIC] Transport tag used for DTLS/SCTP over ICE

On 9/15/16 8:08 PM, Roman Shpount wrote:
> 1. We can state that when DTLS/SCTP is used in combination with ICE, 
> the protocol tag should match the transport used for default ICE 
> candidate (candidate specified in c= and m= lines). This option has 
> the highest chance of being backwards compatible (do we care?), but 
> has the downside, that selected transport can change in the re-Invite 
> sent at the end of ICE negotiation, if default candidate changed from 
> udp to tcp or vice versa.
>
> 2. State that we always specify UDP/DTLS/SCTP when ICE is used. This 
> has a problem that transport specified does not match the address and 
> port specified in c= and m= line, so anything looking at these data 
> will be mislead (once again, do we care?).
>
> provided about which protocol is used by address specified in c= and 
> m= line. Upside this can also serve as an indicator that ICE is 
> required for this connection to work and legacy connections will not 
> be accepted (RTCWeb).
>
> I personally like the combination of 1 and 3 where 3 is used when ICE 
> is required (RTCWeb) and 1 is used when legacy interop is needed.

Since ICE is effectively another layer in the protocol stack I like the idea of indicating it in the <proto>.

	Thanks,
	Paul

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Sep 2016 10:43:39 -0700

> We should remember that, when the initial offer is sent, it is yet not known whether ICE will be used - unless we mandate support and usage of ICE, that is.

For this, I personally would be happy to mandate the use of ICE.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 16 Sep 2016 13:48:38 -0400

On Fri, Sep 16, 2016 at 1:41 PM, Christer Holmberg <
[email-masked]> wrote:

> I think we had this discussion a couple of years ago, and the outcome was
> to use "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP".
>

Yes, but which one if both candidates are provided? Current draft language
is misleading saying that you should use only UDP candidates if
UDP/DTLS/SCTP is specified and only TCP candidates when  TCP/DTLS/SCTP is
specified. This is definitely not what we want.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 16 Sep 2016 13:51:08 -0400

On Fri, Sep 16, 2016 at 1:43 PM, Martin Thomson <[email-masked]>
wrote:

> > We should remember that, when the initial offer is sent, it is yet not
> known whether ICE will be used - unless we mandate support and usage of
> ICE, that is.
>
I am all for ICE only implementations and to use ICE protocol tag to
identify them. Essentially if offer specifies ICE/DTLS/SCTP, ignore address
port in c= and m= line and fail the connection if ICE is not supported.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2016 22:10:26 +0000

Hi,

> Yes, but which one if both candidates are provided? Current draft language is misleading saying that you
> should use only UDP candidates if UDP/DTLS/SCTP is specified and only TCP candidates when  TCP/DTLS/SCTP
> is specified. This is definitely not what we want.

We use the framing mechanism defined in RFC 4571 for TCP transport.

RFC 4571 defines the "TCP/RTP/AVP" proto value, but doesn't say anything about ICE.

One option would be to *only* define "UDP/DTLS/SCTP", and then the ICE Considerations sections would describe how to send over TCP (without changing the proto value).

That would prevent using TCP when ICE is not used, but I doubt anyone would do that anyway....

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Sep 2016 17:53:06 -0400

Hi,

The main issue here is interpreting address and port in c= and m= lines.
Without the transport tag (UDP/DTLS/SCTP or  TCP/DTLS/SCTP) it is
impossible to determine which protocol is used for connection setup to c=
and m= line (UDP or TCP) without looking at ICE candidates. So, if we care
that address in c= and m= lines is meaningful, for instance for some middle
boxes that do connection monitoring, then transport tag should match the
transport for default candidate. This will also mean that the transport in
m= line can change when ICE completes. If we do not care, then we can put
there whatever we want (ICE/DTLS/SCTP or UDP/DTLS/SCTP).

Regards,

_____________
Roman Shpount

On Fri, Sep 16, 2016 at 6:10 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >> I think we had this discussion a couple of years ago, and the outcome
> was to use "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP".
> >
> One option would be to *only* define "UDP/DTLS/SCTP", and then the ICE
> Considerations sections would describe how to send over TCP (without
> changing the proto value).
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Sep 2016 07:30:27 +0000

Hi,

So, my suggestion would then be to simply to start with suggestion 1), i.e, the initial offer contains whatever represents the default candidate. Then, IF usage of ICE is negotiated the endpoints switch to suggestion 2), i.e, there is no need to change the transport.

I am just wondering whether we should update RFC 4571, because I think it would be good to have the same procedure also for RTP-over-TCP.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 20 September 2016 at 00:53
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Transport tag used for DTLS/SCTP over ICE

Hi,

The main issue here is interpreting address and port in c= and m= lines. Without the transport tag (UDP/DTLS/SCTP or  TCP/DTLS/SCTP) it is impossible to determine which protocol is used for connection setup to c= and m= line (UDP or TCP) without looking at ICE candidates. So, if we care that address in c= and m= lines is meaningful, for instance for some middle boxes that do connection monitoring, then transport tag should match the transport for default candidate. This will also mean that the transport in m= line can change when ICE completes. If we do not care, then we can put there whatever we want (ICE/DTLS/SCTP or UDP/DTLS/SCTP).

Regards,

_____________
Roman Shpount

On Fri, Sep 16, 2016 at 6:10 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Sep 2016 07:30:28 +0000

(Re-typing reply, because previous seemed to disappear somewhere)

My suggestion would then be to start with option 1), i.e, set the transport according to the default candidate.

Then, IF usage of ICE is negotiated, endpoints can switch to option 2), i.e, candidates are used to indicate what transport is used.

I am just wondering whether we then should update RFC 4571 (basically adding an ICE considerations section), because I think it would be good to have common procedures for when the TCP framing mechanism is used.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Friday 16 September 2016 at 03:08
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Transport tag used for DTLS/SCTP over ICE

Hi All,

Currently, in https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-17#section-12.2 it states that "UDP/DTLS/SCTP" transport should be used with udp ICE candidates and "TCP/DTLS/SCTP" should be used with tcp ICE candidates. What should be used in cases when both udp and tcp ICE candiates are provided?

1. We can state that when DTLS/SCTP is used in combination with ICE, the protocol tag should match the transport used for default ICE candidate (candidate specified in c= and m= lines). This option has the highest chance of being backwards compatible (do we care?), but has the downside, that selected transport can change in the re-Invite sent at the end of ICE negotiation, if default candidate changed from udp to tcp or vice versa.

2. State that we always specify UDP/DTLS/SCTP when ICE is used. This has a problem that transport specified does not match the address and port specified in c= and m= line, so anything looking at these data will be mislead (once again, do we care?).

3. Define ICE/DTLS/SCTP protocol. Downside is that no information is provided about which protocol is used by address specified in c= and m= line. Upside this can also serve as an indicator that ICE is required for this connection to work and legacy connections will not be accepted (RTCWeb).

I personally like the combination of 1 and 3 where 3 is used when ICE is required (RTCWeb) and 1 is used when legacy interop is needed.

The same issue applies to UDP/DTLS/SAVPF and TCP/DTLS/SAVPF, so if a resolution was already reached for this, we should probably do the same here. If there were no resolution, then I think, our current decision should affect other ICE based protocols as well.

Regards,
_____________
Roman Shpount