[OpenSIPS-Users] [OpenSIPS-Devel] Planning next release - Roadmap

[Iñaki Baz Castillo]

El Tuesday 26 August 2008 17:59:36 Dan Pascu escribió:
> 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.

Did you get sleeping that night?  XD


> > 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).

Yep. As I said before this is more a task for a B2BUA, don't you think?

Best regards.

-- 
Iñaki Baz Castillo
ibc at in.ilimit.es