Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt

Jose M Recio <jose@ch3m4.com> Sat, 10 August 2019 10:22 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 5FC511200F4 for <mmusic@ietfa.amsl.com>; Sat, 10 Aug 2019 03:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=XcbQjKT/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=x/2KO3QP
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 dphKJNueThNR for <mmusic@ietfa.amsl.com>; Sat, 10 Aug 2019 03:22:30 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053BE1200DF for <mmusic@ietf.org>; Sat, 10 Aug 2019 03:22:30 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 137F821D6E; Sat, 10 Aug 2019 06:22:29 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 10 Aug 2019 06:22:29 -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=fm1; bh=O TqV7OnIffG1oMMmdF8Xui333Ay7Csx2ZaXj1fGT0Wg=; b=XcbQjKT/5FQvTtJ+A 49wvk4tZxQkpdWHcds1YLkvPAbPDE2X6dqMnMWDS5HWMzrlq6yrNWYJLZxzyQtbQ jDRjlHSN4jnsGsP4cwVjqlFQsRuVAEcZXMxgW7h/VoOcha/i7YpeC73goY/WrOSl V69Z0BWL3CVAlltFAteScDeMgrMmQ+Qwqdj7cqgbjCZRBJLOliD3sHL76rZEa2S8 eQvex7d+JeMMwt27vghkbQCC2hjrWlrh+G8o+q7zNkCn5XEpCAkJmvmapVV0k+F2 6PKXco+0NdEs3hLnP+UukFofFIu9adFFegbXU6B0OUSNR9tbhL0LnqoxMYyr1yA3 PKEEQ==
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=fm3; bh=OTqV7OnIffG1oMMmdF8Xui333Ay7Csx2ZaXj1fGT0 Wg=; b=x/2KO3QPDx0kbmnDZuHaP1S+QSEWU19sCrU7smhX3hk53Nl4OUbKTrZWa UN7cklTea9ijBpVK8ydkMsAOr2LcPBfnFt8EZiuKVywmy4hWneFWaL/0LkmUObbd olPodbAljEIQI+DQ/qGmpIt5BEEFIXo4D9weW0U2gzNUlrC145EGm2mRMtaGdmru FGAdH7lA35C7ADQ3nYA3+wPbWzVhTi/Eu1g9t2S+wOYzkPEjuDeL76F7W4eC2ctH K1Y9tm/DLf6ibMxGKPg+R1bRk17hEUgrKZkZ6L+y9eKb2SQDfEgHUT8on0FbiGxs IrAkIEoTz0Dp9dtEyrEN+pThiFuAQ==
X-ME-Sender: <xms:5JpOXX4Iqw4_Dj2Dj9K5pj9evRcbt251Y4jds5rCKKH9m7bCEtQP3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduledgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheplfhoshgv ucfoucftvggtihhouceojhhoshgvsegthhefmhegrdgtohhmqeenucfkphepudefkedrje ehrdelfedrgeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhsvgestghhfehmgedr tghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:5JpOXRLHwKGu3tvHEONeTMfyahjkxkpACvSICYDmSAWcN_ML1BKD-w> <xmx:5JpOXZfbMfT6M32g55zcv2cK_B3gtl9fhF6aYXAJd4DFvA-whzO5KA> <xmx:5JpOXccytzTYI8c4wx3fcWx-4a0r5tkO7oHTP-Cx19uto89AorXmPw> <xmx:5ZpOXRF4LXw8swvV2nuZn_hS4Quh5JgmGVfy-tjLXnVTldrVGZJUug>
Received: from [192.168.0.102] (unknown [138.75.93.43]) by mail.messagingengine.com (Postfix) with ESMTPA id C044F8005C; Sat, 10 Aug 2019 06:22:27 -0400 (EDT)
To: "Makaraju, Raju (Nokia - US/Naperville)" <raju.makaraju@nokia.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <155944930400.24112.11116803058885166596@ietfa.amsl.com> <AM0PR07MB51543ED462D47DE84633F66EFFF10@AM0PR07MB5154.eurprd07.prod.outlook.com> <7e1be36f-0a50-e16a-9ee2-ee9d00c37066@ch3m4.com> <AM0PR07MB5154F608363F2C14CA2FD5DCFFCD0@AM0PR07MB5154.eurprd07.prod.outlook.com>
From: Jose M Recio <jose@ch3m4.com>
Message-ID: <4e752c4e-422d-b80c-a0f6-21ee9d5d4b97@ch3m4.com>
Date: Sat, 10 Aug 2019 18:22:24 +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: <AM0PR07MB5154F608363F2C14CA2FD5DCFFCD0@AM0PR07MB5154.eurprd07.prod.outlook.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/LvQKTUBzm01J1Nu3UCII33Yb2gk>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt
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: Sat, 10 Aug 2019 10:22:32 -0000

I believe both changes suggested below are addressed in new -12 draft.

I have left out describing RCS specific behavior.


On 13/07/19 20:23, Makaraju, Raju (Nokia - US/Naperville) wrote:
>> [JM] Draft covers either direct connection to an endpoint or direct connection to a gateway. As middleboxes are out of scope in the connection using >data channel, then CEMA is out of scope. This short explanation currently appears as justification for saying that CEMA is out of scope. I can remove >the explanation and just state that CEMA is out of scope.
> [Raju] I agree with that.
>
>> For example, if the GW is implemented on an SBC, it can use CEMA towars the inside network, using a non-dc transport. But not towards endpoints
>> using data channel transport.
> [Raju] Let's please make this clear in the draft.
>
>> [JM] I agree for RCS should be like that. Would mandating this restrict applicability for other applications?
> [Raju] I agree that such design limitation should only be for RCS (self-imposed), but not for other applications.
>
> Thanks
> Raju
>
> -----Original Message-----
> From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Jose M Recio
> Sent: Tuesday, July 9, 2019 8:23 AM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt
>
>
> On 9/7/19 10:57 AM, Makaraju, Raju (Nokia - US/Naperville) wrote:
>> Do we need to make any further clarifications for the references to CEMA?
>> Section 5.1.1.2 has a sentence that is a little awkward, but seems to be saying the CEMA is out of scope.
> [JM] Draft covers either direct connection to an endpoint or direct connection to a gateway. As middleboxes are out of scope in the connection using data channel, then CEMA is out of scope. This short explanation currently appears as justification for saying that CEMA is out of scope. I can remove the explanation and just state that CEMA is out of scope.
>
>> But in section 6 for gateway function it mentions CEMA can be used.
> [JM] Draft supports gateways providing transport level interworking between MSRP endpoints using different transport protocols. CEMA can't be used towards the endpoints using data channel transport, but the GW could use CEMA to interwork with endpoints using other protocols.
>
> For example, if the GW is implemented on an SBC, it can use CEMA towars the inside network, using a non-dc transport. But not towards endpoints using data channel transport.
>
>> My understanding is I think section 6 suggests to use CEMA equivalent procedures without CEMA attributes!
> [JM] GW can use CEMA with endpoints using non-dc transports. This can be removed, but I think it would make the GW transport interwork option too restrictive. The B2BUA GW would not be affected.
>
>> Also, in section 6 should we add a further statement that the gateway assumes one MSRP data channel instance and one sub-protocol per SIP dialog as RCS mandates that a single SIP session/dialog has only one MSRP m= line?
>>
> [JM] I agree for RCS should be like that. Would mandating this restrict applicability for other applications?
>
>> Thanks
>> Raju
>>
>>
>> -----Original Message-----
>> From: mmusic <mmusic-bounces@ietf.org> On Behalf Of
>> internet-drafts@ietf.org
>> Sent: Saturday, June 1, 2019 11:22 PM
>> To: i-d-announce@ietf.org
>> Cc: mmusic@ietf.org
>> Subject: [MMUSIC] I-D Action:
>> draft-ietf-mmusic-msrp-usage-data-channel-11.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.
>>
>>           Title           : MSRP over Data Channels
>>           Authors         : Keith Drage
>>                             Maridi R. Makaraju (Raju)
>>                             Juergen Stoetzer-Bradler
>>                             Richard Ejzak
>>                             Jerome Marcon
>>                             Jose M. Recio
>> 	Filename        : draft-ietf-mmusic-msrp-usage-data-channel-11.txt
>> 	Pages           : 19
>> 	Date            : 2019-06-01
>>
>> Abstract:
>>      This document specifies how the Message Session Relay Protocol (MSRP)
>>      can be instantiated as a data channel sub-protocol, using the SDP
>>      offer/answer exchange-based generic data channel negotiation
>>      framework.  Two network configurations are documented: a WebRTC end-
>>      to-end configuration (connecting two MSRP over data channel
>>      endpoints), and a gateway configuration (connecting an MSRP over data
>>      channel endpoint with an MSRP over TCP or TLS endpoint).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-cha
>> nnel/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-
>> 11
>> https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-dat
>> a-channel-11
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-ch
>> annel-11
>>
>>
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic