12 Apr
2010
12 Apr
'10
4:57 a.m.
Henning Westerholt wrote:
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.
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(a)sippysoft.com
Skype: SippySoft
[..]
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.