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

It's ok IMHO.


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

The fact is that I don't use mediaproxy but I do know about its
limitations when parallel forking occurs.
I think it creates a RTP session (different port-in and port-out) for
each branch having RTP (183 with SDP), but I'm not sure at 100%.

However I do know that using "engage_mediaproxy()" function is not
possible just to force MediaProxy for certains branches (i.e: those
detected as natted). This function is based on dialog module (just one
dialog entry is created as we do know). It's like a "dialog flag" so
there is no need to invoke mediaproxy for in-dialog requests as the
information about using or not mediaproxy belongs to the whole dialog.
This of course makes impossible to use mediaproxy just for certain
branches.




>> 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".

Oviously I meant:

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



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

Well, it seems we are very close to a definitive design which would
also handle the most complex cases :)

Thanks a lot for all your work.


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