18 Mar
2010
18 Mar
'10
2:47 p.m.
2010/3/18 Timo Reimann <timo.reimann(a)1und1.de>de>:
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).
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.
I hope this case is covered in the wiki proposal, but please check it :)
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. 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. 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 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(a)aliax.net>