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 involved here (UA1 is actually a B2BUA PBX and UA2
has call to an endpoint behind the B2BUA).
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).
Mind the CSeq in belows flow.
UA1 UA2
------reINVITE (CSeq=10)------>
------UPDATE (CSeq=11)------>
<-----200OK (UPDATE)------->
------reINVITE (CSeq=10)------>
<-----500 Invalid CSeq--------
------ACK (CSeq=10)---------->
------BYE (CSeq=12)---------->
<-----200OK(BYE)---------------
My question:
Is an in-dialog UPDATE that crosses a not-completed reINVITE (as shown in
above flow) allowed? Should the B2BUA wait with the UPDATE until the ACK?
You don't indicate which messages contain SDP. I am guessing that the
reINVITE does and the UPDATE does not.
In that case I see nothing technically invalid in what UA1 has sent.
However there is a risk in doing that, and what you see from UA2 is
consistent with that:
If the first reINVITE is lost, or delayed until after the UPDATE
arrives, then UA2 should act as shown. If it actually received the first
reinvite before the update, then ideally would detect the retransmission
of the reinvite as such and not report an invalid cseq.
But there is no requirement that messages in a dialog be processed in
the order received. Reordering them within the UAS is logically
equivalent to reordering them in the network. This can naturally occur
in a multithreaded UAS. (I have encountered cases where exactly that
happened.)
So, the bottom line is that you may initiate a new message in a dialog
before the previous one completes, but you must then be prepared to get
a 500 response. Since doing this is in effect an optimization, it is not
a good idea to kill the dialog when this happens. Rather, either
serialize your requests, or else have logic to retry them (with a new
CSeq) if they fail for being out of sequence.
(Another place where this can be an issue is with NOTIFY. If you have a
subscription that can change state rapidly you may find that you want to
send a new, revised, NOTIFY before the prior one has been confirmed.
Again you can do that, but must be prepared for them to be reordered. In
this case, when you get a 500 it tells you that a subsequent NOTIFY was
processed first. Typically you can simply ignore the error because the
lost notify isn't important. If it is essential that they all be
processed in order then you need to serialize the sending of the
notifications.)
If it's not allowed, do you know where this is specified in RFC's?
We did some digging, but couldn't find this particular one.
You can look at RFC5407. But I don't believe it covers this particular
case. The situation has been discussed, but I don't remember if it has
been written into an RFC.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
