Iñaki Baz Castillo wrote:
2010/3/22 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2010/3/22 Timo Reimann
<timo.reimann(a)1und1.de>de>:
Assuming a single-dialog approach, what about a
new dialog callback type
that is executed when a spiral is detected, e.g., something like
DLGCB_SPIRALING? Couldn't mediaproxy and akin hook up to that in
addition and thereby continue to work just like they did before?
This would be a
workaround for the current dialog module.
But in the proposal I'm writing (based on all these threads) there is
no need for it as creating different dialogs when spiral occurs is
already implemented (as optional feature).
Also, assuming single-dialog approach with the suggested
DLGCB_SPIRALING callback, how could mediaproxy (or any other module)
manage it in order to set certain behavior for the dialog?
IMHO it would be easier if multiple early dialogs are created when
spiral occurs, so each one has its own hash_id, dflags and so.
When I said "single-dialog", I was thinking "single-dialog-in" while
still maintaining multiple dialog-outs, not single (or even no)
dialog-outs. My understanding of the mediaproxy module is really limited
so I'm just bringing forward an idea for commenting by other people who
know more than I do in that area.
Generally, I was just thinking about a way to get rid of the optional
feature (allow_multiple_dialogs_for_spiral) and replace it by installing
another callback. It's just that, if we could avoid multiple dialog-ins
completely, we wouldn't have to care about (i.e., test) how the new
module implementation behaves for various scenarios in both single- and
multiple dialog-in mode. We'd have just one mode to verify, reducing the
number of code paths.
Moreover, I'm not sure if a simple flag is really all we need. Ovidiu
mentioned the need for multiple endpoints but I don't think the current
proposal could provide that, and probably it shouldn't: After all, what
the dialog module is to model IMHO is SIP dialogs with exactly two peers
per call. Splitting up a single SIP dialog into two Kamailio dialogs
with different endpoints simply doesn't mirror the SIP dialog concept
anymore, and it's the modules built on top of the dialog module which
should deal with that, not the dialog module itself.
Cheers,
--Timo