Ooops... I was thinking of route-set and UAC
Just to add, there are applications where a proxy would like to be involved
in
the signaling path only till the point of call establishment and later on
leave
to the endpoints for further signaling messages. The last I tested with
VOCAL,
it behaved in the same manner.
Does the UAC actually honor mid-dialog Record-route changes and removes the
proxy from the signalling path in this case? In other words, does vocal
expect UAC to update it's route-set based on mid-dialog record-route
headers.
-Vishal
"Hearty, John"
<[EMAIL PROTECTED]> To: "Vishal Phirke"
<[EMAIL PROTECTED]>,
Sent by: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED] cc:
lumbia.edu> Subject: RE:
[Sip-implementors] Record-Route and re-INVITE
06/06/2003 11:06 AM
Inline.
> So if UA receives mid-dialog requests with Record-Route headers then it
> should copy the Record-Route headers in to its 2xx response. Correct me
> if
> I am wrong.
>
> [VP] I believe what John was saying is that it shouldn't copy and just
> ignore the record-route headers received in mid-dialog requests and only
> time it might want to use them is when it is trying to recover from a
> crash.
No, Meena and Chris had it right, the UAS still needs to copy the R-R into
the 200 OK. Otherwise a crashed UA on the other end would not be able to
rebuild the session.
And I guess recovery part is implementation dependent. To recover
> from crash you need lot of other state than just record-route and if you
> are saving such states in some persistent way then why not save
> recrod-route as well.
The idea is all state is recovered from the message without storing
anything. Some relevant text from 3261:
12.2.2 UAS Behavior
<snip>
If the request has a tag in the To header field, but the dialog
identifier does not match any existing dialogs, the UAS may have
crashed and restarted, or it may have received a request for a
different (possibly failed) UAS (the UASs can construct the To tags
so that a UAS can identify that the tag was for a UAS for which it is
providing recovery). Another possibility is that the incoming
request has been simply misrouted. Based on the To tag, the UAS MAY
either accept or reject the request. Accepting the request for
acceptable To tags provides robustness, so that dialogs can persist
even through crashes. UAs wishing to support this capability must
take into consideration some issues such as choosing monotonically
increasing CSeq sequence numbers even across reboots, reconstructing
the route set, and accepting out-of-range RTP timestamps and sequence
numbers.
John Hearty
Level3
>
> Since the route sets of the UA are unaltered by the new Record-Route
> headers, they will route future requests according to the initial Route
> set. What if a proxy involved in the Record-Route suddenly decides not
> to record-route the future requests of the dialog?
>
> [VP] What makes you think that proxy might want to get out of the
> signalling path? Proxies use record-route for call monitoring and ideally
> would like to stay in the signalling path till the end of the call.
>
>
> rgds,
> Meena
> ----- Original Message -----
> From: Chris Boulton
> To: Hearty, John ; Nataraju A.B. ; Christer Holmberg (LMF) ; Natesan
> Kannan ; Annamalai Meenatchy ; [EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 12:27 AM
> Subject: RE: [Sip-implementors] Record-Route and re-INVITE
>
>
>
> Sounds good to me John.
>
>
>
>
>
> Chris.
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Hearty, John [mailto:[EMAIL PROTECTED]
> Sent: 05 June 2003 17:13
> To: Nataraju A.B.; Christer Holmberg (LMF); Natesan Kannan; Annamalai
> Meenatchy; [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] Record-Route and re-INVITE
>
>
>
>
>
> This whole thread sounds confusing. At a high level, the way it works
is
> as follows:
>
>
>
> 1. The UAS in the initial transaction uses Record-Route headers and
> Contact in the Invite to set the Route set.
> 2. The UAC in the initial transaction uses Record-Route headers and
> Contact in the 200 OK to set the Route set.
> 3. In subsequent requests within the dialog, either UA uses it's
route
> set stored from the initial transaction to build Route headers.
It
> does not rebuild the Route set from Record-Route headers in
> subsequent requests, though the Contact is updated if it changes.
> 4. Proxies may Record-Route subsequent requests. This is only for
> robustness in the case a UA crashes and restarts, and is willing
to
> rebuild the session from the mid-dialog request, in which case it
> uses the new Record-Routes. If a proxy decides not to include
> Record-Route in mid-dialog requests, it will not receive future
> requests in this case.
>
>
>
>
>
> John Hearty
>
>
> Level3
>
>
> -----Original Message-----
> From: Nataraju A.B. [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 05, 2003 6:27 AM
> To: Christer Holmberg (LMF); 'Natesan Kannan'; 'Annamalai
> Meenatchy'; [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] Record-Route and re-INVITE
>
>
>
>
>
>
>
>
> Regards,
> -Nataraju A.B.
> May you live as long as you wish and love as long as you live.
> --Robert A. Heinlein Time Enough for Love. (He may have gotten it
> elsewhere.)
> ----- Original Message -----
>
>
> From: Christer Holmberg (LMF)
>
>
> To: 'Natesan Kannan' ; 'Annamalai Meenatchy' ;
> [EMAIL PROTECTED]
>
>
> Sent: Thursday, June 05, 2003 5:09 PM
>
>
> Subject: RE: [Sip-implementors] Record-Route and re-INVITE
>
>
>
>
>
>
>
>
> Hi,
>
>
>
>
>
> A little strange text in 12.2, I think...
>
>
>
>
>
> What is the use of including a mid-session Record-Route header if
> you can't change the route set? I am not saying one should be
able
> to change the route set, but I wonder what the Record-Route
header
> shall be used for...
>
>
>
>
>
> [Nataraju A.B.]
>
>
> " The Record-Route process is designed to work for any
SIP
> request that initiates a dialog. INVITE is the only
such
> request in this specification, but extensions to the
> protocol
> MAY define others.
> "
>
>
> - Only the dialog creating requests will insert the RR header,
> while other requests must not add the RR header..
>
>
>
>
>
> Regards,
>
>
>
>
>
> Christer Holmberg
>
>
> Ericsson Finland
> -----Original Message-----
> From: Natesan Kannan [mailto:[EMAIL PROTECTED]
> Sent: 5. kes�kuuta 2003 14:39
> To: Christer Holmberg (LMF); 'Annamalai Meenatchy';
> [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] Record-Route and re-INVITE
>
>
> Further to that, the route-set in the dialog never changes even
if
> there is a record-route header in the response (UAS just copies
> this from the request to the response) to a mid-dialog request.
>
>
>
>
>
> "Requests within a dialog MAY contain Record-Route and Contact
> header
> fields. However, these requests do not cause the dialog's
> route
> set
> to be modified, although they may modify the remote target
> URI."
>
>
> -Section 12.2, rfc 3261
>
>
>
>
>
> -Kannan
>
>
>
> ----- Original Message -----
>
>
> From: Christer Holmberg (LMF)
>
>
> To: 'Annamalai Meenatchy' ; [EMAIL PROTECTED]
>
>
> Sent: Thursday, June 05, 2003 4:58 PM
>
>
> Subject: RE: [Sip-implementors] Record-Route and re-INVITE
>
>
>
>
>
>
>
>
> Hi,
>
>
>
>
>
> There has been discussions about if it is allowed to change the
> route set during a session, but in general the re-INVITE is like
> any other mid-session request, ie if you have a route set you
> include the Route headers...
>
>
>
>
>
> Regards,
>
>
>
>
>
> Christer Holmberg
>
>
> Ericsson Finland
> -----Original Message-----
> From: Annamalai Meenatchy [mailto:[EMAIL PROTECTED]
> Sent: 5. kes�kuuta 2003 13:13
> To: [EMAIL PROTECTED]
> Subject: [Sip-implementors] Record-Route and re-INVITE
>
>
> Hi,
>
>
>
>
>
> When we send out re-INVITE do we need to include the Route
> headers with it? Does the Record-route header in the re-INVITE
> change/modify the route-set? When we respond to the re-INVITE,
> do we need to include the Record-route header in the 2xx
> messsage?
>
>
>
>
>
> Thanks & Regards,
> Meena
>
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
