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

Alan Ford <> Tue, 11 October 2016 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 013471297C7 for <>; Tue, 11 Oct 2016 03:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ktl8-QaHocRp for <>; Tue, 11 Oct 2016 03:45:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DBFC129454 for <>; Tue, 11 Oct 2016 03:45:25 -0700 (PDT)
Received: by with SMTP id s49so9466082qta.0 for <>; Tue, 11 Oct 2016 03:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5w5sDw5WpcrOkTMpr1VnmNRZtn9CZGWbtnANoeRbp+s=; b=C9pgVozrXiRjimGmHYtlUip3gyHeowwGlLwIx9oRAOBR99UBBgVFxII1z5JU1MOvIb t3Sz/TafXWao+XbZZkP8orOLxrakNIEOpiKTx6cVMN65wGfSMDFhkwyYJZP/KwSFA300 J74FsPS+y5BoVU4+Cqz+QdeCnK/Y8HYECUupXZYQxqG3LmNmnwInJ10CZHPWfoqnZGEG lik64w+1Nj3Uk+hYa4riOTHNo/tVKKjLqGbiWlPOUtcFkxJ9iUSBeaYsbwp0ZGKaunF9 eO1R6ISR9msC3jfb+ApXUPz9qALXGSPBTGcyMlHgBVqdskkTyavNBiEaqduikgcpq1EJ 2PJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5w5sDw5WpcrOkTMpr1VnmNRZtn9CZGWbtnANoeRbp+s=; b=aUWoIrxgNj7xtJxBjx06RKKD5TqEESvbISlvFrmvgaGowzVftFmOyR2hVHzZ5e6XQM HxqC186tWD2cnUva/Vn7gNharaFnRQONJnkYst2wZ3X7Z0bfuCfxTvKO0EBn/YBCvfs7 0I00OduP1296o0HQTgFTMAN58rN7wL3jWzFUfyd8W8HJrYHDNJER1zlNI3R65hyAqIVd UMfnGp1bXRqciBjI+ss8O+/TAAWjRpN/cDSxa/tZZ+GMswdyzyWdpogTkc8ZMwaQFYgm 51JsomH9jIXUKKQDDTa1N4q51RmDZexSp+5jaJS65CWZ0uZRFzzniaLnA8k1eV9uaK1q xCjQ==
X-Gm-Message-State: AA6/9Rlfko/aoen9EO4iLySNy5oVNx49IO3HJCja8DeIXujSbHxjVOxWQRlQowbpEP/Lrw==
X-Received: by with SMTP id uj2mr3961803wjc.144.1476182709047; Tue, 11 Oct 2016 03:45:09 -0700 (PDT)
Received: from alans-mbp.lan ([]) by with ESMTPSA id a1sm5338630wjl.28.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Oct 2016 03:45:08 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_49C65D77-13B1-4AE4-8649-68F640FEFEDD"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Tue, 11 Oct 2016 11:46:34 +0100
Message-Id: <>
References: <>
To: "Charles Eckel (eckelcu)" <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>, Christer Holmberg <>
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: Tue, 11 Oct 2016 10:45:28 -0000

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?


> On 28 Sep 2016, at 18:30, Charles Eckel (eckelcu) <> 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 < <>> 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
>> 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):
>> <>
>> 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