On 9/14/16 12:00 PM, Harrison, Jason, Vodafone UK 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
What do you mean by "display update"? Are you changing the display name
in the To-URI?
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
Do you mean that there is no text in any RFC covering this specific
case? While I agree there isn't, there also isn't any text that
specifically covers any use case. The normative text covers primitives.
Most of the requirements pertain to transactions or dialogs. AFAICT the
second example violates no requirements. Hence it is to be considered
valid. 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. The key here is that the dialog is known to be
established by both ends (confirmed by the PRACK), so that UPDATE is
permitted. Beyond that, the UPDATE transaction is independent of the
INVITE transaction.
Thanks,
Paul
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
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
