IETF Logo Mail Archive

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

Roman Shpount <roman@telurix.com> Thu, 01 December 2016 20:46 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 81EB312996F for <bfcpbis@ietfa.amsl.com>; Thu, 1 Dec 2016 12:46:42 -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 MLU-YBepfWBi for <bfcpbis@ietfa.amsl.com>; Thu, 1 Dec 2016 12:46:39 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 AB4D5129E14 for <bfcpbis@ietf.org>; Thu, 1 Dec 2016 12:34:55 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id c47so232780267qtc.2 for <bfcpbis@ietf.org>; Thu, 01 Dec 2016 12:34:55 -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=TCCgDbu0ojnFkIHhljByHlnUE10lV6ZCF+ak0o37dDc=; b=bBgnIIal4F3XYYjzoUWMluM+wUaJ0lrex8E5YoOl0c7RJXv+lIZtTr1GqiVET/ZSDi q/COFsfLTR0GAXiGg/CCY5sqMCTSmWwmLd2p20ZOTfbTXYWeKt7IK/T/yZze2fzQxOK2 0lcTYxIX5JXxrTzQpLEQYJIU3lJEZb0kZz34EXnMOmHOxzsuzl+aBR56TAqg1A+qK2o8 4VkMQNLKAz9u9Ft8lsOs8SMuV7axhm+zTd0+ktvE1KulFTkwOEwy6058yMvGPZuuThvK Ii4b0nVXDmWW2lpP3bg3Y3vyLxMmrzQZYZpBnpynEebJ7lY6rb+I42aZ4EhkPrjp0N9S /BFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TCCgDbu0ojnFkIHhljByHlnUE10lV6ZCF+ak0o37dDc=; b=I+nePvZy8XxYSp56/2XHxpvRO2CYUKbT3cMtfKcZ3l36nod7gtIUrtub1GGuBvDHIw 7xjdktkV+AyMIghDCcnlOu2DYLHoUaSV9e+vqraTTGeBnvyYF0iqscWIeIrPdBjA424C P2Fg0BqBquVkeTGGKjULPTVVhx6DSEpLK4x4y7aqa9HCA/j+/zmGN0xzaFSvHecYrldZ 5lMDPn8kwxA+c+lh3MlWgCmkOWpMugTvftLlVg11iSfF/lNjq7e/B39yEYEMPG/hVXOH YPscmEe28225jvHPwzkalWml9fAL7TL77ak0RoZcS8D2CSV+yDYu/toTCgCdZD4UD7yy WvIQ==
X-Gm-Message-State: AKaTC02xzlyeEiSpl24b8QW4zwe0Ej0Lx0pxPdPLelOnJmEADWRt3grEFv3aLH0Dh+Sh7w==
X-Received: by 10.200.33.252 with SMTP id 57mr39489754qtz.255.1480624494742; Thu, 01 Dec 2016 12:34:54 -0800 (PST)
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com. [209.85.220.177]) by smtp.gmail.com with ESMTPSA id q65sm962569qki.20.2016.12.01.12.34.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 12:34:54 -0800 (PST)
Received: by mail-qk0-f177.google.com with SMTP id q130so70487132qke.1; Thu, 01 Dec 2016 12:34:54 -0800 (PST)
X-Received: by 10.55.36.149 with SMTP id k21mr34828241qkk.252.1480624493868; Thu, 01 Dec 2016 12:34:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.145.205 with HTTP; Thu, 1 Dec 2016 12:34:53 -0800 (PST)
In-Reply-To: <16B5D8FF-F132-4B09-84D6-AE964CA7858D@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>
From: Roman Shpount <roman@telurix.com>
Date: Thu, 01 Dec 2016 15:34:53 -0500
X-Gmail-Original-Message-ID: <CAD5OKxsAHCykObDwZ2_n+XH7brkCz9yLbZFr9-MCQwzkn4uUmg@mail.gmail.com>
Message-ID: <CAD5OKxsAHCykObDwZ2_n+XH7brkCz9yLbZFr9-MCQwzkn4uUmg@mail.gmail.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Content-Type: multipart/alternative; boundary="001a114517f400f8ac05429ec1f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/zwM6P091diN30VFIBUenufdv-Z8>
Cc: "ice@ietf.org" <ice@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, Alan Ford <alan.ford@gmail.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: Thu, 01 Dec 2016 20:46:42 -0000

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>, "bfcpbis@ietf.org" <
> bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <
> mmusic@ietf.org>, 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
>
>
>
>

v2.23.0 | Report a Bug | By Email