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