[sr-dev] Proposal: New Dialog Module Design

[Iñaki Baz Castillo]

2010/3/22 Timo Reimann <timo.reimann at 1und1.de>:
> When I said "single-dialog", I was thinking "single-dialog-in" while
> still maintaining multiple dialog-outs, not single (or even no)
> dialog-outs.

Humm, I meant the same :)
This is, each dialog-in would have one or more dialog-outs associated.
The point is what to do what a spiral occurs (creating or not a new
dialog-in for such "new" INVITE).

Perhaps you mean that when a spiral occurs no new dialog-in entry
would be created but new dialog-outs would be inserted?
If so, I think it would complex to implement and see no real benefict
for it (perhaps I miss soemthing).


> 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.

MediaProxy module "fails" when using "engage_mediaproxy()" as it
depends on dialog module and, until now, dialog module mantains a
single dialog even if parallel forking occurs, so there is no way for
MediaProxy dialog to force RTP throught the mediaproxy server just for
some of those (early-)dialogs (i.e. those detected as NAT).



> 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.

Ok, but I still don't understand the purpose of such new callback.
What/ would be useful for? an example?


> 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.

The proposal I've writen is supposed to provide it as shown in the examples :)


> 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.

I agree, from the point of view of SIP protocol a dialog exists
between two endpoints. However we are already "breaking" such concept
when we try to "monitor/handle" dialogds in a proxy (which should be
dialog aware). This is, at this point it's not so important to mantain
the "romantic" concept of the SIP protocol :)

Anyhow I've considered the posibility of having different dialog-in
entries (each one with its own dialog-outs entries) just because
Ovidiu explained it's required for QOS module to work.