Subject: RE: RR for non-INVITE call legs (was Re: [SIP] new record-route t ext!)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Jan 2001 00:13:07 -0500

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Saturday, December 30, 2000 11:20 PM
> To: Jonathan Rosenberg
> Cc: SIP List
> Subject: RR for non-INVITE call legs (was Re: [SIP] new record-route
> text!)
> 
> 
> 
> RR for non-INVITE call legs and non-INVITE requests, part 1:
> 
>   For me, a call-leg is created equally for all requests.  The final
>   response completes the leg and establishes the Route and tags.  This
>   moves the request from the one-to-many state to a one-on-one call.
> 
>   My implementation of SUBSCRIBE/NOTIFY is no different.  NOTIFYs
>   follow the established Route back and use the tags, and NOTIFYs
>   received which do not match the established legs tags are 481'd.
> 
>   Your proposal seems to be that any request other than INVITE cannot
>   create a call leg, and that the NOTIFY be sent strictly to the
>   Contact address, not follow the Route, and reset the tags.

No, no. THat is not what I had in mind. I believe it is fine to record-route
for any requests that do explicitly establish some kind of session state
with a well defined duration. In rfc2543, thats really only two - INVITE and
REGISTER. For backwards compatibility reasons, and for lack of a strong
need, I don't want to support record-routing on REGISTER. For the rfc2543
methods, that leaves only INVITE. So, where Henning has suggested:

   The record-routing mechanism only applies to {\INVITE} transactions.
   Inserting \header{Record-Route} in requests other than {\INVITE} is
   {\NOTALLOWED}.

I would say:

   The record-routing mechanism only applies to methods that establish some
kind
   of session state. For the methods defined in this specification, that is
only
   the \INVITE method. As such, inserting a \header{Record-Route} into 
   \REGISTER, \OPTIONS, \CANCEL, \ACK, or \BYE is {\NOTALLOWED}. Extensions
   that define new methods {\MUST} state whether requests with those methods
   can be record-routed.

> 
>   That's a big switch.  I'm sure everyone who has implemented (at
>   least) SUBSCRIBE/NOTIFY will have to change their code.

I think my text above addresses this. SUBSCRIBE should allow itself to be
record-routed. I am not proposing to change that.

> 
>   This also means that any firewall proxy MUST mangle the Contact
>   address for all outgoing requests other than INVITE.  

Why does this mean that? There are only three methods that have any meaning
as "initial" requests - INVITE, OPTIONS, REGISTER. INVITE is
record-routable. I have argued that since OPTIONS doesn't establish creation
of any session state, there is no real meaning in record-routing for it
anyway. REGISTER is arguable; however, a firewall proxy may need to mangle
with the contact headers there anyway, as they could contain ip addresses.

> RR for non-INVITE call legs and non-INVITE requests, part 2:
> 
>   RR/Route must be allowed for non-INVITE requests within a call, such
>   as REFER. 

Route, yes. Record-Route, no. What is the point of record-routing refer
mid-call? Record-routing INVITE mid-call is only useful for
crash-and-restart or pre-loaded routes. For REFER, it is useless for
crash-and-restart (since REFER doesn't establish a session), and also for
pre-loaded routes its not useful, since REFER doesn't establish a session. 

> This of course makes the logic really weird, since the
>   behavior for non-INVITE requests outside of a leg is different than
>   those within.

How does this follow?

-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: Billy Biggs <[email-masked]>
Date: Tue, 2 Jan 2001 00:53:28 -0500

Jonathan Rosenberg ([email-masked]):

> >   Your proposal seems to be that any request other than INVITE
> > cannot create a call leg, and that the NOTIFY be sent strictly to
> > the Contact address, not follow the Route, and reset the tags.
> 
> No, no. THat is not what I had in mind. I believe it is fine to
> record-route for any requests that do explicitly establish some kind
> of session state with a well defined duration. [...]

  Thanks, that makes me feel better. :)     However:

> I would say:
> 
>    The record-routing mechanism only applies to methods that establish
>    some kind of session state. For the methods defined in this
>    specification, that is only the \INVITE method. As such, inserting
>    a \header{Record-Route} into \REGISTER, \OPTIONS, \CANCEL, \ACK, or
>    \BYE is {\NOTALLOWED}. Extensions that define new methods {\MUST}
>    state whether requests with those methods can be record-routed.

  To get through our firewall, we have a proxy set to Record-Route every
message with 'sip:proxy.address' and not keep any state.  This gives
immediate compatibility with any new extensions that need to work
through a firewall, such as SUBSCRIBE/NOTIFY.

  So, I would rather:

    [...] Extensions that define new methods {\MUST} state whether
    requests with those methods should be record-routed.
    Implementations {\MAY} choose to add a record-route to unknown
    methods.

> >   RR/Route must be allowed for non-INVITE requests within a call,
> >   such as REFER. 
> 
> mid-call? [...]
> > This of course makes the logic really weird, since the behavior for
> > non-INVITE requests outside of a leg is different than those within.
> 
> How does this follow?

  If you don't know anything about NEWMETHOD and you statelessly add
Record-Routes, then you would want to do the same whether its a mid-call
NEWMETHOD or an initial NEWMETHOD.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]