IETF Logo Mail Archive

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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Sat, 03 December 2016 00:01 UTC

Return-Path: <eckelcu@cisco.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 66676129485; Fri, 2 Dec 2016 16:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level:
X-Spam-Status: No, score=-17.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2GbbwcPA_J-k; Fri, 2 Dec 2016 16:01:45 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8B1129483; Fri, 2 Dec 2016 16:01:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18418; q=dns/txt; s=iport; t=1480723304; x=1481932904; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/XPR/wJKcpX7ZyXOx/XMrKN3NL2fjsS/mbU+SPTZC8A=; b=jAS4IoMHIgL8f5QJgOSbwAZNGDLPIPjqdf98cvILVOVQjET2jZ42BxN1 GtS+V+qkWGLP7hn+29N9nTaod7sHLfQwOA0cfMfOb4WxL5/wiEqUSduCY j1StBuy6YDJ0HehnKhDD6nGYG0YL+OSyTDzU0BojtrkHTkp7sIyaN/Ngg 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A3AQAUC0JY/4gNJK1cGQEBAQEBAQEBAQEBBwEBAQEBgnNFAQEBAQEfWoEGB41AlwuHc4dngxOCD4IIKYV5AhqCAz8UAQIBAQEBAQEBYiiEaAEBAQQjVhACAQgRAwECKAMCAgIfERQJCAIEDgUbiDoDFw6sUYIpL4cUDYN2AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWIOwiCVoJIgiEWgk4tgjAFlHuFNDUBhkqGa4NekDmJTIQ0hAwBHzeBGTEBAYUicgGHcIENAQEB
X-IronPort-AV: E=Sophos;i="5.33,289,1477958400"; d="scan'208,217";a="181748152"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2016 00:01:21 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uB301LdK018194 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 3 Dec 2016 00:01:21 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Dec 2016 18:01:20 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 2 Dec 2016 18:01:20 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
Thread-Index: AQHSQFwSEnIqX9JFq0OJWjTO/qYWEKDczAiAgAAW2ICAAXMeAIAR2UqAgACUI4CAArojgIAAiwyAgAFF5oA=
Date: Sat, 03 Dec 2016 00:01:20 +0000
Message-ID: <64E8A5CF-89ED-4673-AF23-2C960395C3EF@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>
In-Reply-To: <CAD5OKxsAHCykObDwZ2_n+XH7brkCz9yLbZFr9-MCQwzkn4uUmg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: multipart/alternative; boundary="_000_64E8A5CF89ED4673AF232C960395C3EFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/KKO7Debwndl0DgQsX_SG9HK0iUw>
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: Sat, 03 Dec 2016 00:01:47 -0000

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>, "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

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<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

v2.23.0 | Report a Bug | By Email