Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

Alan Ford <alan.ford@gmail.com> Tue, 03 January 2017 23:23 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 6505C1296D2; Tue, 3 Jan 2017 15:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 e1W2VjBQ6l5K; Tue, 3 Jan 2017 15:23:39 -0800 (PST)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 1AD26129489; Tue, 3 Jan 2017 15:23:39 -0800 (PST)
Received: by mail-wm0-x242.google.com with SMTP id c85so50636396wmi.1; Tue, 03 Jan 2017 15:23:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AkHARHZY+XfXLQV3sHh78JQyhU1tfmZeiNhVSbXkLnc=; b=R8b7nx3h9sjcj8vW/+hkDlOT6Q+PMl5eew0oKWnCYFX2X62ZpULrNBXW70XYsT6En8 rLTbhkWDo05p4yKyJWMlyTm8svY8B05hipzFtfEqYiXt5+EHihhxB1dyAAPKYqKqS5cR araqhUnU/xO6Ik91bgCr0Ck0D2i6O1j8fW/QNhlGebIIjmgUQfrM72cbtrVcN4Y6donc /ZqHAx1grpnNnRCfwEOrXPvUyZkmbtCf1tQHVeV5chswBqjrJcR+jOlZg8Y9H3FaktOP YCJaJd9J2GQwYJlmSqkqWfnx62VENZE6OH2Acvm6+Jlo1NHP3vkfRhB9Wp9AKNFvtvvb T22g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AkHARHZY+XfXLQV3sHh78JQyhU1tfmZeiNhVSbXkLnc=; b=ggq2jWtHqeJQ55QzYpK50DCWqzYlh/Pg1VR14VXR3kS3LmS5fRgeL2QUxItuSjSWVp q//nyHJCtWBvDfogYSyraleCAifzEd/LlmMUCSHnboZsv24skVONxb32ldL5gW0BYU9I HC74Sz+x4wmTCDGbMl0DuJopN4UiSrfQw2SkQdnxC3wnrHcQ5dD/zsBj3RC4kkTISXyu Pszt7KcGI8Etby0x3ZFiqmKVq4u8uKKWeycXxJqDir5upXF3gxduakZJi9sFSqjpBGA7 EsyGQA7cEhcXCdkl49YxSmSA09nN41buyBzjVEHU8zjOXZEN90ouvqKvsy1i249vdYEX ek/A==
X-Gm-Message-State: AIkVDXJfyrrdfWKKoy8TJtjJcId+3xOi7iuPB6xM8FZfMVosOEX15KFpfvNY2nuPe43tGw==
X-Received: by 10.28.9.80 with SMTP id 77mr56746324wmj.68.1483485817526; Tue, 03 Jan 2017 15:23:37 -0800 (PST)
Received: from alans-mbp.lan ([37.152.254.113]) by smtp.gmail.com with ESMTPSA id u78sm91845081wma.11.2017.01.03.15.23.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 15:23:36 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <CAD5OKxsAKOw4K_2rC-hQXHtZLQ2=8mv7hzW_mtpemuKyV+-+rw@mail.gmail.com>
Date: Tue, 3 Jan 2017 23:23:35 +0000
Message-Id: <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com>
References: <CAD5OKxuhvCz82+7JK8QrArtrYcjV9+b7vWMpWRnCjNbrL++srA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <CAD5OKxu15YgYO0xyWMYXv7VTAVVQ71iJhH_txt31BV0CvCSjqg@mail.gmail.com> <F96AC385-2721-4652-98F5-1BF92F06214A@gmail.com> <D0210B5A-138A-4C86-8D14-6E1FEC011E33@cisco.com> <CAD5OKxuzpVRsR0cMeUyhe35sA9W6bL=p1=0RUpTqwpQDyinwDA@mail.gmail.com> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <CAD5OKxsAHCykObDwZ2_n+XH7brkCz9yLbZFr9-MCQwzkn4uUmg@mail.gmail.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> <CAD5OKxsAKOw4K_2rC-hQXHtZLQ2=8mv7hzW_mtpemuKyV+-+rw@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/Uhd46R59ee3OoDyK9C3ekc0Cj18>
Cc: "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Charles Eckel \(eckelcu\)" <eckelcu@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
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: Tue, 03 Jan 2017 23:23:42 -0000

Roman,

Do any of those work for having both tcp and udp ICE candidates? I assume any with ICE (+ 4571 framing) would be acceptable for that case?

Ideally we need to support the case where an answer’s m-line protocol does not match any of the candidates, so that an answer could only support TCP (say) when the offerer supported both (and used a UDP m-line protocol). If Christer’s proposed change which permitted an answer not to match the m-line protocol in the ICE candidates was accepted, that would resolve this case. Do you see any problems here?

Regards,
Alan

> On 3 Jan 2017, at 20:08, Roman Shpount <roman@telurix.com> wrote:
> 
> Charles,
> 
> I do not think not supporting ICE tcp candidates will quite work since it will reduce the usability considerably. The simplest way to move forward is to define a different transport tag for BFCP  with RFC 4571 over TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this looks strange and I am open to other suggestions, such as calling all packet based protocols DBFCP). 
> 
> In general what I am proposing is:
> 
> TCP/BFCP -- existing BFCP over TCP
> TLS/BFCP -- exisitng BFCP over TLS
> UDP/BFCP -- BFCP over UDP or ICE udp candidates
> TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp candidates
> UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates
> TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates
> 
> Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other protocols can work with NAT or ICE using normal ICE procedures.
> 
> If we call all packet based protocols DBFCP then transport tags will be:
> 
> TCP/BFCP -- existing BFCP over TCP
> TLS/BFCP -- exisitng BFCP over TLS
> UDP/DBFCP -- DBFCP over UDP or ICE udp candidates
> TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp candidates
> UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates
> TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates
> 
> Since BFCP over UDP (or other packet based protocols) is quite different due to timers and transmission restrictions, it can have a different transport tag and even be defined in a separate RFC.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com <mailto:eckelcu@cisco.com>> wrote:
> Crickets…
> 
> If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best to state that as of this rev of the BFCP spec, BFCP with TCP candidates is not defined. Future updates to the spec may define this usage.
> 
>  
> 
> Cheers,
> 
> Charles
> 
>  
> 
> From: mmusic <mmusic-bounces@ietf.org <mailto:mmusic-bounces@ietf.org>> on behalf of Charles Eckel <eckelcu@cisco.com <mailto:eckelcu@cisco.com>>
> Date: Friday, December 2, 2016 at 4:01 PM
> To: Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>>
> Cc: "ice@ietf.org <mailto:ice@ietf.org>" <ice@ietf.org <mailto:ice@ietf.org>>, "bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>>, Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>, "mmusic@ietf.org <mailto:mmusic@ietf.org>" <mmusic@ietf.org <mailto:mmusic@ietf.org>>
> Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE
> 
>  
> 
> I have no experience with ICE with TCP candidates so hopefully others can chime in as to what they think is a workable solution.
> 
>  
> 
> Cheers,
> 
> Charles
> 
>  
> 
> From: Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>>
> Date: Thursday, December 1, 2016 at 12:34 PM
> To: Charles Eckel <eckelcu@cisco.com <mailto:eckelcu@cisco.com>>
> Cc: Alan Ford <alan.ford@gmail.com <mailto:alan.ford@gmail.com>>, "bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>>, "ice@ietf.org <mailto:ice@ietf.org>" <ice@ietf.org <mailto:ice@ietf.org>>, "mmusic@ietf.org <mailto:mmusic@ietf.org>" <mmusic@ietf.org <mailto:mmusic@ietf.org>>, Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>
> Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
> 
>  
> 
> Charles,
> 
>  
> 
> RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1 <https://tools.ietf.org/html/rfc6544#section-10.1>) says that "The framing defined in RFC 4571 <https://tools.ietf.org/html/rfc4571> MUST be used when sending media." This means the protocol used is not TCP/BFCP which is using application level framing. I believe that STUN/Media demultiplexing requirements would prevent using TCP/BFCP directly with ice tcp candidates without redesign of either ICE TCP or TCP/BFCP.
> 
>  
> 
> Furthermore there are other implied ICE requirements that I outlined before (switching between udp and tpc candidates, existence of SBC which terminate ICE only but do not support the embedded protocol) because of which ice tcp is considered unreliable transport and will require fragmentation support and re-transmit timers that are not part of TCP/BFCP.
> 
>  
> 
> Regards,
> 
> 
> 
> _____________
> Roman Shpount
> 
>  
> 
> On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com <mailto:eckelcu@cisco.com>> wrote:
> 
> Roman,
> 
>  
> 
> Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it does, but after a quick scan I am not sure why.
> 
>  
> 
> Cheers,
> 
> Charles
> 
>  
> 
> From: Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>>
> Date: Tuesday, November 29, 2016 at 10:38 AM
> To: Charles Eckel <eckelcu@cisco.com <mailto:eckelcu@cisco.com>>
> Cc: Alan Ford <alan.ford@gmail.com <mailto:alan.ford@gmail.com>>, "bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>>, "ice@ietf.org <mailto:ice@ietf.org>" <ice@ietf.org <mailto:ice@ietf.org>>, "mmusic@ietf.org <mailto:mmusic@ietf.org>" <mmusic@ietf.org <mailto:mmusic@ietf.org>>, Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>
> Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
> 
>  
> 
> On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com <mailto:eckelcu@cisco.com>> wrote:
> 
> It seems to me that the most straightforward approach would be to mandate support for BFCP over UDP when using ICE, use UDP as the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would be even better.
> 
> Thoughts?
> 
>  
> 
>  
> 
> I agree.
> 
>  
> 
> The only issue that I still have, if DTLS is not used, what protocol is used when ICE tcp candidate is selected for transport. Is this TCP/BFCP (which goes against RFC6544)  or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framing, what transport tag should be used in the re-INVITE which is sent after ICE nomination with only selected candidate? Should it be TCP/UDP/BFCP or something similar?
> 
>  
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
>  
> 
>  
> 
> 
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis