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

Alan Ford <alan.ford@gmail.com> Mon, 17 October 2016 08:10 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 D3D9312959F for <bfcpbis@ietfa.amsl.com>; Mon, 17 Oct 2016 01:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: 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 EhR4WHJ4y8nU for <bfcpbis@ietfa.amsl.com>; Mon, 17 Oct 2016 01:10:23 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 D681C1295BD for <bfcpbis@ietf.org>; Mon, 17 Oct 2016 01:10:22 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id o68so264965942qkf.3 for <bfcpbis@ietf.org>; Mon, 17 Oct 2016 01:10:22 -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: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; d=1e100.net; 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 10.194.9.230 with SMTP id d6mr8509149wjb.98.1476691821849; Mon, 17 Oct 2016 01:10:21 -0700 (PDT)
Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id n6sm4474634wjg.30.2016.10.17.01.10.20 (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 <alan.ford@gmail.com>
In-Reply-To: <D426777A.11238%christer.holmberg@ericsson.com>
Date: Mon, 17 Oct 2016 09:10:20 +0100
Message-Id: <42A8BAE9-A6C2-4112-97FC-2DAE01F9AB0D@gmail.com>
References: <9BE360E6-8462-49BC-9491-7143D476EEAD@cisco.com> <28B9D43D-FF01-4294-BCD6-93E72C0C07E1@gmail.com> <D426777A.11238%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/qielaF2FDqG0fjQUaY1ye3yfAgs>
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: Mon, 17 Oct 2016 08:10:25 -0000

Hi Christer, all,

> On 14 Oct 2016, at 09:48, Christer Holmberg <christer.holmberg@ericsson.com> 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.

Regards,
Alan