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

[Henning Westerholt]

On Thursday 08 April 2010, Maxim Sobolev wrote:
> > [..]
> > 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
> 
> Yes, for the module, so that the module can defer some actions for the
> later time. In my case I need to apply some transformations before the
> message gets reassembled for the delivery.

Hello Maxim,

I understand. I have not looked to deep into the event_route implementation, 
but i think Daniel posted some time ago some notes, and there are of course 
the existing implementations.

> >> 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.
> 
> Yes, exactly, I need something for the message. TM callback is not
> really what I am thinking about here. It has to be on the lower level
> than that.

On a lower level than TM, ok. You could use a in memory hash table like with 
the htable module in the configuration, or something similar in a module that 
traces certain messages over an identifier, like the Call-Id. We implemented 
it for a small workaround like functionality in the cfgutils module, the 
'ring' stuff.

What about an extension of the htable module, that it then also exports an 
interface over a module API? Then this could be accessed from custom modules 
and also in the cfg script.

Regards,

Henning