Subject: [MMUSIC] draft-ice-sip-sdp: m- line matching default candidate in SDP answer?

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Oct 2016 09:37:40 +0000

Hi,

The issue in this e-mail has came up during ICE discussions related to BFCP and SCTP.

Section 4.1.1.2 of draft-ietf-mmusic-ice-sip-sdp-10 says:

   "The default candidates are added to the SDP as the default
   destination for media.  For streams based on RTP, this is done by
   placing the IP address and port of the RTP candidate into the "c="
   and "m=" lines, respectively.”

…and:

   "The transport addresses that will be the default destination for
   media when communicating with non-ICE peers MUST also be present as
   candidates in one or more a=candidate lines."

Assume the offerer sends an offer. The default candidate is TCP-based, which will be reflected in the m- line (e.g., TCP/DTLS/SCTP). The offer also contains UDP-based candidates.

Now, assume the default candidate of the answerer is UDP-based (perhaps the answerer doesn’t even support TCP). However, according to the O/A rules, the answerer cannot change the m- line proto in the answer (e.g., UDP/DTLS/SCTP). So, if I understand correctly, it means that the answerer must reject the m- line – even if there are UDP-based candidates that the answerer would support.

A solution to this would be to NOT mandate the m- line to match the default candidate in the answer. So, in the example above, the answerer could include (TCP/DTLS/SCTP) in the m- line, but ONLY provide UDP candidates.

Another solution would to always mandate support of one or more specific transports, and specify that the default candidate MUST use that transport.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2016 08:51:22 +0000

Anyone having an opinion on this?

It may impact a couple of drafts which are about to be finalised, so it would be good to hear what people think.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday 17 October 2016 at 12:37
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] draft-ice-sip-sdp: m- line matching default candidate in SDP answer?

Hi,

…and:

Regards,

Christer

---

From: Alan Ford <[email-masked]>
Date: Thu, 20 Oct 2016 13:12:33 +0100

Hi Christer,

It’s definitely something that would enhance the usefulness of ICE in transport-agnostic protocols such as BFCP where there’s no guarantee one end implements both UDP and TCP transports (for example).

I don’t see a problem with a change in text to make that second requirement of 4.1.1.2 apply only to the offerer (not the answerer) - any endpoints implementing this should be fine with this. I would be a little more concerned, however, about proxies that may make some wrong assumptions in these scenarios.

Regards,
Alan

> On 20 Oct 2016, at 09:51, Christer Holmberg <[email-masked]> wrote:
> 
> From: mmusic <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2016 12:42:49 +0000

Hi Alan,

>I don’t see a problem with a change in text to make that second requirement of 4.1.1.2 apply only to the offerer (not the answerer) - any endpoints implementing this should be fine with this. I woul…

Not sure I understand the proxy question. Even if you DO support the transport you indicate in the m- line, it still doesn’t guarantee that you will end up using that transport.

Regards,

Christer

On 20 Oct 2016, at 09:51, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Christer

Hi,

…and:

Regards,

Christer

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

---

From: Alan Ford <[email-masked]>
Date: Thu, 20 Oct 2016 23:33:43 +0100

Hi Christer,

Upon further thought, yes, you’re right - any proxy would have to support the concept of ICE candidates in the first place, so it really doesn’t matter whether it’s the m-line transport or not.

So yes, given the issue recently raised in bfcpbis, and the potential impact also on SCTP, I’d be in favour of this clarification in the text - that the requirement on the transport line matching a candidate is only required for the offerer, not the answerer.

Regards,
Alan

> On 20 Oct 2016, at 13:42, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Alan,
> 
>> On 20 Oct 2016, at 09:51, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Oct 2016 19:09:49 -0400

Hi All,

What do you propose to put in c= and m= line in the answer? Whatever
information you are going to put there it will need to have the correct
transport (UDP or TCP) in the m= line proto in order to be correctly
interpreted?

Another solution (which would correspond to the practical implementations)
is that when initiating or restarting ICE:
a. Implementations MUST support UDP based protocols and MUST include UDP
based candidates
b. Default candidate MUST be UDP based candidate

As a result m= line proto in both offer and answer will always be UDP based.

Once ICE nomination process is completed and candidate pair is selected,
transport in m= line proto MUST correspond to the transport in nominated
ICE candidate pair.

Regards,

_____________
Roman Shpount

On Thu, Oct 20, 2016 at 6:33 PM, Alan Ford <[email-masked]> wrote:

> Hi Christer,
>
> Upon further thought, yes, you’re right - any proxy would have to support
> the concept of ICE candidates in the first place, so it really doesn’t
> matter whether it’s the m-line transport or not.
>
> So yes, given the issue recently raised in bfcpbis, and the potential
> impact also on SCTP, I’d be in favour of this clarification in the text -
> that the requirement on the transport line matching a candidate is only
> required for the offerer, not the answerer.
>
> Regards,
> Alan
>
> >It’s definitely something that would enhance the usefulness of ICE in
> transport-agnostic protocols such as BFCP where there’s no guarantee one
> end implements both UDP and TCP transports (for example).
> >
> >I don’t see a problem with a change in text to make that second
> requirement of 4.1.1.2 apply only to the offerer (not the answerer) - any
> endpoints implementing this should be fine with this. I would be a little
> more concerned, however, about proxies that may make some wrong assumptions
> in these scenarios.
>
> Not sure I understand the proxy question. Even if you DO support the
> transport you indicate in the m- line, it still doesn’t guarantee that you
> will end up using that transport.
>
> Regards,
>
> Christer
>
> From: mmusic <[email-masked]> on behalf of Christer Holmberg <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> Assume the offerer sends an offer. The default candidate is TCP-based,
> which will be reflected in the m- line (e.g., TCP/DTLS/SCTP). The offer
> also contains UDP-based candidates.
>
> Now, assume the default candidate of the answerer is UDP-based (perhaps
> the answerer doesn’t even support TCP). However, according to the O/A
> rules, the answerer cannot change the m- line proto in the answer (e.g.,
> UDP/DTLS/SCTP). So, if I understand correctly, it means that the answerer
> must reject the m- line – even if there are UDP-based candidates that the
> answerer would support.
>
> A solution to this would be to NOT mandate the m- line to match the
> default candidate in the answer. So, in the example above, the answerer
> could include (TCP/DTLS/SCTP) in the m- line, but ONLY provide UDP
> candidates.
>
> Another solution would to always mandate support of one or more specific
> transports, and specify that the default candidate MUST use that transport.
>
> Regards,
>
> Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Oct 2016 06:32:09 +0000

Hi,

>What do you propose to put in c= and m= line in the answer? Whatever information you are going to put there it will need to have the correct transport (UDP or TCP) in the m= line proto in order to be correctly interpreted?
>
>Another solution (which would correspond to the practical implementations) is that when initiating or restarting ICE:
>a. Implementations MUST support UDP based protocols and MUST include UDP based candidates
>Once ICE nomination process is completed and candidate pair is selected, transport in m= line proto MUST correspond to the transport in nominated ICE candidate pair.

Mandating UDP would probably work for most protocols (RTP, SCTP-over-DTLS etc), but can we do it for BFCP? We could of course say that, if an BFCP endpoint supports ICE, it MUST also support BFCP-over-UDP.

Regards,

Christer

On Thu, Oct 20, 2016 at 6:33 PM, Alan Ford <[email-masked]<mailto:[email-masked]>> wrote:
Hi Christer,

Regards,
Alan

On 20 Oct 2016, at 13:42, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alan,

Regards,

Christer

Regards,

Christer

Hi,

…and:

Regards,

Christer

---

From: Alan Ford <[email-masked]>
Date: Fri, 21 Oct 2016 09:15:13 +0100

Hi Roman,

> On 21 Oct 2016, at 00:09, Roman Shpount <[email-masked]> wrote:
> 

That’s the basis of the question, however. For the answer, is there any reason the m-line transport actually does need to match an ICE candidate?

Regards,
Alan

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Oct 2016 08:45:42 +0000

Hi,

>That¹s the basis of the question, however. For the answer, is there any
>reason the m-line transport actually does need to match an ICE candidate?

It¹s not only about the m- line transport. The IP address and port in the
c/m- line most likely won¹t be valid either (if you use different ports
and addresses for UDP and TCP).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Oct 2016 18:44:00 +0000

Hi,

Maybe we, in draft-bfcpbis and draft-sctp-sdp simply could say: "the rules in ICE apply regarding when the c/m- lines must match the default candidate".  

Then we'll deal with the issue in draft-ice-sip-sdp, and it won't stop progress of draft-bfcpbis and draft-sctp-sdp.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21 October 2016 11:46
To: Alan Ford <[email-masked]>; Roman Shpount <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] draft-ice-sip-sdp: m- line matching default candidate in SDP answer?

Hi,

>>information you are going to put there it will need to have the 
>>correct transport (UDP or TCP) in the m= line proto in order to be 
>>correctly interpreted?
>

It¹s not only about the m- line transport. The IP address and port in the
c/m- line most likely won¹t be valid either (if you use different ports and addresses for UDP and TCP).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2016 14:50:41 -0400

> Then we'll deal with the issue in draft-ice-sip-sdp, and it won't stop progress of draft-bfcpbis and draft-sctp-sdp.

Seems like that would work. But of course they will still eventually 
block on their dependency to that draft.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Oct 2016 18:55:42 +0000

Hi,

>> Maybe we, in draft-bfcpbis and draft-sctp-sdp simply could say: "the rules in ICE apply >>  regarding when the c/m- lines must match the default candidate".
>>
>> Then we'll deal with the issue in draft-ice-sip-sdp, and it won't stop progress of draft->> bfcpbis and draft-sctp-sdp.
>
> Seems like that would work. But of course they will still eventually block on their 
> dependency to that draft.

True. But, at least we'll get the drafts out of the WGs, IESG reviewed etc.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 24 Oct 2016 22:44:23 +0200

> transports, and specify that the default candidate MUST use that transport.

Another solution would be to remove the useless address in the c= and
m= lines because it has zero values when ICE is required (such as in
WebRTC). Or just do as current WebRTC browsers do: put something fake
in there (127.0.0.1 with any port).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 24 Oct 2016 18:23:12 -0400

My initial solution had two parts:

1. In cases where backwards compatibility with non-ICE endpoints is
required, require that ICE includes UDP candidates and uses UDP candidate
for default candidate. Essentially this considers UDP protocol version and
UDP candidate support required to implement and considers TCP based
protocol version and TCP ICE candidate support optional extensions.

2. In cases where ICE is required and non-ICE answer will not be accepted,
define a new transport tag ICE such as ICE/DTLS/SCPT. In this case no
default candidate should be included. c= line should use transport address
IN IP4 127.0.0.1. m= line should use port 7 (discard). In this case no
additional re-INVITE should be sent when ICE nomination process is
completed. This should correspond to the normal use case for WebRTC
browsers.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2016 21:31:08 -0400

On 10/24/16 6:23 PM, Roman Shpount wrote:
> required, require that ICE includes UDP candidates and uses UDP
> candidate for default candidate. Essentially this considers UDP protocol
> version and UDP candidate support required to implement and considers
> TCP based protocol version and TCP ICE candidate support optional
> extensions.
>
> 2. In cases where ICE is required and non-ICE answer will not be
> accepted, define a new transport tag ICE such as ICE/DTLS/SCPT. In this
> case no default candidate should be included. c= line should use
> transport address IN IP4 127.0.0.1. m= line should use port 7 (discard).
> In this case no additional re-INVITE should be sent when ICE nomination
> process is completed. This should correspond to the normal use case for
> WebRTC browsers.

How about:

C=IN IP4 invalid

'invalid' is a syntactically valid FQDN and so can be used there, and we 
have precedent from anonymous.invalid to use it to signify an unusable 
address.

It also occurs to me that with the expansion of TLDs, maybe somebody 
ought to reserve 'invalid' before somebody else reserves it to use it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Oct 2016 09:01:07 +0000

Hi,

I¹ve modified the WGLC pull request for draft-ietf-mmusic-sctp-sdp:

https://github.com/cdh4u/draft-sctp-sdp/pulls

The impacted ICE text now says:

"When an SDP offer or answer is sent, the rules in
   [I-D.ietf-mmusic-ice-sip-sdp] apply regarding when the proto value
   must match the transport protocol associated with the default
   candidate.

   If an endpoint switches between TCP-based and UDP-based candidates
   during a session the endpoint is not required to send an SDP offer in
   order to modify that proto value of the associated m- line.²

I guess the text in the second paragraph should also be put
draft-ice-sip-sdp, but I guess it doesn¹t hurt to keep it also here.

Regards,

Christer

On 24/10/16 21:55, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Hi,
>
>>> Maybe we, in draft-bfcpbis and draft-sctp-sdp simply could say: "the
>>>rules in ICE apply >>  regarding when the c/m- lines must match the
>>>default candidate".
>>>
>>> Then we'll deal with the issue in draft-ice-sip-sdp, and it won't stop
>>>progress of draft->> bfcpbis and draft-sctp-sdp.
>>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 25 Oct 2016 11:25:45 +0200

2016-10-25 0:23 GMT+02:00 Roman Shpount <[email-masked]>:
> define a new transport tag ICE such as ICE/DTLS/SCPT.

Yes please. In fact, ICE is a (virtual) transport (which can use UDP,
TCP, SCTP or whatever behind the scenes), so it fits perfectly in
there.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Oct 2016 09:36:20 +0000

Hi,

>>accepted,

draft-sctp-sdp is in WGLC, so such must-use-ICE proto value should be
defined in a separate document. In addition, I assume it would also cover
other protocols than DTLS/SCTP.

In addition, we have added text in draft-sctp-sdp recommending against
usage of TCP to begin with (unless UDP doesn¹t work), so I don¹t think it
will be a problem for DTLS/SCTP.

Regards,

Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 25 Oct 2016 12:04:37 +0000

Hi Christer,

This seems like a good approach to me. I will suggest we follow this same approach for draft-ietf-bfcpbis-rfc4583bis on the bfcpbis list.

Cheers,
Charles

On 10/25/16, 11:01 AM, "mmusic on behalf of Christer Holmberg" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

On 24/10/16 21:55, "mmusic on behalf of Christer Holmberg"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>>
wrote:

Hi,

block on their

True. But, at least we'll get the drafts out of the WGs, IESG reviewed
etc.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 25 Oct 2016 08:18:18 -0400

On Mon, Oct 24, 2016 at 9:31 PM, Paul Kyzivat <[email-masked]> wrote:

> It also occurs to me that with the expansion of TLDs, maybe somebody ought
> to reserve 'invalid' before somebody else reserves it to use it.
>

As far as I know, IN IP4 127.0.0.1 and m= line with port 7 are already used
by WebRTC enabled browsers to indicate that c= and m= line address should
be discarded. Unless there is a significant benefit in using 'invalid' TLD
in c= line, I do not see a reason to change the current implementations. I
think the main reason current implementations use  IN IP4 127.0.0.1 is
related to the fact that a lot of SDP end point implementations do not
support domain names in c= line.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Oct 2016 13:01:41 +0000

Hi,

I just had a chat with Roman, and our suggestion is to remove even more generic ICE stuff from draft-sftp-sdp, because it should be added to draft-ietf-mmusic-ice-sip-sdp.

NEW TEXT:

-----

12.2.  ICE Considerations

   When SCTP-over-DTLS is used with UDP based ICE candidates
   [I-D.ietf-ice-rfc5245bis] then the procedures for UDP/DTLS/SCTP
   [Section 7] are used.

   When SCTP-over-DTLS is used with TCP based ICE candidates [RFC6544]
   then the procedures for TCP/DTLS/SCTP [Section 8] are used.

   The generic ICE rules defined in [I-D.ietf-mmusic-ice-sip-sdp] apply
   also to SCTP-over-DTLS. Therefore, implementations must treat all ICE candidate pairs associated with an
   SCTP association on top of a DTLS association as part of the same
   DTLS association.  Thus, there will only be one SCTP handshake and
   one DTLS handshake even if there are multiple valid candidate pairs,
   and shifting from one candidate pair to another will not impact the
   SCTP or DTLS associations.  If new candidates are added, they will
   also be part of the same SCTP and DTLS associations.

   In addition, when an SDP offer or answer is sent, the rules in
   [I-D.ietf-mmusic-ice-sip-sdp] apply regarding when the proto value
   (“UDP/DTLS/SCTP” or “TCP/DTLS/SCTP”) must match the transport
   protocol associated with the default 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.

-----

Note that I am not using 2119 terminology, because the generic ICE procedures
are expected to be defined in draft-ietf-mmusic-ice-sip-sdp.

Regards,

Christer

From: Charles Eckel <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 25 October 2016 at 15:04
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] draft-ice-sip-sdp: m- line matching default candidate in SDP answer?

Hi Christer,

Cheers,
Charles

Hi,

Regards,

Christer

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Oct 2016 10:02:06 -0400

> TCP, SCTP or whatever behind the scenes), so it fits perfectly in

+1

(But it would be quite disturbing to have ICE/DTLS/SCTP and have ICE 
decide to use SCTP as *its* underlying transport - effectively 
SCTP/ICE/DTLS/SCTP.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Oct 2016 10:05:41 -0400

On 10/25/16 8:18 AM, Roman Shpount wrote:
>
> On Mon, Oct 24, 2016 at 9:31 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     'invalid' is a syntactically valid FQDN and so can be used there,
>     and we have precedent from anonymous.invalid to use it to signify an
>     unusable address.
>
> As far as I know, IN IP4 127.0.0.1 and m= line with port 7 are already
> used by WebRTC enabled browsers to indicate that c= and m= line address
> should be discarded. Unless there is a significant benefit in using
> 'invalid' TLD in c= line, I do not see a reason to change the current
> implementations. I think the main reason current implementations use  IN
> IP4 127.0.0.1 is related to the fact that a lot of SDP end point
> implementations do not support domain names in c= line.

It was only a thought, to avoid using magic numbers. I don't especially 
care.

In any case, 'c=IN IP4 FQDN' is a bit ill-conceived, since it shouldn't 
be necessary to commit to IP4 or IP6 when using an FQDN. It really ought 
to be 'c=IN IP FQDN'.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Oct 2016 14:12:38 +0000

Hi,

The transport selection would be done based on the available candidates, and I doubt there would be any SCTP candidates.

Regards,

Christer 

Sent from my iPhone

> On 25 Oct 2016, at 17.02, Paul Kyzivat <[email-masked]> wrote:
> 
> (But it would be quite disturbing to have ICE/DTLS/SCTP and have ICE decide to use SCTP as *its* underlying transport - effectively SCTP/ICE/DTLS/SCTP.)
> 
>    Thanks,
>    Paul
>