[BUG] rtp_relay mixes up caller and callee context

[sindy39]

OpenSIPS version you are running

version: opensips 3.6.4 (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: 2367deb8e
main.c compiled on  with gcc 12

Describe the bug

When invoking rtpengine, rtp_relay uses information from $rtp_relay and $rtp_relay_peer incorrectly. If bridge mode is required , this causes incorrect assignment of rtpengine interfaces. Given what mi rtp_relay_list shows, it seems that the root cause is that the caller block is populated with data of the callee:

(opensips-cli): mi rtp_relay_list
[
    {
        "callid": "f329c81e-a937-4e60-b838-ed5a1d8ef01f",
        "caller": {
            "tag": "a1c67636-d271-47ac-830b-c04ef78e69da",
            "interface": "ext"
        },
        "callee": {
            "tag": "a1c67636-d271-47ac-830b-c04ef78e69da",
            "interface": "ext"
        },
        "relay": "rtpengine",
        "node": "udp:localhost:2223",
        "set": 1,
        "ctx": {
            "from-tag": "a1c67636-d271-47ac-830b-c04ef78e69da",
            "to-tag": "eefd9c18-841b-4b4b-aec3-c8221bf5b64f"
        }
    }
]

To Reproduce

1. set up rtpengine with two interfaces, "ext" and "int"
2. set up opensips with rtp_relay and rtpengine modules and two udp sockets, one for the external network and one for the internal one, and with the following code on the request route handling the initial INVITE:

    if ($socket_in == "udp:INT_IP_ADDR:5060") {
        $rtp_relay(iface) = "int";
        $rtp_relay_peer(iface) = "ext";
    } else {
        $rtp_relay(iface) = "ext";
        $rtp_relay_peer(iface) = "int";
    }
    rtp_relay_engage("rtpengine",1);

3. set both opensips and rtpengine to log level 7 to see the details (on opensips side there isn't actually much to see regarding "why")
4. send an initial INVITE to the "internal" opensips socket
5. see the outcome in the log, example:

May 03 19:11:22 sbc-a rtpengine[920]: ", "direction": [ "ext", "ext" ], "call-id": "27ce5762-e152-47dc-b16c-2086d9bd889b", "received-from": [ "IP4", "192.168.101.62" ], "from-tag": "3b463144-9f00-430f-b48b-67e238928e6c", "command": "offer" }
May 03 19:11:22 sbc-a rtpengine[920]: ", "direction": [ "ext", "ext" ], "call-id": "27ce5762-e152-47dc-b16c-2086d9bd889b", "received-from": [ "IP4", "192.168.100.61" ], "from-tag": "3b463144-9f00-430f-b48b-67e238928e6c", "to-tag": "48822b8a-46a6-47c4-8e75-4571041bbffd", "command": "answer" }

Expected behavior

The direction parameter in the offer message should contain the ext and int interface names in proper order (and ideally be absent in the answer message), like this (manually invoked rtpengine_offer):

May 03 19:51:56 sbc-a rtpengine[920]: ", "direction": [ "int", "ext" ], "call-id": "090b1655-f306-4499-985d-9fb2256f3c70", "received-from": [ "IP4", "192.168.101.62" ], "from-tag": "b98efbce-c66b-4fc2-bea7-5d1c41077610", "command": "offer" }
May 03 19:51:56 sbc-a rtpengine[920]: ", "call-id": "090b1655-f306-4499-985d-9fb2256f3c70", "received-from": [ "IP4", "192.168.100.61" ], "from-tag": "b98efbce-c66b-4fc2-bea7-5d1c41077610", "to-tag": "b1a978f5-94c6-4489-83e4-c9488eafdc8b", "command": "answer" }

Relevant System Logs

See attached file:
rtp_relay.log

OS/environment information

• Operating System: Debian 12.13
• OpenSIPS installation: https://apt.opensips.org bookworm 3.6-releases
• other relevant information:

Additional context

My motivation for using rtp_relay as a wrapper to rtpengine is to be able to update the session in case of failover using mi rtp_relay_update rather than deploying redis to synchronize rtpengine state between instances. Unfortunately, if I switch to the route engine and handle rtpengine "manually", using the corresponding routes, mi rtp_relay_update has no effect.

[sindy39]

Just tested the same script with the opensips 3.4 pre-built package from apt.opensips.org, the mi rtp_relay_list shows the same:

(opensips-cli): mi rtp_relay_list
[
    {
        "callid": "4e3b1d00-22c6-4819-b377-2b7219eb96aa",
        "caller": {
            "tag": "4dc92b40-0244-490e-b9cf-6102f47416f2",
            "interface": "ext"
        },
        "callee": {
            "tag": "4dc92b40-0244-490e-b9cf-6102f47416f2",
            "interface": "ext"
        },
        "relay": "rtpengine",
        "node": "udp:localhost:2223",
        "set": 1,
        "ctx": {
            "from-tag": "4dc92b40-0244-490e-b9cf-6102f47416f2",
            "to-tag": "d00209c9-37b7-45ac-b11c-d8de6d1fe844"
        }
    }
]

The exact version is

version: opensips 3.4.17 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_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: 3e7ad039d
main.c compiled on  with gcc 12

[sindy39]

Thanks for looking into it. Just to help in the investigation, the following solves it for my basic tests but I have no idea where it may go evil - I simply assume that if there is a caller leg in a session and no other leg, the leg to be added must be the outgoing one for the initial INVITE.

root@sbc-a:/usr/src/opensips-3.6.5# diff modules/rtp_relay/rtp_relay_orig.c modules/rtp_relay/rtp_relay.c -u
--- modules/rtp_relay/rtp_relay_orig.c  2026-05-07 14:21:16.641425525 +0200
+++ modules/rtp_relay/rtp_relay.c       2026-05-07 14:20:29.261382322 +0200
@@ -467,7 +467,7 @@
                        if (!peer) {
                                if (!set)
                                        return NULL;
-                               peer = rtp_relay_new_leg(ctx, &get_from(msg)->tag_value, RTP_RELAY_ALL_BRANCHES);
+                               peer = rtp_relay_new_leg(ctx, &get_to(msg)->tag_value, RTP_RELAY_ALL_BRANCHES);
                                if (!peer) {
                                        LM_ERR("cannot create a new leg\n");
                                        return NULL;

A side quest(ion), how can I make LM_RTP_DBG messages make it to the log? I ended up substituting them by plain LM_DBG.

What also puzzles me is that although everything works, the call id, from tag etc. in the log messages are mostly empty:

DBG:rtp_relay:rtp_relay_offer: leg=caller callid=[] ftag=[] ttag=[] type=[] in-iface=[int] out-iface=[ext] ctx-flags=[] flags=[] peer-flags=[]

DBG:rtp_relay:rtp_relay_answer: leg=callee callid=[] ftag=[] ttag=[675d8747-a1e6-43c8-9f02-52bf6dacd06f] type=[] in-iface=[ext] out-iface=[int] ctx-flags=[] flags=[] peer-flags=[]

DBG:rtp_relay:rtp_relay_delete: callid=[fe9bd9c9-1c23-4be0-bc73-4dcb0987b582] ftag=[] ttag=[675d8747-a1e6-43c8-9f02-52bf6dacd06f] ctx-flags=[] delete-flags=[]