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

[Timo Reimann]

Iñaki Baz Castillo wrote:
> 2010/3/25 Timo Reimann <timo.reimann at 1und1.de>:
>>> 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?

I haven't explicitly considered it but it's easily feasible: When the
second (just marginally slower) 200 response is handled by the dialog
module, the dflags from the already existing dialog_out entry can be
copied into the new dialog_out entry. For better understanding, please
see the updated example for that specific part of the scenario.

However, I'm wondering if this is the way it's supposed to be done. I
consider the second 200 response to result in the creation of a new
dialog, so it seems wrong that the new dialog already comes with set
flags. For instance, there might be use cases where a set of already
configured dflags is not desired or, worse, breaks things.

Configurability of behavior might be one way out. For further
considerations, let me ask you this about mediaproxy: What does that
module do when multiple early responses with early media arrive for a
single INVITE? Will it relay to a different port for each response?


>>> 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:

That's a good improvement. When I wrote the proposal amendment, I had
this feeling that three tables weren't optimal but couldn't get my head
around it. Very much appreciated. :)

I replaced my initial approach with yours.


Cheers,

--Timo