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

From: Igor Slepchin <[email-masked]>
Date: Thu, 21 Dec 2000 14:41:04 -0500

One thing I'd like to ensure is that proxies insert Record-Route in all
requests, no matter what the request method is (CANCEL and ACK are possible
exceptions). It is then up to the endpoints to decide whether there is any
use for that Record-Route. 

If we do that this way, the proxies won't need to know about cryptic things
like "Record-Route for INVITEs and SUBSCRIBEs but not for REGISTER". Makes
defining new methods much easier.

---
Igor Slepchin

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> 
> This issue is what I meant when I said:
> 
> >What is the the scope of the Route? To which set of messages does
> >it apply? When can the route be purged? 
> 
> The obvious generalization of the current Route mechanism is 
> that a UA uses
> the Routes for all requests with the same To/From/Call-ID. 
> This would then
> effect refreshes of REGISTER, and is also how we handle 
> record-routing of
> SUBSCRIBE/NOTIFY and MESSAGE as well.
> 
> What would you use RR on REGISTER for? Not sure... any ideas?
> 
> -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
>  
> 
> > -----Original Message-----
> > From: Sean Olson [mailto:[email-masked]]
> > Sent: Tuesday, December 19, 2000 2:18 PM
> > To: Steve Donovan
> > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List
> > Subject: Re: [SIP] Record-Route and REGISTER
> > 
> > 
> > What about subsequent re-registrations? It is conceivable that
> > a stateful proxy might want to know about these re-registrations
> > (perhaps for caching purposes). Of course, this doesn't help
> > with the case where multiple UAs are registering for the same
> > user.
> > 
> > Sean
> > 
> > Steve Donovan wrote:
> > > 
> > > Why are we worried about record-routing REGISTER messages.  
> > Record-Routing
> > > is used to ensure that all messages within a session go 
> > through interested
> > > proxies.  This is obviously useful with INVITE and SUBSCRIBE.
> > > 
> > > There is no session created by REGISTER.  As such, there 
> > are no other
> > > messages that need to take the same route.
> > > 
> > > Is the goal to ensure that subsequent REGISTER requests 
> > make it to the same
> > > instance of a registrar within a domain?  If so, is the use 
> > of Record-Route
> > > the correct solution?
> > > 
> > > Steve
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of 
> > Jonathan Rosenberg
> > > > Sent: Tuesday, December 19, 2000 12:25 AM
> > > > To: 'David Shrader'; SIP List
> > > > Subject: RE: [SIP] Record-Route and REGISTER
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: David Shrader [mailto:[email-masked]]
> > > > > Sent: Sunday, December 17, 2000 3:40 PM
> > > > > To: SIP List
> > > > > Subject: [SIP] Record-Route and REGISTER
> > > > >
> > > > > When using the REGISTER method, however, the Contact header
> > > > > is NOT used for
> > > > > that purpose. The Contact header in the Response to a
> > > > > REGISTER is simply a
> > > > > list of registered contacts and does not in fact identify the
> > > > > recipient of a
> > > > > subsequent request.
> > > >
> > > > Correct. REGISTER is nearly a separate protocol, for all 
> > intents and
> > > > purposes. As specified right now, record-routing for 
> > REGISTER is ambigous.
> > > > In any case, record-routing for transactions outside of 
> INVITE is
> > > > not clear.
> > > > What is the the scope of the Route? To which set of 
> messages does
> > > > it apply?
> > > > When can the route be purged? These issues must be 
> > resolved as well, and
> > > > they are much harder.
> > > >
> > > > The solution to your specific problem is for the UAC and 
> > UAC to use RR in
> > > > REGISTER instead. So:
> > > >
> > > > 1. A UAC inserts a REcord-route into the REGISTER 
> > pointing to itself, just
> > > > like the Contact would look in an INVITE
> > > > 2. proxies can record-route
> > > > 3. UAS (the registrar, in this case) also adds a RR, 
> and reflects
> > > > that back
> > > > in 200 OK
> > > > 4. Route is constructed normally except COntact is ignored
> > > >
> > > >
> > > > Kind of a pain to have a special procedure for REGISTER, 
> > I know. In
> > > > hindsight, I would have used something instead of Contact 
> > here, but at the
> > > > time rfc2543 was being written, the usages were similar enough
> > > > and the idea
> > > > of record-routing REGISTER was not something we considered.
> > > >
> > > > -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
> > > >
> > > 
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Billy Biggs <[email-masked]>
Date: Thu, 21 Dec 2000 14:06:50 -0600

Igor Slepchin ([email-masked]):

> One thing I'd like to ensure is that proxies insert Record-Route in
> all requests, no matter what the request method is (CANCEL and ACK are
> possible exceptions). It is then up to the endpoints to decide whether
> there is any use for that Record-Route. 
> 
> If we do that this way, the proxies won't need to know about cryptic
> things like "Record-Route for INVITEs and SUBSCRIBEs but not for
> REGISTER". Makes defining new methods much easier.

  Please, don't Record-Route unless you need to.

  If all proxies Record-Route'ed, we get:

  1) Huge messages
  2) Increased failure probability
  3) Increased delay
  4) Intelligence in the network
  5) ...

  A call-logger should only Record-Route for INVITE-initiated call legs.
Of course, a firewall proxy should Record-Route everything, but that is
a very special case.

  I've heard rumors that some proxies Record-Route unconditionally (!!).

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: Sean Olson <[email-masked]>
Date: Thu, 21 Dec 2000 14:05:53 -0600

I'm hoping that proxies are not blindly inserting Record-Route, ie.
there is a reason for them to insert it in the first place. I 
understand the need to insert a RR in the INVITE/CANCEL/ACK/BYE.
This is distinct from the need to insert a RR in the SUB/NOT. This is
also distinct from the need to insert a RR in the REGISTER. The desire
of a proxy to be in the signalling path for each of these scenarios
is based on different functions the proxy is hoping to perform. That
being said, I believe that once a proxy RR's in one of these situations,
it should RR for *all* methods that match that call leg including 
possibly future unknown methods.

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. Given that these are two different call legs, this 
would be new behaviour. I can see value for both sides.

But fundamentally, RR is for the benefit of the proxies, not the UAs.
The UAs should not be making decisions about whether or not RR is
appropriate for a given method.

my two cents
/sean