OpenSIPS version you are running
version: opensips 3.6.8 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, F_PARALLEL_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: f9f85260e5
main.c compiled on with gcc 14
Describe the bug
If conflicting requests are received from both sides of a b2b_init_request("top hiding") at nearly the same time, and one of those requests later arrives at local_route (for example, to send out a PRACK), then use of $b2b_logic may result in a deadlock. The most common scenario is a CANCEL and 183 Session Progress (with or without SDP) arriving from opposite legs within a few milliseconds of each other.
To Reproduce
Configure OpenSIPS 3.6.8 with b2b_entities and b2b_logic.
Configure at least two UDP IPv4 sockets, one for each endpoint.
Configure two endpoints to communicate through OpenSIPS with b2b_init_request("top hiding");.
In your routing script, access a $b2b_logic variable (for example, $b2b_logic.key, $b2b_logic.entity, $b2b_logic.ctx()) in local_route. For example:
local_route
{
if ($b2b_logic.key)
{
xlog("request belongs to B2B session: $b2b_logic.key\n");
}
}
Create a call scenario between the two endpoints where one of the endpoints sends a CANCEL at about the same millisecond as the other endpoint sends 183 Session Progress.
If you are successful in reproducing the bug, the deadlock will occur at $b2b_logic.key in local_route.
Example sngrep:

Expected behavior
Do not deadlock.
Relevant System Logs
The last log entries for the relevant processes before the deadlock occurs are usually something like:
2026-09-08T16:49:57.182703-05:00 opensips[59117]: DBG:b2b_entities:b2b_parse_key: hash_index = [204] - local_index= [3219646]
2026-09-08T16:49:57.182792-05:00 opensips[59106]: DBG:b2b_logic:b2bl_parse_key: hash_index = [716] - local_index= [0]
OS/environment information
Debian GNU/Linux 13 (trixie)
Additional context
We are willing to send the following privately: gdb trap files, log files, tcpdump packet capture, config
OpenSIPS version you are running
Describe the bug
If conflicting requests are received from both sides of a
b2b_init_request("top hiding")at nearly the same time, and one of those requests later arrives atlocal_route(for example, to send out a PRACK), then use of$b2b_logicmay result in a deadlock. The most common scenario is a CANCEL and 183 Session Progress (with or without SDP) arriving from opposite legs within a few milliseconds of each other.To Reproduce
Configure OpenSIPS 3.6.8 with b2b_entities and b2b_logic.
Configure at least two UDP IPv4 sockets, one for each endpoint.
Configure two endpoints to communicate through OpenSIPS with
b2b_init_request("top hiding");.In your routing script, access a
$b2b_logicvariable (for example,$b2b_logic.key,$b2b_logic.entity,$b2b_logic.ctx()) inlocal_route. For example:Create a call scenario between the two endpoints where one of the endpoints sends a CANCEL at about the same millisecond as the other endpoint sends 183 Session Progress.
If you are successful in reproducing the bug, the deadlock will occur at
$b2b_logic.keyinlocal_route.Example sngrep:

Expected behavior
Do not deadlock.
Relevant System Logs
The last log entries for the relevant processes before the deadlock occurs are usually something like:
OS/environment information
Debian GNU/Linux 13 (trixie)
Additional context
We are willing to send the following privately: gdb trap files, log files, tcpdump packet capture, config