Hi,
I think we can check whether this is happening everytime when similar
scenario is ran or sometime. This seems to be a race condition. If everytime
similar thing observed then it might be issue of UAS where its not able to
detect Re-INVITE is retransmitted.
Thanks and Regards,
Vivek Tal
I was apparently writing my reply in parallel with Brett. And we have
arrived at essentially the same conclusion.
Thanks,
Paul
On 9/22/15 10:30 AM, Brett Tate wrote:
Consider SIP-dialog between UA1 & UA2.
UA1 sends reINVITE to UA2, and immediately also an in-dialog
UPDATE (to s
On 9/22/15 9:31 AM, Eize Slange wrote:
Hi all,
We've a situation here that happens under high load and so things are
running 'out of sync' / being queued / delayed responses etc. The end
result is that the call is being dropped due to 500 response, which is
unwanted.
Different SIP-stacks are inv
> Consider SIP-dialog between UA1 & UA2.
> UA1 sends reINVITE to UA2, and immediately also an in-dialog
> UPDATE (to send updated P-Asserted-Identity value).
Sending a request such as UPDATE immediately after re-INVITE is valid.
However as you observed if the requests are received out-of-order (be
Hi all,
We've a situation here that happens under high load and so things are
running 'out of sync' / being queued / delayed responses etc. The end
result is that the call is being dropped due to 500 response, which is
unwanted.
Different SIP-stacks are involved here (UA1 is actually a B2BUA PBX a
