e 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
>
> W
Paul Kyzivat writes:
> There is no *general* requirement that there be only one
> transaction at a time within a dialog, and in fact there are many cases
> where there are more.
Indeed, it is well-known that having multiple transactions in progress
at the same time is value (though uncommon) --
du
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
-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 "Haseb
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 e
On 9/14/16 7:05 AM, Harrison, Jason, Vodafone UK wrote:
Hi,
I have an issue and I can't identify if the behaviour is wrong:
Here is a working call
Provider Customer
SBCSBC
INVITE (SDP offer)-->
<--100 Trying
<--180 Ringing (SDP answer)
PRACK -->
<-- 200OK (
> 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 INV
Hi,
I have an issue and I can't identify if the behaviour is wrong:
Here is a working call
Provider Customer
SBCSBC
INVITE (SDP offer)-->
<--100 Trying
<--180 Ringing (SDP answer)
PRACK -->
<-- 200OK (PRACK)
<-- UPDATE
200OK UPDATE -->
<--200OK (INVITE)
ACK -
