[sr-dev] new dialog module design: tm trigger for dialog management

[Iñaki Baz Castillo]

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

>> But the complete dialog identifier is the union of a dialog_in entry
>> and a dialog_out entry. By itself, a dialog_in entry means "nothing".
>
> I agree with that. However, by attaching dialog callbacks to the
> dialog_in entry, you associate multiple dialog_outs resulting from
> concurrent 200 responses to the same dialog from a user's perspective.
> That's why I believe they need to be separated.

Good reason :)


> Don't get me wrong -- I still want to keep one dialog_out per confirmed
> response. However, I do not see them attached properly under the same
> dialog_in entry. Instead, there should be distinct dialog_ins per
> confirmed response, and that includes concurrent 200 responses.

ok






>> Then you couldn't set specific dflags to the secondly generated
>> dialog, neither manage it as any other "normal" dialog.
>> Imagine the UAC receives both 200 and sends the BYE for the first one.
>> Then there would exist an active dialog for which dialog module is not
>> storing its information properly. Do I miss something here?
>
> I think a callback to DLGCB_CONCURRENTLY_CONFIRMED should be treated
> similar to a callback to DLGCB_CREATED, i.e., it is not related to a
> prior dialog. So the earliest moment a user can set dflags on a
> concurrently confirmed dialog is when DLGCB_CONCURRENTLY_CONFIRMED is
> executed, analogous to a regularly created dialog and DLGCB_CREATED.
> After that, both call type's dflags should be usable in the same fashion.

Just to be sure I understand properly:

It should be posible to set a dialog flag even in early state (imagine
mediaproxy module setting a dialog flag to force MediaProxy usage, it
must also work if there is RTP during the 183 session progress).

Is it allowed in your proposal?


>> But I still need to understand the possible limitation in double-200
>> scenarios. Could you please draw an example of how the dialog table(s)
>> would look when such scenario occurs? :)
>
> ...please have a look at the wiki section covering an example scenario I
> just created
>
> http://www.kamailio.org/dokuwiki/doku.php/dialog-stateful:new-dialog-module-design#concurrently_confirmed_calls
>
> and add further comments here.

Just great :)
It simplifies a lot the design. Also the approach of two "dialog_in"
(when two confirmed dialogs) seems really reasonable.

But I don't like the usage of three tables (dialog, dialog_in and
dialog_out), so I've tryed to simplify it by just leaving dialog_in
and dialog_out tables with some modifications:

- dialog_in contains a new field "dialog_id".
- dialog_out doesn't contain "hash_id" field anymore. Instead it
contains "dialog_in".

Please let me know if it's ok or I miss something:

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


Best regards.



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