25 Mar
2010
25 Mar
'10
2:52 p.m.
2010/3/25 Timo Reimann <timo.reimann(a)1und1.de>de>:
Good reason :)
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?
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…
Best regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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. 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. 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.