[sr-dev] Proposal: New Dialog Module Design

[Henning Westerholt]

On Monday 22 March 2010, Iñaki Baz Castillo wrote:
> [..]
> 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 :)

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