[sr-dev] improving the dialog module

[Iñaki Baz Castillo]

2010/3/18 Timo Reimann <timo.reimann at 1und1.de>:

>> 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
<ibc at aliax.net>