Hi Jason, I am curious here (and this might be a newbie question, but I'll ask anyways if it can trigger some interesting discussion), how is this different from the presence event package in RFC 3856? Are you trying to update more than the status of the call on the phone?
Thank you, Julien On Wed, Sep 14, 2016 at 12:00 PM, Harrison, Jason, Vodafone UK < jason.harri...@vodafone.com> wrote: > 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 > -- Julien Marchand QA Specialist | Jive Communications, Inc. Jive.com | 418-478-0989 x2018 | jmarch...@jive.com _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
