[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] What ACM is all about [was: RE: MSRP-ACM compatibility]



See my rant at the end, in response to Christer's email. I haven't sent it to the list yet.

Am I grasping at too abstract a concept? I.e., ignoring the basic repugnancy of SBCs, is it reasonable to argue that we shouldn't _in_general_ modify protocol to work with proprietary devices without documenting our assumptions about said device behavior and how the protocol modification works with these assumptions?

------------------------------------

(as individual)

On May 19, 2009, at 12:40 AM, Christer Holmberg wrote:


Hi,

In particular, I am skeptical about doing non-trivial changes
to make MSRP work better across proprietary intermediaries without
some better description of what will and will not work in
the general case (i.e. not just what will work with one vendor.)

As said before, I don't think this is about "one vendor".

So what _is_ it about? To my knowledge, We've had only one vendor
stand up and say "this stuff will work across our SBCs".

You are trying to work around the behavior of proprietary middle
boxes. They may behave similarly in some ways, but not others. For
example, if other vendors don't have support for TCP media, then
there's not much value in this for them. Without some standard
behavior, or some survey of behavior like BEHAVE did with
NATs, we're just sort of hoping things will work most of the time. That
may be
good enough to write product requirements around, but it's probably
not good enough to write standards around.

What it is about is to allow these middle boxes to treat MSRP more or
less like any other type of TCP media, without having to modify the MSRP
messages etc.

Of course, some intermediates may not support TCP in the first place,
but that's normal. We don't expect everyone to support everything we do.

But, OMA PoC uses MSRP, so compliant intermediates will have to support TCP. 3GPP IMS uses MSRP, so compliant intermediates will have to support TCP. Intermediates also DO exist in other SIP networks, so in order for MSRP to work they will have to support TCP. That is what I meant by the
statement that it's not only about one vendor.

Forgive my ignorance, but does PoC specify intermediary behavior?



So, in my opinion, intermediates can be expected to support TCP. The
issue is with supporting legacy MSRP, and that is what ACM is trying to
solve.

I do agree that these intermediates aren't standardized, but when it
comes to sending the media through them they all behave in the same way:
by modifying the SDP.


Of course, If we also for ACM would still use the a=path attribute for
routing, rather than the c/,- line, the intermeidates will of course
have to be able to modify the a=path attribute. But, no matter whather
that can be done using configuration (I guess that is what Hadirel
indicated for his product) or whether it requires a software patch, it's
a relatively small thing compared to having to modify MSRP messages.


Do we expect this draft to specify the actual middlebox behavior that is enabled by changing the treatment of the path attribute URIs?

The point I am struggling with is, this part of the ACM draft does not add value in itself. Rather, it sets out to relax an MSRP requirement to enable another middlebox to add value. But the behavior of that middlebox is not standardized, and we haven't really analyzed the requirements for the middlebox to get its job done. And we know full well that there are security implications both in this new behavior we propose for the middlebox (i.e. rewriting path attributes) as well as the presence of the middlebox in the first place.

This is pretty much the same argument that has been popping up in all of RAI concerning the collision between SBCs and the SIP architecture as defined by the IETF.

If we are going to change MSRP to enable SBCs or any other sort of middlebox, I'd really like to see more documentation on how that middlebox is expected to behave in context, and how the whole architecture works when said middlebox is present. I'm not necessarily talking about normative specification.This is the point I was trying to get across in previous reviews when I suggested we needed some use case analysis and possibly call flows to describe the requirements that section 4.2 sets out to solve.

We spun up a whole working group (BEHAVE) to do this for NATs, and subsequently learned that many of or generally held assumptions were wrong.