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

(Adding Roman, who has had opinions on this)

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).

Regards,

Christer

On 28 Sep 2016, at 18:30, Charles Eckel (eckelcu) <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> 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 <bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org>> on behalf of Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Date: Monday, September 26, 2016 at 10:51 PM
To: "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>
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

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
bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>
https://www.ietf.org/mailman/listinfo/bfcpbis