[sr-dev] RFC: adding new callback mechanism into core API

Henning Westerholt henning.westerholt at 1und1.de
Wed Apr 7 18:47:01 CEST 2010


On Sunday 04 April 2010, Maxim Sobolev wrote:
> We have some new functionality for the nathelper planned that would need
> to know final destination URI for the message to work properly.
> Currently this means that we have to require script writer to invoke
> this function only after all URI transformations have been applied,
> which might quite significantly complicate script logic. Moreover it
> might be even impossible in some cases to do so, for example when using
> t_relay() function, which uses transaction state to determine message
> destination.

Hi Maxim,

so the callback you think about should be registered in the configuration, or 
the module, e.g. nathelper? If the latter, then perhaps the event_route stuff 
that Daniel implemented some time ago may be help you here. It looks that it 
could fit to your needs, more informations can e.g. be found here:
http://by-miconda.blogspot.com/2009/12/best-of-new-in-kamailio-300-9.html

> Therefore, I see the need for a callback mechanism in core, allowing
> callback functions to be registered on per-message basis and then to be
> executed in some well-defined points of message processing. The
> mechanism could be sufficiently generic to allow different uses. One of
> the other use that I have in mind is destructor callback, which is to be
> called when the message structure is being freed, so that modules would
> be able to release any resources allocated (memory, connections,
> descriptors, etc).

Did i understand you correctly that you need to have the CB bound to a certain 
message? The existing way of achieving this functionality is to bind against a 
transaction or a dialog, this is not usable here? For the destructor call, i 
think there is a callback when the transaction is destroyed, the 
'TMCB_DESTROY'. The problem i see here is also the message state, that is not 
available if you run in without TM.

Regards,

Henning



More information about the sr-dev mailing list