Brett & Paul: thanks for your comprehensive reply !
I (we) really appreciate this.
As you had a few questions / comment, I will add some additional info about
the given scenario.
First about the complete scenario:
I only wrote down the failing side of the dialog, but the complete scenario
is as shown below. UAa + UAb + CC-App are new entities here compared to my
initial drawing.
---------
UAa ------| B2BUA |-----UA2 (=Traffic Generator
(queue) | (UA1) | or normal caller)
| |
UAb ------| |
(IVR) ---------
^ CTI Call manipulation
| (switches call UA2 all time between
CallCenter app-/ queue and IVR line )
The caller (UA2) calls a number, which is routed to UAb (IVR)
for announcement. After that it is transferred to a queue. From that moment
the call is regularly transferred back to IVR for new announcement and back
to queue again. This is controlled by the CallCenter which commands the
B2BUA (PBX) to manipulate the call (it also receives events from PBX).
The B2BUA does not use REFER, it only does reINVITEs for media-stream
updates and UPDATE (without SDP) with updated P-Asserted-Identity so show
updated connected party info.
When B2BUA gets that 500 response, as in my described flow, it sends the
BYE to both endpoints which are 'connected' at that moment.
We're testing now with traffic generator to max capacity. It is also tested
inside lab network, so no public network is involved here.
To answer your questions/comments with respect to my given scenario:
- reINVITE always includes SDP in INVITE (Q from Paul)
- I also think that the first INVITE isn't lost but already
being processed inside the SIP-stack. This because it's
a lab network and so lost packet is rare...
(C from Brett and Paul)
- UPDATE has no SDP (only used to give updated P-Asserted-ID)
(Q from Paul)
- 500 error includes no 'Retry-After' (Q from Brett)
About the 'Retry-After' (Q Brett)
We have two types of endpoints (2 different stacks) which encountering
given scenario (and ending into unwanted BYE from B2BUA):
- PJSIP stack (2.x branch): returning: 500 Invalid Seq
- Sofia-SIP (1.12.11) : returning: 500 Internal Server Error.
Sofia-SIP is originated from Nokia Development center.
Both PJSIP and Sofia-SIP do not include the 'Retry-After' in given scenario.
Summarizing (if I recall your comments correctly):
The UPDATE through reINVITE sequence is correct.
But preferable the UA1 (B2BUA) should not terminate the dialog on that 500
error immediately. It should try serialize them (so UPDATE after complete
reINVITE) or do another retry of the UPDATE. If that fails again, it could
decide to kill the dialog.
Also it would be great if the UA2 (the endpoints) could include a
'Rety-After 0' is indicator for UA1 (B2BUA).
With regards,
Eize
On Tue, Sep 22, 2015 at 4:30 PM, Brett Tate <br...@broadsoft.com> wrote:
> > 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 (because
> of dropped packets or other reasons), it can cause a 500 response
> (hopefully with Retry-After 0) to be generated as mentioned within RFC
> 3261 section 12.2.2.
>
>
> > Is an in-dialog UPDATE that crosses a not-completed reINVITE
> > (as shown in above flow) allowed?
>
> Sending a request such as UPDATE immediately after re-INVITE is valid.
> Based upon the information you provided, it is behaving as though the
> first re-INVITE was somehow dropped and the CSeq ordering issue is
> observed when processing the retry after UPDATE.
>
>
> > Should the B2BUA wait with the UPDATE until the ACK?
>
> If the sender wants to ensure no ordering issue, it needs to queue the
> UPDATE. If the sender wants to recover from the CSeq issue, it should try
> again based upon the 500 response (which hopefully included a Retry-After
> 0). Unfortunately RFC 3261 did not allocate a response code specifically
> for the CSeq issue. Thus the UAC does not really know the 500 was because
> of a CSeq issue. However, the inclusion of a Retry-After header with a
> value of 0 provides a good indication that there was an ordering issue (or
> similar issue) and immediately trying again might work.
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
