Hi Puneet, 200 OK i.e. 5 will contain Contact header which contains target-uri for the UAS. While creating ACK, Request URI should be filled up with that target-uri so proxy will not face any problem in forwarding.
----- Original Message ----- From: "Kumar, Puneet (Puneet)" <[email protected]> To: "Kamini Gangwani" <[email protected]>; <[email protected]>; <[email protected]> Sent: Tuesday, December 11, 2012 8:51 PM Subject: Re: [Sip-implementors] 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 > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ________________________________ DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto. Thank you - OnMobile Global Limited. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
