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

[Daniel-Constantin Mierla]

Hello,

On 4/12/10 10:57 AM, Maxim Sobolev wrote:
> 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.
3.0+ has so called core events, used now by topoh and debugger modules. 
The idea is to have callbacks from core at very low impact for core, 
when the callback is not registered.

As I understand you need something before relaying. Try to look at 
triggers of onsend_route and get a place for your callback before it.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla * http://www.asipto.com/ * 
http://twitter.com/miconda * 
http://www.linkedin.com/in/danielconstantinmierla