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
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
