2010/3/18 Timo Reimann <[email protected]>: >> It could occur a corner case (very famous in SIPit events) in which >> two UAS (UAS1 and UAS2) reply 200 for the INVITE at the same time so >> the proxy must relay *both* 200 responses to UAC which must ACK both >> and later send a BYE for one of them. Until such BYE occurs there are >> two established dialogs in the proxy (or there must be). > > Since it's up to the UAC what to do with these "concurrent dialogs" > (e.g., immediately BYE one dialog, or keep both for a long period of > time) the creation of another, regular dialog should take care of > things. That is, when a response is about to be forwarded for which a > dialog with the same Call-ID and From-tag already exists, create a > completely new dialog. That way, a concurrent dialog created from such a > race condition would be treated and managed just like another dialog > created "regularly", including in-dialog routing as the dialog > identifiers will differ. > > The only issue one have to think about in these scenarios is how to deal > with callbacks as one of the two concurrent dialogs hasn't gone through > the regular "none/early/confirmed" transition but starts off right at > being "confirmed". Maybe a flag or a brand new callback type could be > used to enable users to hook up to dialogs established this very special > way.
I still think that the approach with an unique dialog_in and multiple dialog_out is easier. I'm going to send right now a mail inviting the people to comment all this stuf. I've writen a new proposal for the Dialog moduel trying to achieve all the cases explained in this thread (even complex ones). >> But AFAIK that would fail in case of serial forking as the new branch >> (created after the first one fails) doesn't inherit the callbacks. > > Does serial forking imply deletion of the transaction and creation of a > new one? If so, the dialog callbacks will in fact be destroyed. If not, > each branch's provisional response will map to the same transaction and > hence, to the same dialog. I believe the latter is the case but please > correct me if I am wrong. The new transaction (due to serial forking) should inherit the callbacks applied to the original transaction, but... shouldn't in fact such callbacks be inserted into the proxy *server* transaction? that's an unique transaciton even if the proxy forkes. >> Agree. I'm trying to figure out the best design taking spirals into >> account. It will take some time to me as I don't find a proper >> solution yet (all the solutions have some corner cases or >> vulnerabilities when handling spirals). > > Do you happen to have a list of these corner cases where spiraling or > the dialog module in general fails? I hope this case is covered in the wiki proposal, but please check it :) > I think it would prove really helpful if we make a checklist of items, > including issues we have already discussed and and those which we > haven't but which you may know. That way, we could verify whether any > new approach discussed here is sufficiently good. > > Additionally, I think that as soon as we have figured out the most > important design choices for the improved dialog module, we should set > up a wiki page to maintain the new dialog design and have a rough > specification to implement from. There we go! :) -- Iñaki Baz Castillo <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
