Re: [sr-dev] improving the dialog module

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.