Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
*Background: * Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
*Script config: * onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } }
route(NATDETECT); #!ifdef WITH_RTPENGINE route(RTPMANAGE); #!endif }
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); }
if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); }
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); }
if (!t_relay()) { sl_reply_error(); }
exit; }
route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); }
failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER");
}
*Call Flows: *
The above fix works well when an explicit error reply is received back.
*error reply SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange: * SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards, Kaufman
________________________________ From: Alex A via sr-users Sent: Wednesday, March 19, 2025 4:58 PM To: sr-users@lists.kamailio.org Cc: Alex A Subject: [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
Background: Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
Script config: onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } }
route(NATDETECT); #!ifdef WITH_RTPENGINE route(RTPMANAGE); #!endif }
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); }
if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); }
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); }
if (!t_relay()) { sl_reply_error(); }
exit; }
route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); }
failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER");
}
Call Flows:
The above fix works well when an explicit error reply is received back.
error reply SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. Current timer expiry SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
Maybe I didn't fully understand the problem here, but wouldn't a fr_inv_timer do the trick by setting: loadmodule("tm") modparam("tm", "fr_inv_timer", 10000) // 10 seconds timeout
?
and then using event_route[tm:branch-failure:myroute] to use the second branch?
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
On Thu, Mar 20, 2025 at 4:58 PM Patrick Karton via sr-users < sr-users@lists.kamailio.org> wrote:
If "SBC" in your call flow is a kamailio instance why do you need to cancel branch0 with another dedicated function ?
As soon as kamailio receives an 1xx response without a final response it will send automatically a CANCEL on that branch.
Le 20 mars 2025 14:57, Ben Kaufman via sr-users < sr-users@lists.kamailio.org> a écrit :
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards, Kaufman
*From:* Alex A via sr-users *Sent:* Wednesday, March 19, 2025 4:58 PM *To:* sr-users@lists.kamailio.org *Cc:* Alex A *Subject:* [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
*Background:* Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
*Script config:* onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } }
route(NATDETECT); *#!ifdef WITH_RTPENGINE* route(RTPMANAGE); *#!endif* }
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); }
if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); }
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); }
if (!t_relay()) { sl_reply_error(); }
exit; }
route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); }
failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER");
}
*Call Flows:*
The above fix works well when an explicit error reply is received back.
*error reply SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
HI Sergio,
Thank you for the response. The challenge is that I cannot execute cancel_branch from failure routes (only in onreply_route); Therefore I am not able to place a delay between the CANCEL of branch0 and new branch1 INVITE (they happen to be executed when t_relay runs.
Regards,
On Thu, Mar 20, 2025 at 1:23 PM Sergio Charrua sergio.charrua@voip.pt wrote:
Maybe I didn't fully understand the problem here, but wouldn't a fr_inv_timer do the trick by setting: loadmodule("tm") modparam("tm", "fr_inv_timer", 10000) // 10 seconds timeout
?
and then using event_route[tm:branch-failure:myroute] to use the second branch?
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
On Thu, Mar 20, 2025 at 4:58 PM Patrick Karton via sr-users < sr-users@lists.kamailio.org> wrote:
If "SBC" in your call flow is a kamailio instance why do you need to cancel branch0 with another dedicated function ?
As soon as kamailio receives an 1xx response without a final response it will send automatically a CANCEL on that branch.
Le 20 mars 2025 14:57, Ben Kaufman via sr-users < sr-users@lists.kamailio.org> a écrit :
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards, Kaufman
*From:* Alex A via sr-users *Sent:* Wednesday, March 19, 2025 4:58 PM *To:* sr-users@lists.kamailio.org *Cc:* Alex A *Subject:* [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
*Background:* Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
*Script config:* onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } }
route(NATDETECT); *#!ifdef WITH_RTPENGINE* route(RTPMANAGE); *#!endif* }
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); }
if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); }
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); }
if (!t_relay()) { sl_reply_error(); }
exit; }
route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); }
failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER");
}
*Call Flows:*
The above fix works well when an explicit error reply is received back.
*error reply SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hello Ben,
do you have any reference (e.g. bug tracker, e-mail thread) for the "freeswitch don't support SIP branching"?
It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project.
Thanks,
Henning
From: Ben Kaufman via sr-users sr-users@lists.kamailio.org Sent: Donnerstag, 20. März 2025 15:57 To: sr-users@lists.kamailio.org Cc: Alex A alex.antonevych@replicant.ai; Ben Kaufman bkaufman@bcmone.com Subject: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards, Kaufman
________________________________ From: Alex A via sr-users Sent: Wednesday, March 19, 2025 4:58 PM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A Subject: [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
Background: Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
Script config: onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } }
route(NATDETECT); #!ifdef WITH_RTPENGINE route(RTPMANAGE); #!endif }
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); }
if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); }
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); }
if (!t_relay()) { sl_reply_error(); }
exit; }
route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); }
failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER");
}
Call Flows:
The above fix works well when an explicit error reply is received back.
error reply SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. Current timer expiry SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
The reference is 16 years old, so perhaps my statement would have been better phrased as "didn't support" rather than what was at the time "doesn't support":
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
With that said, the very specific statment of "We currently don't support forked dialogs" is here: https://narkive.com/pl2VL6Gu:6.378.42
It's been a few years since I dealt with the issue first hand, but IIRC it was relatively simple to recreate by relaying an INVITE to a freeswitch that returns failure, then re-targeting that same freeswitch from kamailio failure route.
Regards, Kaufman
________________________________ From: Henning Westerholt Sent: Friday, March 21, 2025 2:41 AM To: Kamailio (SER) - Users Mailing List Cc: Alex A; Ben Kaufman Subject: RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Ben,
do you have any reference (e.g. bug tracker, e-mail thread) for the “freeswitch don’t support SIP branching”?
It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project.
Thanks,
Henning
From: Ben Kaufman via sr-users sr-users@lists.kamailio.org Sent: Donnerstag, 20. März 2025 15:57 To: sr-users@lists.kamailio.org Cc: Alex A alex.antonevych@replicant.ai; Ben Kaufman bkaufman@bcmone.com Subject: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards,
Kaufman
________________________________
From: Alex A via sr-users Sent: Wednesday, March 19, 2025 4:58 PM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A Subject: [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
Background: Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
Script config:
onreply_route[MANAGE_REPLY] {
xlog("L_INFO", "reply $T_reply_code received");
if (t_check_status( "1[1-9][0-9]")) {
t_reset_fr();
} else {
t_set_fr(120000);
}
}
route(NATDETECT);
#!ifdef WITH_RTPENGINE
route(RTPMANAGE);
#!endif
}
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
}
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
setflag(FLT_DLGINFO);
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[TOCARRIER] {
process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER");
route(RELAY);
}
failure_route[MANAGE_FAILURE_CARRIER] {
xlog("L_INFO", "reply $T_reply_code received");
if ($avp(inbound_attempt)<=1){
if ($dlg_var(b2bua)=="true"){
usleep(1900000);
}
route("TOCARRIER");
}
Call Flows:
The above fix works well when an explicit error reply is received back.
error reply SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. Current timer expiry SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
Hi Ben,
thank you. 16 years is indeed a longer time, one could hope that its now fixed in a newer version.
Cheers,
Henning
From: Ben Kaufman bkaufman@bcmone.com Sent: Freitag, 21. März 2025 14:21 To: Henning Westerholt hw@gilawa.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex A alex.antonevych@replicant.ai Subject: Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
The reference is 16 years old, so perhaps my statement would have been better phrased as "didn't support" rather than what was at the time "doesn't support":
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
With that said, the very specific statment of "We currently don't support forked dialogs" is here: https://narkive.com/pl2VL6Gu:6.378.42
It's been a few years since I dealt with the issue first hand, but IIRC it was relatively simple to recreate by relaying an INVITE to a freeswitch that returns failure, then re-targeting that same freeswitch from kamailio failure route.
Regards, Kaufman
________________________________ From: Henning Westerholt Sent: Friday, March 21, 2025 2:41 AM To: Kamailio (SER) - Users Mailing List Cc: Alex A; Ben Kaufman Subject: RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Ben,
do you have any reference (e.g. bug tracker, e-mail thread) for the "freeswitch don't support SIP branching"?
It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project.
Thanks,
Henning
From: Ben Kaufman via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Sent: Donnerstag, 20. März 2025 15:57 To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai>; Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> Subject: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards,
Kaufman
________________________________
From: Alex A via sr-users Sent: Wednesday, March 19, 2025 4:58 PM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A Subject: [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
Background: Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
Script config:
onreply_route[MANAGE_REPLY] {
xlog("L_INFO", "reply $T_reply_code received");
if (t_check_status( "1[1-9][0-9]")) {
t_reset_fr();
} else {
t_set_fr(120000);
}
}
route(NATDETECT);
#!ifdef WITH_RTPENGINE
route(RTPMANAGE);
#!endif
}
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
}
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
setflag(FLT_DLGINFO);
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[TOCARRIER] {
process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER");
route(RELAY);
}
failure_route[MANAGE_FAILURE_CARRIER] {
xlog("L_INFO", "reply $T_reply_code received");
if ($avp(inbound_attempt)<=1){
if ($dlg_var(b2bua)=="true"){
usleep(1900000);
}
route("TOCARRIER");
}
Call Flows:
The above fix works well when an explicit error reply is received back.
error reply SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. Current timer expiry SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
It was about two years ago that I tested, so my statments here are just what I recall, and therefor may be incorrect:
I believe that I tested against 1.10, and there was no change in Freeswtich behavior. Looking through issues it seems like Freeswitch's support team's position was that the CSeq number should be incremented. Of course, this would be problematic at the proxy level as it would then have to track the offset it's creating from the UAC (I know there are functions for this in Kamailio, but this doesn't seem the appropriate place for this). There are some old issues reported for the same type of thing within Kamailio, where Daniel pointed that the issue was Freeswitches behavior, so it was a both sides pointing fingers situation (although I'm pretty sure Daniel is correct).
I think many people encoutring this issue went ahead with the "sleep" solution. I inherited maintenance of an environment where this was done, and the issue came to my attention via performance issues caused by the blocking sleep call. Since I also had an array of Freeswitch servers which could handle the request, my direct solution was to just make sure that the failure route pointed to a different Freeswitch than the request route. That was a workable situation in my scenario and much easier than trying to convince someone the behavior is incorrect. My guess is that the Freeswitch behavior is the same to this day simply because it hasn't been revisited.
On a personal level, I'm in the process of removing these Freeswitch instances. This isn't a complaint against Freeswitch, but rather that it was installed to handle media relay and RTPEngine is much better suited if that's the only task that's needed. Given this, I don't have a lot of motivation to dig into he issue further, but if needed, I think I could pretty easily cook up a small docker-compose environment that illustrates the problem.
Regards, Kaufman ________________________________ From: Henning Westerholt hw@gilawa.com Sent: Friday, March 21, 2025 8:22 AM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex A alex.antonevych@replicant.ai; Ben Kaufman bkaufman@bcmone.com Subject: RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Ben,
thank you. 16 years is indeed a longer time, one could hope that its now fixed in a newer version.
Cheers,
Henning
From: Ben Kaufman bkaufman@bcmone.com Sent: Freitag, 21. März 2025 14:21 To: Henning Westerholt hw@gilawa.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Alex A alex.antonevych@replicant.ai Subject: Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
The reference is 16 years old, so perhaps my statement would have been better phrased as "didn't support" rather than what was at the time "doesn't support":
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
With that said, the very specific statment of "We currently don't support forked dialogs" is here: https://narkive.com/pl2VL6Gu:6.378.42
It's been a few years since I dealt with the issue first hand, but IIRC it was relatively simple to recreate by relaying an INVITE to a freeswitch that returns failure, then re-targeting that same freeswitch from kamailio failure route.
Regards,
Kaufman
________________________________
From: Henning Westerholt Sent: Friday, March 21, 2025 2:41 AM To: Kamailio (SER) - Users Mailing List Cc: Alex A; Ben Kaufman Subject: RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Ben,
do you have any reference (e.g. bug tracker, e-mail thread) for the “freeswitch don’t support SIP branching”?
It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project.
Thanks,
Henning
From: Ben Kaufman via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Sent: Donnerstag, 20. März 2025 15:57 To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai>; Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> Subject: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards,
Kaufman
________________________________
From: Alex A via sr-users Sent: Wednesday, March 19, 2025 4:58 PM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A Subject: [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
Background: Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
Script config:
onreply_route[MANAGE_REPLY] {
xlog("L_INFO", "reply $T_reply_code received");
if (t_check_status( "1[1-9][0-9]")) {
t_reset_fr();
} else {
t_set_fr(120000);
}
}
route(NATDETECT);
#!ifdef WITH_RTPENGINE
route(RTPMANAGE);
#!endif
}
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
}
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
setflag(FLT_DLGINFO);
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[TOCARRIER] {
process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER");
route(RELAY);
}
failure_route[MANAGE_FAILURE_CARRIER] {
xlog("L_INFO", "reply $T_reply_code received");
if ($avp(inbound_attempt)<=1){
if ($dlg_var(b2bua)=="true"){
usleep(1900000);
}
route("TOCARRIER");
}
Call Flows:
The above fix works well when an explicit error reply is received back.
error reply SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. Current timer expiry SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
Just about the FS problem: I can definitely reproduce the same behaviour on 1.10 right now (482 merged calls). So yeah, It is still exists.
I also struggle a bit with this issue especially when do some extended test scenarios. It just doesn't recognizes different branches.
So best approach - avoid send the same call to the same machine.
On Fri, Mar 21, 2025, 15:00 Ben Kaufman via sr-users < sr-users@lists.kamailio.org> wrote:
It was about two years ago that I tested, so my statments here are just what I recall, and therefor may be incorrect:
I believe that I tested against 1.10, and there was no change in Freeswtich behavior. Looking through issues it seems like Freeswitch's support team's position was that the CSeq number should be incremented. Of course, this would be problematic at the proxy level as it would then have to track the offset it's creating from the UAC (I know there are functions for this in Kamailio, but this doesn't seem the appropriate place for this). There are some old issues reported for the same type of thing within Kamailio, where Daniel pointed that the issue was Freeswitches behavior, so it was a both sides pointing fingers situation (although I'm pretty sure Daniel is correct).
I think many people encoutring this issue went ahead with the "sleep" solution. I inherited maintenance of an environment where this was done, and the issue came to my attention via performance issues caused by the blocking sleep call. Since I also had an array of Freeswitch servers which could handle the request, my direct solution was to just make sure that the failure route pointed to a different Freeswitch than the request route. That was a workable situation in my scenario and much easier than trying to convince someone the behavior is incorrect. My guess is that the Freeswitch behavior is the same to this day simply because it hasn't been revisited.
On a personal level, I'm in the process of removing these Freeswitch instances. This isn't a complaint against Freeswitch, but rather that it was installed to handle media relay and RTPEngine is much better suited if that's the only task that's needed. Given this, I don't have a lot of motivation to dig into he issue further, but if needed, I think I could pretty easily cook up a small docker-compose environment that illustrates the problem.
Regards, Kaufman
*From:* Henning Westerholt hw@gilawa.com *Sent:* Friday, March 21, 2025 8:22 AM *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Cc:* Alex A alex.antonevych@replicant.ai; Ben Kaufman < bkaufman@bcmone.com> *Subject:* RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hi Ben,
thank you. 16 years is indeed a longer time, one could hope that its now fixed in a newer version.
Cheers,
Henning
*From:* Ben Kaufman bkaufman@bcmone.com *Sent:* Freitag, 21. März 2025 14:21 *To:* Henning Westerholt hw@gilawa.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Cc:* Alex A alex.antonevych@replicant.ai *Subject:* Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
The reference is 16 years old, so perhaps my statement would have been better phrased as "didn't support" rather than what was at the time "doesn't support":
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
With that said, the very specific statment of "We currently don't support forked dialogs" is here: https://narkive.com/pl2VL6Gu:6.378.42
It's been a few years since I dealt with the issue first hand, but IIRC it was relatively simple to recreate by relaying an INVITE to a freeswitch that returns failure, then re-targeting that same freeswitch from kamailio failure route.
Regards,
Kaufman
*From:* Henning Westerholt *Sent:* Friday, March 21, 2025 2:41 AM *To:* Kamailio (SER) - Users Mailing List *Cc:* Alex A; Ben Kaufman *Subject:* RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hello Ben,
do you have any reference (e.g. bug tracker, e-mail thread) for the “freeswitch don’t support SIP branching”?
It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project.
Thanks,
Henning
*From:* Ben Kaufman via sr-users sr-users@lists.kamailio.org *Sent:* Donnerstag, 20. März 2025 15:57 *To:* sr-users@lists.kamailio.org *Cc:* Alex A alex.antonevych@replicant.ai; Ben Kaufman < bkaufman@bcmone.com> *Subject:* [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards,
Kaufman
*From:* Alex A via sr-users *Sent:* Wednesday, March 19, 2025 4:58 PM *To:* *sr-users@lists.kamailio.org sr-users@lists.kamailio.org* *Cc:* Alex A *Subject:* [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
*Background:* Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: *https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-in-serial-forking-solved* )
*Script config:*
onreply_route[MANAGE_REPLY] {
xlog("L_INFO", "reply $T_reply_code received");
if (t_check_status( "1[1-9][0-9]")) {
t_reset_fr();
} else {
t_set_fr(120000);
}
}
route(NATDETECT);
*#!ifdef WITH_RTPENGINE*
route(RTPMANAGE);
*#!endif*
}
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
}
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
setflag(FLT_DLGINFO);
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[TOCARRIER] {
process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER");
route(RELAY);
}
failure_route[MANAGE_FAILURE_CARRIER] {
xlog("L_INFO", "reply $T_reply_code received");
if ($avp(inbound_attempt)<=1){
if ($dlg_var(b2bua)=="true"){
usleep(1900000);
}
route("TOCARRIER");
}
*Call Flows:*
The above fix works well when an explicit error reply is received back.
*error reply SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Thank you both for the detailed feedback.
The RFC 3261 standard is pretty clear on that matter, a CSEQ should be increased for new requests, like when challenged for authentication.
There are also good examples in the standard, like this one: https://datatracker.ietf.org/doc/html/rfc5359#section-2.8 It clearly shows that the CSEQ should be not incremented from a SIP proxy on serial forking.
I had a quick look to the issue tracker for freeswitch and I found a few bugs that might be related, but nothing that pointed exactly in this direction. So maybe a new issue could be opened there as well.
Cheers,
Henning
-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/
From: Yuriy G ovoshlook@gmail.com Sent: Freitag, 21. März 2025 15:26 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Henning Westerholt hw@gilawa.com; Alex A alex.antonevych@replicant.ai; Ben Kaufman bkaufman@bcmone.com Subject: Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
Just about the FS problem: I can definitely reproduce the same behaviour on 1.10 right now (482 merged calls). So yeah, It is still exists.
I also struggle a bit with this issue especially when do some extended test scenarios. It just doesn't recognizes different branches.
So best approach - avoid send the same call to the same machine.
On Fri, Mar 21, 2025, 15:00 Ben Kaufman via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> wrote: It was about two years ago that I tested, so my statments here are just what I recall, and therefor may be incorrect:
I believe that I tested against 1.10, and there was no change in Freeswtich behavior. Looking through issues it seems like Freeswitch's support team's position was that the CSeq number should be incremented. Of course, this would be problematic at the proxy level as it would then have to track the offset it's creating from the UAC (I know there are functions for this in Kamailio, but this doesn't seem the appropriate place for this). There are some old issues reported for the same type of thing within Kamailio, where Daniel pointed that the issue was Freeswitches behavior, so it was a both sides pointing fingers situation (although I'm pretty sure Daniel is correct).
I think many people encoutring this issue went ahead with the "sleep" solution. I inherited maintenance of an environment where this was done, and the issue came to my attention via performance issues caused by the blocking sleep call. Since I also had an array of Freeswitch servers which could handle the request, my direct solution was to just make sure that the failure route pointed to a different Freeswitch than the request route. That was a workable situation in my scenario and much easier than trying to convince someone the behavior is incorrect. My guess is that the Freeswitch behavior is the same to this day simply because it hasn't been revisited.
On a personal level, I'm in the process of removing these Freeswitch instances. This isn't a complaint against Freeswitch, but rather that it was installed to handle media relay and RTPEngine is much better suited if that's the only task that's needed. Given this, I don't have a lot of motivation to dig into he issue further, but if needed, I think I could pretty easily cook up a small docker-compose environment that illustrates the problem.
Regards, Kaufman ________________________________ From: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Sent: Friday, March 21, 2025 8:22 AM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai>; Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> Subject: RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Ben,
thank you. 16 years is indeed a longer time, one could hope that its now fixed in a newer version.
Cheers,
Henning
From: Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> Sent: Freitag, 21. März 2025 14:21 To: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai> Subject: Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
The reference is 16 years old, so perhaps my statement would have been better phrased as "didn't support" rather than what was at the time "doesn't support":
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
With that said, the very specific statment of "We currently don't support forked dialogs" is here: https://narkive.com/pl2VL6Gu:6.378.42
It's been a few years since I dealt with the issue first hand, but IIRC it was relatively simple to recreate by relaying an INVITE to a freeswitch that returns failure, then re-targeting that same freeswitch from kamailio failure route.
Regards,
Kaufman
________________________________
From: Henning Westerholt Sent: Friday, March 21, 2025 2:41 AM To: Kamailio (SER) - Users Mailing List Cc: Alex A; Ben Kaufman Subject: RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Ben,
do you have any reference (e.g. bug tracker, e-mail thread) for the “freeswitch don’t support SIP branching”?
It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project.
Thanks,
Henning
From: Ben Kaufman via sr-users <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Sent: Donnerstag, 20. März 2025 15:57 To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai>; Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> Subject: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards,
Kaufman
________________________________
From: Alex A via sr-users Sent: Wednesday, March 19, 2025 4:58 PM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A Subject: [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
Background: Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... )
Script config:
onreply_route[MANAGE_REPLY] {
xlog("L_INFO", "reply $T_reply_code received");
if (t_check_status( "1[1-9][0-9]")) {
t_reset_fr();
} else {
t_set_fr(120000);
}
}
route(NATDETECT);
#!ifdef WITH_RTPENGINE
route(RTPMANAGE);
#!endif
}
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
}
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
setflag(FLT_DLGINFO);
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[TOCARRIER] {
process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER");
route(RELAY);
}
failure_route[MANAGE_FAILURE_CARRIER] {
xlog("L_INFO", "reply $T_reply_code received");
if ($avp(inbound_attempt)<=1){
if ($dlg_var(b2bua)=="true"){
usleep(1900000);
}
route("TOCARRIER");
}
Call Flows:
The above fix works well when an explicit error reply is received back.
error reply SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. Current timer expiry SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Thank you for looking into this everyone.
I ended up going with suggestions (added a dispatcher to use a next FS instance on the retry).
To address any late replies from cancelled branches, added the following logic:
when cancelling add "first attempt" IP to hashtable with expiry and then drop any traffic from it in:
route[WITHINDLG] if ($sht(cancel=>$ci) == $si) { xlog("L_INFO",'{ "route_name":"$cfg(route)", "correlations":$dlg_var(correlations), "text":"$si branch is already canceled. Dropping $rm" }'); drop; }
reply_route { if ($sht(cancel=>$ci) == $si) { if ($rs=="200") { xlog("L_INFO",'{ "route_name":"$cfg(route)", "correlations":$dlg_var(correlations), "text":"$si branch is already canceled. Dropping 200 reply" }'); drop; }}
Thanks again
On Fri, Mar 21, 2025 at 12:02 PM Henning Westerholt hw@gilawa.com wrote:
Thank you both for the detailed feedback.
The RFC 3261 standard is pretty clear on that matter, a CSEQ should be increased for new requests, like when challenged for authentication.
There are also good examples in the standard, like this one: https://datatracker.ietf.org/doc/html/rfc5359#section-2.8
It clearly shows that the CSEQ should be not incremented from a SIP proxy on serial forking.
I had a quick look to the issue tracker for freeswitch and I found a few bugs that might be related, but nothing that pointed exactly in this direction. So maybe a new issue could be opened there as well.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
*From:* Yuriy G ovoshlook@gmail.com *Sent:* Freitag, 21. März 2025 15:26 *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Cc:* Henning Westerholt hw@gilawa.com; Alex A < alex.antonevych@replicant.ai>; Ben Kaufman bkaufman@bcmone.com *Subject:* Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
Just about the FS problem: I can definitely reproduce the same behaviour on 1.10 right now (482 merged calls). So yeah, It is still exists.
I also struggle a bit with this issue especially when do some extended test scenarios. It just doesn't recognizes different branches.
So best approach - avoid send the same call to the same machine.
On Fri, Mar 21, 2025, 15:00 Ben Kaufman via sr-users < sr-users@lists.kamailio.org> wrote:
It was about two years ago that I tested, so my statments here are just what I recall, and therefor may be incorrect:
I believe that I tested against 1.10, and there was no change in Freeswtich behavior. Looking through issues it seems like Freeswitch's support team's position was that the CSeq number should be incremented. Of course, this would be problematic at the proxy level as it would then have to track the offset it's creating from the UAC (I know there are functions for this in Kamailio, but this doesn't seem the appropriate place for this). There are some old issues reported for the same type of thing within Kamailio, where Daniel pointed that the issue was Freeswitches behavior, so it was a both sides pointing fingers situation (although I'm pretty sure Daniel is correct).
I think many people encoutring this issue went ahead with the "sleep" solution. I inherited maintenance of an environment where this was done, and the issue came to my attention via performance issues caused by the blocking sleep call. Since I also had an array of Freeswitch servers which could handle the request, my direct solution was to just make sure that the failure route pointed to a different Freeswitch than the request route. That was a workable situation in my scenario and much easier than trying to convince someone the behavior is incorrect. My guess is that the Freeswitch behavior is the same to this day simply because it hasn't been revisited.
On a personal level, I'm in the process of removing these Freeswitch instances. This isn't a complaint against Freeswitch, but rather that it was installed to handle media relay and RTPEngine is much better suited if that's the only task that's needed. Given this, I don't have a lot of motivation to dig into he issue further, but if needed, I think I could pretty easily cook up a small docker-compose environment that illustrates the problem.
Regards,
Kaufman
*From:* Henning Westerholt hw@gilawa.com *Sent:* Friday, March 21, 2025 8:22 AM *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Cc:* Alex A alex.antonevych@replicant.ai; Ben Kaufman < bkaufman@bcmone.com> *Subject:* RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hi Ben,
thank you. 16 years is indeed a longer time, one could hope that its now fixed in a newer version.
Cheers,
Henning
*From:* Ben Kaufman bkaufman@bcmone.com *Sent:* Freitag, 21. März 2025 14:21 *To:* Henning Westerholt hw@gilawa.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Cc:* Alex A alex.antonevych@replicant.ai *Subject:* Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
The reference is 16 years old, so perhaps my statement would have been better phrased as "didn't support" rather than what was at the time "doesn't support":
https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-...
With that said, the very specific statment of "We currently don't support forked dialogs" is here: https://narkive.com/pl2VL6Gu:6.378.42
It's been a few years since I dealt with the issue first hand, but IIRC it was relatively simple to recreate by relaying an INVITE to a freeswitch that returns failure, then re-targeting that same freeswitch from kamailio failure route.
Regards,
Kaufman
*From:* Henning Westerholt *Sent:* Friday, March 21, 2025 2:41 AM *To:* Kamailio (SER) - Users Mailing List *Cc:* Alex A; Ben Kaufman *Subject:* RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hello Ben,
do you have any reference (e.g. bug tracker, e-mail thread) for the “freeswitch don’t support SIP branching”?
It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project.
Thanks,
Henning
*From:* Ben Kaufman via sr-users sr-users@lists.kamailio.org *Sent:* Donnerstag, 20. März 2025 15:57 *To:* sr-users@lists.kamailio.org *Cc:* Alex A alex.antonevych@replicant.ai; Ben Kaufman < bkaufman@bcmone.com> *Subject:* [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry?
I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep();
Regards,
Kaufman
*From:* Alex A via sr-users *Sent:* Wednesday, March 19, 2025 4:58 PM *To:* *sr-users@lists.kamailio.org sr-users@lists.kamailio.org* *Cc:* Alex A *Subject:* [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry?
*CAUTION:* This email originated from outside the organization. *Do not click links or open attachments* unless you recognize the sender and know the content is safe.
Hi All,
I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one.
*Background:* Running Kamailio 5.6.x
Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2
On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: *https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-... https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-in-serial-forking-solved* )
*Script config:*
onreply_route[MANAGE_REPLY] {
xlog("L_INFO", "reply $T_reply_code received");
if (t_check_status( "1[1-9][0-9]")) {
t_reset_fr();
} else {
t_set_fr(120000);
}
}
route(NATDETECT);
*#!ifdef WITH_RTPENGINE*
route(RTPMANAGE);
*#!endif*
}
route[RELAY] {
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
}
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
setflag(FLT_DLGINFO);
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[TOCARRIER] {
process bunch of things, attach custom headers, generate request URI
t_on_failure("MANAGE_FAILURE_CARRIER");
route(RELAY);
}
failure_route[MANAGE_FAILURE_CARRIER] {
xlog("L_INFO", "reply $T_reply_code received");
if ($avp(inbound_attempt)<=1){
if ($dlg_var(b2bua)=="true"){
usleep(1900000);
}
route("TOCARRIER");
}
*Call Flows:*
The above fix works well when an explicit error reply is received back.
*error reply SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected.
however does not work when NO reply is received at all and the timer expires. *Current timer expiry SIP exchange:* SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch
I am looking to CANCEL branch0 before the sleep delay runs
Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408).
Any suggestions on how to handle this would be greatly appreciated.
TIA
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
Alex A -
Ben Kaufman -
Henning Westerholt -
Patrick Karton -
Sergio Charrua -
Yuriy G