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

[Jonathan Rosenberg <[e-mail]>]

 

> -----Original Message-----
> From: Billy Biggs [mailto:[e-mail]]
> Sent: Tuesday, January 02, 2001 12:53 AM
> To: Jonathan Rosenberg
> Cc: SIP List
> Subject: Re: RR for non-INVITE call legs (was Re: [SIP] new 
> record-route
> t ext!)
> 
> 
> Jonathan Rosenberg ([e-mail])
> 
> > >   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.

Well, you shouldn't expect for those record-routes to be reflected or used
except in the methods that they are supposed to be present in.

> 
>   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.

If you are saying that a UA shouldn't barf on a record-route where one
shouldn't normally be, I'll agree. If you are saying that a UA should be
able to reflect record-routes in methods where they are not supposed to be,
I would disagree.


> 
> > > 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? [...]
> > 
> > > 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.

As above, if by "allowed" you mean that a UA shouldn't barf, but will
otherwise ignore it when it shouldn't be there, I'll agree. I added some
text indicating that.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.cs.columbia.edu/~jdrosen         PHONE: [phone]
http://www.dynamicsoft.com

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