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

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Fri, 22 Feb 2002 08:46:09 -0500

You are right.

However, a clarification in the spec would foster interoperability.

regards/RRR

-----Original Message-----
From: George Foti (LMC) [mailto:[email-masked]]
Sent: Friday, February 22, 2002 8:40 AM
To: Roy, Radhika R, ALASO; Christer Holmberg (LMF); Pete Cordell
Cc: Bob Penfield; [email-masked]; Jonathan Rosenberg
Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message
bod y

I guess, its up to the editors to consider including such a definition. But
its already in people's mind, may be thats why it is not explicitly defined
rgds/gf

> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 8:32 AM
> To: George Foti (LMC); Christer Holmberg (LMF); Pete Cordell
> Cc: Bob Penfield; [email-masked]; Jonathan Rosenberg
> Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message
> bod y
> 
> 
> Inline [RRR]
> 
> -----Original Message-----
> From: George Foti (LMC) [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 8:12 AM
> To: Christer Holmberg (LMF); Pete Cordell
> Cc: Bob Penfield; [email-masked]; Jonathan Rosenberg
> Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message
> bod y
> 
> 
> There was the definition of "transperent" B2BUA to allow a 
> proxy to initiate
> things it is not supposed to do, such as a BYE to terminate  
> a session (in
> case of prepaid) or deregistration (if the network operator 
> decides to kick
> somebody out)
>  
> So while the spec. says as a *pure* proxy you cannot modify 
> SDP, I guess
> most of us will do B2BUA, as the way out.
> 
> [RRR] Is not better to clarify in the spec: "Pure" Proxy vs. 
> "Transparent" B2BUA Proxy?
> 
> Regards
> 
> George Foti
> Ericsson Canada
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Feb 2002 11:55:01 -0500

> However, a clarification in the spec would foster interoperability.

Well, while we are at it, how about this. Let us design a whole family
of B2BUA definitions, each with selective pieces of the specification
from proxy as opposed to UA! We could detail a wide array of call flows
and everything. Fun fun!!

Please.

The essence of the SIP model is that it is a protocol for faciliating
end-to-end negotiation of sessions of some sort. The ->LOGICAL<- role of
a proxy server is to facilitate those exchanges through routing,
location and policy services. A thing that implements that role needs to
consider those requirements. Simple fact is, a thing that mucks with
bodies needs to consider UA requirements. As a simple example, if I send
a request like this as a UAC:

INVITE sip:[email-masked]
Require: m-lines-in-SDP-mean-something-else
....
<SDP>

The thing that mucks with the body needs to know about it. There are
other pitfalls, security being another one. Another is the need to do
the various content handling in bis (what if the INVITE comes with
sdp-ng? What if its been gzipped and has content encodings that are not
understood by this "proxy"?) So, a logical proxy can't muck with these
bodies or the entire model of SIP begins to fall apart. It has become a
logical UA by the result of its needing to follow UA requirements for
the protocol to properly operate. 

So, such a thing will need to take the logical role of a UA. Now, you
can build stupid B2BUA, or smart ones. A smart one might realize that it
can perform its functions without call state. A stupid one might not.
THe market will pick the winners. 

I found it astounding how much people look to IETF and other standards
bodies to do their engineering work for them - to specify the system and
implementations so fully that their is little room for error (or
innovation or differentiation). That is not the IETF way, and it is not
the SIP way. Being a B2BUA means - WARNING - you need to think about
things UAs think about. How you implement that is your own choice. I am
continually shocked that people assume that because something is a B2BUA
its a hulking bear that prevents services. ONLY is that true when you
buy products from people who do a bad job at such things. If your
sdp-mucking-server-product breaks services, even though its a b2bua, get
a new one.

There is a marketing issue, that such things can't rightly be called
"proxy servers". I hope, Pete, you and others are not arguing for a
feature to facilitate your marcom. Maybe you should hire some of those
people that have managed to convince the industry that their products
are "sofswitches". Here, we worry about technology. 

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 22 Feb 2002 19:29:03 -0000

Just when I was thinking of calling it a day....

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>

> bodies needs to consider UA requirements.

I really think you are being too restrictive in your definition of what a
proxy can do.  Especially as SIP is a general mechanism, not just for VoIP
or Instant Messaging.

For example, hypothetically again, but imagine something like a SIP service
that notifies you when a co-operatively edited document has changed.
Perhaps it also diffs the changes, zips them up, and puts them in the body
of a SIP INVITE (or possibly a NOTIFY) so that an automated system can
automatically update a local copy of the document so that next time I look
at it the changes are already incorporated.  Now I want to get notifications
on my mobile phone when the document is changed.  I don't want to get a huge
file downloaded when it comes in because I'll probably just go straight to
my laptop and look at it there.  Therefore the proxy could erase the MIME
attachment for me, perhaps store the file on its hard disk and insert a URL
into the body.

To do this it just needs to tweak the body as it passes through.  It doesn't
need to be a back to back UA, and it doesn't need to be dialog stateful.  It
does have to understand what it is doing though, and it needs to do it in
full knowledge of what impact it will have on other UAs in the dialog.
(Let's ignore the opes issues for the time being and assume that's a solved
problem, which I assume it will be soon.)

True, there maybe better ways to cut such a service, but for five minutes
thinking it vaguely sounds like a useful service.  My real point is not that
this particular service is useful, but that there are likely to be many
services out there that we just haven't thought of yet, that would really
benefit from changing the body.  Saying that we can't change the body
prevents that.

> As a simple example, if I send
> other pitfalls, security being another one.

So far I find the security arguments somewhat circular: I can't change the
body because it's been integrity checked, I can integrity check the body
because it can't be changed.  That's not much of an argument to me.

I guess integrity checking the body is a hang over from HTTP.  There it
makes sense to integrity check the body as that is the actual thing that is
being delivered.  In the case of SIP, the SDP simply points to something
else (RTP).  There's not much point in integrity checking a pointer if you
can then just change what's pointed to.

> Another is the need to do

Not being able, and not being willing to handle any body makes it an
application specific proxy, not a B2BUA with dialog state etc.

One way to deal with this would be to send 415 and send Accepts headers
back.  That doesn't seem to be asking much more of a proxy than sending 404
Not Found back, and I don't see that that automatically makes it a B2BUA.

Also, just because the proxy decides to tweak SDP, doesn't mean it can't let
through other things, such as IM, that it knows about and is happy with
(assuming a firewall type role here.  If it's not doing firewalling, say
just NAT facilitation, then it could just let anything through that it
doesn't understand - screws up if it was sdp-ng, but at least we tried and
it wouldn't have worked anyway.  Hopefully sdp-ng is on most peoples radar
scope though.).

> innovation or differentiation).

My point is the opposite, that the IETF is actually limiting my innovation
and differentiation here.  I'm quite happy to do the engineering work, work
through the impact it has on other systems, make sure my product is robust
and reliable in the context of all the other SIP UA and proxies it might
come across and take my chances in the market place.  But the IETF is
actually saying that I can't design something this way, and as far as I can
see, for no good reason.

> That is not the IETF way, and it is not
> buy products from people who do a bad job at such things.

Exactly, and you don't have to be a B2BUA to do a bad job of SIP.

And it's that word WARNING that is precisely the issue.  Why WARNING for
B2BUAs, but no warning for other SIP implementations?  The market is being
poisoned with the notion that B2BUAs are inherently bad, and therefore you
shouldn't touch them.  With the definition that anything that is not a pure
proxy as defined by the standard, is a B2BUA - and therefore unclean in some
way - the vitality and take up of SIP in the market place is sure to be
restricted.  And at the end of that day that will impact the pure as well as
the unclean.

> If your

And there was me thinking that you were trying to say that I can't change
bodies because it didn't fit in with your business plans.  I'm glad we've
sorted that out.

Let's worry about technology.  But let's give that technology a future.
Let's not stiffle it's growth due to our limited vision.  Give it the chance
of a million minds working to make it better.  Let it be free.  That's all I
ask !

Oh - and change Content-Length to amr !

(Well done to you all on getting the spec out by the way.  And there was me
thinking we could talk about you behind your back because you'd be asleep
today !!!)

> -Jonathan R.

Pete.

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