22 Mar
2010
22 Mar
'10
4:03 p.m.
2010/3/22 Timo Reimann <timo.reimann(a)1und1.de>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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>