Re: [Sip-implementors] Building route set from provisional responses
On 10/12/16 12:40 PM, Brett Tate wrote: Hi, Since these are B2BUAs, there are *three* different early dialogs here: - UAC:B2BUA1 - B2BUA1:B2BUA2 - B2BUA2:UAS All the rules regarding route sets, etc. apply separately to each. I agree. However, I just wanted to mention that the 3gpp specs appear to be requiring B2BUA Application Servers to add Record-Route instead of replacing a gruu Contact. I'm not sure how well the 3gpp requirement will work since nothing has been specified for building (record routing) routes for use when sending a request to a gruu location. It always seemed to me that you should't be a UA without putting in your own Contact URI. But I have scoured 3261 for support for that opinion and have not found it. So I have (reluctantly) accepted that B2BUAs using Record-Route to stay in the path while leaving the Contact URI unchanged are valid. But Record-Route does cause problems with GRUU. If you aren't careful you can end up in sub-optimal routing spirals. A long time ago I worked on some proposals for additions to IMS that made things work with GRUU. It was complex. And I don't know if that stuff was ever adopted. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Building route set from provisional responses
Hi, > Since these are B2BUAs, there are *three* different > early dialogs here: > - UAC:B2BUA1 > - B2BUA1:B2BUA2 > - B2BUA2:UAS > > All the rules regarding route sets, etc. apply > separately to each. I agree. However, I just wanted to mention that the 3gpp specs appear to be requiring B2BUA Application Servers to add Record-Route instead of replacing a gruu Contact. I'm not sure how well the 3gpp requirement will work since nothing has been specified for building (record routing) routes for use when sending a request to a gruu location. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Building route set from provisional responses
On 10/12/16 8:16 AM, Gagandeep Singh wrote: Considering below scenario. (Please view in fixed-width font) UAC B2BUA1 B2BUA2 UAS |--INVITE->| | | | |--INVITE->| | | | |--INVITE->| | | | | | | |<---180---| | |<---180---| | |<---180---| | | | | | | |<---183(100rel)---| | | | | | | |--PRACK-->| | | | |(-PRACK?>)| | | | | | (1) Route set due to 180: , (2) Route set due to 183: Since these are B2BUAs, there are *three* different early dialogs here: - UAC:B2BUA1 - B2BUA1:B2BUA2 - B2BUA2:UAS All the rules regarding route sets, etc. apply separately to each. B2BUA1 has not received a reliable provisional from B2BUA2, so it cannot send a PRACK. People like to think that there is a single dialog between UAC and UAS, but that can't be with B2BUAs. They can try to maintain the illusion by carefully correlating the messages on each side. But as soon as you depart from proxy behavior you are going to encounter cases where that strategy breaks down. As a B2BUA developer it is your responsibility to follow all the rules on each side of your B2BUA. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Building route set from provisional responses
Gagandeep Singh writes: > Considering below scenario. (Please view in fixed-width font) > > UAC B2BUA1 B2BUA2 UAS > |--INVITE->| | | > | |--INVITE->| | > | | |--INVITE->| > | | | | > | | |<---180---| > | |<---180---| | > |<---180---| | | > | | | | > |<---183(100rel)---| | | > | | | | > |--PRACK-->| | | > | |(-PRACK?>)| | > | | | | > > (1) Route set due to 180: , > (2) Route set due to 183: > > PRACK should be routed as per (2), which will not be possible if route set > (1) is used. As all the responders have indicated, within a dialog, the UAS MUST provide the same Record-Routes for all the provisional responses, which is indeed the set of Record-Routes that was attached to the INVITE when it received it. When B2BUAs are operating, there are two methods of operation: (1) operate the incoming and outgoing dialogs as specified in RFC 3261, that is, be a UAC connected to a UAS, or (2) act as a "quasi-proxy", which does not fully terminate either the incoming or outgoing dialog, but also modifies the messages within the dialog in ways that are not permitted by RFC 3261. In the latter case, the B2BUA has to ensure that the message flow appears to the upstream and downstream devices to be operating according to RFC 3261. (That is not easy to do.) In the example you diagram, if B2BUA1 is operating in mode (1), then the PRACK terminates at B2BUA1; B2BUA1 sends a 200 response for it. But also, the 180 and the 183 going to UAC do not contain Record-Route headers for B2BUA2 or UAS; B2BUA1 is the UAS for the dialog with UAC. B2BUA1 MUST NOT send a PRACK to B2BUA2 because B2BUA1 has not received a 100rel provisional response from B2BUA2. If B2BUA1 is operating in mode (2), it still MUST NOT send a PRACK to B2BUA2. Since it decided to send the 183 itself, it knows that it MUST provide the response to the PRACK it receives for the 183 -- despite that it MUST have provided the 183 with the same Record-Route headers that were on the 180 going to UAC. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Building route set from provisional responses
> (1) Route set due to 180: , > (2) Route set due to 183: > > PRACK should be routed as per (2), which will > not be possible if route set (1) is used. > > Kindly guide where am I missing. The B2BUA needs to be smart enough to know to not relay the PRACK even though the Route might indicate to do so. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Building route set from provisional responses
> Suppose UAC receives multiple provisional responses > before confirmation of the dialog (2xx), and each > provisional response has a different set of Record-Route > headers. (Each provisional response is within the same > early dialog. i.e. same From-tag and To-tag.) > > In this scenario: > 1. Should UAC update its route set according to latest > Record-Route headers received? > 2. Or should UAC retain the route set formed from first > provisional response? > > It is noted that "final" route set will be built from > Record-Routes in 2xx response. In my opinion, the answer to the question should be irrelevant since the UAS should be providing the same Record-Route within the 101-299 responses to INVITE (excluding 199 situation mentioned within RFC 6228). However, the answer is relevant since there are vendors not including the Record-Route because they ignore the fact that the sent 1xx might create a dialog because of dropped/reordered responses or UAC forgot dialog (e.g. because of race condition or unwillingness to maintain an infinite number of early dialogs). More specifically for interoperability reasons, I think that the UAS should interpret RFC 3261 section 12.1.1's MUST statement to include Record-Route as applying to every 101-198 response to INVITE during call setup since they don't truly know that it won't create an early dialog. With that said, RFC 6141 updated some of the rules mentioned within RFC 3261 (although I think just associated within Contact instead of also Record-Route). I don't recall either RFC having any normative statements indicating/precluding UAC to allow reliable 1xx's present/missing Record-Route to update the route set during call setup; however from a compliance perspective, it is easier to defend not updating the route set. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Building route set from provisional responses
Considering below scenario. (Please view in fixed-width font) UAC B2BUA1 B2BUA2 UAS |--INVITE->| | | | |--INVITE->| | | | |--INVITE->| | | | | | | |<---180---| | |<---180---| | |<---180---| | | | | | | |<---183(100rel)---| | | | | | | |--PRACK-->| | | | |(-PRACK?>)| | | | | | (1) Route set due to 180: , (2) Route set due to 183: PRACK should be routed as per (2), which will not be possible if route set (1) is used. Kindly guide where am I missing. Warm Regards Gagandeep Singh On Wed, Oct 12, 2016 at 4:27 PM, ankur bansal wrote: > Hi Gagan, > > UAC constructs dialog-set when early dialog is created(on first prov rsp) > and this is maintained for rest of dialog . > Which means on getting first prov response ,route-set is filled.And not > updated on getting further prov responses. > > Later when 200ok comes,route-set can be updated again in dialog-set. > > Can you please explain scenario where provisional responses in same dialog > coming via different route ? > > Regards > Ankur Bansal > > On Wed, Oct 12, 2016 at 1:38 PM, Gagandeep Singh > wrote: > >> Hello >> >> Suppose UAC receives multiple provisional responses before confirmation of >> the dialog (2xx), and each provisional response has a different set of >> Record-Route headers. >> (Each provisional response is within the same early dialog. i.e. same >> From-tag and To-tag.) >> >> In this scenario: >> 1. Should UAC update its route set according to latest Record-Route >> headers >> received? >> 2. Or should UAC retain the route set formed from first provisional >> response? >> >> It is noted that "final" route set will be built from Record-Routes in 2xx >> response. >> >> Warm Regards >> Gagandeep Singh >> ___ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Building route set from provisional responses
Hi Gagan, UAC constructs dialog-set when early dialog is created(on first prov rsp) and this is maintained for rest of dialog . Which means on getting first prov response ,route-set is filled.And not updated on getting further prov responses. Later when 200ok comes,route-set can be updated again in dialog-set. Can you please explain scenario where provisional responses in same dialog coming via different route ? Regards Ankur Bansal On Wed, Oct 12, 2016 at 1:38 PM, Gagandeep Singh wrote: > Hello > > Suppose UAC receives multiple provisional responses before confirmation of > the dialog (2xx), and each provisional response has a different set of > Record-Route headers. > (Each provisional response is within the same early dialog. i.e. same > From-tag and To-tag.) > > In this scenario: > 1. Should UAC update its route set according to latest Record-Route headers > received? > 2. Or should UAC retain the route set formed from first provisional > response? > > It is noted that "final" route set will be built from Record-Routes in 2xx > response. > > Warm Regards > Gagandeep Singh > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Building route set from provisional responses
Hello Suppose UAC receives multiple provisional responses before confirmation of the dialog (2xx), and each provisional response has a different set of Record-Route headers. (Each provisional response is within the same early dialog. i.e. same From-tag and To-tag.) In this scenario: 1. Should UAC update its route set according to latest Record-Route headers received? 2. Or should UAC retain the route set formed from first provisional response? It is noted that "final" route set will be built from Record-Routes in 2xx response. Warm Regards Gagandeep Singh ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors