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

[Maxim Sobolev]

Henning Westerholt wrote:
> 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.

I am not really sure we need it to be so complicated (call-id lookup and 
whatnot). My current intention is to have some additional structure 
attached to every sip_msg where registered callback hooks are stored and 
called by the core on certain points.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sales at sippysoft.com
Skype: SippySoft