22 Mar
2010
22 Mar
'10
7:59 p.m.
On Monday 22 March 2010, Iñaki Baz Castillo wrote:
Well, i think that one of the important decisions that must be done in a
design process is to agree and adhere to some scope that is covered from an
implementation. And my proposal for the scope in this regards is that we track
dialogs like they are defined in 3261. This standard is probably not perfect,
but i don't agree to you here that it defines something romantic. ;-)
Its for me the same thing here as in the TM module, which (for the most cases)
only cares about SIP transactions, and not about e.g. dialogs or media
sessions. More advanced functionality is implemented on top of it, in an own
dedicated layer.
Best regards,
Henning
[..]
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.
Hi Iñaki,
first, thanks for your proposal, it helps a lot to better understand this long
discussion! Having read it i must say that i also not like this additional
parameter that much.
Ok, but I still don't understand the purpose of
such new callback.
What/ would be useful for? an example?
This callback is useful for dialog clients (like qos) in order to be monitored
when a spiraled request is received. A way to achive the existing behaviour
without the "allow_multiple_dialogs_for_spiral" parameter.
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" dialogs 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 :)