Re: [sr-dev] improving the dialog module

Klaus Darilion wrote: 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