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

Alan Ford <> Mon, 17 October 2016 08:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3D9312959F for <>; Mon, 17 Oct 2016 01:10:24 -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 EhR4WHJ4y8nU for <>; Mon, 17 Oct 2016 01:10:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D681C1295BD for <>; Mon, 17 Oct 2016 01:10:22 -0700 (PDT)
Received: by with SMTP id o68so264965942qkf.3 for <>; Mon, 17 Oct 2016 01:10:22 -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=kf4H6yx0lp0FuYc0EpHrrhIpdeTVI7DK8OMJXVeEO88=; b=k4/ZT9HoUa9VSV727NCbbvJ+4WIZg0/UAYdeBT/jf7XbahOs1xTPjO9ntQfgQKPIDt +Vjs5hrhZkJ8c6BhXAiQFiEfnVHzuIkm7P9iNgct62lS2ZZ0fZr2r/DgBXa0JKrai3PV rhTm0TWDX1ebUO3py12UBsuoom00/4zvU8HyMx8qA1M+dzQpfX/ZO75DDUr7RYgmCbS+ qY6OO6C3/yOLUkkERG3YuaqifMUpGqpW66T47VTsJJUcYXzeObJcambNWgRr0FwUhSXm BSf+D2s3bEi/Y/22ZjfqkAyq1z1WO3lO14E+Hli5UjWET7Wd8ukMgiG496EPGTjygH6r Ji+Q==
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=kf4H6yx0lp0FuYc0EpHrrhIpdeTVI7DK8OMJXVeEO88=; b=PBv7nUr87t2FTiwpSJ44vmfsk+qQg5+7uh33fHLHLZ12YjFb76XiU/XOb+Ce17B27S Zenq73B7K/Sk422dHf1dqyEjiSPVZSzTUqs6jEGYhTYbM5AkuQCsO7kAlZpd2b3rBkYY D/Bmkm97durhwJaghxtJWo6Z1Qu8zLaKIF+zKedhIsWCaNq9brRiP2GDp3R3MLyGozot 94t0tsqpY5ZttRxDTrG4ifFkvJmpx0EUZinG/hLuMNyC6UdndaxfIPRUAaS1vuw5T7e3 rBaNPCWRA1OfHnxfJpe1NY/dCfPE8EN6olflN5WW6FakxTnhhojRBxIzyHrjE9HwlK2H R4Aw==
X-Gm-Message-State: AA6/9RkkgubRTrnugc7KxO+fk77D0+MyDRmrjw9ZG22YLJZlM03Dk98LfF/7ncdB+hmZjw==
X-Received: by with SMTP id d6mr8509149wjb.98.1476691821849; Mon, 17 Oct 2016 01:10:21 -0700 (PDT)
Received: from alans-mbp.lan ([]) by with ESMTPSA id n6sm4474634wjg.30.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 17 Oct 2016 01:10:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BB472DBA-DE80-4114-8032-E3CBAE254C20"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Mon, 17 Oct 2016 09:10:20 +0100
Message-Id: <>
References: <> <> <>
To: Christer Holmberg <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>, "Charles Eckel (eckelcu)" <>, 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: Mon, 17 Oct 2016 08:10:25 -0000

Hi Christer, all,

> On 14 Oct 2016, at 09:48, Christer Holmberg <> wrote:
> >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.

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.