5 Apr
2010
5 Apr
'10
7:48 a.m.
Gang,
We have some new functionality for the nathelper planned that would need
to know final destination URI for the message to work properly.
Currently this means that we have to require script writer to invoke
this function only after all URI transformations have been applied,
which might quite significantly complicate script logic. Moreover it
might be even impossible in some cases to do so, for example when using
t_relay() function, which uses transaction state to determine message
destination.
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).
Any comments and suggestions are welcome.
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
8 Apr
8 Apr
2:47 a.m.
On Sunday 04 April 2010, Maxim Sobolev wrote:
We have some new functionality for the nathelper
planned that would need
to know final destination URI for the message to work properly.
Currently this means that we have to require script writer to invoke
this function only after all URI transformations have been applied,
which might quite significantly complicate script logic. Moreover it
might be even impossible in some cases to do so, for example when using
t_relay() function, which uses transaction state to determine message
destination.
Hi Maxim,
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
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.
Regards,
Henning
5:15 p.m.
Henning Westerholt wrote:
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.
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
On Sunday 04 April 2010, Maxim Sobolev wrote:
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.
We have some new functionality for the nathelper
planned that would need
to know final destination URI for the message to work properly.
Currently this means that we have to require script writer to invoke
this function only after all URI transformations have been applied,
which might quite significantly complicate script logic. Moreover it
might be even impossible in some cases to do so, for example when using
t_relay() function, which uses transaction state to determine message
destination.
Hi Maxim,
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 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.
9 Apr
9 Apr
11:37 p.m.
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.
Regards,
Henning
[..]
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.
12 Apr
12 Apr
6:57 p.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. 
13 Apr
13 Apr
4:35 a.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. 
8:48 a.m.
Maxim,
Could you please clarify the following
> 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.
1) The callback function that you plan on adding - Will the function be
modifying any attributes in the SDP ? Will it be recording any of the
SDP attributes for future use ?
2) Once you have implemented this callback mechanism in Kamailio, will
you be doing something similar for rtpproxy. Callback functions
registered at appropriate points could be used for encryption/decryption
or transcoding.
Thanks and Regards,
Vikram.
5412
days inactive
5420
days old
6 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Maxim Sobolev -
Vikram Ragukumar