[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] MSRP-ACM: c/m versus a=path, and how to update 4975 session matching
Hi,
One of the remaining open issues of MSRP ACM was whether we should use the SDP c/m line for routing (as for other media), which is what is currently described in the draft, or whether we should continue using the a=path attribute as in legacy MSRP (RFC 4975).
A group of interested people have been discussing this quite much since Stockholm, and our suggestion would be that we would use the a=path attribute. The reason is that it does not re-define the MSRP routing mechanism completely, and we do not need to describe how To/From-Path headers are build based on c/m lines etc. But, if anyone still thinks that we should use the c/m line for routing, please indicate so on the list asap.
The next issue, which was briefly discussed already in Stockholm, is the issue regarding ACM-legacy interoperability when an intermediate modifies the SDP a=path attribute (or, in case of c/m routing, the c/m parameters).
Section 7.3 RFC 4975 defines a session maching procdure, how a client when it receives an MSRP message checks whether the message belongs to an ongoing session. The client does that by comparing the received To-Path URI with SDP a=path URIs for ongoing session(s). The whole URI (address information part, session-id part etc) is used for the check, so if a ACM supporting intermediate modifies the SDP a=path attribute (but do not modify the associated MSRP messages), the session match will produce a failure at the legacy client.
The proposed mechanism to solve that is to update RFC 4975 (most likely only a change to section 7.3 is needed), and say that only the session-id part of the URI is used for the matching. Again, this was discussed briefly already in Stockholm, but we decided to first deal with the a=path versus c/m routing issue.
The exact procedure for the 4975 update is still to be discussed, and our intention is to spend meeting time in Hiroshima for that.
Thanks!
Christer