Hey Guys,
Was wondering what would be the recommended way to share information between $evapi(msg) received and transaction processors? I have tried $avp() but they do not appear to be available in evapi:message-received route. Trying to avoid here $sht() so I don't need to do extra management to destroy them. Is there any way to "activate" the $avp or $dlg_var based on dialog index, label maybe?
Thanks in advance for any kind of tip!
DanB //
Hello,
On 24/05/15 11:01, DanB wrote:
Hey Guys,
Was wondering what would be the recommended way to share information between $evapi(msg) received and transaction processors? I have tried $avp() but they do not appear to be available in evapi:message-received route. Trying to avoid here $sht() so I don't need to do extra management to destroy them. Is there any way to "activate" the $avp or $dlg_var based on dialog index, label maybe?
have you called t_continue() somewhere?
Note also that you can define a hash table with auto-expires, so you don't need to do manual removal of items in the hash table.
Cheers, Daniel
Hey Daniel,
Thanks for coming back to me.
Yes, called t_continue and for now I have used $var() to pass information back to the route with transaction info recovered. Will that be OK to leave it like that? Is $var() safe to use between event_route[evapi:message-received] and route called by t_continue()? I am just speaking about these two interactions since after t_continue, I will process the vars into $avp().
You can find the .cfg we are using it as part of our test build here:
https://github.com/cgrates/cgrates/blob/master/data/tutorials/kamevapi/kamai... https://github.com/cgrates/cgrates/blob/master/data/tutorials/kamevapi/kamai...
Ta, DanB
Hello,
yes, it is safe to use $var(x) to pass values between the block calling t_continue() and the route executed by t_continue().
Cheers, Daniel
On 25/05/15 10:52, DanB wrote:
Hey Daniel,
Thanks for coming back to me.
Yes, called t_continue and for now I have used $var() to pass information back to the route with transaction info recovered. Will that be OK to leave it like that? Is $var() safe to use between event_route[evapi:message-received] and route called by t_continue()? I am just speaking about these two interactions since after t_continue, I will process the vars into $avp().
You can find the .cfg we are using it as part of our test build here:
https://github.com/cgrates/cgrates/blob/master/data/tutorials/kamevapi/kamai... https://github.com/cgrates/cgrates/blob/master/data/tutorials/kamevapi/kamai...
Ta, DanB
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel,
On 05/25/2015 06:32 AM, Daniel-Constantin Mierla wrote:
yes, it is safe to use $var(x) to pass values between the block calling t_continue() and the route executed by t_continue().
Why is that, when the scope of $var() variables is, as I understand it, maintained only by a given SIP receiver thread?
Regardless, is this true only when async task workers are used, or is this also true with other mechanisms, like resuming suspended transactions in rtimer threads?
$var(x) keeps the value in the context of the process. t_continue() doesn't delegate route execution to other processes, it is executed in the context of same process. So, yes, it is also the same for rtimer processes. Actually, I can bet more for rtimer case, for evapi, I will need to double check, because the libev might create some extra threads around...
In other words, t_continue(tindex, tlabel, rtname) is like:
set_active_transaction(tindex, tlabel); route(rtname);
t_suspend() is the one that parks the transaction and you can resume processing it with t_continue() in other process, so if you set $var(x) before t_suspend(), don't expect proper value at t_continue().
Cheers, Daniel
On 25/05/15 12:35, Alex Balashov wrote:
Daniel,
On 05/25/2015 06:32 AM, Daniel-Constantin Mierla wrote:
yes, it is safe to use $var(x) to pass values between the block calling t_continue() and the route executed by t_continue().
Why is that, when the scope of $var() variables is, as I understand it, maintained only by a given SIP receiver thread?
Regardless, is this true only when async task workers are used, or is this also true with other mechanisms, like resuming suspended transactions in rtimer threads?
Oh, I see. I think I misunderstood the thread when I wandered into it and saw your answer, thinking that the question was whether variables set prior to t_suspend() can be used in the route invoked by t_continue(). I should read more carefully.
-- Alex
On 05/25/2015 06:50 AM, Daniel-Constantin Mierla wrote:
$var(x) keeps the value in the context of the process. t_continue() doesn't delegate route execution to other processes, it is executed in the context of same process. So, yes, it is also the same for rtimer processes. Actually, I can bet more for rtimer case, for evapi, I will need to double check, because the libev might create some extra threads around...
In other words, t_continue(tindex, tlabel, rtname) is like:
set_active_transaction(tindex, tlabel); route(rtname);
t_suspend() is the one that parks the transaction and you can resume processing it with t_continue() in other process, so if you set $var(x) before t_suspend(), don't expect proper value at t_continue().
Cheers, Daniel
On 25/05/15 12:35, Alex Balashov wrote:
Daniel,
On 05/25/2015 06:32 AM, Daniel-Constantin Mierla wrote:
yes, it is safe to use $var(x) to pass values between the block calling t_continue() and the route executed by t_continue().
Why is that, when the scope of $var() variables is, as I understand it, maintained only by a given SIP receiver thread?
Regardless, is this true only when async task workers are used, or is this also true with other mechanisms, like resuming suspended transactions in rtimer threads?
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany -http://www.kamailioworld.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
DanB -
Daniel-Constantin Mierla