Subject: Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value

From: Alan Ford <[email-masked]>
Date: Tue, 11 Oct 2016 11:46:34 +0100

Hi all,

While the text is fine and probably closest to current behaviour, it means we can’t get the benefits from ICE if one end supported only one of UDP or TCP.

Today if you offer only TCP or UDP as the proto value on the m-line, and the far end doesn’t, then the far end will zero-port the m-line and you’ll either re-INVITE if you support the other, or just run without BFCP. That same behaviour would continue with the proposed text.

However, the real benefit of ICE in this circumstance would allow the offerer to offer TCP and UDP candidates under a TCP m-line, but the answerer, if they supported only UDP, could then only offer back only UDP candidates (whilst matching the offerer’s proto). But given the text requires a default candidate to be present matching the proto on the m-line, then if the answerer did not support TCP, they would have to zero-port the line.

However, I would assume that breaking the semantics of the offered proto field is probably not a good thing, and defining a transport-agnostic proto isn’t practical, so borrowing the proposed text (with the photo -> proto typo fixed) is probably sufficient at this stage. Unless anyone can think of a neater way of solving this?

Regards,
Alan

> On 28 Sep 2016, at 18:30, Charles Eckel (eckelcu) <[email-masked]> wrote:
> 
> Christer,
> 
> Thanks for point out this issue and sharing the proposal for addressing it within draft-sctp-sdp. I’d like to hear from folks who have implementation experience using ICE for determining BFCP ports as to what they are doing. If you are not using ICE, it would good to understand why that is the case as well.
> 
> Cheers,
> Charles
> 
> From: bfcpbis <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> Date: Monday, September 26, 2016 at 10:51 PM
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Subject: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
> 
>> Hi,
>> 
>> An issue came up during the review of draft-sctp-sdp, which I believe also applies to BFCPbis.
>> 
>> Q1:
>> 
>> The document defines TCP/TLS/BFCP and UDP/TLS/BFCP. If ICE is used, and there can be both TCP- and UDP-based candidates, which value shall be used? Also,
>>  if there is a
>> candidate switch from TCP to UDP (or vice verse), is an updated offer required? Is it even possible to switch between candidates, since in the case of BCFP one uses DTLS and the other TLS
>>  (for RTP and SCTP DTLS is always used – also for TCP).
>> The same applies to UDP/BFCP and TCP/BFCP.
>> 
>> In the following pull request you can see how we suggest to address it in draft-sctp-sdp (look at the changes in the ICE Considerations sections):
>> 
>> https://github.com/cdh4u/draft-sctp-sdp/pull/2 <https://github.com/cdh4u/draft-sctp-sdp/pull/2>
>> 
>> 
>> Q2:
>> 
>> In case of TCP/TLS/BFCP and UDP/TLS/BFCP, if you have
>>  both UDP- and TCP-based candidates, it also means you are going to have both a TLS connection and an DTLS association. If the TLS roles (client/server) change etc, it will affect both
>>  the TLS connection and the DTLS association. I think this needs to be described in the draft, as it is not covered e.g. by referencing draft-dtls-sdp.
>> 
>> 
>> 
>> Regards,
>> 
>> Christer
>> 
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Oct 2016 08:48:01 +0000

(Adding Roman, who has had opinions on this)

Hi,

>However, the real benefit of ICE in this circumstance would allow the offerer to offer TCP and UDP candidates under a TCP m-line, but the answerer, if they supported only UDP, could then only offer back only UDP
>candidates (whilst matching the offerer’s proto). But given the text requires a default candidate to be present matching the proto on the m-line, then if the answerer did not support TCP, they would have to zero-port the line.
>

I guess one solution would be to allow the answerer to use a m- line proto value that does NOT match the default candidate (or, doesn’t match ANY candidate).

Regards,

Christer

On 28 Sep 2016, at 18:30, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:

Christer,

Cheers,
Charles

From: bfcpbis <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 26, 2016 at 10:51 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value

Hi,

Q1:

The document defines TCP/TLS/BFCP and UDP/TLS/BFCP. If ICE is used, and there can be both TCP- and UDP-based candidates, which value shall be used? Also, if there is a
candidate switch from TCP to UDP (or vice verse), is an updated offer required? Is it even possible to switch between candidates, since in the case of BCFP one uses DTLS and the other TLS (for RTP and SCTP DTLS is always used – also for TCP).
The same applies to UDP/BFCP and TCP/BFCP.

https://github.com/cdh4u/draft-sctp-sdp/pull/2

Q2:

In case of TCP/TLS/BFCP and UDP/TLS/BFCP, if you have both UDP- and TCP-based candidates, it also means you are going to have both a TLS connection and an DTLS association. If the TLS roles (client/server) change etc, it will affect both the TLS connection and the DTLS association. I think this needs to be described in the draft, as it is not covered e.g. by referencing draft-dtls-sdp.

Regards,

Christer

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

---

From: Alan Ford <[email-masked]>
Date: Mon, 17 Oct 2016 09:10:20 +0100

Hi Christer, all,

> On 14 Oct 2016, at 09:48, Christer Holmberg <[email-masked]> wrote:
> 

That would certainly work in this scenario - different from the SCTP text, but would permit this behaviour, whilst still providing clear guidance.

However, I fear that would go against the ICE spec; specifically, 5245 says:

   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.

So we’d no longer be adhering to that in the answer.

Regards,
Alan

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Oct 2016 08:55:25 +0000

Hi,

>>> While the text is fine and probably closest to current behaviour, it
>>>means we can¹t get the benefits from ICE if one end supported only one
>>>of UDP or TCP.
>>>
>>> Today if you offer only TCP or UDP as the proto value on the m-line,
>>>and the far end doesn¹t, then the far end will zero-port the m-line and
>>>you¹ll 
>>> either re-INVITE if you support the other, or just run without BFCP.
>>>That same behaviour would continue with the proposed text.
>>>
>>> However, the real benefit of ICE in this circumstance would allow the
>>>offerer to offer TCP
>>> and UDP candidates under a TCP m-line, but the answerer, if they
>>>supported only UDP, could then only offer back only UDP
>>>
>>>
>>> candidates (whilst matching the offerer¹s proto). But given the text
>>>requires a default candidate to be present matching the proto on the
>>>m-line, then if the answerer did not support TCP, they would have to
>>>zero-port the line.
>>>
>>> However, I would assume that breaking the semantics of the offered
>>>proto field is probably not a good thing, and defining a
>>>transport-agnostic proto isn¹t practical, so borrowing the proposed
>>>text (with the photo -> proto typo fixed) is probably
>>>
>>> sufficient at this stage. Unless anyone can think of a neater way of
>>>solving this?
>>
>>
>> I guess one solution would be to allow the answerer to use a m- line
>>proto value that does NOT match the default candidate (or, doesn¹t match
>>ANY candidate).
>
>
> That would certainly work in this scenario - different from the SCTP
>text, but would permit this behaviour, whilst still providing clear
>guidance.

We would update the SCTP text too.

> So we¹d no longer be adhering to that in the answer.

The text is certainly valid for the offer, but when the answer is sent it
is known whether the peers support ICE or not.

In any case, I don¹t think there should be different rules for BFCF, SCTP
etc. This should be defined in draft-ietf-mmusic-ice-sip-sdp as a generic
rule.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2016 12:08:20 +0000

Hi,

>etc. This should be defined in draft-ietf-mmusic-ice-sip-sdp as a generic

I was thinking a little more about this: maybe indicating a transport in
the m- line that you don’t support isn’t a very good idea - even if it
won’t be used with ICE.

Maybe it would be better to say that the m- line shall contain a transport
that the peer is “most likely” to support. In case of BFCP, I guess
neither TCP or UDP is mandatory to support, but in other cases there is
often a mandatory transport.

Regards,

Christer

---

From: Alan Ford <[email-masked]>
Date: Wed, 19 Oct 2016 13:58:54 +0100

> On 19 Oct 2016, at 13:08, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

That still implies they need to support the transport in question, so it’s not dissimilar to the SCTP text about default candidate.

Question really is - and this is probably something more for icebis than here - would it be legitimate to relax that requirement in the text I quoted earlier for the answerer? (The way it is written in 5245 suggests it applies to both offerer and answerer). I don’t see it being a problem for endpoints, but I’d be worried some proxies may expect behaviour here which isn’t true.

Regards,
Alan

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2016 13:06:32 +0000

Hi,

>That still implies they need to support the transport in question, so
>it’s not dissimilar to the SCTP text about default candidate.

The idea was that, if the answerer doesn’t support the transport in the m-
line of the offer, it would have to reject the m- line (as you pointed out
earlier).

>Question really is - and this is probably something more for icebis than
>here - would it be legitimate to relax that requirement in the text I
>quoted earlier for the answerer? (The way it is written in 5245 suggests
>it applies to both offerer and answerer). I don’t see it being a problem
>for endpoints, but I’d be worried some proxies may expect behaviour here
>which isn’t true.

I DID send an e-mail to the MMUSIC list (I think it is more related to
SIP/SDP-usage of ICE than ICE in general) about this a few days ago, but
nobody has replied. Feel free to jump on the discussion :)

Obviously, if you e.g., include TCP in the m- line of the answer (because
the offer contained TCP), but you don’t actually support TCP, the m- line
port value would only be a “dummy value”.

Regards,

Christer

---

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

This issue was discussed in more detail on the mmusic list. Here is the solution Christer applied to draft-ietf-mmusic-sctp-sdp.

   "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.”

This seems like a good approach. I suggest we do the same for draft-ietf-bfcpbis-rfc4583bis by adding this text to section 10.

Cheers,
Charles

On 10/19/16, 3:06 PM, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I guess one solution would be to allow the answerer to use a m- line
proto value that does NOT match the default candidate (or, doesn¹t
match
ANY candidate).
That would certainly work in this scenario - different from the SCTP
text, but would permit this behaviour, whilst still providing clear
guidance.
We would update the SCTP text too.
However, I fear that would go against the ICE spec; specifically, 5245
says:
  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.
So we¹d no longer be adhering to that in the answer.
The text is certainly valid for the offer, but when the answer is sent
it
is known whether the peers support ICE or not.
In any case, I don¹t think there should be different rules for BFCF,
SCTP
etc. This should be defined in draft-ietf-mmusic-ice-sip-sdp as a
generic
rule.
I was thinking a little more about this: maybe indicating a transport in
the m- line that you don’t support isn’t a very good idea - even if it
won’t be used with ICE.
Maybe it would be better to say that the m- line shall contain a
transport
that the peer is “most likely” to support. In case of BFCP, I guess
neither TCP or UDP is mandatory to support, but in other cases there is
often a mandatory transport.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Oct 2016 15:35:00 +0000

Hi,

Please see the updated text proposal on the MMUSIC. For example, the second paragraph has been removed, because it is generic ICE and should be added to draft-ietf-mmusic-ice-sip-sdp.

Regards,

Christer

From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: 25 October 2016 15:05
To: Christer Holmberg <[email-masked]>; Alan Ford <[email-masked]>; Tom Kristensen (tomkrist) <[email-masked]>; Tom Kristensen <[email-masked]>
Cc: [email-masked]; Roman Shpount <[email-masked]>
Subject: Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value

Cheers,
Charles

Hi,

Regards,

Christer