Subject: RE: [SIP] Record-Route and REGISTER

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Dec 2000 15:07:30 -0500

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Thursday, December 21, 2000 3:55 PM
> To: Igor Slepchin
> Cc: Jonathan Rosenberg; Sean Olson; Steve Donovan; David Shrader; SIP
> List
> Subject: Re: [SIP] Record-Route and REGISTER
> 
> 
> Igor Slepchin ([email-masked]):
> 
> > I never suggested that all proxies always Record-Route. 
> What I said is
> > that proxies should not necessarily base the decision about 
> whether to
> > record route based only on the request type.
> 
>   I argue that the decision should be based on the request 
> type and the
> proxy's requirements.  Being conservative here is important 
> to avoid all
> the problems of having packets route through a (disinterested) third
> party.

I think the overall statement is that, ultimately, record-routing is at the
policy discretion of the server. This will depend on what it wants to do,
the request method, etc. No disagreement there, I think. 

Sean said:
> RR is well defined for all methods within a call leg. What is up for
> consideration (I believe -- please correct me if I'm wrong) is whether
> a RR in the REGISTER should also apply to the INVITE/CANCEL/ACK/BYE
> and vice-versa.

No, that is not the issue. THis changes the meaning of Route/Record-Route
and that is not on the table.

So what is the issue?

Igor has made the statement that a proxy should be able to record-route for
any request method. Indeed, that is the issue. UAs will need to be prepared
to handle that. In order to do so, they must know how to do several things
that, right now, are not very clear:

1. if some method foo gets record-routed, in which other request should that
Route go?
2. when is it safe to destroy that route set?

Currently, the answers to these for INVITEs are (1) all requests within the
call leg, and (2) when the call leg is over, from BYE or timeout. With
REGISTER, for example, what are the answers? Turns out that "call leg",
using the more formal local ID/remote ID/Call-ID works well, resulting in
routes being established for all refreshes from a single UA. The same is
true for IM and SUBSCRIBE. The answer to the second question is more
complex, and is very likely method dependent. 

So, the question is (1) do we want to even specify, in the base spec,
record-route semantics for non-INVITE requests, and (2) if so, what are the
answers to questions 1 and 2 above. 

I'm inclined to say no to the first, actually. This doesn't mean that its
impossible to record-route for anything else, but rather that the answers to
questions 1. and 2., which constitute the primary issue of standardization,
are method specific in part. All that we need say in rfc2543 is that
processing of Route headers in proxies is not method dependent. I suspect
thats the case for most proxies today already.

I haven't seen much value yet in Record-routing register. Its not useful for
OPTIONS, and everything else is covered. MESSAGE and SUB/NOT will need it,
but we can simply specify the meaning for these within those documents. As
Mike said, lets try and keep things simple.

-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: David Shrader <[email-masked]>
Date: Thu, 28 Dec 2000 17:31:25 -0500

The reason I raised this question originally is in the context of a security
architecture in which we maintain secure connections to user agents outside
of a secure/trusted perimeter. Upon establishment of a secure connection for
a user agent to the network, RR could be used to insure that the secure
channel is used in both directions for subsequent interactions. The REGISTER
message, of course, must be included in the overall structure.

Note: the overall solution to this problem might involve pre-loaded Route
headers as well which were not under discussion in this email.

As such, I think the RR mechanism could be useful as a generic routing
mechanism that applies to any SIP call leg (To/From/Call-ID) and whatever
requests are a part of that call leg without having to define method
specific processing.

----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]
http://www.EyeForTheFuture.com

> From: Jonathan Rosenberg <[email-masked]>
> Date: Fri, 22 Dec 2000 15:07:30 -0500
> To: "'Billy Biggs'" <[email-masked]>, Igor Slepchin
> <[email-masked]>
> Cc: Jonathan Rosenberg <[email-masked]>, Sean Olson
> <[email-masked]>, Steve Donovan <[email-masked]>, David
> Shrader <[email-masked]>, SIP List <[email-masked]>
> Subject: RE: [SIP] Record-Route and REGISTER
> 
> 
> 
> 
>