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

Christer Holmberg <> Mon, 17 October 2016 08:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCBEA1295BA for <>; Mon, 17 Oct 2016 01:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qujzXCvC-0aa for <>; Mon, 17 Oct 2016 01:56:07 -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 CD5ED1294AA for <>; Mon, 17 Oct 2016 01:56:06 -0700 (PDT)
X-AuditID: c1b4fb3a-e95069800000099a-d8-580492256d8a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5D.D4.02458.52294085; Mon, 17 Oct 2016 10:56:05 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Mon, 17 Oct 2016 10:55:27 +0200
From: Christer Holmberg <>
To: Alan Ford <>
Thread-Topic: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
Date: Mon, 17 Oct 2016 08:55:25 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2J7uK7qJJYIgzWv+SxWnlvBbPFv3VEm i02zvrBZzLgwldmBxWPK742sHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBnXX59i L7ggVNFz7jpjA+Nrvi5GDg4JAROJ70sduhi5OIQE1jNKnHtwlR3CWcwo8XPlRxaQIjYBC4nu f9ogpoiAssTyWaxdjJwczAK1EnPmPGIGsYUF3CX2Tp3MCFHiITGvqxwkLCLgJvFz3jZ2EJtF QFXiSc9TsHJeAWuJ/6fbmSA2XWGUeLi9AyzBKWArsX3Cd0YQm1FATOL7qTVMELvEJW49mQ9m SwgISCzZc54ZwhaVePn4HyvIXlEBPYk198MgwooSH1/tY4Ro1ZO4MXUKG0gJM9DeXauCIcLa EssWvoY6R1Di5MwnLBMYxWchWTYLSfcshO5ZSLpnIelewMi6ilG0OLW4ODfdyEgvtSgzubg4 P08vL7VkEyMwFg9u+W21g/Hgc8dDjAIcjEo8vA+WMUUIsSaWFVfmHmKU4GBWEuE92M8SIcSb klhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVANj/J9v5rxsnTfP tU4yUPU5vih+eqVPZ/1+tftsyxQ5Ug8fm1j9qzaef7Fe2axo5fRY7YlvT0ebsidsyc3MPsKh 84D7s6LxFjb/A04fz7L11nikyvycc3+mT/6lH0q8Bx+zPmv/NPvIrBPe1jLf5pi188zZNT9U XmaGgVbox4eLLwds7P++XMdZiaU4I9FQi7moOBEAqpXbC8ECAAA=
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:56:09 -0000


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

We would update the SCTP text too.

> However, I fear that would go against the ICE spec; specifically, 5245
>   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.

The text is certainly valid for the offer, but when the answer is sent it
is known whether the peers support ICE or not.

In any case, I don¹t think there should be different rules for BFCF, SCTP
etc. This should be defined in draft-ietf-mmusic-ice-sip-sdp as a generic