Hi Dale and others who have responded, Thanks for the response; the UPDATE does not contain any SDP as it is just for a display update as the call is picked up on another phone
As this behaviour is not covered by the RFCs we are between a rock and a hard place, however I can get the customer PBX to use a re-INVITE instead of an UPDATE, hopefully that will change things Regards -----Original Message----- From: Dale R. Worley [mailto:wor...@ariadne.com] Sent: 14 September 2016 16:56 To: Harrison, Jason, Vodafone UK Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Query on UAS sending 200 for INVITE before it receives a 200 for an UPDATE it sent 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
