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

[Jose M Recio <[e-mail]>]

Just posted updated draft based on your (and mail list) feedback. Main 
changes: removed cema attribute being optional, make it explicit that 
path shall not be used for transport negotiation neither for the direct 
end-to-end architecture nor for the GW one.

Following up on this comment:
> Regarding the GW, I think that also needs more text. For example, *IF* 
> the data channel MSRP client inserts multiple path attributes, will 
> the GW then copy paste those in the outgoing legacy MSRP message? I 
> assume it will, but there is very little detail on the GW procedures.
GW has two modes of operation: B2BUA, where there's nothing furthermore 
specified; and transport level gateway. In the second case, the draft 
already specifies that relays SHALL NOT be requested by the dc endpoint; 
and as the GW just operates at transport level, I think it's fair to 
leave any MSRP behavior (such as forwarding path attributes) as per MSRP 
specs.

What do you think?


On 31/05/19 18:51, Christer Holmberg wrote:
>
> What is the status regarding this?
>
> Regards,
>
> Christer
>
> *From: *Jose M Recio <[e-mail]>
> *Date: *Thursday, 25 April 2019 at 14.29
> *To: *Christer Holmberg <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Subject: *Re: [MMUSIC] I-D Action: 
> draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on 
> msrp-cema attribute
>
> On 23/4/19 4:32 AM, Christer Holmberg wrote:
>
>     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.
>
>
> It indeed assumes that the data channel endpoint will be a MSRP peer, 
> either another endpoint or a MSRP GW. If that's not clear enough it 
> should be made more explicit.
>
> If the endpoint is a GW, messages can be relayed, similar to the 
> scenario where the connection to the GW is done using TLS, or 
> WebSockets, instead of dc.
>