Subject: [MMUSIC] MSRP data channel and CEMA

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2019 17:50:21 +0000

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.

Regards,

Christer

---

From: Jose M Recio <[email-masked]>
Date: Wed, 14 Aug 2019 20:34:29 +0800

On 12/08/19 01:50, Christer Holmberg wrote:
> 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.

1 makes possible removing all the convoluted statements we have right 
now on path (not using path for transport, and so on), as CEMA does 
exactly that.

2 would avoid any possible issue with endpoints not understanding the 
data channel characteristics.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Aug 2019 17:34:17 +0000

Hi,

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

>1 makes possible removing all the convoluted statements we have right now on path (not using path 
>for transport, and so on), as CEMA does exactly that.

It's probably good to mention it somewhere, but we don't need to repeat it.

In addition, in Section 5.1.1.2, for the "cema" attribute we can say:

o  defined in [RFC6714]: "cema", reflecting that the MSRP endpoint will use the c/m-line
information associated with the data channel for sending MSRP messages, instead of using
the path attribute information.

Then we can remove the following:

"As described in Section 5.1.2 the path attribute is not used for transport establiment."

In Section 5.1.2 we can remove:

"The path attribute SHALL NOT be used for transport negotiation."

>2 would avoid any possibl.e issue with endpoints not understanding the data channel characteristics.

I don't understand.

Regards,

Christe

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2019 16:05:25 -0400

> 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