2010/3/22 Timo Reimann timo.reimann@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.
From the point of view of MediaProxy module it could be useful in the
case we don't want to modify the SDP until the spiral occurs (for any exotic reason I cannot imagine right now).
Regards.