Subject: RE: [SIP] Record-Routing again (Was: Record-Route and REGISTER)

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 27 Dec 2000 17:05:43 -0800

> 
> 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?
> 
...
> 
> 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, you question in (1) where the UA should place a Route header. I am
unclear whether you are also infering that the UA should not copy the
Record-Route headers into a 200 response if the request is an "undefined
Record-Route method". Regardless, ...

Why not make it work for OPTIONS as well? If you are using OPTIONS to
determine the capability set of the UA before making a call (ie sending an
INVITE), it would be nice if the OPTIONS and INVITE actually went to the
same UA; ditto for failed authorization. 

What about this suggestion for un-Record-Route-defined or
unsuccessful-INVITE requests [methods that have no meaning outside of an
INVITE session 481'ed]:
a) if a UAS copies the Record-Route into the response of a request, then the
UA must be prepared to match subsequent requests with the same
To/From/Call-Id. The Request-URI of subsequent requests must be ignored -
the original Request-URI is always used instead. Record-Routing does not
affect whether or not a Contact is included.
b) the UAS and proxies must keep state for the To/From/Call-Id for at least
32 seconds (the same as the retransmit cache period).
c) if the UAC receives a Record-Route in a response for a To/From/Call-Id
for which it make another request, then it should include a forward Route;
otherwise the Record-Route/Route information is discarded. [See below, the
Contact is not included in building the Route if it is used for other
purposes, eg REGISTER.]

This covers OPTIONS, failed INVITES and any other methods that do not
specifically define Record-Route. If the UA must place Route headers in
subsequent requests then it must have its longevity and Record-ROute use
explicitly defined (eg sucessful INVITE & SUB/NOT). 

For the REGISTER case [or in other cases where the Contact is un-usable], if
the UA decides to use the Record-Route header in the response, then the UA
MUST ignore the Contact field when building the forward Route. As discussed
in the previous Record-Route discussions, the proxies must be able to
reproduce the _forward_ call forwarding path in the absence of a (usable)
Contact in the Record-Route response. [This also covers Record-Routed
non-200 responses where Contacts are not allowed.]

I don't think we need to say that record-routing REGISTER, OPTIONS or other
"generic"/un-Record-Route-defined method will never have any useful purpose.
IMO opinion we should be making R-R as generic as possible.

Cheers,

Robert.

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 27 Dec 2000 17:56:26 -0800

Just a couple of corrections ....

> specifically define Record-Route. If the UA must place Route 

							^^^ UAS

> headers in

Actually, I guess there's also the problem that the longevity of REGISTER is
a lot longer than 32 seconds. However, I don't see this as much of a problem
because you can be pretty sure that the UA and Registrar will keep state for
the required period (otherwise the UA or Registrar should accept/return the
Record-Route header). So the onus is on the proxy which record-routed the
REGISTER in the first place. For robustness, if a proxy record-routes a
REGISTER then it should ensure that it does so in a stateless manner. This
is acheived, as previously discussed in the Record-Route thread, by
embedding directional and forwarding information in the header.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Dec 2000 10:04:46 -0500

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, December 27, 2000 8:06 PM
> To: 'Jonathan Rosenberg'; 'Billy Biggs'; Igor Slepchin
> Cc: Sean Olson; Steve Donovan; David Shrader; SIP List
> Subject: RE: [SIP] Record-Routing again (Was: Record-Route 
> and REGISTER)
> 
> 
> > 

Well, if the request is an unknown method, the response is 405 in any case,
so RR is not really relevant. As per REGISTER and OPTIONS (which are known
but not currently record-routed), I suspect most, if not all,
implementations do not copy RR headers into the response. 

> same UA; ditto for failed authorization. 

Well, OPTIONS is a tricky one. In the case you describe, it makes sense.
However, there is no way for a proxy, for example, to know whether an
OPTIONS will ever be followed by INVITE. As a result, any state created by
OPTIONS (which is why the proxy record-routed) can't easily be destroyed. 

Record-routing for things for which there is no clear notion of a session,
in general, is tricky. To handle the case you are considering, one would use
caller preferences along with an Accept-Contact to get back to the same UA
that the OPTIONS went to.

As for failed authorizations, the spec currently does allow for
Record-Routes in these responses. However, I am not a big fan of response
code specific processing, and at the bakeoff, we discussed removing these
and rather not allowing Record-Route in anything but the 200 OK response.
Because of the stateless nature of the authentication mechanism, there is
not really a need to record-route.

> explicitly defined (eg sucessful INVITE & SUB/NOT). 

Its all extra work. I am trying to keep a handle on SIP's complexity. There
is also a backwards compatibility issue for Record-routing of REGISTER and
OPTIONS.

-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