[Kamailio-Devel] RFC: Dialog: Feature-Extensions

[Carsten Bock]

Hi,


Am Dienstag, den 16.09.2008, 17:24 +0200 schrieb Jerome Martin:
> Hi,
> 
> I'd like to jump in because I too have some needs/patches wrt the
> dialog module. We are also using dialog for billing.
> 
> 1/ About your patches :
> > - in case "tight matching" fails (when using the
> Record-Route-Parameter
> > for in-dialog requests), try to find the dialog based on the
> > SIP-Elements in the message
> 
> I think this is already mode 1 in 1.4 ?

As i wrote in my previous mail ;-)

> 
> > - i've moved the loading of dialogs to the first child (rather than
> > during the initialization of the module)
> 
> May I ask what is your goal there ?

Basically, this is required since the create-callbacks (registered by
other modules) is empty when loading the module. The create-callbacks
are registered after loading the dialog module and before creating the
first child.

> 
> > - i'll execute the create_dlg-callbacks when loading from database
> at
> > startup. We do billing based on the dialog module, so we need the
> > callbacks, when a dialog terminates... (and the callbacks should
> also be
> > executed, if the proxy was restarted in the meanwhile ;-)
> 
> I am VERY interested in your create_dlg-callbacks when loading from DB
> stuff !
> As we do billing from dialog too, I was planning on getting to code
> something lalong those lines myself.
> Also, I wondered about loading dialogs with other sockets than the
> local one in case the proxy who created a dialog died meanwhile, have
> you thought about this ?

When looking at the code, it seems the proxy will load all dialogs and
basically ignore the socket if not local.
I thought about implementing a fallback-to-db-feature for the dialog
module, in case we receive a request which is not in the local memory of
the proxy (e.g. in case of a failover due to a failed proxy on the way).
Is this what you mean?

> 
> 2/ I try to use is_in_profile() to determine if requests (ACK, etc...)
> are for an existing dialog in the script. For replies, it works fine,
> but for requests, the dialog callback creating the current_dlg is
> called only during t_relay. So I have a patch that adds a callback in
> pre script / request to create the dialog there. It means
> is_in_profile() can now be used from the request route to check if an
> ACk, a re-INVITE, etc... belongs to an existing dialog. It does not
> work for CANCELs.

I haven't used the profiles of the dialog-module so far, but sounds
interesting...

> 
> 3/ I use 1.4 now, but I have patches for 1.3 (not ported yet ...) that
> (quoting from memory) :
>     . handles REQBYE properly when dialog is in DELETED state

Could you clarify, what you mean by "not handled properly"?

>     . adds an extra_info column in the dialog from an avp (I think
> this one is now obsolete)
>     . move deleted dialogs to an other "archive" table instead of
> deleting them

I would say, these are quite custom requirements. Maybe you could
provide patches on the tracker, so these enhancements are not lost. I
believe, these enhancements need further discussion.

> 
> 4/ I have partial patches that were aimed at :
>     . saving the dialogs earlier in DB, as soon as the INVITE is
> received

Is there any special use-case for this, why is this required?

>     . adding a new state to the state_machine, RINGING
> 

What's the difference to the state "early"? A dialog should have the
state "early", if a provisional response was received...

Kind regards,

Carsten

> Please comment on this too :-)
> I do not want to hijack the thread, but I felt relevant to inject here
> my own tweaks, maybe we can do something more structured all
> together ? :-)
> 
> Regards,
> 
> Jérôme Martin | LongPhone
> Responsable Architecture Réseau
> 122, rue la Boetie | 75008 Paris 
> Tel :  +33 (0)1 56 26 28 44
> Fax : +33 (0)1 56 26 28 45
> Mail : jmartin at longphone.fr
> Web : www.longphone.com
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel