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

Roman Shpount <roman@telurix.com> Tue, 03 January 2017 20:08 UTC

Return-Path: <roman@telurix.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 5B2BE129B77 for <bfcpbis@ietfa.amsl.com>; Tue, 3 Jan 2017 12:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 Nm3t13kRmZ3G for <bfcpbis@ietfa.amsl.com>; Tue, 3 Jan 2017 12:08:07 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 337E6129B70 for <bfcpbis@ietf.org>; Tue, 3 Jan 2017 12:08:07 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id u25so375658501qki.2 for <bfcpbis@ietf.org>; Tue, 03 Jan 2017 12:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7y3H8XNkvR1aeMz8bkAx3Ee0MwlRaiQOFINbX/t73r8=; b=LmqFjgGnJpEAT8293nLy+iZwrWMh6/9AtnJ3EJzHJ/CEpEA7F73DgS6q1ac1enCr9J d/omcMmi6YnB9Y6A/qRtFRIuzO8ZPbW9E48imMy/H5aMFqGcP/e+b3Pl2l0Ps3HAb8Su ONbKOomO6rn211o/OWEReNUkoeE42tVcIBdEFGEeGYGKF82lddUGcyVi0pQmxosKAD45 HOZ45Bs4HShG1QfFxHffGDqtAKqpJJ8JHcuWJglY2AO69SOjOVTUZd/5J+K3sbiEF/RN LrXYbIQyqfWSYYKaoOhiw3J2k+v3n8Bk7DgUJ0ZgqCRt7e9dW+QiQJq5i2Xu9sHEccyf PyTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7y3H8XNkvR1aeMz8bkAx3Ee0MwlRaiQOFINbX/t73r8=; b=NzRewA0Fl04FzAro7HlCRc9tz4mRdP3uINZQz9DFqL/HBsLIegXhER4UU+UoVSy4fN eQYFYYfBwtVtjyHw7pXO9vGYmUMrXhyOtelQzkOs3xoitMbo8i7Eh/eZ53fdjKCeekPt eTcMuVS8Br0yVRnuw0vCHoON4ZNsA3hCNU45wH92/oY4iiznPoFA1EXCWzfHfhik9eSS ijPILQNhtrkvoiEQA+kLGBRK6kmUww5Kt1TRt+3pukDIWL2zmWXm0XIShOO/Vq27aKwr 1DecH3jbwzYVTVW2xl9nJmxVfCpftJCt5JbVJZKwGmz3SjTE1BCaE+f8VKOJp4A419IO Sx7g==
X-Gm-Message-State: AIkVDXL9I5zfUzIAZaIBdef6GOgLLPKaeCkjNJiTNCQYDqhPrHeLQHS+jflWk1cXPoe+RQ==
X-Received: by 10.55.185.133 with SMTP id j127mr59738566qkf.39.1483474086212; Tue, 03 Jan 2017 12:08:06 -0800 (PST)
Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com. [209.85.216.169]) by smtp.gmail.com with ESMTPSA id k143sm17289079qke.37.2017.01.03.12.08.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 12:08:05 -0800 (PST)
Received: by mail-qt0-f169.google.com with SMTP id k15so233896116qtg.3; Tue, 03 Jan 2017 12:08:05 -0800 (PST)
X-Received: by 10.200.45.144 with SMTP id p16mr589450qta.141.1483474085308; Tue, 03 Jan 2017 12:08:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.136.230 with HTTP; Tue, 3 Jan 2017 12:08:04 -0800 (PST)
In-Reply-To: <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.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>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 3 Jan 2017 15:08:04 -0500
X-Gmail-Original-Message-ID: <CAD5OKxsAKOw4K_2rC-hQXHtZLQ2=8mv7hzW_mtpemuKyV+-+rw@mail.gmail.com>
Message-ID: <CAD5OKxsAKOw4K_2rC-hQXHtZLQ2=8mv7hzW_mtpemuKyV+-+rw@mail.gmail.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Content-Type: multipart/alternative; boundary=001a1140396ce390540545363931
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/WwG-bg0WHZwSsg1a3H6LnG0AES0>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "ice@ietf.org" <ice@ietf.org>
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 20:08:10 -0000

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>
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> on behalf of Charles Eckel <
> eckelcu@cisco.com>
> *Date: *Friday, December 2, 2016 at 4:01 PM
> *To: *Roman Shpount <roman@telurix.com>
> *Cc: *"ice@ietf.org" <ice@ietf.org>rg>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>rg>,
> Christer Holmberg <christer.holmberg@ericsson.com>om>, "mmusic@ietf.org" <
> 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>
> *Date: *Thursday, December 1, 2016 at 12:34 PM
> *To: *Charles Eckel <eckelcu@cisco.com>
> *Cc: *Alan Ford <alan.ford@gmail.com>om>, "bfcpbis@ietf.org" <
> bfcpbis@ietf.org>gt;, "ice@ietf.org" <ice@ietf.org>rg>, "mmusic@ietf.org" <
> mmusic@ietf.org>gt;, Christer Holmberg <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) 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>
> 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>
> *Date: *Tuesday, November 29, 2016 at 10:38 AM
> *To: *Charles Eckel <eckelcu@cisco.com>
> *Cc: *Alan Ford <alan.ford@gmail.com>om>, "bfcpbis@ietf.org" <
> bfcpbis@ietf.org>gt;, "ice@ietf.org" <ice@ietf.org>rg>, "mmusic@ietf.org" <
> mmusic@ietf.org>gt;, Christer Holmberg <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> 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
>
>
>
>
>
>