[sr-dev] Proposal: New Dialog Module Design

[Timo Reimann]

Iñaki Baz Castillo wrote:
> 2010/3/22 Iñaki Baz Castillo <ibc at aliax.net>:
>> 2010/3/22 Timo Reimann <timo.reimann at 1und1.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