Subject: RE: [SIP] new record-route text!

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 9 Jan 2001 02:24:16 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, January 04, 2001 11:20 AM
> To: Jonathan Rosenberg
> Cc: 'Christian Huitema'; Henning Schulzrinne; [email-masked]
> Subject: RE: [SIP] new record-route text!
> 
> 
> Jonathan Rosenberg writes:
>  > > From: Christian Huitema [mailto:[email-masked]]
>  > > I am concerned with the mandatory aspect of the record-route 
>  > > parameter.
>  > > Part of the beauty of SIP is that it can operate in a strict 
>  > > end-to-end
>  > > mode; the record-route procedure allows intermediaries 
> to arbitrarily
>  > > break that end-to-end property. I understand that this 
> could be useful
>  > > sometimes, for some crazy network configurations,
>  > 
>  > Er, I suspect these "crazy" cases are likely to be the 
> norm (i.e., presence
>  > of NATs and firewalls).
> 
> Jonathan,
> 
> I respect your desire to get this to play as well
> as to be expected with fog machines, but if it
> comes at the cost of making a mess out of a clear,
> sunny net I have serious problems. Assuming you
> haven't already drank the kool-aid, let's be
> careful here; record route is a sometimes useful,
> but unwieldy and unreliable tool which should be
> used as little as possible. The preface text of
> RR ought to be "If you think you need it, you
> probably don't. Think again."

I just don't agree with that. If thats the case, boy 
have we been wasting a lot of time specifying and testing
it at bakeoffs. 

Record route serves many useful functions; functions that
user agents will want to get from proxy servers. They are critical
for call features (such as those provided by sip cgi, cpl, servlets, etc.),
security functions of all sorts, including but not limited to firewall
traversal,
building distributed proxy systems (whereby pieces of a proxy or gateway
function reside in distributed proxies, rather than all in one), and so on. 

Record routing is the ultimate in flexibility. A proxy that doesn't need to
be in the call path can get out of the way, and one which needs to be in the
call path to serve a useful function, can. It allows people to build sip
networks of all different flavors, and have them work with the same UA.

If you make record-route support in a UA optional, the result is that things
which the user expects to work (call features, correct call establishment,
etc.) won't in some cases. I don't want to have to have our customer support
folks field calls like "I can't call California, ever", with an answer of,
"oh, well, your phone doesn't support record-route, and the california proxy
is performing some security checks that require you to route through it.
Sorry, and have a nice day". 

People also know that I'm a big fan of new applications enabled by sip. Fact
is, some of these applications live in servers in the network. Many of these
won't work if proxies can't see all signaling for the call. I'm afraid that
we will literally destroy sips ability to provide services if we don't
ensure that record route functions properly. I do not think the answer
should be "use a B2BUA for all of these". There is a big cost difference in
having a B2BUA process calls as compared to a proxy, and there are also
security issues that arise. B2BUA is applicable in some cases, to be
certain, but not in EVERY case where we want call state aware processing in
the network.

The burden of record-route support in UA is small. You need to store the
record-route list and reuse it for subsequent requests. Its not a big deal. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Jan 2001 08:38:55 -0800 (PST)

Jonathan, I think you were misreading the spirit of my post.
Read on...

 > security functions of all sorts, including but not limited to firewall

   I'm not sure what you mean by security functions. As
   I posted earlier, if you mean things that require the
   proxy to open and close something that doesn't actually
   pass through it (like, say, media) you already have to
   deal with soft-state elsewhere. At the least, record 
   route is adding extra hops that soft-state could 
   probably reap, and at worst, it might be (perhaps
   mistakenly) adding soft state to your proxy as well.

 > Record routing is the ultimate in flexibility.

   Sure. I'm not saying to nuke it.

 > If you make record-route support in a UA optional, 

   No, I don't think that's what I was saying. I am interested
   in Christian's escape-hatch idea though. I read that as a
   "I implement it and thanks but no thanks" kind of proposal.

 > certain, but not in EVERY case where we want call state aware processing in

   The dividing line, IMO, is whether you *require* knowledge of
   the end of the session -- especially if it may be in the UA's
   advantage to "forget" to proxy route the BYE.

 > record-route list and reuse it for subsequent requests. Its not a big deal. 

   The controversy, such as it is, is not whether the few lines
   of code are a problem on the UA. The problem that I see with
   RR is much more in the domain of gratuituously adding state
   and unneeded routing to proxies, and increasing the complexity
   and single points of failure to the system. Without RR, 
   fate sharing is the minimum: the parties of the session.
   I also worry a little about traffic analysis through parties
   that want to glean more information about your call than
   the bare necessity and hand it over to people who shouldn't
   be getting it (= feds, spammers...). 

   For these reasons, I think that RR should be discouraged 
   unless there really, really isn't any other way to perform
   the function you need. Not deprecated, not not standardized,
   but just listed with a bunch of "CAUTION:"'s.

		   Mike

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 11 Jan 2001 13:31:19 -0600

> Jonathan, I think you were misreading the spirit of my post.
[...]
>> People also know that I'm a big fan of new applications enabled by sip. 
>> Fact is, some of these applications live in servers in the network. Many 
>> of these won't work if proxies can't see all signaling for the call. I'm 
>> afraid that we will literally destroy sips ability to provide services if 
>> we don't ensure that record route functions properly.
> 

Many services also occur mid-session; i.e. proxies may provide services
based on re-INVITEs or INFO requests as well.

>    fate sharing is the minimum: the parties of the session.

These situations can be alleviated by judicious use of DNS; one can argue 
that response traversal based on the Via list is also a single point of 
failure, isn't it -- if a server in the Via chain crashes, the next 
downstream server will not be able to properly proxy the response to the
crashed upstream server.

In general I believe that the SIP community is aware of problems with 
*gratituous* use of R-R; but as Jonathan points out (and no one disagrees), 
R-R has its uses.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184