[kamailio/kamailio] tmx: t_reuse_branch() doesn't copy $du into new branch (#1264)
### Description When using the t_reuse_branch() function after a branch failure, Kamailio doesn't send out the call again if $du was filled and differed from $ru. Instead, Kamailio tries to send the call directly to $ru. I would expect that the call gets sent out the same way as the original call. ### Troubleshooting #### Reproduction You need a setup like this: UAC1 K(LB) <=> K(Proxy/Registrar) <=> K(LB) => UAC2 When a UAC registers, the Path module is used to save the LB (Loadbalancer) for outbound calls. When UAC1 calls UAC2, the original call gets sent through K(LB) to UAC2. However, if the first call gets rejected and the call gets retried through branch failure route, K(Proxy/Registrar) tries to send the call directly to the request URI. In your branch_route add a reference to a branch failure route: ```t_on_branch_failure("samplename");``` Then add a branch failure route like this: ```event_route[tm:branch-failure:handle_tls_branch] { if(t_check_status("488")) { if (isbflagset(0) && !isbflagset(1)) { t_reuse_branch(); setbflag(1); t_relay(); } } }``` When filling $du manually before sending out the call again, everything works. ### Possible Solutions The original destination URI should be copied to the reused branch. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 4.4.5 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 4.7.2 ``` But from what I see in source code, the devel version still copies the same value. * **Operating System**: <!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) --> ``` Debian Wheezy ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1264
This is how the function was developed and it is documented in the readme: * https://www.kamailio.org/docs/modules/stable/modules/tmx.html#tmx.f.t_reuse_... I looked a bit and dst uri is not saved directly in the transaction branch structure, so there needs to be a larger patch involved to add this enhancement. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1264#issuecomment-335862378
I saw that it is documented like that, but in my eyes that makes it pretty useless in a scenario where $du is filled by the path from registration of a device. That's why I thought it was a bug. Do you have any suggestions to circumvent that problem? How would I save a per-branch variable? I tried something like `$avp(foo)[$T_branch_idx]` but it seems like Kamailio doesn't like variables being used for an index. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1264#issuecomment-336175926
I looked a bit and dst uri is not saved directly in the transaction branch structure, so there needs to be a larger patch involved to add this enhancement.
Is this fact the reason why $du does not hold the last used value in subsequent runs of the branch_failure_route? Example: ``` branch_route[PROVIDER_BRANCH] { xlog("L_NOTICE", "--- SCRIPT_PROVIDER_BRANCH: Will try setting dialog profile for du: $du\n"); set_dlg_profile("outbound_providers", "$(du{uri.param,xdesc})"); } event_route[tm:branch-failure:PROVIDER_FAILOVER] { xlog("L_NOTICE", "--- SCRIPT_PROVIDER_FAILOVER: Will try unsetting dialog profile for du: $du\n"); unset_dlg_profile("outbound_providers", "$(du{uri.param,xdesc})"); if (t_is_canceled()) exit; # next DST - only for 5xx or local timeout if ( t_check_status("5[[:digit:]]+") || (t_branch_timeout() && !t_branch_replied()) ) { if ( ds_next_dst() ) { xlog("L_NOTICE", "--- SCRIPT_PROVIDER_FAILOVER: A failover destination was selected: Forwarding to $du\n"); t_on_branch("PROVIDER_BRANCH"); t_on_branch_failure("PROVIDER_FAILOVER"); t_on_failure("TRY_OTHER"); route(RELAY); exit; } else { xlog("L_NOTICE", "--- SCRIPT_PROVIDER_FAILOVER: Giving Up. Negative response will be sent upstream.\n"); } } } ``` In this case, when the first branch fails, unset_dlg_profile will work (dst_uri was set in other route, not shown here). Then the branch failure route will select the next $du as a result of ds_next_dst, and indeed a new branch is relayed to the next dst_uri. If this second branch also fails, however, $du holds the initial dst_uri (of the first branch) when tm:branch-failure is executed a second time. Sorry for tainting this thread if this is an unrelated issue. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1264#issuecomment-578868723
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1264#issuecomment-1801271056 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/1264/1801271056@github.com>
Closed #1264 as not planned. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1264#event-11042725167 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issue/1264/issue_event/11042725167@github.com>
participants (4)
-
Daniel-Constantin Mierla -
George Diamantopoulos
-
github-actions[bot]
-
Sebastian Damm