Thank you Paul. Your reply is much appreciated. Just want to clear my doubt (just to see if my understanding is correct) In my scenario,
CLIENT --> SBC01 ---> SBC02 ---> Core When client sends a CANCEL & SBC01 sends 200 OK to the cancel (this happens before it receives a 200 OK from SBC02) SBC01 sends the CANCEL to SBC02 & SBC02 sends 200 OK to invite first & 200 OK to cancel after that. >From SBC01 - It had received 200 OK for the invite; before it received the 200 >OK for the CANCEL (that is towards SBC02 leg); What should be the behavior of >SBC01? - It should send an ACK to SBC02 for the 200OK for Invite & send a Bye immediately after that. - It should have send a 487 towards the client Is my understanding right? Sylvester, Prasanth +91 959 198 7272 -----Original Message----- From: ext Paul Kyzivat [mailto:[email protected]] Sent: Friday, February 06, 2015 9:23 PM To: Sylvester, Prasanth (NSN - IN/Bangalore); [email protected] Subject: Re: [Sip-implementors] race conditions On 2/6/15 4:31 AM, Sylvester, Prasanth (NSN - IN/Bangalore) wrote: > Hi Paul, > > Thanks for your reply. > For Handling the race conditions, there is already an RFC 5407; I'm familiar with it. (I'm one of the authors.) > however as per few I've consulted, RFC 5407 doesn't have "Normative" status. > Does that mean people aren't obliged to follow the RFC? > If this RFC (5407) is to be followed, I see SBC01 isn't behaving that way. It isn't normative because it doesn't make any changes to existing standards - it merely interprets and clarifies what they meant. > Also, sending a BYE before ACK isn't as per RFC 3261; I didn't mean to suggest sending BYE before ack. Rather, immediately after. Thanks, Paul > Sylvester, Prasanth > +91 959 198 7272 > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of ext Paul > Kyzivat > Sent: Thursday, February 05, 2015 10:02 PM > To: [email protected] > Subject: Re: [Sip-implementors] race conditions > > On 2/5/15 2:49 AM, Sylvester, Prasanth (NSN - IN/Bangalore) wrote: >> Hi Team, >> >> I've a situation, >> Customer A -> SBC01 (XYZ vendor) -> SBC02 (XYZ Vendor) -> Core >> >> Customer A sends an invite to SBC01, which reaches to Core. While Core >> sends a 200 OK & before it reaches the Customer A, Customer A had sent a >> cancel. >> Please see the attached pic. >> >> Now the situation is, >> 1; Customer A sends a cancel to SBC01; >> 2; SBC01 sends 200 OK back to customer A; >> 3; SBC01 passes that CANCEL to SBC02; >> 3; SBC02 sends the 200 OK invite to SBC01. >> 4; SBC02 sends the 200 OK for cancel to SBC01 >> >> Technically, SBC02 has sent a 200OK to invite before it sends 200OK to >> cancel (towards SBC01) >> SBC01 has received CANCEL request from A and 200 Ok'd it; Also it had sent >> CANCEL towards SBC02 as well, however it received 200 OK (INVITE) before >> 200OK (CANCEL). >> >> What should be the behavior of SBC01? SBC02? And Customer A? > > First, note that this could happen if the SBCs were replaced with > proxies. It is quite possible that there will be a race condition > between the cancel and the invite 200 ok. And that can occur in many > places. The bottom line is that it is not an error for the UAC to send a > cancel, get a 200 ok for the cancel, and then still get a 200 ok to the > invite. It must be prepared for that to happen. In that case it can > choose to either handle the call as if the cancel had never been sent, > or it can send an immediate BYE. > > Is that your concern? Or are you explicitly asking if the SBCs may/must > behave differently that proxies would under the same circumstance? > > There is not much in the way of explicit rules for SBCs or B2BUAs in > general, other than the the obvious ones that they must behave like a > UAC on one side and a UAS on the other. (And in practice SBCs do lots of > things that don't meet that requirement.) > > Also note that CANCEL is "special" among SIP requests, in that it is > handled hop-by-hop rather than end to end. So for handling cancel > proxies and SBCs are much more similar than for other requests. > >> ************************************************************************************************************************************************************************************************ >> This is my understanding, >> >> SBC01, it has two roles, >> 1) UAS ,While it talks with Customer A. [Case 1] >> 2) UAC ,while it talks with SBC02 [Case 2] >> >> Case 1/ SBC01 as UAS - Since SBC01 is "receiving CANCEL & responding 200 OK >> for the cancel" it shouldn't have passed 200OK for the invite (which it >> received from SBC02) towards Customer A; >> instead, the behavior should be, >> A) SBC01 should send a 200OK for CANCEL to Customer A(it's doing it) >> B) SBC01 should NOT forward the 200 OK for invite to Customer. >> C) It should send 487 (request terminated) to Customer A. > > What you describe is plausible (in this case the SBC is "adding value" > by eliminating the need for Customer A to deal with it). But I don't > think it is *required* to do so. (Because there aren't any rules for > SBCs.) (The 200 to the cancel only says "I received and understood your > cancel". It is then expected to begin the process of acting on it, but > it can take its sweet time in doing so, and might not get around to it > until it sees a response from the other side.) > >> Case 2/ it's a typical race condition. Where SBC01 has sent a CANCEL to >> SBC01, however SBC02 has send 200OK for invite before sending a 200OK for >> CANCEL. Means, SBC01 has received 200OK for invite first; can be considered >> as a race condition. How to behave in a race condition is mentioned in RFC >> 5407 (click the link below ) >> https://tools.ietf.org/html/rfc5407#page-13<https://tools.ietf.org/html/rfc5407> >> Now, the behavior of SBC01 towards SBC02 should have been, >> A) It should send an ACK to SBC for the 200OK for Invite. >> B) It should send BYE Immediately to SBC (just after ACK). > > Again, while it *could* do so, I'm not aware of anything that says it > must. Some SBCs try to act like proxies most of the time. > > What is your goal here? There is nothing that the SBCs can do that will > totally prevent Customer A from ever seeing a 200 ok to an invite after > successfully sending a cancel. It MUST remain capable of dealing with that. > > Thanks, > Paul > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
