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

Alan Ford <alan.ford@gmail.com> Wed, 19 October 2016 12:58 UTC

Return-Path: <alan.ford@gmail.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DA012955B for <bfcpbis@ietfa.amsl.com>; Wed, 19 Oct 2016 05:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE7eLAlMBdNj for <bfcpbis@ietfa.amsl.com>; Wed, 19 Oct 2016 05:58:57 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7128A1293DF for <bfcpbis@ietf.org>; Wed, 19 Oct 2016 05:58:57 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id m5so17833172qtb.3 for <bfcpbis@ietf.org>; Wed, 19 Oct 2016 05:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.28.22.210 with SMTP id 201mr2516704wmw.128.1476881936328; Wed, 19 Oct 2016 05:58:56 -0700 (PDT)
Received: from [10.44.28.203] (host81-142-89-185.in-addr.btopenworld.com. [81.142.89.185]) by smtp.gmail.com with ESMTPSA id jb2sm26285717wjb.44.2016.10.19.05.58.55 (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 <alan.ford@gmail.com>
In-Reply-To: <D42D3DE9.11645%christer.holmberg@ericsson.com>
Date: Wed, 19 Oct 2016 13:58:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC53FDEE-0A52-488D-AF36-EDACE0A69232@gmail.com>
References: <9BE360E6-8462-49BC-9491-7143D476EEAD@cisco.com> <28B9D43D-FF01-4294-BCD6-93E72C0C07E1@gmail.com> <D426777A.11238%christer.holmberg@ericsson.com> <42A8BAE9-A6C2-4112-97FC-2DAE01F9AB0D@gmail.com> <D42A6D07.1138D%christer.holmberg@ericsson.com> <D42D3DE9.11645%christer.holmberg@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/rW3bU_3vVY1RkBcvwG4fmr1GgnQ>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>, Roman Shpount <roman@telurix.com>
Subject: Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2016 12:58:59 -0000

> On 19 Oct 2016, at 13:08, Christer Holmberg <christer.holmberg@ericsson.com> 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.

Regards,
Alan