Hi,
Adding a small piece in this long discussion for the proxy perspective,
One of simple reasons why a proxy will add a record route to any INVITE /
SUBSCRIBE shall be that it may not know if this is a dialog creation request
or a mid-dialog request. This is a valid condition for a
transaction-stateful proxy.
However as of 3261 there is a critical distinguisher that the dialog
creation request neccessarily shall not have a To tag but a mid-dialog one
neccessarily shall have a To tag, 2543 compliant entities may not have this
restriction.
Moreover it is outside the scope of a transaction stateful proxy to
determine the dialog association of a message.
Hence the simple implementation, mark INVITE and SUBSCRIBE and also NOTIFY
(for forkings) as dialog creation requests and add the record-route to them.
Cheers,
Prasanna
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Shashi
Kaligotla
Sent: Saturday, June 07, 2003 3:04 AM
To: Vishal Phirke; Hearty, John
Cc: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [Sip-implementors] Record-Route and re-INVITE
You are right on that, no midway record-route changes definitely!
--- Vishal Phirke <[EMAIL PROTECTED]> wrote:
>
> 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. kesdkuuta 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. kesdkuuta 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
=====
---------------------------------------------------------------------------
Shashi Kaligotla
(703) 723-8372 [Home] AOL/Yahoo IM: shashionip
(703) 948-3837 [Work] MSN IM: shashidhar_k
---------------------------------------------------------------------------
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
_______________________________________________
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
