[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] MSRP-ACM vs existing SBCs (was Re: What ACM is all about [was: RE: MSRP-ACM compatibility)
On May 20, 2009, at 10:00 AM, Adam Roach wrote:
I think we have a disconnect here. One of the key arguments, as far
as I understand it, for making the changes proposed in MSRP-ACM has
to do with working through existing SBCs.
Because, let's face it, if SBCs need to go mucking with more than
just the c= and m= lines, then they may as well understand the MSRP-
specific syntax anyway. If this is true, then backwards
compatibility with deployed SBCs is not a design consideration.
And here we have Christer saying that the intermediary would need to
modify the a= lines in a MSRP-specific way.
If that's the case, why are we chasing a requirement to relax the
URI matching rules?
< history review>
Christer's original proposal was to have MSRP-ACM compliant devices
use the c-line addressing rather than the "a=path" line, in order to
be more friendly to existing SBCs. This would not work with MSRP
relays, except in a pure "fall back to 4975 behavior model". The
working group stated a requirement to support the scenario where an
endpoint is behind an SBC, and it's peer is behind a relay.
The a=path modification, and the relaxation of URI rules were an
attempt to make ACM work with relays. We've since run into TLS cert
matching complications with that approach.
</history review.
But to Adam's point, I think we've got some conflicting requirements.
The requirement to interoperate between existing unmodified SBCs
(without behavior modification) and RFC4976 relays cannot be achieved.
The path attribute discussion contains an implicit assumption that we
can modify SBCs a little (e.g. MSRP specific treatment of SDP), but
not a lot (e.g. making them process the to-path and from-path header
fields in MSRP SEND requests.) That is an assumption worth explicit
discussion.
/a