Hi,
I see that if 4.0.3 has a network error in sending a request, it sends back a 477 response, but does not execute the t_on_failure route block.
Which I want to use to route the call via a local alternative gateway.
I saw a bug that talked about the failure_exec_mode modparam, but that's not listed in the 4.0.3 documentation.
Is there a way to get this to work?
Thanks, Steve
Hello,
On 8/22/13 9:18 PM, Steve Davies wrote:
Hi,
I see that if 4.0.3 has a network error in sending a request, it sends back a 477 response, but does not execute the t_on_failure route block.
Which I want to use to route the call via a local alternative gateway.
I saw a bug that talked about the failure_exec_mode modparam, but that's not listed in the 4.0.3 documentation.
Is there a way to get this to work?
in the request_route actions, you should do for now:
if(!t_relay()) { # try the next gateway ... }
Cheers, Daniel
22 aug 2013 kl. 22:14 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 8/22/13 9:18 PM, Steve Davies wrote:
Hi,
I see that if 4.0.3 has a network error in sending a request, it sends back a 477 response, but does not execute the t_on_failure route block.
Which I want to use to route the call via a local alternative gateway.
I saw a bug that talked about the failure_exec_mode modparam, but that's not listed in the 4.0.3 documentation.
Is there a way to get this to work?
in the request_route actions, you should do for now:
if(!t_relay()) { # try the next gateway ... }
Please read the full documentation for t_relay. There's a lot of return codes that actually is really helpful. If it fails, read the return code and take action accordingly.
Yeah, I know I'm boring, but we do try to write proper reference documentation in this project ;-)
/O
On 23 August 2013 07:55, Olle E. Johansson oej@edvina.net wrote:
Please read the full documentation for t_relay. There's a lot of return codes that actually is really helpful. If it fails, read the return code and take action accordingly.
Yeah, I know I'm boring, but we do try to write proper reference documentation in this project ;-)
Hi Olle,
Where is this documentation?
Here's all that is said about return codes from t_relay in the 4.0.x module documentation ( http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_relay). Looks like there are docs that I didn't find?
"Returns a negative value on failure -- you may still want to send a
negative reply upstream statelessly not to leave upstream UAC in lurch."
All the examples about re-routing calls are all about doing append_route out of the to_on_failure route. Which works beautifully for "soft" failures etc. Seems a shame this exception must be done differently?
Steve
23 aug 2013 kl. 08:13 skrev Steve Davies steve@connection-telecom.com:
On 23 August 2013 07:55, Olle E. Johansson oej@edvina.net wrote:
Please read the full documentation for t_relay. There's a lot of return codes that actually is really helpful. If it fails, read the return code and take action accordingly.
Yeah, I know I'm boring, but we do try to write proper reference documentation in this project ;-)
Hi Olle,
Where is this documentation?
Here's all that is said about return codes from t_relay in the 4.0.x module documentation (http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_relay). Looks like there are docs that I didn't find?
"Returns a negative value on failure -- you may still want to send a negative reply upstream statelessly not to leave upstream UAC in lurch."
All the examples about re-routing calls are all about doing append_route out of the to_on_failure route. Which works beautifully for "soft" failures etc. Seems a shame this exception must be done differently?
That must be a big OOPS. (embarrassed smile on my lips).
Check here: http://kamailio.org/docs/modules/1.5.x/tm.html#id2514020
Someone more familiar with the tm module code than I am have to upgrade the 4.0 docs and devel as well.
Thanks for pointing that out.
/O
On 23 August 2013 08:13, Steve Davies steve@connection-telecom.com wrote:
Here's all that is said about return codes from t_relay in the 4.0.x module documentation ( http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_relay). Looks like there are docs that I didn't find?
"Returns a negative value on failure -- you may still want to send a
negative reply upstream statelessly not to leave upstream UAC in lurch."
All the examples about re-routing calls are all about doing append_route out of the to_on_failure route. Which works beautifully for "soft" failures etc. Seems a shame this exception must be done differently?
Hi Olle,
Here's what I put in RELAY route block:
$var(rr) = t_relay();
xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n");
if (!$var(rr)) {
sl_reply_error();
}
In 4.0.3, t_relay gives a -1 in the case that there is a physical network issue (in my test I have a "-j DROP" iptables rule)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(_sip._ udp.vc2.connection-telecom.com(36), 33), h=940
Aug 23 10:41:02 ubuntu voipmonitor[1935]: packetbuffer interface: datalink number [0] is not supported
Aug 23 10:41:02 voipmonitor[1935]: last message repeated 17 times
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(_sip._ udp.vc2.connection-telecom.com, 33) failed
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._ udp.vc2.connection-telecom.com, 3
3, 60, 1)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding _sip._ udp.vc2.connection-telecom.com(36) 33 (flag
s=1) at 940
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find( vc2.connection-telecom.com(26), 1), h=1021
Aug 23 10:41:02 ubuntu voipmonitor[1935]: packetbuffer interface: datalink number [0] is not supported
Aug 23 10:41:02 voipmonitor[1935]: last message repeated 3 times
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [resolve.c:954]: get_record(): get_record: skipping 0 NS (p=0x82b143c, end=0x82b143c)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [resolve.c:970]: get_record(): get_record: parsing 0 ARs (p=0x82b143c, end=0x82b143c)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [dns_cache.c:1779]: dns_get_related(): dns_get_related(0xb2f5cd68 ( vc2.connection-telecom.com, 1), 1, *(nil
)) (0)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [dns_cache.c:872]: dns_cache_add_unsafe(): dns_cache_add: adding vc2.connection-telecom.com(26) 1 (flags=0)
at 1021
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [forward.c:213]: get_out_socket(): DEBUG: get_out_socket: socket determined: 0xb716bae8
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(172.16.230.1, 172.16.230.1, 0)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: ERROR: <core> [udp_server.c:611]: udp_send(): ERROR: udp_send: sendto(sock,0xb2f5cdd8,1099,0,41.221.230.60:5060,16): Oper
ation not permitted(1)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: ERROR: tm [../../forward.h:196]: msg_send(): msg_send: ERROR: udp_send failed
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_fwd.c:1369]: t_send_branch(): t_send_branch: send to 41.221.230.60:5060(1) failed
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: ERROR: tm [t_fwd.c:1387]: t_send_branch(): ERROR: t_send_branch: sending request on branch 0 failed
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_funcs.c:357]: t_relay_to(): ERROR:tm:t_relay_to: t_forward_nonack returned error
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_funcs.c:365]: t_relay_to(): -477 error reply generation delayed
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=560 a=26 n=xlog
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: NOTICE: <script>: SLD: in RELAY, t_relay returned -1
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=564 a=16 n=if
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=564 a=2 n=exit
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_lookup.c:1553]: t_unref(): t_unref: delayed error reply generation(-477)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(172.16.230.1, 172.16.230.1, 0)
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_reply.c:1547]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG: trans=0xb2f5aeb8, callback type 512, id 0 entered
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: acc [acc_logic.c:539]: tmcb_func(): acc callback called for t(0xb2f5aeb8) event type 512, reply code 477
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_reply.c:706]: _reply_light(): DEBUG: reply sent out. buf=0xb7157938: SIP/2.0 477 Unfortun..., shmem=0xb2f5c7
18: SIP/2.0 477 Unfortun
Aug 23 10:41:02 ubuntu /usr/local/sbin/kamailio[7136]: DEBUG: tm [t_reply.c:716]: _reply_light(): DEBUG: _reply_light: finished
So I don't get a specific response; not sure how to tell if I'm facing a case where the t_on_failure branch was executed or a case where it was not. Is there a way to get hold of that "-477" error reply referred to in the trace?
Thanks, Steve
On 23 August 2013 11:18, Steve Davies steve@connection-telecom.com wrote:
Here's what I put in RELAY route block:
$var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n"); if (!$var(rr)) { sl_reply_error(); }In 4.0.3, t_relay gives a -1 in the case that there is a physical network issue (in my test I have a "-j DROP" iptables rule)
Trying to find a way to detect the case where t_relay fails but doesn't call the failure block. I dumped some hopeful looking pseudo variables, and tried to use an avp to communicate from the failure branch back to the relay point.
I tried this:
$avp(senttoast) = 0; $var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr) err.rcode is $err.rcode t_r_c is $T_reply_code sent = $avp(senttoast)\n"); if ($var(rr) < 0) { sl_reply_error(); }
and in my failure block I set $avp(senttoast) to 1.
I get:
Aug 23 12:07:02 ubuntu /usr/local/sbin/kamailio[7819]: NOTICE: <script>: SLD: in RELAY, t_relay returned -1 err.rcode is <null> t_r_c is 100 sent = 0
In the case of a 477 being sent back. So I can't find anything distinctive so far.
In the case of a soft failure (I have the upstream send a 500):
Aug 23 12:09:32 ubuntu /usr/local/sbin/kamailio[7817]: NOTICE: <script>: SLD: in RELAY, t_relay returned 1 err.rcode is <null> t_r_c is 100 sent = 0
So the same.
From the trace I can see that the failure block is only executed after the
t_relay returns. The failure block runs on a different pid.
So there is a race. Or maybe the avp doesn't work across branches or something?
Clues would be welcome!
Steve
Hello,
it seems that the flag not to generate the internal reply was lost when adopting the new ser tm module.
Can you try the attached patch on 4.0.x?
Once applied and kamailio reinstalled, before t_relay() use:
t_disable_internal_reply();
An the return code should be -4 in this case.
Let me know if works and I will push the fixes in the git repo, with updates to docs.
Cheers, Daniel
On 8/23/13 12:13 PM, Steve Davies wrote:
On 23 August 2013 11:18, Steve Davies <steve@connection-telecom.com mailto:steve@connection-telecom.com> wrote:
Here's what I put in RELAY route block: $var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n"); if (!$var(rr)) { sl_reply_error(); } In 4.0.3, t_relay gives a -1 in the case that there is a physical network issue (in my test I have a "-j DROP" iptables rule)Trying to find a way to detect the case where t_relay fails but doesn't call the failure block. I dumped some hopeful looking pseudo variables, and tried to use an avp to communicate from the failure branch back to the relay point.
I tried this:
$avp(senttoast) = 0; $var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)err.rcode is $err.rcode t_r_c is $T_reply_code sent = $avp(senttoast)\n"); if ($var(rr) < 0) { sl_reply_error(); }
and in my failure block I set $avp(senttoast) to 1.
I get:
Aug 23 12:07:02 ubuntu /usr/local/sbin/kamailio[7819]: NOTICE:
<script>: SLD: in RELAY, t_relay returned -1 err.rcode is <null> t_r_c is 100 sent = 0 In the case of a 477 being sent back. So I can't find anything distinctive so far. In the case of a soft failure (I have the upstream send a 500): Aug 23 12:09:32 ubuntu /usr/local/sbin/kamailio[7817]: NOTICE: <script>: SLD: in RELAY, t_relay returned 1 err.rcode is <null> t_r_c is 100 sent = 0 So the same. From the trace I can see that the failure block is only executed after the t_relay returns. The failure block runs on a different pid. So there is a race. Or maybe the avp doesn't work across branches or something? Clues would be welcome! Steve _______________________________________________ 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
On 8/23/13 12:20 PM, Daniel-Constantin Mierla wrote:
Hello,
it seems that the flag not to generate the internal reply was lost when adopting the new ser tm module.
Can you try the attached patch on 4.0.x?
Once applied and kamailio reinstalled, before t_relay() use:
t_disable_internal_reply();
correction for the above line, the function name is:
t_set_disable_internal_reply();
Daniel
An the return code should be -4 in this case.
Let me know if works and I will push the fixes in the git repo, with updates to docs.
Cheers, Daniel
On 8/23/13 12:13 PM, Steve Davies wrote:
On 23 August 2013 11:18, Steve Davies <steve@connection-telecom.com mailto:steve@connection-telecom.com> wrote:
Here's what I put in RELAY route block: $var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n"); if (!$var(rr)) { sl_reply_error(); } In 4.0.3, t_relay gives a -1 in the case that there is a physical network issue (in my test I have a "-j DROP" iptables rule)Trying to find a way to detect the case where t_relay fails but doesn't call the failure block. I dumped some hopeful looking pseudo variables, and tried to use an avp to communicate from the failure branch back to the relay point.
I tried this:
$avp(senttoast) = 0; $var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)err.rcode is $err.rcode t_r_c is $T_reply_code sent = $avp(senttoast)\n"); if ($var(rr) < 0) { sl_reply_error(); }
and in my failure block I set $avp(senttoast) to 1.
I get:
Aug 23 12:07:02 ubuntu /usr/local/sbin/kamailio[7819]: NOTICE:
<script>: SLD: in RELAY, t_relay returned -1 err.rcode is <null> t_r_c is 100 sent = 0 In the case of a 477 being sent back. So I can't find anything distinctive so far. In the case of a soft failure (I have the upstream send a 500): Aug 23 12:09:32 ubuntu /usr/local/sbin/kamailio[7817]: NOTICE: <script>: SLD: in RELAY, t_relay returned 1 err.rcode is <null> t_r_c is 100 sent = 0 So the same. From the trace I can see that the failure block is only executed after the t_relay returns. The failure block runs on a different pid. So there is a race. Or maybe the avp doesn't work across branches or something? Clues would be welcome! Steve _______________________________________________ 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-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
On 23 August 2013 12:22, Daniel-Constantin Mierla miconda@gmail.com wrote:
correction for the above line, the function name is:
t_set_disable_internal_reply();
I can't get the parser to agree its valid:
0(29626) DEBUG: <core> [sr_module.c:680]: find_mod_export_record(): find_export_record: <t_set_disable_internal_reply> not found 0(29626) DEBUG: <core> [sr_module.c:680]: find_mod_export_record(): find_export_record: <t_set_disable_internal_reply> not found 0(29626) ERROR: <core> [cfg.y:3431]: yyparse(): cfg. parser: failed to find command t_set_disable_internal_reply 0(29626) : <core> [cfg.y:3570]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 560, column 31: unknown command, missing loadmodule?
It is there in the tm.so binary:
# strings /usr/local/lib/kamailio/modules/tm.so | grep t_set_disable_internal_reply t_set_disable_internal_reply
I applied the patch, did make clean, make all, make install, restarted Kamailio.
Then tried "make group_include="standard standard-dep stable experimental" all" and make install.
I looked at the code and I can't see how its different from other functions that do work.
Feel stupid ...
Steve
Oh, I forgot that the group of t_set_* functions have one parameter, to allow set/unset the flag. Use:
t_set_disable_internal_reply(1);
Daniel
On 8/23/13 1:34 PM, Steve Davies wrote:
On 23 August 2013 12:22, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
correction for the above line, the function name is: t_set_disable_internal_reply();I can't get the parser to agree its valid:
0(29626) DEBUG: <core> [sr_module.c:680]: find_mod_export_record(): find_export_record: <t_set_disable_internal_reply> not found 0(29626) DEBUG: <core> [sr_module.c:680]: find_mod_export_record(): find_export_record: <t_set_disable_internal_reply> not found 0(29626) ERROR: <core> [cfg.y:3431]: yyparse(): cfg. parser: failed to find command t_set_disable_internal_reply 0(29626) : <core> [cfg.y:3570]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 560, column 31: unknown command, missing loadmodule?
It is there in the tm.so binary:
# strings /usr/local/lib/kamailio/modules/tm.so | grep t_set_disable_internal_reply t_set_disable_internal_reply
I applied the patch, did make clean, make all, make install, restarted Kamailio.
Then tried "make group_include="standard standard-dep stable experimental" all" and make install.
I looked at the code and I can't see how its different from other functions that do work.
Feel stupid ...
Steve
23 aug 2013 kl. 12:13 skrev Steve Davies steve@connection-telecom.com:
On 23 August 2013 11:18, Steve Davies steve@connection-telecom.com wrote: Here's what I put in RELAY route block:
$var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n"); if (!$var(rr)) { sl_reply_error(); }In 4.0.3, t_relay gives a -1 in the case that there is a physical network issue (in my test I have a "-j DROP" iptables rule)
Trying to find a way to detect the case where t_relay fails but doesn't call the failure block. I dumped some hopeful looking pseudo variables, and tried to use an avp to communicate from the failure branch back to the relay point.
I tried this:
$avp(senttoast) = 0; $var(rr) = t_relay(); xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr) err.rcode is $err.rcode t_r_c is $T_reply_code sent = $avp(senttoast)\n"); if ($var(rr) < 0) { sl_reply_error(); }and in my failure block I set $avp(senttoast) to 1.
I get:
Aug 23 12:07:02 ubuntu /usr/local/sbin/kamailio[7819]: NOTICE: <script>: SLD: in RELAY, t_relay returned -1 err.rcode is <null> t_r_c is 100 sent = 0
In the case of a 477 being sent back. So I can't find anything distinctive so far.
In the case of a soft failure (I have the upstream send a 500):
Aug 23 12:09:32 ubuntu /usr/local/sbin/kamailio[7817]: NOTICE: <script>: SLD: in RELAY, t_relay returned 1 err.rcode is <null> t_r_c is 100 sent = 0
So the same.
From the trace I can see that the failure block is only executed after the t_relay returns. The failure block runs on a different pid.
So there is a race. Or maybe the avp doesn't work across branches or something?
Clues would be welcome!
THe failure route is executed when a transaction fails, i.e. ends with a code higher than 299.
The failure of t_relay happens when you try to send to something that doesn't exist or something similar.
set
$du="sip:127.0.0.2:1234;transport=udp";
and run t_relay to get an error. Or
$du="sip:steve.davies.learns.kamailio@jburg.example.com;transport=udp";
(for DNS errors)
or
$du = "sip:david.duffet@www.digium.com:80;transport=tcp";
(for connection errors).
Test with those to see different behaviours.
/O
Steve Davies writes:
Trying to find a way to detect the case where t_relay fails but doesn't call the failure block.
daniel did some work on this recently when i brought the issue up regarding dead tcp destinations.
it is now possible to set
t_on_branch_failure("something");
and if t_relay() fails to tcp destination, route block
event_route [tm:branch-failure:something]
gets executed after a timeout.
is your problem something else?
-- juha
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Steve Davies