[OpenSIPS-Users] [OpenSIPS-Devel] Planning next release - Roadmap
Dan Pascu
dan at ag-projects.com
Tue Aug 26 17:59:36 CEST 2008
On Tuesday 26 August 2008, Ovidiu Sas wrote:
> There are no various confirmed dialogs. Once a dialog is confirmed,
> all the other branches are canceled.
In an ideal world yes. In practice we have to deal with race conditions
(like a CANCEL and the 200 OK crossing each other in the proxy) and
things are less simple. I even witnessed a case where a 200 OK for the
original INVITE came on a branch that was canceled and even acknowledged
the cancel. The 200 OK came after the cancel was acknowledged and after
the new branch (to the voicemail) was started and has send the INVITE out
and a 180 ringing came over the new branch. After the 200 OK from the 1st
branch came, came a 200 OK from the voicemail as well, and in a twisted
turn of events, the 200 OK from the voicemail was sent before the other
200 OK, even though it arrived later. As a consequence, the 2st 200 OK
coming from the canceled branch to the 1st device did set the callee
elements in the dialog (contact, totag, route set), however the 200 OK
from the voicemail was actually confirmed by the caller and started the
dialog. As a consequence, the whole dialog identification elements that
were stored in the dialog structure were wrong and further in-dialog
messages could not be matched with the dialog.
> Having several PRACKs for different early dialogs going through the
> same dialog should work just fine.
Again, this is like playing the lottery. If one of the endpoints decides
to send something at the same time, the cseq numbers from that and the
internally generated OPTIONS message will conflict. This never happens
with the devices alone, as they monotonely and sequentially increment
their cseq numbers and have full control over it avoiding any conflict.
In the proposed case there are 2 independent sources for the cseq number
which cannot avoid conflicts when generating the next cseq number, except
by chance (i.e. if they do not send at the same time).
--
Dan
More information about the Users
mailing list