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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 2 Jan 2001 10:46:37 -0800

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, but if we make this
mandatory we should have at a minimum an escape hatch. More precisely,
the syntax of the contact header should allow us to distinguish between
two cases:
1) a contact address that can only be reached through the recorded
route,
2) a contact address that can be accessed directly.
I would contend that, if we don't want to recycle the SIP spec to the
proposed standard spec, the latter should be the default, as the strict
record route requirement breaks compatibility with the original
specification.

-- Christian Huitema

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

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 02 Jan 2001 15:08:10 -0600

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I took a stab at the new text for record routing. Its much, much more
> verbose than rfc2543, and hopefully, as a result, will make it much 
> clearer what you need to do.
[...]
> Please comment; alternate text related to those comments is requested.

Jonathan:

The text uses R-R parameters to implement certain functionality.  R-R param-
eters are specified in the bis BNF for Record-Route; RFC 2543 BNF did not 
contain R-R parameters for Record-Route.  What happens if a R-R with 
parameters inserted by a proxy makes its way to a RFC 2543 UAS, which does 
not echo R-R parameters in the 2xx response (since it does not know how to 
parse them)?  In this case, the proxy may not be able to correlate the 
response to the apppropriate R-R for header modification.

Assuming we are dealing with all bis implemented SIP entities, then the 
example you provide would (to me, anyway) make more sense if the 
myparam=9877 was appended by the proxy at 10.0.1.1 to the INVITE going 
downstream instead of the 2xx going upstream, especially given the para-
graphs that follow.

> OPEN-ISSUE: Handling for non-200 responses, including provisionals
> and certain 400 class responses. Are we supporting record-routing for
> non-200 class responses? Record-routing for provisional responses is
> discussed in the 100rel spec. What needs to be said here?

I would think R-R makes sense for 2xx responses only.

> OPEN-ISSUE: should the UA remove the maddr param, if present, if the
> request is sent to the server at that maddr?

I would say probably not; no good reason for it, though.  I don't think it
hinders any.

Henning mentioned some verbiage about handling record-routing of non-INVITE
requests, which I think should be added as well.

Thanks for the time to document this...

Regards,

- 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Jan 2001 01:47:30 -0500

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 11:37 AM
> To: Jonathan Rosenberg; Michael Thomas
> Cc: Henning Schulzrinne; [email-masked]
> Subject: RE: [SIP] new record-route text!
> 
> I would not object all that much if the specification did not preclude
> bypass of the recorded route, e.g. by issuing a re-invite to the 
> contact address through an entirely new path. This would allow the
> conversation to be redirected to a more direct path, or to a path
> that is less dependent of the initial set of proxies. Come to 
> think of 
> it, there is no way to prevent UAs to do just that, which 
> means that we
> should not specify the impossible.

Well, the SIP spec is full of MUSTs, almost all of which are things that you
cannot prevent a UA or proxy from doing. That doesn't mean they shouldn't be
a MUST. Things are a MUST when not doing them will normally cause protocol
operations to fail. I think that will be the case here. The new text already
is very explicit about proxies not record routing gratiutiously. WHen they
do it, it is almost always since its in the best interests of the user -
either the signaling won't work at all, or some features are provided that
won't work. The user has no way of knowing, and so the only sensible thing
is to honor the record route, since it really is in the user's best interest
to do so.

Mike Thomas writes:
>  > 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,
> 
>    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.

There are other security functions besides firewall traversal. For example,
a VoIP provider will probably want to have a bunch of access proxies which
authenticate the users and/or calls at the ingress to the network. Once
authenticated at the edge, the messages are allowed to pass into the
network, and once inside, are not re-authenticated by all proxies within the
domain. In such a scenario, the access proxies will need to record route in
order to validate each message. 

-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