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

"Charles Eckel (eckelcu)" <> Wed, 28 September 2016 17:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9281012B633 for <>; Wed, 28 Sep 2016 10:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.836
X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dwYSCXpfwhaq for <>; Wed, 28 Sep 2016 10:30:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD17912B63D for <>; Wed, 28 Sep 2016 10:30:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11854; q=dns/txt; s=iport; t=1475083828; x=1476293428; h=from:to:subject:date:message-id:mime-version; bh=uPrnt8bcYIQaGMM5UXFRzjm110t2A/0JRQpXieKCGXY=; b=Cjip5SYFuI4Fpmfw/AlXq+Moc9u01PxTTWQ5/wP/dW4n0cSM91MfeYZI cjxKcOMEZgyqtJMUP6Jv1juTQasLNOnhHgAzwiZUTjki0TVy6EioumrG7 LhGasfKYxEkFyv9RQhZh3HfM2Z778Wxvn5JMeRukGEUne4X1mZ+inlhTJ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAQC1/etX/4kNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgwk2AQEBAQEeV3wHjSumC4USggYkhXoegUM4FAECAQEBAQEBAV4nhGE?= =?us-ascii?q?BAQUjaAEIEQMBAigDAgQwFAkKBAESiE0OrxeMewEBAQEBAQEBAgEBAQEBAQEBA?= =?us-ascii?q?QEYBYgzCIJQhC42gmQrgi8FmXYBhiaJRI9sjGyDfAEeNhqEb3KGMoEAAQEB?=
X-IronPort-AV: E=Sophos;i="5.30,410,1470700800"; d="scan'208,217";a="156257813"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Sep 2016 17:30:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u8SHU1vP006150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2016 17:30:02 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Sep 2016 12:30:01 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 28 Sep 2016 12:30:01 -0500
From: "Charles Eckel (eckelcu)" <>
To: Christer Holmberg <>, "" <>
Thread-Topic: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
Thread-Index: AQHSGa3x+izuQLaNQkCcn/MwWSz+hw==
Date: Wed, 28 Sep 2016 17:30:01 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9BE360E6846249BC94917143D476EEADciscocom_"
MIME-Version: 1.0
Archived-At: <>
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: Wed, 28 Sep 2016 17:30:51 -0000


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.