[sr-dev] Proposal: New Dialog Module Design

[Iñaki Baz Castillo]

2010/3/21 Ovidiu Sas <osas at voipembedded.com>:
> IMHO, I think it's better to have a dialog for each initial INVITE (no
> to-tag) that is hitting the proxy and a cloned dialog for each branch.
> The original dialog that is created when the INVITE arrives would be
> for the first branch.  If there's no forking, we are done.

And what about if the forking occurs in a proxy behind us? then there
is still a single outgoing transaction, but with different
early-dialogs in top of it.


> If there is forking, a new dialog will be created (by cloning the
> existing one) for each branch.

This means cloning too much info. Why to clone fixed dialog
information as caller contact, route-set, caller socket, from-tag,
call-id...?
Also, if Alice calls Bob and there is forking (so there are N
early-dialogs) then from the point of view of the caller there is just
one dialog, and not N. This is what the dialog_in table tries to
achieve in my proposal.


> For each reply (forking case), we match the right dialog (based on branch).

Again you miss the case of remote forking.



> Once we have a final reply to the original INVITE, there will be on
> single winning dialog and all the other dialogs will be destroyed.

And what about if there are two 200 at the same time? then both would
arrive to the UAC, the UAC would send a BYE for one of them and such
BYE would terminate the dialog in Kamailio (while it remains active
with the other branch that also replies 200).



> It may be a little heavy, but it's a clean design, easy to follow and
> debug.  And it is addressing all the issues: spiral and forking.
> Just my 2c.

Well, I think addressing all the issues requires more than 10 lines of
text as there are complex cases not considered in your mail.
I strongly suggest you to read the proposal I'm working on (which is
more elaborated than what I tell in my mails):

http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module-design

Of course I'll add again the multidialog approach for spiral
scenarios. But as you can see any other exotic case is addressed in
the proposal (or that is what I've tryed).



> As long as the new dialog work is not affecting the existing dialog,
> I'm happy.  The current dialog design is not perfect, but it works in
> most of the common scenarios.  If one knows the limitations of the
> dialog module, it can come up with workaround solutions and so far I'm
> ok with the current dialog module.

That's the point. I don't consider that the current design of the
dialog module is easily "upgradeable" when coming to address the
corner and special cases described in this thread.


>  It can be improved, of course, but works well for some common scenarios.

So please, tell me what exactly is missing in the proposal I' writting :)


Thanks a lot.



-- 
Iñaki Baz Castillo
<ibc at aliax.net>