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

Christer Holmberg <> Mon, 22 April 2019 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7B8912038A for <>; Mon, 22 Apr 2019 13:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 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] 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 YgyQaTJ3JCZZ for <>; Mon, 22 Apr 2019 13:32:07 -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 27B1912004B for <>; Mon, 22 Apr 2019 13:32:06 -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=KbBslIb1je8tbwDG7N8CUYk8yU6lD9atv+FQJUaN2h4=; b=P1RSrHI8EnIQg1Kio4DPnTLvjDflI2OSJjYmjXkEkflYvTFm/H2rv2biiK5+p3gCwY5LigtdWX7pllirogYhy+o08U9mPwLlnMe30aRBiZCe6uqqQILK5KmU5zVa8qoXkSelDtQCEWbQAmMrJJAzmx69aVz6mk9aiPk3VYCReO8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.11; Mon, 22 Apr 2019 20:32:04 +0000
Received: from ([fe80::747a:900a:3053:2184]) by ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Mon, 22 Apr 2019 20:32:04 +0000
From: Christer Holmberg <>
To: 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/EWrEZLX3OSx16ZIK12AgACp4oA=
Date: Mon, 22 Apr 2019 20:32:03 +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: b7563cfa-6385-49cc-525d-08d6c76194c9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4234;
x-ms-traffictypediagnostic: HE1PR07MB4234:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00159D1518
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(83716004)(71190400001)(71200400001)(81166006)(8936002)(256004)(14454004)(36756003)(8676002)(33656002)(6506007)(44832011)(25786009)(82746002)(2616005)(2501003)(81156014)(478600001)(486006)(966005)(476003)(11346002)(446003)(6116002)(3846002)(2906002)(26005)(305945005)(7736002)(76176011)(186003)(66066001)(58126008)(6246003)(99286004)(5660300002)(86362001)(316002)(76116006)(110136005)(97736004)(53936002)(102836004)(66556008)(6436002)(66446008)(68736007)(6512007)(6306002)(66476007)(66946007)(229853002)(64756008)(73956011)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4234;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sOUcAgwwpqrYvBgFotK6UgBgTty6pZZwWM/lcHUYZgS3vcbCZT1/OBNghM+UYBXvHf6SO1q1myHpN8hDE1fpQ028re6c+/lfoO5uG+diV0YFvGFpKBd1DsfTTTwOWFclref6amlL2LFM6KW7RoGCcfArjPBfi0C3Fc2/hUvk0IOM+KJWGUhGrL/mey4IE5SgNgfhQCOmt7BplRS4oA9vegygYcVZnu1LubNukG79zOjtPCbqTEmG78M6wUTT0byziasE6DEtnPFY8VMt89gCsiLeom9e/jxLEyZY8tzIshJiEVtW43JjJx8CheeyRPeJicoz+BXJf2Q++AvMNJ7fND/JmGboF0GjCoUKtsKRS2Esqsd2sOYznr27lLauxEa+HL6B4YQgLUaWt2dhYSH7rJNlcANOd0JjbF4IGjLa0fo=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b7563cfa-6385-49cc-525d-08d6c76194c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2019 20:32:04.0019 (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: HE1PR07MB4234
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: Mon, 22 Apr 2019 20:32:11 -0000


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



    mmusic mailing list