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.
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
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..
On 8/1/11 7:27 PM, Andrew Pogrebennyk wrote:
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..
OK. Btw, do you set both parameters of t_set_fr(...)?
Cheers, Daniel
Daniel,
On 02.08.2011 11:35, Daniel-Constantin Mierla wrote:
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(...)?
I've tried adding a second parameter, also inserted t_reset_fr() before the call to t_set_fr(), still no luck.
Hello,
On 8/2/11 11:59 AM, Andrew Pogrebennyk wrote:
Daniel,
On 02.08.2011 11:35, Daniel-Constantin Mierla wrote:
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(...)?
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
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla