Re: [Simple] MSRP-ACM vs existing SBCs (was Re: What ACM is all about [was: RE: MSRP-ACM compatibility)

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi, 

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

Below Ben indicates why it was proposed to change that - and I also
think also You asked why we couldn't use the path attribute instead.

But, the question is not whether an intermediate CAN understand the MSRP
specific syntax - the question is the COST the intermediate having to
modify every MSRP message. Most sessions contain only a single
offer/answer exchange, but most MSRP sessions are probably going to
contain more than a single MSRP message exchange.

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

Correct (we are discussing a solution proposal for that, though).

And, as we have been discussing, there may be some cert issues related
to the comedia part, if there are relay cases where the fingerprint
attribute must be included.

></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.

Instead of "modify SBCs" I guess we should say "add MSRP specific
treatment of SDP to SBCs". MSRP ACM is currently not standardized, so
there is nothing existing MSRP ACM related which needs to be modified :)

Regards,

Christer