22 Aug
2013
22 Aug
'13
9:18 p.m.
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
--
Steve Davies: Technical Director, Connection Telecom (Pty) Ltd
Email is preferred, but: Phone: 0878200200
22 Aug
22 Aug
10:14 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
23 Aug
23 Aug
7:55 a.m.
New subject: 477 Unfortunately error on sending to next hop occurred
22 aug 2013 kl. 22:14 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
On 8/22/13 9:18 PM, Steve Davies 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 ;-)
/O
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
...
}
8:13 a.m.
New subject: 477 Unfortunately error on sending to next hop occurred
On 23 August 2013 07:55, Olle E. Johansson <oej(a)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
8:47 a.m.
New subject: 477 Unfortunately error on sending to next hop occurred
23 aug 2013 kl. 08:13 skrev Steve Davies <steve(a)connection-telecom.com>om>:
On 23 August 2013 07:55, Olle E. Johansson <oej(a)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
11:18 a.m.
New subject: 477 Unfortunately error on sending to next hop occurred
On 23 August 2013 08:13, Steve Davies <steve(a)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
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
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?
12:13 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
On 23 August 2013 11:18, Steve Davies <steve(a)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
12:20 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
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(a)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(a)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
12:22 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 23 August 2013 11:18, Steve Davies <steve(a)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(a)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
1:34 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
On 23 August 2013 12:22, Daniel-Constantin Mierla <miconda(a)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
2:24 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
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(a)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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
4:16 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
23 aug 2013 kl. 12:13 skrev Steve Davies <steve(a)connection-telecom.com>om>:
On 23 August 2013 11:18, Steve Davies <steve(a)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
7:08 p.m.
New subject: 477 Unfortunately error on sending to next hop occurred
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
4121
days inactive
4122
days old
12 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Steve Davies