Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute

Christer Holmberg <> Tue, 23 April 2019 05:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FD0512004D for <>; Mon, 22 Apr 2019 22:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZiYdReyGvgmf for <>; Mon, 22 Apr 2019 22:56:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE2D6120223 for <>; Mon, 22 Apr 2019 22:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P05/nxcuTK3NtUNbHuTcwhW5FgzIjexM6AAH/JCHHYU=; b=kLhLw9ZxPDpC+W+5WRLBOiXziGlPFrtCo3SdMBJJcij7crf1F+vt7fY0SwnirGSv2FBfDvVPB1WV5mVnRqHy79N5wZqPB9iL/DRLsugkedESLXBkuAEU5T17o6wqHqUy2SPx5oI8IPpbpTPfMaIktxEfZeBdQ2HLpoUx4f0Cobs=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.9; Tue, 23 Apr 2019 05:56:45 +0000
Received: from ([fe80::747a:900a:3053:2184]) by ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Tue, 23 Apr 2019 05:56:45 +0000
From: Christer Holmberg <>
To: RIchard Ejzak <>, Jose M Recio <>, "" <>
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
Thread-Index: AQHU+PdOAq7bCRTG/EWrEZLX3OSx16ZIK12AgACp4oD//6bNAIAA9vmA
Date: Tue, 23 Apr 2019 05:56:45 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 495214d5-784c-4d85-4681-08d6c7b077e2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4282;
x-ms-traffictypediagnostic: HE1PR07MB4282:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0016DEFF96
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(346002)(136003)(366004)(189003)(199004)(64756008)(66556008)(66446008)(316002)(36756003)(110136005)(5660300002)(6486002)(58126008)(6436002)(2906002)(6506007)(73956011)(7736002)(256004)(305945005)(6116002)(3846002)(76176011)(86362001)(53546011)(102836004)(6512007)(6306002)(99286004)(66476007)(68736007)(93886005)(66946007)(186003)(81156014)(82746002)(76116006)(6246003)(97736004)(26005)(476003)(66066001)(25786009)(44832011)(8936002)(81166006)(14454004)(486006)(83716004)(2501003)(966005)(229853002)(33656002)(11346002)(478600001)(446003)(53936002)(71190400001)(8676002)(71200400001)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4282;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nGZmXTFFk/gMKMbZYSNo06sd7AhJyyiqwbkAoac4SaeKSwYmIinxfV4MQgUutPC7nFN5FSS0SfqcUtpGXF9O3MuS3xwJvyLkkeLzArjWjvDvS/miQ/hPnMeTYn8urhe1GoZ3alybEftmscHGjoFF2fx7G+tZi2QEerTVzL1FZQvKMNF07etqLYhmbJtqDLVvGFSJpiE93en+kKhmKOj8+cmM0LQt0gOjE807rdOrs0gcpuIiPIyvmqxQEBh2h9CbhZlY2L9nY60ZEnfl/VLdQ3YUc96mA/QnhvDDhK00m/Y0Hm0+CFlG/3vP6JAkMI+lUYqH4ufoNglQ10W+C3o7Ne0r9W9r1CBm4fbimf8Pt5LTVo8jj5+C4h0SA+Wd/xsxBCoT7Nsm9NCRiVMsoeyUsaqvtj4pi1bE9n5wjfkIsVk=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 495214d5-784c-4d85-4681-08d6c7b077e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 05:56:45.7592 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4282
Archived-At: <>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Apr 2019 05:56:53 -0000

Hi Richard,

Long time no see - hopefully you are fine __
>    Since I wrote the original text, I should probably reply...
>    I agree with Christer that the CEMA attribute is not needed.  It was 
>    originally included to make it clear that the path attribute could not 
>    be used to establish the data channel.  But this is obvious for this new 
>    type of transport.  RFC7977 (WebSocket transport for MSRP) handles this 
>    very nicely by using an .invalid domain name in the path attribute.  I 
>    suggest adopting this approach for dc.
My point is that the path attribute is not used for establishing the transport to begin with: the SDP c/m= lines are used for that.

There aren't even going to be any "real" path attributes - they will be encapsulated within dcsa attributes.



    On 4/22/19 3:32 PM, Christer Holmberg wrote:
    > Hi,
    >>> First, in general, I don't want attributes to be "assumed". If an extension (CEMA in this case) mandates an attribute to be included, it shall be included.
    >>     I can rewrite so the attribute is always there. I think the intention is
    >>     to make using legacy MSRP stacks (that may not be supporting CEMA)
    >>     transparently use data transport.
    > I think we first need to think whether it is needed.
    > Keep in mind (and that should probably better described in the document) that the normal MSRP routing procedures don't apply. The MSRP messages will be routed in the data channel, which is established between the SIP peers (or whatever signaling protocol is used). I guess proxies and application servers can look at the top-most path attribute, but that is not going to be the primary routing input. I don't think the draft says anything about that - it just seems to assume that the data channel will end up in the intended MSRP peer.
    > If there then is a gateway that forwards the MSRP messages towards a legacy MSRP endpoint it may use CEMA, but that's a separate thing.
    >>> Second, I am not sure I understand the text on "ensuring that the data channel is not established using the path attribute". How would you
    >>> establish a data channel using the path attribute?
    >>     The way I understand this is "make sure path attribute is ignored for
    >>     setting up the transport".
    >>     This is also connected to CEMA being assumed. I believe the overall
    >>     intention of the paragraph is that transport establishment must always
    >>     use CEMA, even if the attribute is not there, and path should never be
    >>     used. So, for data channel transport, CEMA is not optional, as RFC6714
    >>     says. Maybe a rewriting making this more clear is needed.
    > But the transport establishment of a data channel does not use CEMA.
    > Maybe there is a reason for all of this (it's such a long time since I looked at it), but it needs to be clear why we mandate certain things.
    > Regards,
    > Christer
    >      _______________________________________________
    >      mmusic mailing list
    > _______________________________________________
    > mmusic mailing list