Hi all, I'm using kamailio 1.4.4. In kamailio.cfg I have call forward on busy and call forward no answer that works good when I redirect the call to a local user. If I redirect the call to a PSTN number using lcr module I receive the error:
ERROR:lcr:next_gw: No ruri_user AVP
If I call directly the PSTN number all is OK and I see in the debug:
DBG:lcr:next_gw: Added ruri_user_avp <0255XXXXXX>
Where I need to set the ruri_user_avp? I just have modparam("lcr", "ruri_user_avp", "$avp(i:500)") in the script. With a very similar configuration and openser 1.2.3 the problem doesn't occur.
Thanks. Regards.
Antonio.
Seems to be solved setting the ruri_user_avp ($avp(i:500) = $rU;) in the failure route where I do the call forwarding. Is this a normal behavior? Thanks. Regards.
Antonio.
2009/4/22 Antonio Reale ant.reale@gmail.com:
Hi all, I'm using kamailio 1.4.4. In kamailio.cfg I have call forward on busy and call forward no answer that works good when I redirect the call to a local user. If I redirect the call to a PSTN number using lcr module I receive the error:
ERROR:lcr:next_gw: No ruri_user AVP
If I call directly the PSTN number all is OK and I see in the debug:
DBG:lcr:next_gw: Added ruri_user_avp <0255XXXXXX>
Where I need to set the ruri_user_avp? I just have modparam("lcr", "ruri_user_avp", "$avp(i:500)") in the script. With a very similar configuration and openser 1.2.3 the problem doesn't occur.
Thanks. Regards.
Antonio.
Antonio Reale writes:
Seems to be solved setting the ruri_user_avp ($avp(i:500) = $rU;) in the failure route where I do the call forwarding. Is this a normal behavior?
no it is not. both avp (ruri_user_avp and gw_uri_avp) are internal avps that are set automatically when you call the functions (load_gws, next_gw) correctly.
-- juha
Antonio Reale writes:
If I redirect the call to a PSTN number using lcr module I receive the error:
ERROR:lcr:next_gw: No ruri_user AVP
If I call directly the PSTN number all is OK and I see in the debug:
DBG:lcr:next_gw: Added ruri_user_avp <0255XXXXXX>
Where I need to set the ruri_user_avp? I just have modparam("lcr", "ruri_user_avp", "$avp(i:500)") in the script.
check that you also have defined gw_uri_avp. perhaps the error message is wrong.
if you still have the problem, tell exactly which lcr functions you call in which order before the error occurs.
-- juha
Hi Juha,
2009/4/22 Juha Heinanen jh@tutpro.com:
check that you also have defined gw_uri_avp. perhaps the error message is wrong.
I have this parameters defined:
loadmodule "lcr.so" modparam("lcr", "db_url", "mysql://openser:openserrw@db/kamailio") modparam("lcr", "gw_table", "gw") modparam("lcr", "gw_name_column", "gw_name") modparam("lcr", "ip_addr_column", "ip_addr") modparam("lcr", "port_column", "port") modparam("lcr", "uri_scheme_column", "uri_scheme") modparam("lcr", "transport_column", "transport") modparam("lcr", "grp_id_column", "grp_id") modparam("lcr", "lcr_table", "lcr") modparam("lcr", "strip_column", "strip") modparam("lcr", "prefix_column", "prefix") modparam("lcr", "from_uri_column", "from_uri") modparam("lcr", "priority_column", "priority") modparam("lcr", "gw_uri_avp", "$avp(i:709)") modparam("lcr", "ruri_user_avp", "$avp(i:500)") modparam("lcr", "contact_avp", "$avp(i:711)") modparam("lcr", "fr_inv_timer_avp", "$avp(s:fr_inv_timer_avp)") modparam("lcr", "fr_inv_timer", 90) modparam("lcr", "fr_inv_timer_next", 30) modparam("lcr", "rpid_avp", "$avp(s:rpid)") modparam("lcr", "flags_avp", "$avp(i:712)")
if you still have the problem, tell exactly which lcr functions you call in which order before the error occurs.
For PSTN termination: ---------------------------------------------------------------------------------------------------- avp_print(); if(!load_gws()) {
xlog("L_ERR", "Error loading PSTN gateways - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("503", "PSTN Termination Currently Unavailable"); exit; } if(!next_gw()) {
xlog("L_ERR", "No PSTN gateways available - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("503", "PSTN Termination Currently Unavailable"); exit; } -----------------------------------------------------------------------------------------------------
In the debug I see:
Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613b578, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<callee_uuid> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<0 / 1> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613b548, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<acc_state> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<cfb / 3> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613b648, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<acc_caller_domain> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<10.10.45.86 / 11> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613b508, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<acc_caller_user> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<0001 / 4> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613e4a8, flags=0x0002 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: id=<902> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<0001|0001|10.10.45.86 / 21> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613e470, flags=0x0002 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: id=<901> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<0002|0002|sipsvr|call / 25> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613e368, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<acc_callee_domain> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<10.10.45.86 / 11> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613e3f0, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<acc_callee_user> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<0001 / 4> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613e330, flags=0x0083 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<cli> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<sip:0001@sipsvr / 15> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613b5b0, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<caller_cli> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<sip:0002@sipsvr / 15> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: p=0xb613b608, flags=0x0003 Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: name=<caller_uuid> Apr 22 16:17:47 [10540] INFO:avpops:ops_print_avp: val_str=<0002 / 4> Apr 22 16:17:47 [10540] DBG:lcr:do_load_gws: Added matched_gws[0]=[0,0] Apr 22 16:17:47 [10540] DBG:lcr:do_load_gws: Added gw_uri_avp <0sip:|0@10.10.45.228:5060;transport=udp> Apr 22 16:17:47 [10540] DBG:lcr:next_gw: Added flags_avp <0> Apr 22 16:17:47 [10540] ERROR:lcr:next_gw: No ruri_user AVP
-- juha
Thanks. Regards.
Antonio.
Antonio Reale writes:
Apr 22 16:17:47 [10540] DBG:lcr:do_load_gws: Added matched_gws[0]=[0,0] Apr 22 16:17:47 [10540] DBG:lcr:do_load_gws: Added gw_uri_avp <0sip:|0@10.10.45.228:5060;transport=udp> Apr 22 16:17:47 [10540] DBG:lcr:next_gw: Added flags_avp <0> Apr 22 16:17:47 [10540] ERROR:lcr:next_gw: No ruri_user AVP
are you sure that you have not assigned a value to ruri_user_avp yourself? debug should show this upon first call of next_gw:
LM_DBG("added ruri_user_avp <%.*s>\n", val.s.len, val.s.s);
xlog value of ruri_user_avp and gw_uri avp before load_gws() call and befor eeach next_gw() call.
-- juha
Antonio,
For a sample lcr config take a look here: http://www.voipembedded.com/resources/openser_dbtext_lcr.cfg The sample config is for openser 1.3, but you can easily adapt it for kamailio 1.4 or 1.5.
Regards, Ovidiu Sas
On Wed, Apr 22, 2009 at 10:44 AM, Juha Heinanen jh@tutpro.com wrote:
Antonio Reale writes:
Apr 22 16:17:47 [10540] DBG:lcr:do_load_gws: Added matched_gws[0]=[0,0] Apr 22 16:17:47 [10540] DBG:lcr:do_load_gws: Added gw_uri_avp <0sip:|0@10.10.45.228:5060;transport=udp> Apr 22 16:17:47 [10540] DBG:lcr:next_gw: Added flags_avp <0> Apr 22 16:17:47 [10540] ERROR:lcr:next_gw: No ruri_user AVP
are you sure that you have not assigned a value to ruri_user_avp yourself? debug should show this upon first call of next_gw:
LM_DBG("added ruri_user_avp <%.*s>\n", val.s.len, val.s.s);
xlog value of ruri_user_avp and gw_uri avp before load_gws() call and befor eeach next_gw() call.
-- juha
Hi Ovidiu
2009/4/22 Ovidiu Sas osas@voipembedded.com:
For a sample lcr config take a look here: http://www.voipembedded.com/resources/openser_dbtext_lcr.cfg The sample config is for openser 1.3, but you can easily adapt it for kamailio 1.4 or 1.5.
Thanks, I'm giving it a look. Anyway, I'm already using lcr in a production environment and with openser 1.2.3 and a pretty similar configuration I have no problem.
Regards, Ovidiu Sas
Regards, Antonio.
I have lcr 1.5 running in a production environment. I haven't observed any of the issues that you are describing here.
Regards, Ovidiu Sas
On Wed, Apr 22, 2009 at 12:20 PM, Antonio Reale ant.reale@gmail.com wrote:
Hi Ovidiu
2009/4/22 Ovidiu Sas osas@voipembedded.com:
For a sample lcr config take a look here: http://www.voipembedded.com/resources/openser_dbtext_lcr.cfg The sample config is for openser 1.3, but you can easily adapt it for kamailio 1.4 or 1.5.
Thanks, I'm giving it a look. Anyway, I'm already using lcr in a production environment and with openser 1.2.3 and a pretty similar configuration I have no problem.
Regards, Ovidiu Sas
Regards, Antonio.
2009/4/22 Juha Heinanen jh@tutpro.com:
Antonio Reale writes:
are you sure that you have not assigned a value to ruri_user_avp yourself?
Yes. avp(i:500) is present only in modparam("lcr", "ruri_user_avp", "$avp(i:500)").
debug should show this upon first call of next_gw:
LM_DBG("added ruri_user_avp <%.*s>\n", val.s.len, val.s.s);
I can't see similar line in my debug.
xlog value of ruri_user_avp and gw_uri avp before load_gws() call and befor eeach next_gw() call.
Scenario 1: local user --> PSTN
Apr 22 17:48:02 sipsvr1 /usr/sbin/kamailio[10619]: gw_uri_avp before load_gws: '<null>' Apr 22 17:48:02 sipsvr1 /usr/sbin/kamailio[10619]: ruri_user_avp before load_gws: '<null>' Apr 22 17:48:02 sipsvr1 /usr/sbin/kamailio[10619]: gw_uri_avp before next_gw: '0sip:|0@10.10.45.228:5060;transport=udp' Apr 22 17:48:02 sipsvr1 /usr/sbin/kamailio[10619]: ruri_user_avp before next_gw: '<null>' Apr 22 17:48:02 sipsvr1 /usr/sbin/kamailio[10619]: Request leaving server, D-URI='<null>' - M=INVITE RURI=sip:02555XXXX@10.10.45.228:5060;transport=udp ...
Scenario 2: local user --> local user --> PSTN (call forwarding)
Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: gw_uri_avp before load_gws: '<null>' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: ruri_user_avp before load_gws: '<null>' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: gw_uri_avp before next_gw: '0sip:|0@10.10.45.228:5060;transport=udp' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: ruri_user_avp before next_gw: '<null>' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: ERROR:lcr:next_gw: No ruri_user AVP
-- juha
Thanks a lot for the support. Regards. Antonio
Antonio Reale writes:
Scenario 2: local user --> local user --> PSTN (call forwarding)
Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: gw_uri_avp before load_gws: '<null>' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: ruri_user_avp before load_gws: '<null>' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: gw_uri_avp before next_gw: '0sip:|0@10.10.45.228:5060;transport=udp' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: ruri_user_avp before next_gw: '<null>' Apr 22 17:46:23 sipsvr1 /usr/sbin/kamailio[10623]: ERROR:lcr:next_gw: No ruri_user AVP
antonio,
i read 1.4 code and saw that request uri user is saved to ruri_user_avp only if next_gw() is called from request route. so if you call it from failure_route, it will not be saved, which could explain the above error.
so if you do local user -> local user -> pstn forwarding, you need to either route the request back to your proxy and then to pstn, or you need to call next_gw() in route block before you enter failure route even when the request is not yet going to a local user.
in 1.5 the implementation is different in that it is possible to call load_gws() and next_gw() also first time in failure route.
-- juha
Hi Juha,
2009/4/23 Juha Heinanen jh@tutpro.com:
i read 1.4 code and saw that request uri user is saved to ruri_user_avp only if next_gw() is called from request route. so if you call it from failure_route, it will not be saved, which could explain the above error.
I call next_gw the first time in request route and then in the failure route. In the scenario with call forwarding the route for PSTN termination is called from failure route but next_gw that gives the error is in the request route. It seems that the problem is that the ruri_user_avp is no longer defined (initially assigned with modparam("lcr", "ruri_user_avp", "$avp(i:500)")), not the null value of the ruri_user_avp (because before calling nexg_gw it is null also in the working scenario).
REQUEST ROUTE ---------------------------------------------------- route[15] { if(uri =~ "^sip:[0-9]+@") { # only route numeric users to PSTN xlog("L_INFO", "gw_uri_avp before load_gws: '$avp(i:709)'\n"); xlog("L_INFO", "ruri_user_avp before load_gws: '$avp(i:500)'\n"); if(!load_gws()) {
xlog("L_ERR", "Error loading PSTN gateways - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("503", "PSTN Termination Currently Unavailable"); exit; } xlog("L_INFO", "gw_uri_avp before next_gw: '$avp(i:709)'\n"); xlog("L_INFO", "ruri_user_avp before next_gw: '$avp(i:500)'\n"); if(!next_gw()) { xlog("L_ERR", "No PSTN gateways available - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("503", "PSTN Termination Currently Unavailable"); exit; } xlog("L_INFO", "gw_uri_avp after next_gw: '$avp(i:709)'\n"); xlog("L_INFO", "ruri_user_avp after next_gw: '$avp(i:500)'\n");
t_on_failure("1"); route(11); } }
FAILURE ROUTE 1 ---------------------------- failure_route[1] { xlog("L_INFO", "Failure route for PSTN entered - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(20); if(!next_gw()) {
xlog("L_ERR", "Failed to select next PSTN gateway - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); exit; }
t_on_failure("1"); route(11); }
FAILURE ROUTE 2 ---------------------------------------- if($avp(s:cfb) != NULL) { avp_delete("$avp(s:acc_caller_user)/g"); avp_delete("$avp(s:acc_caller_domain)/g"); avp_delete("$avp(s:acc_state)/g"); avp_copy("$avp(s:acc_callee_user)", "$avp(s:acc_caller_user)"); avp_copy("$avp(s:acc_callee_domain)", "$avp(s:acc_caller_domain)"); $avp(s:acc_state) = "cfb"; avp_pushto("$ru", "$avp(s:cfb)"); setflag(29); append_branch();
t_on_branch("1"); xlog("L_INFO", "CFB detected - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); route(13); ### Route that find callee then go to route 15 for PSTN }
The script is based on sipwise generated script and modified to work with 1.4. I didn't add further lcr functions. If you want I can send the entire script.
[CUT]
-- juha
Thank you very much. Regards, Antonio
Antonio Reale writes:
I call next_gw the first time in request route and then in the failure route. In the scenario with call forwarding the route for PSTN termination is called from failure route but next_gw that gives the error is in the request route.
if you call route block from failure route block, the functions you call in that route block are considered to be called from failure route block.
as i told, you either need to (1) route the forwarded call back to your proxy, (20 call next_gw before you enter failure route, or (3) upgrade to 1.5.
-- juha
2009/4/24 Juha Heinanen jh@tutpro.com:
if you call route block from failure route block, the functions you call in that route block are considered to be called from failure route block.
OK.
as i told, you either need to (1) route the forwarded call back to your proxy, (20 call next_gw before you enter failure route, or (3) upgrade to 1.5.
Can't upgrade at this moment, so I will try to use your suggestions. As a last resort, what do you think about forcing the ruri_user_avp value in the failure route? Can it lead up side effects?
-- juha
Regards, Antonio.
2009/4/24 Juha Heinanen jh@tutpro.com:
> Can't upgrade at this moment, so I will try to use your suggestions. > As a last resort, what do you think about forcing the ruri_user_avp > value in the failure route? Can it lead up side effects?
you should be able to do that before calling next_gw().
OK. Thanks for your time.
-- juha
Regards, Antonio.
-
Antonio Reale -
jh＠tutpro.com -
Ovidiu Sas