IETF Logo Mail Archive

Re: [MMUSIC] MSRP data channel and CEMA

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 14 August 2019 20:05 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 5F3EF120ECC for <mmusic@ietfa.amsl.com>; Wed, 14 Aug 2019 13:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5Jb52pi695ba for <mmusic@ietfa.amsl.com>; Wed, 14 Aug 2019 13:05:28 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8742120F18 for <mmusic@ietf.org>; Wed, 14 Aug 2019 13:05:27 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7EK5PEq021873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Wed, 14 Aug 2019 16:05:26 -0400
To: mmusic@ietf.org
References: <A1B7047A-BA0A-4766-B077-1D9F16F8F57B@ericsson.com> <ebddf066-2068-73e8-308d-38e737de7e78@ch3m4.com> <HE1PR07MB316108A1869AFA6D0DE917B793AD0@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <f5337bb5-d407-4f56-770d-19e05be63057@alum.mit.edu>
Date: Wed, 14 Aug 2019 16:05:25 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <HE1PR07MB316108A1869AFA6D0DE917B793AD0@HE1PR07MB3161.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/X0f8sYQC-wv_sAnuWaJmiN3c9cc>
Subject: Re: [MMUSIC] MSRP data channel and CEMA
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: Wed, 14 Aug 2019 20:05:35 -0000

On 8/14/19 1:34 PM, Christer Holmberg wrote:
> Hi,
> 
>>> I was thinking more about CEMA and MSRP data channels.
>>>   
>>> RFC 6714 says:
>>>   
>>>     “MSRP endpoints that support the CEMA extension will use the SDP c/m-line address
>>>     information for establishing the TCP or TLS connection for sending
>>>     and receiving MSRP messages.”
>>>   
>>> …which is exactly what is done when a data channel is established.
>>>
>>> Of course, the data channel will be established using the c/m- line no matter whether
>>> CEMA is indicated or not, but I think it would be good to have it explicit.
>>
>> Thinking about it, I think one possible approach to make it more clear could be: 1) mandate that endpoints include the CEMA attribute , and
>>
>> 2) specify that transport level gateways should not forward CEMA attributes from/to data channel endpoints.
> 
> Why would they not forward the CEMA attribute?

ISTM that a separate decision would be made about the need for CEMA on 
the next hop.

	Thanks,
	Paul

v2.23.0 | Report a Bug | By Email