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

Alan Ford <> Wed, 19 October 2016 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41DA012955B for <>; Wed, 19 Oct 2016 05:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, 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 lE7eLAlMBdNj for <>; Wed, 19 Oct 2016 05:58:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7128A1293DF for <>; Wed, 19 Oct 2016 05:58:57 -0700 (PDT)
Received: by with SMTP id m5so17833172qtb.3 for <>; Wed, 19 Oct 2016 05:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/KaBr1wgRndvnkVnVyix36pjTowneA6OjbvenuyyHv0=; b=KUM5j4Va7fQI8txjvefHCZ8pBkqIzXur7h6FWIPS3finIT5EttG9hO/EqElST/Gii7 gYrnfN1tFOXx9TD+97ZMNMj1tcR3aEAfmq73rjDrt8sFURCKzV6L4KPGRsVGn/ZbnJfH 82pjeEE0hc4pjI09T0pCpAqLyt87pX3dBjffYtAyOoba83p2yo0t+DEszoTKpdOCXkok BiLDH914CQ7hYpMMhTwNXQo2ysotUZN3QA8XzYNRSj10J6/IVigOhfIUwCCwMGa+9acJ Jc555Tr0SHlbpxD/oWu1w0+dnwQTFdZVtsY4sqskgrD4nnfQMPa9vBSeVhOT0N/vxqxk urCA==
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 :content-transfer-encoding:message-id:references:to; bh=/KaBr1wgRndvnkVnVyix36pjTowneA6OjbvenuyyHv0=; b=HMlB8n/P5yR7+U+xGMfXhKkYBvj7oqcnzOTmgfJYv6YHhauHs016Z4yHbvdz09dEgG N4nolJx8XB9zHahOKzUOnqxBp32wWAGIrgnEzjhvYLdXUc2+kMRnzwxkCfT2EYrwQiyg aG5kFpVS7qEIhkngWzL+6gNRxNJwZIHQKifR86gawY0x1lpVUD5YH2wE+Y4oX7Cz3MIr 31hwISlzGTpZMXqjvWof/INXUxc0HzHvnHae3a6TX8zaJGGBiSmbbz9CWWOXagdSpcLf OhMs29f9Tp5oceEXZs9cSmEI9b27aC/EqtnfjyccnxgUfur3AyeQzICW6Y+tH4B/j2h3 8dYg==
X-Gm-Message-State: AA6/9Rnbi4EmPrS2y125E83Rpq+JJcPYzekHr+l+1bS60r1BFy8eAZRCIM/8jAF9Fx+lhg==
X-Received: by with SMTP id 201mr2516704wmw.128.1476881936328; Wed, 19 Oct 2016 05:58:56 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id jb2sm26285717wjb.44.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 19 Oct 2016 05:58:55 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Wed, 19 Oct 2016 13:58:54 +0100
Content-Transfer-Encoding: quoted-printable
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: Wed, 19 Oct 2016 12:58:59 -0000

> On 19 Oct 2016, at 13:08, Christer Holmberg <> wrote:
> Hi,
>>>> 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.
>> We would update the SCTP text too.
>>> 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.
>> 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
>> rule.
> I was thinking a little more about this: maybe indicating a transport in
> the m- line that you don’t support isn’t a very good idea - even if it
> won’t be used with ICE.
> Maybe it would be better to say that the m- line shall contain a transport
> that the peer is “most likely” to support. In case of BFCP, I guess
> neither TCP or UDP is mandatory to support, but in other cases there is
> often a mandatory transport.

That still implies they need to support the transport in question, so it’s not dissimilar to the SCTP text about default candidate.

Question really is - and this is probably something more for icebis than here - would it be legitimate to relax that requirement in the text I quoted earlier for the answerer? (The way it is written in 5245 suggests it applies to both offerer and answerer). I don’t see it being a problem for endpoints, but I’d be worried some proxies may expect behaviour here which isn’t true.