Subject: Re: [MMUSIC] Transport tag used for DTLS/SCTP over ICE - text suggestion

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Sep 2016 08:15:54 +0000

Hi,

What about adding the following text to the ICE Considerations section:

"Whenever an SDP offer or answer is sent, the photo value of each m- line MUST match the
transport protocol associated with the default candidate. Hence, if UDP
  transport is used for the default candidiate the ‘UDP/DTLS/SCTP’
proto value MUST be used. If TCP transport is used for the default
candidate the ‘TCP/DTLS/SCTP’ photo value MUST be used.
However, if an endpoint switches between using TCP-based and UDP-based candidates during a session
the endpoint is not required to send an SDP offer in order to modify the proto value
of the associated m- line to match the transport protocol of the used candidate.

NOTE: The text in the paragraph above only applies when the usage of ICE has been negotiated. If ICE is not used,
the proto value MUST always reflect the transport protocol used at any given time.”

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 21 September 2016 at 10:30
To: Roman Shpount <[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

(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?

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: Mon, 26 Sep 2016 10:30:01 -0400

This sounds reasonable to me.
(But please s/photo/proto/.)

	Thanks,
	Paul

On 9/26/16 4:15 AM, Christer Holmberg wrote:
> From: mmusic <[email-masked] <mailto:[email-masked]>>
> on behalf of Christer Holmberg <[email-masked]
> <mailto:[email-masked]>>
> To: Roman Shpount <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> 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]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> 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
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Sep 2016 20:16:20 +0000

Hi,

>(But please s/photo/proto/.)

I'll fix that :)

Regards,

Christer

On 9/26/16 4:15 AM, Christer Holmberg wrote:
> "Whenever an SDP offer or answer is sent, the photo value of each m- 
> line MUST match the transport protocol associated with the default 
> candidate. Hence, if UDP  transport is used for the default candidiate 
> the 'UDP/DTLS/SCTP'
> candidate the 'TCP/DTLS/SCTP' photo value MUST be used.
> However, if an endpoint switches between using TCP-based and UDP-based 
> candidates during a session the endpoint is not required to send an 
> SDP offer in order to modify the proto value of the associated m- line 
> to match the transport protocol of the used candidate.
>
> NOTE: The text in the paragraph above only applies when the usage of 
> ICE has been negotiated. If ICE is not used, the proto value MUST 
> always reflect the transport protocol used at any given time."
>
> Regards,
>
> Christer
>
> From: mmusic <[email-masked] 
> <mailto:[email-masked]>> on behalf of Christer Holmberg 
> Then, IF usage of ICE is negotiated, endpoints can switch to option 
> 2), i.e, candidates are used to indicate what transport is used.
>
> 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
>
> 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.
>
> 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
>
>