12 Apr
2010
12 Apr
'10
2:35 p.m.
Hello,
On 4/12/10 10:57 AM, Maxim Sobolev wrote:
Henning Westerholt wrote:
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
On Thursday 08 April 2010, Maxim Sobolev wrote:
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.
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. [..]
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. >
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.