1 Aug
2011
1 Aug
'11
5:44 p.m.
I've got stuck today trying to implement some sequential forking
scenario. When the call comes destined to the local user, I'm trying to
reach it sequentially through two alternative extensions. For each
extension, I'm calling t_set_fr with a timeout of 15sec. They reply only
180 and do not pick up the phone. After that the call should go to the
"last resort" PSTN number. I'm calling then t_set_fr with a timeout of
30sec. But immediately after sending INVITE to PSTN gw Kamailio
generates cancel and sends 408 Request Timeout to the initial INVITE.
In the debug log I'm seeing this:
Aug 1 17:34:43 localhost /usr/local/sbin/kamailio[28488]: DEBUG: tm
[t_hooks.c:288]: DBG: trans=0xb60f543c, callback type 1048576, id 0 entered
Aug 1 17:34:43 localhost /usr/local/sbin/kamailio[28488]: DEBUG: tm
[t_reply.c:1634]: DEBUG: relay_reply: branch=1, save=1, relay=-1
Aug 1 17:34:43 localhost /usr/local/sbin/kamailio[28488]: DEBUG: tm
[t_cancel.c:328]: DEBUG: cancel_branch: sending cancel...
Does it look like something familiar to you?
Kamailio version: 3.1.4
Config of tm module:
modparam("tm", "fr_timer", 20000)
modparam("tm", "fr_inv_timer", 120000)
modparam("tm", "restart_fr_on_each_reply", 1)
The rest of config is really simple, I can upload it somewhere if it's
necessary.
--
Sincerely,
Andrew Pogrebennyk
1 Aug
1 Aug
8:12 p.m.
Hello,
On 8/1/11 4:44 PM, Andrew Pogrebennyk wrote:
I've got stuck today trying to implement some
sequential forking
scenario. When the call comes destined to the local user, I'm trying
to reach it sequentially through two alternative extensions. For each
extension, I'm calling t_set_fr with a timeout of 15sec. They reply
only 180 and do not pick up the phone. After that the call should go
to the "last resort" PSTN number. I'm calling then t_set_fr with a
timeout of 30sec. But immediately after sending INVITE to PSTN gw
Kamailio generates cancel and sends 408 Request Timeout to the initial
INVITE.
In the debug log I'm seeing this:
Aug 1 17:34:43 localhost /usr/local/sbin/kamailio[28488]: DEBUG: tm
[t_hooks.c:288]: DBG: trans=0xb60f543c, callback type 1048576, id 0
entered
Aug 1 17:34:43 localhost /usr/local/sbin/kamailio[28488]: DEBUG: tm
[t_reply.c:1634]: DEBUG: relay_reply: branch=1, save=1, relay=-1
Aug 1 17:34:43 localhost /usr/local/sbin/kamailio[28488]: DEBUG: tm
[t_cancel.c:328]: DEBUG: cancel_branch: sending cancel...
Does it look like something familiar to you?
Kamailio version: 3.1.4
Config of tm module:
modparam("tm", "fr_timer", 20000)
modparam("tm", "fr_inv_timer", 120000)
modparam("tm", "restart_fr_on_each_reply", 1)
The rest of config is really simple, I can upload it somewhere if it's
necessary.
does it happen to exceed the max lifetime for transaction?
http://kamailio.org/docs/modules/stable/modules/tm.html#max_inv_lifetime
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
8:27 p.m.
Hi Daniel,
On 01.08.2011 20:12, Daniel-Constantin Mierla wrote:
does it happen to exceed the max lifetime for
transaction?
http://kamailio.org/docs/modules/stable/modules/tm.html#max_inv_lifetime
No, it does not (30 < 150). I've also tried settings max_inv_lifetime to
even greater 300 seconds, no luck..
--
Sincerely,
Andrew Pogrebennyk
2 Aug
2 Aug
11:35 a.m.
On 8/1/11 7:27 PM, Andrew Pogrebennyk wrote:
Hi Daniel,
On 01.08.2011 20:12, Daniel-Constantin Mierla wrote:
OK. Btw, do you set both parameters of
t_set_fr(...)?
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
does it happen to exceed the max lifetime for
transaction?
http://kamailio.org/docs/modules/stable/modules/tm.html#max_inv_lifetime
No, it does not (30 < 150). I've also tried settings max_inv_lifetime
to even greater 300 seconds, no luck..
12:59 p.m.
Daniel,
On 02.08.2011 11:35, Daniel-Constantin Mierla wrote:
I've tried adding a second parameter, also inserted t_reset_fr() before
the call to t_set_fr(), still no luck.
--
Sincerely,
Andrew Pogrebennyk
No, it does
not (30 < 150). I've also tried settings max_inv_lifetime
to even greater 300 seconds, no luck..
OK. Btw, do you set both parameters of
t_set_fr(...)?
26 Aug
26 Aug
10:19 a.m.
Hello,
On 8/2/11 11:59 AM, Andrew Pogrebennyk wrote:
Daniel,
On 02.08.2011 11:35, Daniel-Constantin Mierla wrote:
I've tried adding a second parameter, also inserted t_reset_fr()
before the call to t_set_fr(), still no luck.
I found some time to look over the logs you sent to me. The cancel is
for first branch, not the second. Can you send a sip trace to properly
confirm that and see if something wrong there? From the logs:
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:630]: SIP Request:
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:632]: method: <INVITE>
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:634]: uri: <sip:0115@a.b.c.d:5060>
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:636]: version: <SIP/2.0>
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/parse_via.c:1287]: Found param type 232, <branch> =
<z9hG4bKa397.6dc05bd1.1>; state=16
...
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: tm
[t_cancel.c:328]: DEBUG: cancel_branch: sending cancel...
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:630]: SIP Request:
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:632]: method: <CANCEL>
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:634]: uri: <sip:0116@a.b.c.d:5061>
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/msg_parser.c:636]: version: <SIP/2.0>
Aug 2 15:44:00 localhost /usr/local/sbin/kamailio[32195]: DEBUG: <core>
[parser/parse_via.c:1287]: Found param type 232, <branch> =
<z9hG4bKa397.6dc05bd1.0>; state=16
As you can see the branch parameter for cancel ends in .0, while the
forwarded invite has .1
Cheers,
Daniel
No, it
does not (30 < 150). I've also tried settings max_inv_lifetime
to even greater 300 seconds, no luck..
OK. Btw, do you set both parameters of
t_set_fr(...)?
4843
days inactive
4868
days old
5 comments
2 participants
participants (2)
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla