Hello All,
I'm having problems when calling next_gw from a failure_route. It appears that extra characters are getting appended after the transport=udp portion of the INVITE.
This first INVITE that goes out on the wire looks normal. I'm intentionally causing the 1st gateway to be offline (time out) so it failure routes to the next gw: SIP/SD Request: INVITE sip:1310xxxyyyy@192.168.18.13:5060;transport=udp
The next INVITE to the next gw (called from failure_route) fails due to extra characters. Note the \000dp after the transport=udp: SIP/SD Request: INVITE sip:1310xxxyyyy@192.168.142.40:5060;transport=udp\000dp
And the same thing happens on the next failure route with the \0009b SIP/SD Request: INVITE sip:1310xxxyyyy@192.168.101.202:5060;transport=udp\0009b
Looks like I've got extras characters on each of the bad INVITES. \0009b = .9b & \000dp = .dp
A sample config that reproduces the problem looks like this:
# ------------------------------------------------------------- route{ ...snip... route(1); }
# -------------------------------------------------------------
route[1] {
if(!load_gws()){ sl_send_reply("500", "Internal server error\n"); xlog("LCR Failure: Unable to load gateways\n"); exit; };
if(!next_gw()){ sl_send_reply("503", "Service not available"); xlog("LCR Failure: No gateways found\n"); exit; }; t_on_failure("1"); # Process Failures
if (!t_relay()) { sl_reply_error(); }; exit; }
# -------------------------------------------------------------
failure_route[1]{
if(!next_gw()){ t_reply("503", "Service not available"); xlog("$CwrLCR Failure: No gateways found$Cxx\n"); exit; }; t_relay(); exit; } # -------------------------------------------------------------
If I replace the next_gw call in the failure_route with a rewrite_uri(), append_branch() and a t_relay() then it works as desired so I believe that the problem is LCR related.
Debug shows the URI's seem to be correct in the gw_uri_avp: 2(12902) load_gws(): DEBUG: Added gw_uri_avp sip:1|0@192.168.101.202:5060;transport=udp 2(12902) load_gws(): DEBUG: Added gw_uri_avp sip:1|0@192.168.142.40:5060;transport=udp 2(12902) load_gws(): DEBUG: Added gw_uri_avp sip:|0@192.168.18.13:5060;transport=udp
System: Solaris10/Sparc64 OpenSER: 1.2.0 with TLS
Any suggestions or thoughts?
Thanks, Lyle
Lyle Thaut writes:
I'm having problems when calling next_gw from a failure_route. It appears that extra characters are getting appended after the transport=udp portion of the INVITE.
looks like there is a bug in failure route next_gw(). i'll try to locate and fix it. was this with version 1.2?
-- juha
Juha,
Version 1.2.0-tls. Thanks for looking at this...
Lyle
Juha Heinanen wrote:
Lyle Thaut writes:
I'm having problems when calling next_gw from a failure_route. It appears that extra characters are getting appended after the transport=udp portion of the INVITE.
looks like there is a bug in failure route next_gw(). i'll try to locate and fix it. was this with version 1.2?
-- juha
Lyle Thaut writes:
I'm having problems when calling next_gw from a failure_route. It appears that extra characters are getting appended after the transport=udp portion of the INVITE.
i found why next_gw() in failure route does not work in 1.2. in version 1.1 action.c APPEND_BRANCH_T was implemented like this:
case APPEND_BRANCH_T: 292 if ((a->p1_type!=STRING_ST)) { 293 LOG(L_CRIT, "BUG: do_action: bad append_branch_t %d\n", 294 a->p1_type ); 295 ret=E_BUG; 296 break; 297 } 298 s.s = a->p1.string; 299 s.len = s.s?strlen(s.s):0; 300 ret = append_branch( msg, &s, &msg->dst_uri, 0, a->p2.number, 0, 301 msg->force_send_socket); 302 break;
whereas in 1.2 it has been changed to this:
case APPEND_BRANCH_T: 481 /* WARNING: even if type is STRING_ST, it expects a str !!!*/ 482 if ((a->elem[0].type!=STRING_ST)) { 483 LOG(L_CRIT, "BUG: do_action: bad append_branch_t %d\n", 484 a->elem[0].type ); 485 ret=E_BUG; 486 break; 487 } 488 if (a->elem[0].u.s.s==NULL) { 489 ret = append_branch(msg, 0, &msg->dst_uri, 0, 490 a->elem[1].u.number, getb0flags(), msg->force_send_socket); 491 /* reset all branch info */ 492 msg->force_send_socket = 0; 493 setb0flags(0); 494 if(msg->dst_uri.s!=0) 495 pkg_free(msg->dst_uri.s); 496 msg->dst_uri.s = 0; 497 msg->dst_uri.len = 0; 498 } else { 499 ret = append_branch(msg, &a->elem[0].u.s, &msg->dst_uri, 0, 500 a->elem[1].u.number, getb0flags(), msg->force_send_socket); 501 } 502 break;
i must have missed a warning about the change devel mailing list (if there was one) and therefore didn't know to react.
i'll submit a patch to lcr module soon.
-- juha