When looking at a race condition, it is always worth looking at RFC 5407
("Example Call Flows of Race Conditions in SIP", often abbreviated to
"Race Conditions in SIP" or even "Hasebe" in honor of the author). That
is the best collection of carefully analyzed race conditions.
I've added to your example notation of the offers and answers, because
offer/answer processing often controls what is valud and what is not.
"Harrison, Jason, Vodafone UK" <jason.harri...@vodafone.com> writes:
> Hi,
>
> I have an issue and I can't identify if the behaviour is wrong:
>
> Here is a working call
> Provider Customer
> SBC SBC
> INVITE (SDP offer 1)-->
> <--100 Trying
> <--180 Ringing (SDP answer 1)
> PRACK -->
> <-- 200OK (PRACK)
> <-- UPDATE (SDP offer 2)
> 200OK UPDATE (SDP answer 2) -->
> <--200OK (INVITE) (SDP answer 1)
> ACK -->
>
> And here is a failed call
> Provider Customer
> SBC SBC
> INVITE (SDP offer 1) -->
> <--100 Trying
> <--180 Ringing (SDP answer 1)
> PRACK -->
> <-- 200OK (PRACK)
> <-- UPDATE (SDP offer 2)
> <--200OK (INVITE) (SDP answer 1)
> 200OK (UPDATE) (SDP answer 2) -->
> ACK -->
> BYE -->
> <--200OK (BYE)
>
> In the failed call I am being told by the provider that their SBC sent
> a BYE because the 200OK for the INVITE was received before it managed
> to send the 200OK for the UPDATE, I have checked the RFCs and can't
> find if the customer SBC is breaking any rules by sending an 200OK for
> the INVITE before it received a response for the UPDATE
This reasoning seems to be rediculous. The Provider terminates the call
because it receives one message before it has been able to process the
previous message that it received? The only way for the Customer to
avoid that would be to send messages in lockstep, only sending one
message after the response to the previous message had been received.
And for that matter, it is easy for the Provider to handle multiple
incoming messages -- just postpone processing the new message until the
previous message has been processed.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
