Skip to content

[BUG] - a second SDP rebuild terminates a worker, causing a complete restart of opensips #4135

Description

@sindy39

OpenSIPS version you are running

version: opensips 3.6.7 (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: eaee48e28e
main.c compiled on  with gcc 15

Describe the bug

An SDP rebuild triggered by the second SDP change causes the worker to terminate, leading to opensips core shutdown on SIGCHLD (see the log below).

To Reproduce

  1. Set up an opensips instance with rtpengine; use rtp_relay module to replicate my setup as closely as possible.
  2. In the configuration script, use an assignment to $sdp.line and rtp_relay_engage() (the mutual order of these two does not matter), as in the example below.
  3. Send an initial INVITE carrying an SDP - the worker dies, causing the rest of the processes to shut down as well, see the log below. If you comment either the $sdp.line(o=) assignment or the rtp_relay_engage(), the INVITE gets through successfully.
branch_route[per_branch_ops] {

        if ( has_body("application/sdp") ) {
                if ( $socket_out(af) == "INET6" ) {
                        $var(o) = $(sdp.line(o=){re.subst,/^(.*IN IP).*/\1/}) + "6 " + $(socket_out(ip){re.subst,/^.(.*).$/\1/});
                } else {
                        if ( isflagset("s2u") ) {
                                $var(o) = $(sdp.line(o=){re.subst,/^(.*IN IP).*/\1/}) + "4 " + $socket_out(ip);
                        } else {
                                $var(o) = $(sdp.line(o=){re.subst,/^(.*IN IP).*/\1/}) + "4 " + $socket_out(advertised_ip);
                        }
                }
                xlog("L_INFO","socket_out(ip) = >$socket_out(ip)<\r\n");
                xlog("L_INFO","socket_out(af) = >$socket_out(af)<\r\n");
                xlog("L_INFO","modified o= line in req: $var(o)\r\n");
                $sdp.line(o=) = $var(o);
        }

        if (!has_totag()) {
                $var(af) = "IP4";
                if ( ($(si{ip.isip6}) == 1) || ($(dd{ip.isip6}) == 1) ) {
                        $var(af) = "IP6";
                }

                if ( isflagset("s2u") ) {
                        $rtp_relay(iface)      = "int";
                        $rtp_relay(flags)      = "replace-origin RTP/SAVP address-family=" + $var(af);
                        $rtp_relay_peer(iface) = "ext";
                        $rtp_relay_peer(flags) = "replace-origin RTP/AVP";
                } else {
                        $rtp_relay(iface)      = "ext";
                        $rtp_relay(flags)      = "replace-origin RTP/AVP";
                        $rtp_relay_peer(iface) = "int";
                        $rtp_relay_peer(flags) = "replace-origin RTP/SAVP address-family=" + $var(af);
                }
                rtp_relay_engage("rtpengine",1);
        }
}

Expected behavior

The second SDP rebuild succeeds

Relevant System Logs

DBG:core:sdp_get_custom_body: found previously re-built custom SDP => quick-return (0 / 1)
DBG:core:get_body: found custom 'SDP ops' body, len: 599
CRITICAL:core:del_lump: offset exceeds message size (72948840 > 1551) aborting...
DBG:core:handle_sigs: OpenSIPS exit status = 6
INFO:core:handle_sigs: child process 19016 exited by a signal 6
INFO:core:handle_sigs: core was not generated
INFO:core:handle_sigs: terminating due to SIGCHLD
DBG:core:shutdown_opensips: Asking process 1 [MI FIFO] to terminate
DBG:core:shutdown_opensips: Asking process 4 [SIP receiver udp:192.168.100.20:5060] to terminate
DBG:core:shutdown_opensips: Asking process 5 [SIP receiver udp:192.168.100.20:5060] to terminate
DBG:core:ipc_handle_job: received job type 0[RPC] from process 0
DBG:core:rpc_process_terminate: Process 5 exiting with code 0...
DBG:core:shutdown_opensips: Asking process 6 [SIP receiver udp:192.168.100.20:5060] to terminate
DBG:core:shutdown_opensips: Asking process 7 [SIP receiver udp:192.168.100.20:5060] to terminate
DBG:core:shutdown_opensips: Asking process 9 [TCP receiver] to terminate
DBG:core:shutdown_opensips: Asking process 10 [TCP receiver] to terminate
DBG:core:shutdown_opensips: Asking process 11 [TCP receiver] to terminate
DBG:core:shutdown_opensips: Asking process 12 [TCP receiver] to terminate
DBG:core:shutdown_opensips: Asking process 13 [TCP receiver] to terminate
DBG:core:shutdown_opensips: Asking process 14 [TCP receiver] to terminate
DBG:core:shutdown_opensips: Asking process 15 [TCP receiver] to terminate
DBG:core:shutdown_opensips: Asking process 16 [Timer handler] to terminate
DBG:core:ipc_handle_job: received job type 0[RPC] from process 0
DBG:core:rpc_process_terminate: Process 16 exiting with code 0...
DBG:core:ipc_handle_job: received job type 0[RPC] from process 0
DBG:core:rpc_process_terminate: Process 1 exiting with code 0...
DBG:core:shutdown_opensips: Asking process 17 [TCP main] to terminate
INFO:core:sig_usr: signal 15 received
INFO:core:sig_usr: signal 15 received
DBG:core:ipc_handle_job: received job type 0[RPC] from process 0

OS/environment information

  • Operating System: Ubuntu 26.04 LTS (Resolute Raccoon)
  • OpenSIPS installation: apt.opensips.org
  • other relevant information:

Additional context

In my case, the goal was just to put the IP address of the opensips socket to the o= line of the SDP rather than let rtpengine set it to its own address according to the replace-origin flag, which is just a cosmetic difference. But I guess someone else might want to use the new approach to SDP manipulation for something more serious.

Outside the scope of this bug report, should $sdp.line(o=/[4]) = "IP6"; actually do anything? Because it neither throws an error nor changes the contents of the o= line, but it does flag the SDP as DIRTY and thus causes a rebuild.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions