Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

Jose M Recio <jose@ch3m4.com> Sun, 17 May 2020 14:52 UTC

Return-Path: <jose@ch3m4.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B973A079B for <mmusic@ietfa.amsl.com>; Sun, 17 May 2020 07:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ch3m4.com header.b=nKk5Xeo1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WwdOOMiK
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 LfTntlYIYI_z for <mmusic@ietfa.amsl.com>; Sun, 17 May 2020 07:52:38 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ECD3A076C for <mmusic@ietf.org>; Sun, 17 May 2020 07:52:38 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7019D5C00AE for <mmusic@ietf.org>; Sun, 17 May 2020 10:52:37 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 17 May 2020 10:52:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ch3m4.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=C KL+dpjP95b2oX13696VbPQYgb4dE/HdE9BZWM1jzqM=; b=nKk5Xeo1RZ/O4SaIA LALZe9fuS59G9kOvj4x+NCrk30siGDIa542xpEDvkUPaGkrOgw5t/k2DRVEIfDqu CyG4khdMddHFNh4zdXwkypD9/4GXwtl8zEQ7ub2kwBBbdyeijgiZtjhfumVpvN81 WCocYAB5NBiJkL9TEj57UqHYw2MLvxDBJmuxqIEyM6+OtXwyFG0Dw4a/PKxdXyf9 5BLGiSBC59Q4QfQPj5NijU3Ktz0TfQFkiujtIInWtdybDlnO9oeLs7+pZOJKE/lM bhPjk+f+345ce40ibU6H6Y04Rz9j/y08JuHPnRJbd1lKc61EKVmsmAYjiofBskx/ tPq5g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=CKL+dpjP95b2oX13696VbPQYgb4dE/HdE9BZWM1jz qM=; b=WwdOOMiKdmwgyo3UHlt1zswS9mTK9iETL5uhyuLPrl2Y92tuZEPazu5EG AUE4UrX0pFcyUzgmhGS4wpj6OJLDBpFWPf+8ygEzAUtyYr/4G3GWbWsOORqpkbCu MIIa7OBK4ydHnJkJO1LF9RCBkQZHMkUUX9cAc+G/tD1mDCLtsLThwts5p3oZZuFD yBtz9Q4QvZTmPRA+iUc+t9PYecxXLSxt23ysrCTIkkdQMXufSkifHr42+5HoqSEm IFkwp+mNwcfq/JX0VfoxbTe3M3H9PMklLuPRhg0cnUcpfkuGcQmPtyYzUr1KG2P0 WHwxua6+63OgVTFtJXbtXCufcpMNg==
X-ME-Sender: <xms:tU_BXni4BfX0FyOLhJSTPFyUj7vYdEvHSXBV1lKTrQ1-isT-k1-lHA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtfedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtje ertddtfeejnecuhfhrohhmpeflohhsvgcuofcutfgvtghiohcuoehjohhsvgestghhfehm gedrtghomheqnecuggftrfgrthhtvghrnhephfefheeihfdtheeludduueehvedtfeehje dvgfevffeggfevleffvdegfeeivdelnecukfhppedufeekrdejhedrvdduiedrgedtnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhoshgvse gthhefmhegrdgtohhm
X-ME-Proxy: <xmx:tU_BXkB3wd13XApBK1XyElpAwyNYYHXfvksZ97wttvKjbePu7xcMvw> <xmx:tU_BXnGe46I5nn4A9_1Q05_S3YONPmnOFRv-PRoWhN40NIja3ew4eQ> <xmx:tU_BXkRoUy6Ub-HmGFt9hoam3b4B7mGOAJXVN5XAbIcnID8FdoB-Bg> <xmx:tU_BXkjTF5rt5ScwVksp7RbNtdr5lMYQa2s2xhv_v9na6PsFoPK5Pg>
Received: from [192.168.0.102] (unknown [138.75.216.40]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F6CB328005A for <mmusic@ietf.org>; Sun, 17 May 2020 10:52:36 -0400 (EDT)
To: mmusic@ietf.org
References: <HE1PR07MB4426ADA1E4B1D696A48BA9A98DA40@HE1PR07MB4426.eurprd07.prod.outlook.com> <2F549E6E-1250-426F-8602-99CB44C84365@ericsson.com> <ef5b4ef8-4063-e38e-d300-185a933cc3dc@ch3m4.com> <AM7PR07MB7012D222A4AF5FD13FCC8C3793A00@AM7PR07MB7012.eurprd07.prod.outlook.com> <a3210a85-e69d-2bfc-a802-7649c70a6534@ch3m4.com> <60ab60db-f81a-904a-0481-935fa3156a9e@ch3m4.com> <80F9E944-16A1-4D14-8691-181A6089B4D1@ericsson.com> <822e1c54-77fd-bf15-1139-94a8e08442aa@alum.mit.edu> <F8C86ECB-9489-40AD-8BA0-CF89EC370CF2@ericsson.com> <308616ac-cd24-341e-be31-4b348d803889@alum.mit.edu> <E3EB3037-335E-4121-AA72-230B7353CEDF@ericsson.com> <668DE0D3-8E9E-4137-87DC-620858F05DA5@ericsson.com> <43071726-f305-a620-6529-db7d42752959@alum.mit.edu> <6771CBB5-F636-4411-B4BB-3A88315F2419@ericsson.com> <936f3801-80ab-c2e3-8729-aaaaff3a4954@alum.mit.edu> <8EB2E029-0DB3-499D-8F16-04117562C75F@ericsson.com> <d24a406c-7e4e-38cf-4f32-b8fb9f877b03@alum.mit.edu> <9374331B-84BD-4FE0-95DB-527447577E3B@ericsson.com>
From: Jose M Recio <jose@ch3m4.com>
Message-ID: <1c74399c-31dc-2e89-95d6-e30543d2cb43@ch3m4.com>
Date: Sun, 17 May 2020 22:52:28 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <9374331B-84BD-4FE0-95DB-527447577E3B@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/4FDRkKNkIjKp_KY8m8h7HB3szoE>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 May 2020 14:52:41 -0000


On 16/05/20 01:46, Christer Holmberg wrote:
>      > The problem is that there are multiple ways to set up a chat session
>      > under sip. This is much like the old problem of whether to IPv4 or IPv6
>      > in a c= line when you could do both. It took ICE to solve *that* problem
>      > in an acceptable way. AFAICT it isn't solved for chat. (The only likely
>      > solution that comes to mind is capability negotiation. But hardly
>      > anybody implements that do they?)
>      >
>      > I don't think it is necessary to solve it in this draft. But it would be
>      > good to at least acknowledge the problem.
>
>      This draft does *not* cover how you establish the SCTP association, and how you choose between IPv4, IPv6 etc for that association. There is a separate draft for that.
>
>      This draft does *not* even cover the generic procedures for negotiation a data channel. There is a separate draft for that.
>
>      This draft only describes the specifics associated with negotiation a data channel for MSRP usage.
I believe part of the confusion is that using data channels, transport 
negotiation and MSRP negotiation are not as tightly related as with 
other transports.

Given an example with the following sequence of steps on a web-based 
user UI:
- Alice wants to chat with Bob, opens a web page, logs in, selects Bob 
in an application-based address book, writes "Hello" and clicks Send

What this triggers, assuming that a) there is no pre-existing WebRTC 
PeerConnection between Alice and Bob; and b) session is established 
directly between Alice and Bob, i.e., no MSRP data channel gateway is used:
1. Alice and Bob setup a WebRTC PeerConnection that includes a SCTP 
association. An out-of-band signaling channel, provided by the web 
application, is used to exchange the messages required for the negotiation
2. WebRTC PeerConnection and SCTP association are established. As part 
of that, Alice and Bob web endpoints have found ICE candidates through 
which communicate
3. MSRP data channel is negotiated according to this draft. It will be 
instantiated as a new stream over the existing SCTP association, so the 
underlying transport (SCTP association, DTLS, ICE) is already setup, in 
advance. As this draft builds on mmusic-data-channel-sdpneg, an 
out-of-band signalling protocol is needed to exchange the SDPs, 
tipycally the same used to establish the WebRTC PeerConnection, provided 
by the web application.
3.1. Alice web endpoint fills up the SDP used to negotiate a MSRP data 
channel over the already existing SCTP association, in particular:
3.1.1 IP address and port for m= and c= lines are obtained from the 
appropriate ICE candidate in the WebRTC PeerConnection
3.1.2 domain part of the MSRP URI are obtained from application policy, 
configuration, or address book
3.2. Bob receives the MSRP data channel SDP offer from Alice, fills up 
the response also using the IP address and port from the ICE candiate in 
the WebRTC PeerConnection for the m= and c= lines, and so on
3.3. MSRP data channel negotiation succeeds, and MSRP session is open
4. Alice MSRP stack sends "Hello" over the negotiated MSRP data channel 
and message is received by Bob MSRP stack

This is not so complicated in practice. For browser endpoints, steps 1 
and 2 are hidden behind the W3C WebRTC JS API. Steps 3 and 4 can reuse 
existing MSRP stacks, unchanged for the most part, and driven by 
negotiation code