Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y

From: Adam Roach <[email-masked]>
Date: Mon, 25 Feb 2002 15:46:38 -0500

We're getting a bit far off into a meta-discussion here, but I feel
compelled to rebut some of your contentions.

> -----Original Message-----
> From: Pete Cordell [mailto:[email-masked]]
> For me the main concern about a back to back UAS / UAC implementation
> (perhaps with the two instances joined by something other 
> than SIP) is that
> they lose feature transparency.  It's the loss of feature 
> transparency that
> is the problem, not that it is a B2BUA.  There are many 
> devices that are not
> pure proxies that do not lose feature transparency

They can have feature transparancy *for* *certain* *features*.
One of the reasons that "proxy" is defined to be such a narrow
term is to allow the protocol to evolve without destroying the
functionality of nodes in the middle of the network. For example,
let's take the imaginary (if somewhat contrived) extension
"ip-reversed," which indicates that IP addresses in the SDP
will be in reversed order. Now, you have something you claim
to be a proxy in the middle of the network, except it
helpfully attempts to tweak the SDP if it thinks I'm coming
through a NAT. It thinks it's a proxy, so it doesn't feel
bound to obey the "Require: ip-reversed" header present in
the message.

Boom.

This thing, no matter how similar it is to a proxy, has just broken
the network by doing something that proxies are "not supposed to do."

In order to perform this sort of processing in a way that will work
into the future, any node that does something that proxies aren't
allowed to do MUST pay attention to the "Require" headers. I don't
really care about the semantics of what you end up calling these
things, as long as you don't confuse the issue by calling them
"proxies."

> Thus people are trying to build innovative products 
> delivering exciting
> services beyond simple call routing, that are good netizens, 
> but they are
> getting tarred as bad implementations by people that have 
> never seen them
> simply because they are not pure proxies.

They're not bad implementations. They *are* throttles to effective
deployment of new services, since they must process, honor, and
understand everything that comes by in a "Require" header. For
example, if I and one of my friends got the newest, spiffiest
terminals that had a *really* *cool* service -- one that necessarily
used a "Require" header -- but one of the nodes that my call was
routed thorough didn't support it, I promise you'd have me calling
customer service to figure out why my new $800 phone didn't work
as advertised. And you can be *darn* sure that I'd be pissed --
probably even pissed enough to go shopping for a new provider --
when I found out it's because you have a node in your network
blocking my spiffy service, and that it'll take several months to
a year for you to get an upgrade in place.

Is this an intentional smear campaign? No; it's just a statement
of the ramifications of nodes pretending to be proxies doing
things that proxies are not "supposed" to do. Are such impacts
negative? It depends on whether you want to anger your end users;
most people would say yes. But I've been the customer to uncountable
companies who have taken the decision to piss of their customers
(presumably) for some sort of trade off. It really comes down
to a business decision.

> After all, wasn't the promise of SIP that it could offer lots 
> of exciting
> new services? Now an intermediary device can only do what I 
> can already do
> on my domestic phone line.

Of course, exciting services can *only* come from the *middle* of
the network. I can't beleive that, until now, I had considered the
possibility that the *endpoints* could provide nifty services.
How naive of me (and the others who have been working on SIP for
the past four years) to think that the web model of providing
services might actually work.

> 1) Either understand that anything that is not a pure proxy is not
> necessarily a B2BUA (That really is just a matter of 
> definitions.  I don't
> care what you call it.  Maybe Application-aware Proxy.), or relax the
> definition of a proxy at least so it allows changing the body.

You can't change a body that you can't read or don't understand.
Extensions can (and do) create a situation in which the bodies
will be different than what is understood by nodes in the middle
of the network. If these nodes require comprehension of such
information, they are not proxies. It's more than terminology; it's
about which parts of the SIP spec apply to the behavior you implement.

> 2) Have people appreciate that some of the most exciting 
> services, including
> many that will make SIP worth developing, will end up being 
> implemented with
> elements of B2BUA in them, and if they want SIP to be successful, they
> shouldn't be prejudiced against them and perpetuating the 
> smear campaign.

As I said above, it's not a smear campaign; it's an awareness campaign.
Once you start doing things that proxies don't do, you aren't a proxy.
That makes you liable for following all of the other rules in SIP,
such as processing of "Require" headers. That's really *all* it comes
down to.

Some people think this is a Bad Thing, for the reasons I've described
above. You might not. If you want to create and sell, or deploy and
maintain such nodes, you are free to do so -- but you really should
understand the logical ramifications of doing so.

/a

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 26 Feb 2002 11:01:45 -0000

----- Original Message -----
From: Adam Roach <[email-masked]>

> things, as long as you don't confuse the issue by calling them

Would you prefer that you pushed me into producing a full B2BUA and I bumped
you because you had a Require: header in there?  Would you be happy when you
called in to complain when I say "I would liked to have been as transparent
to your service as I could, but the standard forced me to reject your
transaction." ?  It wouldn't make me feel a whole lot better.

And why don't I ring you up and say 'your new service broke my proxy'.....

This is a protocol design issue and not fundamentally an issue
about modifying bodies.  For example, you could easily have defined
Body-Require:, or you could say that if the body no longer means what it
used to mean, then give it a new Content-Type, e.g. Content-Type:
application/really-cool-sdp.  Or define: Content-Type:
application/sdp-with-requires; require=really-cool.

Actually this is an excellent example of why we should be honest about what
is going to happen in the real world and say that proxies can change bodies.
If we don't, then people will design services that will break the system,
and that helps no one.

> a year for you to get an upgrade in place.

Why should your potentially system breaking service be good, while my
service is bad.  A good protocol should accommodate both service types.

(BTW - Surely you paid too much for your phone.  Does it do ISDN also ?!)

> things that proxies are not "supposed" to do.

But the protocol designers say what a proxy should do.  I'm saying that the
current situation is not good for the long term.  Between what the standard
says now, and what people want to do with it, the SIP infrastructure
will be broken.

> Are such impacts

Typical crap that I would expect from some IETF members: if in trouble -
manipulate words and flame.

Calm down and consider the following - where did I say that ALL services had
to be delivered from the middle.  That's correct, no where.  Many services
will be delivered by end-systems.  BUT many services will hopefully be
delivered by middle systems also.  Hopefully it's not too much of a
revelation to you that some services fit better in the end-systems and some
fit better in the middle.  Blimey, some can even work in both locations !!!!

Or are you saying that you KNOW for a fact that the routing that proxies
provide is the only service that can be delivered in the middle?

... cut rest as duplicated stuff already covered ...

> /a

This is getting us no where.  I have raised the issue that services in the
middle would like to change bodies.  A number of e-mails in this discussion
have confirmed this view.  I also pointed out that a number of these
services are not implemented as full B2BUAs as defined in the standard.
This e-mail demonstrates that there is a real issue if people are not aware
that bodies might change.  I've pointed out that the situation is not
improved if body modifying services are made into compliant B2BUAs (they
will bump everything that has a Require: header whereas at least body
modifying Proxies would carry on).

From these observations I have postulated that, if nothing is done the SIP
infrastructure will be broken and consequently the services that SIP can
offer will not be as rich as some had hoped.

I am prepared to help work on solutions to these problems (I don't think it
will take much solving), but if the inner circle do not wish to consider
these issues, then that's fine by me also.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================