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