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

Christer Holmberg <> Fri, 14 October 2016 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4CAF1296BA for <>; Fri, 14 Oct 2016 01:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BVYEm75wAlh9 for <>; Fri, 14 Oct 2016 01:48:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B1C7128DF6 for <>; Fri, 14 Oct 2016 01:48:13 -0700 (PDT)
X-AuditID: c1b4fb3a-e95069800000099a-34-58009bccead3
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A1.9B.02458.CCB90085; Fri, 14 Oct 2016 10:48:12 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Fri, 14 Oct 2016 10:48:02 +0200
From: Christer Holmberg <>
To: Alan Ford <>, "Charles Eckel (eckelcu)" <>
Thread-Topic: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
Thread-Index: AQHSGa3x+izuQLaNQkCcn/MwWSz+h6CjBJQAgATKB4A=
Date: Fri, 14 Oct 2016 08:48:01 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D426777A11238christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM+Jvje6Z2QwRBgfWS1isPLeC2eLfuqNM FptmfWGzmHFhKrMDi8eU3xtZPXbOusvusWTJTyaPW1MKAliiuGxSUnMyy1KL9O0SuDJWPD/P VLC6qGLHwu/sDYx3E7sYOTgkBEwktn+37mLk4hAS2MAoceTJLTYIZwmjxKMZfUwgRWwCFhLd /7S7GDk5RARCJDb/amQEsZkFfCTO3T7CAmILC7hL7J06mRGkXETAQ2JeVzlEuZXE9p0LWUFs FgFVif1bH4GV8ApYSxx/kgYSFhLIl5j37T8TiM0pYCsxZ2oTWDmjgJjE91NrmCA2iUvcejIf zJYQEJBYsuc8M4QtKvHy8T+welEBPYnvX2dDxRUlPr7aB3VlgkTjy11gcV4BQYmTM5+wTGAU nYVk7CwkZbOQlEHEDSTen5vPDGFrSyxb+BrK1pfY+OUsI4RtLbHs9HtGZDULGDlWMYoWpxYX 56YbGemlFmUmFxfn5+nlpZZsYgTG6cEtv612MB587niIUYCDUYmHd8Hp/+FCrIllxZW5hxgl OJiVRHgjpjNECPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp 1cC41GnBHtYt3frVU021Ld/5/J7cs3bTakeH6S2iTyZfORQqce68gEpAubNESMsFFq8NP/dm hm74WSS8J/Vks+XTiZvkMn50X5jIHP9nRRKT0MmU/I5p044m7mNnnTzbs9n6+cQPT0+2XmJl 648s4PgXWFQT+SwxIl3gfMO9dW9ObH6wRMZj0bzNSizFGYmGWsxFxYkAvwuoQM8CAAA=
Archived-At: <>
Cc: "" <>, Roman Shpount <>
Subject: Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Oct 2016 08:48:17 -0000

(Adding Roman, who has had opinions on this)


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



On 28 Sep 2016, at 18:30, Charles Eckel (eckelcu) <<>> wrote:


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.


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


An issue came up during the review of draft-sctp-sdp, which I believe also applies to BFCPbis.


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


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.



bfcpbis mailing list<>