Hi Puneet, As per RFC 3261, "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. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways."
Since Re-INVITE send within a dialog and 200 OK for Re-INVITE does not contain Route Header and shall contain contact Header, then while sending ACK Contact Header shall be used. Thanks, Kamini -----Original Message----- From: Kumar, Puneet (Puneet) [mailto:[email protected]] Sent: Tuesday, December 11, 2012 8:52 PM To: Kamini Gangwani; [email protected]; [email protected] Subject: RE: Route Set creation from response Thanks Kamini. Then: UAC UAS ---------INVITE------------> (1) <----------200---------------- (2) --------------ACK------------> (3) ---------INVITE--------------> (4) <----------200---------------- (5) After step (5) ACK going from UAC should not have Route header in it? Then how will Proxy forward this ACK in absence of any Route header? Please note here that this 200 at step(4) is response to a reINVITE. Thanks, Puneet -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kamini Gangwani Sent: Tuesday, December 11, 2012 8:08 PM To: [email protected] Subject: Re: [Sip-implementors] Route Set creation from response Hello Puneet, Please refer RFC 3261 Sec-12.1.2 for UAC Behavior which says about receiving response with no Record-Route Header field: "The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog." Thanks, Kamini -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, December 11, 2012 6:55 PM To: [email protected] Subject: Sip-implementors Digest, Vol 117, Issue 2 Send Sip-implementors mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip-implementors digest..." Today's Topics: 1. branch length in Via field (Aro RANAIVONDRAMBOLA) 2. Re: branch length in Via field (Brett Tate) 3. Re: branch length in Via field (Paul Kyzivat) 4. Regarding Expires values in SUBSCRIBE (Santhana Krishnan) 5. Re: Regarding Expires values in SUBSCRIBE (Paul Kyzivat) 6. Request-URI Vs to URI (ikuzar RABE) 7. Re: Request-URI Vs to URI (Olle E. Johansson) 8. Route Set creation from response. (Kumar, Puneet (Puneet)) ---------------------------------------------------------------------- Message: 1 Date: Fri, 7 Dec 2012 17:35:16 +0100 From: Aro RANAIVONDRAMBOLA <[email protected]> Subject: [Sip-implementors] branch length in Via field To: [email protected] Message-ID: <CAEerzHdgJqnXHQDUu3th2DD=ZjS+LwC7Na=vwyyb6myczkh...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi, I did not found anywhere the length of branch (in Via field). I found in RFC 3261 that branch start with "z9hG4bK". But what about length limits ? thanks ------------------------------ Message: 2 Date: Fri, 7 Dec 2012 16:45:58 +0000 From: Brett Tate <[email protected]> Subject: Re: [Sip-implementors] branch length in Via field To: Aro RANAIVONDRAMBOLA <[email protected]>, "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" > I did not found anywhere the length of branch (in Via field). I found > in RFC 3261 that branch start with "z9hG4bK". But what about length > limits? There basically is no limit (unless maybe from a RFC 3261 section 18.1.1 perspective). ------------------------------ Message: 3 Date: Fri, 07 Dec 2012 12:19:38 -0500 From: Paul Kyzivat <[email protected]> Subject: Re: [Sip-implementors] branch length in Via field To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 12/7/12 11:35 AM, Aro RANAIVONDRAMBOLA wrote: > Hi, > > I did not found anywhere the length of branch (in Via field). I found > in RFC 3261 that branch start with "z9hG4bK". But what about length limits ? The *general* answer to "what is the length limit for XYZ in a sip message" is that there is no limit. Certain kinds of individual elements may have limits imposed by other standards. (E.g. the domain name with was discussed recently.) You should construct your implementation accordingly. (One way to deal with this is to simply buffer the entire message and pass around references to substrings of that buffer.) Thanks, Paul ------------------------------ Message: 4 Date: Mon, 10 Dec 2012 01:35:24 -0800 (PST) From: Santhana Krishnan <[email protected]> Subject: [Sip-implementors] Regarding Expires values in SUBSCRIBE To: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=iso-8859-1 Hi,? ? ? ? ? ? ? ?I have copied some statements from few RFCs as shown below.? >From RFC 3265 A natural consequence of the behavior described in the preceding ? ?sections is that an immediate fetch without a persistent subscription ? ?may be effected by sending a SUBSCRIBE with an "Expires" of 0. Of course, an immediate fetch while a subscription is active may be ? ?effected by sending a SUBSCRIBE with an "Expires" equal to the number ? ?of seconds remaining in the subscription. >From RFC 3680 ? ?However, notifications triggered as a result of a fetch operation (a ? ?SUBSCRIBE with Expires of 0) SHOULD result in the full state of all ? ?contacts for all registrations to be present in the NOTIFY. 1) From above paras, Is the Fetch operation done by sending Initial(First) SUBSCRIBE with Expires: 0 ? Which should return in NOTIFY with FULL state. How to effect the Fetch operation in the middle of an active dialog from above. How to send this Expires: with remaining seconds in the subscription. This may create race condition with the Notifier, while calculating the "remaining seconds in the subscription). >From RFC 3856 ? ?In fact, ? ?behavior of the presence agent for handling a SUBSCRIBE request with ? ?Expires of zero is no different than for any other expiration value; ? ?pending or authorized SUBSCRIBE requests result in a triggered NOTIFY ? ?with the current presentity and subscription state. ? ?It is also possible to fetch the current presence state, resulting in ? ?a one-time notification containing the current state. ?This is ? ?accomplished by sending a SUBSCRIBE request with an immediate ? ?expiration. 2) From first para here, In case a SUBSCRIBE with Expires: 0 is sent, then NOTIFY with current presentity state is received from the Notifier. But before this NOTIFY if 200 OK response is received from the Notifier for that SUBSCRIBE(with Expires:0), then the dialog would have been cleared by the Subscriber. Then what is the use of this NOTIFY ? What is the use case here ? 3) From second para here, As per this RFC, a SUBSCRIBE with immediate expiration will result in Fetch operation returning FULL state. What does this immediate expiration mean here ? Is it some small expiration value ? If so then the Notifier may take this as a newly requested Subscribe duration and may?honor?it also, which may not be desired by the Subscriber.? Any clarity on the above statements is appreciated.? thanks & regards Santhana ------------------------------ Message: 5 Date: Mon, 10 Dec 2012 13:24:32 -0500 From: Paul Kyzivat <[email protected]> Subject: Re: [Sip-implementors] Regarding Expires values in SUBSCRIBE To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Santhana, I think you are trying to make this more complex than necessary, and missing the point. The main thing you need to understand is that there is no special case for an expires value of zero. SUBSCRIBE works the same way with an expires value of zero as it does for a non-zero value: - if the SUBSCRIBE outside an existing subscription, it establishes a new subscription. (This is true (conceptually anyway) even if the expires value is zero.) State for that subscription is derived from the request: the expiration time is derived from the expires value; and filters, if any, are set from the body of the message. - if the SUBSCRIBE is within an existing subscription dialog, the state for that subscription is revised based on the content of the SUBSCRIBE message. - regardless of the expiration value (zero or not) and initial NOTIFY is sent. And when a time equal to the expiration time passes, a final NOTIFY is sent and the subscription is ended. The case where the expires value in the SUBSCRIBE is zero is a degenerate case of the above. It means that the ending of the subscription happens immediately when the SUBSCRIBE is processed. So the final NOTIFY needs to be sent at the same time as the initial NOTIFY. So a single NOTIFY serves both purposes. You can use this common behavior to achieve a variety of different goals: - if you want to poll (fetch) the state of the event but don't want to maintain an ongoing subscription, send a SUBSCRIBE out-of-dialog with expires=0. You will get one NOTIFY and will have no ongoing subscription. - if you want to maintain an ongoing awareness of the state of an event, then send a SUBSCRIBE with a non-zero expires value. Capture and save the value of the first NOTIFY. Then each time you get a subsequent NOTIFY, update your saved value with it. Keep track of when the subscription will expire. Before it does, send another SUBSCRIBE within the dialog established by the first one. Again include a non-zero expires value. When you no longer want to track the state of the event, send an in-dialog SUBSCRIBE with expires=0. - if you have a previously established subscription but you have forgotten the latest value (or want to double check it), send another SUBSCRIBE within the dialog established by the first one. Again include a non-zero expires value. Good Luck, Paul On 12/10/12 4:35 AM, Santhana Krishnan wrote: > Hi, > I have copied some statements from few RFCs as shown below. > >>From RFC 3265 > A natural consequence of the behavior described in the preceding > sections is that an immediate fetch without a persistent subscription > may be effected by sending a SUBSCRIBE with an "Expires" of 0. > Of course, an immediate fetch while a subscription is active may be > effected by sending a SUBSCRIBE with an "Expires" equal to the number > of seconds remaining in the subscription. > >>From RFC 3680 > > However, notifications triggered as a result of a fetch operation (a > SUBSCRIBE with Expires of 0) SHOULD result in the full state of all > contacts for all registrations to be present in the NOTIFY. > > 1) From above paras, Is the Fetch operation done by sending Initial(First) > SUBSCRIBE with Expires: 0 ? Which should return in NOTIFY with FULL state. > How to effect the Fetch operation in the middle of an active dialog from > above. How to send this Expires: with remaining seconds in the subscription. > This may create race condition with the Notifier, while calculating the > "remaining seconds in the subscription). > >>From RFC 3856 > > In fact, > behavior of the presence agent for handling a SUBSCRIBE request with > Expires of zero is no different than for any other expiration value; > pending or authorized SUBSCRIBE requests result in a triggered NOTIFY > with the current presentity and subscription state. > > It is also possible to fetch the current presence state, resulting > in > > a one-time notification containing the current state. This is > accomplished by sending a SUBSCRIBE request with an immediate > expiration. > > 2) From first para here, In case a SUBSCRIBE with Expires: 0 is sent, then > NOTIFY with current presentity state is received from the Notifier. But > before this NOTIFY if 200 OK response is received from the Notifier for that > SUBSCRIBE(with Expires:0), then the dialog would have been cleared by the > Subscriber. Then what is the use of this NOTIFY ? What is the use case here ? > > > 3) From second para here, As per this RFC, a SUBSCRIBE with immediate > expiration will result in Fetch operation returning FULL state. What does > this immediate expiration mean here ? Is it some small expiration value ? If > so then the Notifier may take this as a newly requested Subscribe duration > and may honor it also, which may not be desired by the Subscriber. > > > Any clarity on the above statements is appreciated. > > thanks & regards > Santhana > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ------------------------------ Message: 6 Date: Tue, 11 Dec 2012 13:29:40 +0100 From: ikuzar RABE <[email protected]> Subject: [Sip-implementors] Request-URI Vs to URI To: [email protected] Message-ID: <CACNnN_kaNxxC_KpiTsFt7Leqg-AjJz=3wowuyhgdvwzu+1y...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi all, I'd like to know what are the differences between Request-URI and to URI ? from URI and contact URI ? Thanks for your help ------------------------------ Message: 7 Date: Tue, 11 Dec 2012 13:32:17 +0100 From: "Olle E. Johansson" <[email protected]> Subject: Re: [Sip-implementors] Request-URI Vs to URI To: ikuzar RABE <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii 11 dec 2012 kl. 13:29 skrev ikuzar RABE <[email protected]>: > Hi all, > > I'd like to know what are the differences between Request-URI and to URI ? > from URI and contact URI ? URI is a generic concept, a SIP address, like sip:[email protected] Request-URI is the URI in the first line of a SIP request. >From URI is found in the From: header Contact URI is found in the Contact: header To URI is found in the To: header etc :-) They are all URI's. /O ------------------------------ Message: 8 Date: Tue, 11 Dec 2012 13:24:23 +0000 From: "Kumar, Puneet (Puneet)" <[email protected]> Subject: [Sip-implementors] Route Set creation from response. To: "[email protected]" <[email protected]> Message-ID: <db7756d97fa5f04bb007ee2e91c436ff01d...@az-ffexmb04.global.avaya.com> Content-Type: text/plain; charset="us-ascii" Hello, I have a scenario which has below SIP signaling. UAC UAS ---------INVITE------------> (1) <----------200---------------- (2) --------------ACK------------> (3) ---------INVITE--------------> (4) <----------200---------------- (5) 200 mentioned as (2) contain a Record-Route header. UAC uses it to create Route header for ACK in (3) & reINVITE in (4). But 200 at (5) so not have any Record-Route header in it. What should be the UAC behavior? Should it resuse the old route set created after step (2). ? Can you point me any text from RFC which supports this? Thanks, Puneet ------------------------------ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors End of Sip-implementors Digest, Vol 117, Issue 2 ************************************************ =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
