Inline
On 9/23/15 3:23 AM, Eize Slange wrote:
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).
That pretty much covers it.
The problem with trying to recover from the 500 response is that it
isn't unique to sequence errors, and you probably don't want to retry
other reasons that might result in a 500. The Retry-After would be a
useful qualifier if you could rely on it being present in the case of
sequence errors but, as you see, that isn't reliable. Parsing the text
in the 500 response is also a very unreliable approach.
The best I can say about that is that when you send a request you note
if it is the sort of request where you anticipate a sequence error is
possible and retryable. Then if you get a 500 response in that case,
retry it.
Or, restructure code to serialize all in-dialog requests. (Queue pending
requests.) You would have to decide if that is feasible in your code base.
Or, in this case you could conceivably merge the media change with the
P-A-ID change into the same transaction.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
