25 Mar
2010
25 Mar
'10
4:16 p.m.
Iñaki Baz Castillo wrote:
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
2010/3/25 Timo Reimann <timo.reimann(a)1und1.de>de>:
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?
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. 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.