[sr-dev] improving the dialog module

[Timo Reimann]

Klaus Darilion wrote:
>>> Am 12.03.2010 15:22, schrieb Timo Reimann:
>>>> (2)
>>>> Kamailio maps all forked branches to the same dialog because they all
>>>> carry the same dialog ID, i.e., Call-ID, From-tag, and To-tag. In order
>>>
>>> Why do they have the same to-tag? Actually the to-tag creates a dialog.
>>
>> Yeah my bad, you're completely right. Of course, they do not have any
>> To-tag while still unconfirmed. Still, branches will be mapped to the
>> same dialog.
> 
> So, maybe if a response is received and there is no dialog with this
> totag, just create a new dialog. Also somehow group these early dialogs
> to destroy them in case one of these gets into confirmed state.

Applying your idea to the example from my original post (5xx response
received from branch #1 prior to 200 response from branch #2): On
reception of the 5xx response the proxy would first destroy the dialog
that was created when the request was received. Then, after reception of
the 200, it would detect no matching dialog and (re-)create a new one.
Did I get that right?

If so, my major concern with this approach is that it will break dialog
callback functionality. If a dialog user, upon creation of an
unconfirmed dialog (initial request received), registers for further
callbacks associated with that dialog (for instance, DLGCB_CONFIRMED),
it won't get any further callbacks in the scenario outlined above. The
reason for this is that when the dialog is terminated due to the 5xx
response, all associated callbacks will be swept out too, and the
re-created dialog's structure will not contain any callbacks yet.

One possible workaround to this would be to somehow remember the number
of branches forked initially and not shut down the dialog unless all
branches have failed, just like I mentioned in my original post.

But the 5xx-before-200 is just a special scenario how multiple branches
can affect the dialog state. You'd still need to deal with other cases,
such as multiple branches in the early state. Which leads back to my
initial question on how one could achieve that.


Cheers,

--Timo