rtp_relay: in-dialog re-INVITE (hold/unhold) not re-anchored for proxied dialog

[sukitha]

OpenSIPS version: 3.6.6 — code is byte-identical in master (4.0.0-beta) for the affected functions
Modules: rtp_relay (rtpengine backend), dialog, proxy setup (no b2b)

Description

In a dialog-based (non-b2b) proxied call where rtp_relay is engaged on the initial INVITE, sequential in-dialog re-INVITEs (hold / unhold) are not re-anchored. The DLGCB_REQ_WITHIN callback (rtp_relay_indlg) fires, but no offer/answer is sent to the RTP backend, and the original SDP is forwarded unchanged. After unhold, audio is dead because the endpoint's real SDP reaches the peer without passing through rtpengine.

Topology

An upstream B2BUA (FreeSWITCH) bridges the call; OpenSIPS proxies the FreeSWITCH↔agent leg. rtp_relay is the sole media handler on that leg.

Config (relevant)

initial INVITE
create_dialog();
rtp_relay_engage("rtpengine");
in-dialog
if (has_totag() && loose_route()) { t_relay(); } # rtp_relay left to manage media automatically

Steps to reproduce

1. Establish call — media is correctly anchored (rtp_relay_offer: leg=caller, rtp_relay_answer: leg=callee).
2. Agent presses hold → phone sends re-INVITE with SDP (c=0.0.0.0 / a=sendonly).
3. Unhold → re-INVITE with active SDP.

Expected: rtp_relay re-runs offer/answer on each in-dialog re-INVITE and rewrites the SDP via rtpengine.
Actual: rtp_relay_indlg runs but emits no offer/answer; SDP forwarded unchanged; media breaks after unhold.

Debug (log_level 4) — on the hold re-INVITE:
DBG:dialog:run_dlg_callbacks: dialog=0x..., type=16 # DLGCB_REQ_WITHIN fires
DBG:rtp_relay:rtp_relay_reqin: reffing ref=2 for ctx=0x...
<-- no rtp_relay_offer / rtp_relay_answer line at all -->
Initial setup, for comparison:
DBG:rtp_relay:rtp_relay_offer: leg=caller ...
DBG:rtp_relay:rtp_relay_answer: leg=callee ttag=[...] ...

[razvancrainea]

Can you please provide full debug logs? Thanks!

[sukitha]

logs-os-issue.rtf

Please check the attachment

[razvancrainea]

I guess the re-INVITE does have a body, correct? Would you be able to apply a patch to add further debugging on this matter?

[sukitha]

Yes, the re-INVITE does carry a body, and we'll be able to apply a patch and assist with further debugging on this matter.

[razvancrainea]

please run again your scenario with the attached patch, and let us know how INVITE is being handled.

rtp_relay_reinvite_debug_v1.patch

[sukitha]

Please find the log after the provided patch.

patch-01.rtf

[sukitha]

working-patch.patch

@razvancrainea, I tried this code, and it worked. Maybe you can use this knowledge to create a permanent fix.

[razvancrainea]

Your patch is somhow correct, but does not fix all the cases (i.e. when the session is established on ringing).
Can you please apply the attached patch and let me know if it works for you?

Thanks!

rtp_relay_reinvite_tag_v2.patch

[sukitha]

1. Plain SIP↔SIP via rtp_relay works fine — media anchors, calls answer 200.

2. SIP → WebRTC (WSS) fails — the WebRTC callee always gets a plain RTP/AVP offer (no DTLS/SAVPF/ICE) and replies 488.

3. Logs — the callee type/peer never reaches the offer:
   DBG:rtp_relay:rtp_relay_offer: leg=caller type=[] ctx-flags=[] \ flags=[replace-origin replace-session-connection] peer-flags=[] → rtpengine then returns m=audio … RTP/AVP (no a=fingerprint/a=setup) → callee 488.

With $rtp_relay_peer set in the branch route (as in your example), the assignment errors:
ERROR:rtp_relay:pv_get_rtp_relay_leg: no leg identified, so cannot figure out peer
ERROR:rtp_relay:pv_set_rtp_relay_var: could not get context session!

4. Config (your CommCon example):
   request route (caller, RTP/AVP)
   $rtp_relay(flags) = "replace-origin replace-session-connection";
   $rtp_relay(type) = "RTP/AVP";
   $rtp_relay(peer) = "ICE=remove";
   rtp_relay_engage("rtpengine");

branch route (callee, WebRTC)
$rtp_relay_peer(flags) = "replace-origin replace-session-connection";
$rtp_relay_peer(type) = "UDP/TLS/RTP/SAVPF";
$rtp_relay_peer(peer) = "ICE=force rtcp-mux-require SDES-off";

Tried $rtp_relay_peer in the request route, in the branch route, and both legs in the branch route — in every case, the offer comes out type=[] peer-flags=[], so the SAVPF/DTLS profile never reaches rtpengine. Caller flags apply fine; only the callee peer profile is lost.

Question: Is this a side effect of the rtp_fix patch, or an independent behaviour we should open a new issue for?

[razvancrainea]

@sukitha not sure what causes this behavior, but it looks like somehow your leg does not get updated properly. Can you compile opensips with the flag -DRTP_RELAY_DEBUG (i.e. CC_EXTRA_OPTS=-DRTP_RELAY_DEBUG make all install) and place another call and send me the debug logs?

[sukitha]

debug-logs.rtf

Please find the attached log

The -DRTP_RELAY_DEBUG log shows the callee leg is never linked into the session before the initial offer:

request route -> rtp_relay_engage(): only the CALLER leg is pushed
rtp_relay_new_sess: new sess index=-1
rtp_relay_get_leg: searching for tag [DHg6jQp9Hj93N] idx [-1] -> no leg
rtp_relay_get_leg: searching for tag [] idx [-1] -> no leg
rtp_relay_new_leg: new leg index=-1 tag=[DHg6jQp9Hj93N]
rtp_relay_push_sess_leg: pushing sess index=-1 type=0 leg=(-1/DHg6jQp9Hj93N) # CALLER
(no type=1 push -> sess->legs[CALLEE] is NULL)

branch_route -> $rtp_relay (callee) creates a leg at branch index 0,
but it is NEVER pushed into sess->legs[CALLEE]
Callee WEBRTC detected
rtp_relay_get_leg: searching for tag [] idx [0] -> no leg
rtp_relay_new_leg: new leg index=0 tag=[]
rtp_relay_get_leg: searching for tag [] idx [0] # repeated reads, never pushed to sess

initial offer toward the callee (TMCB_REQUEST_FWDED, leg=caller):
rtp_relay_offer: leg=caller type=[] flags=[replace-origin replace-session-connection] peer-flags=[]
rtpengine reply: m=audio 35064 RTP/AVP 0 101 # plain RTP/AVP, no SAVPF/DTLS

WebRTC UA then replies:
SIP/2.0 488 Not Acceptable Here

the callee leg only gets linked later, on the provisional/answer:
rtp_relay_new_leg: new leg index=-1 tag=[kefn23qj4b]
rtp_relay_push_sess_leg: pushing sess index=-1 type=1 leg=(-1/kefn23qj4b)

Root cause (as I read it): sess->legs[RTP_RELAY_CALLEE] is filled in rtp_relay_new_sess() at engage time (request route), before the branch_route runs, so it stays NULL. The callee profile provisioned by $rtp_relay in the branch_route lives only in ctx->legs (leg at the branch index) and is never pushed into sess->legs[CALLEE]. The initial offer in rtp_relay_ctx_initial_cb() → TMCB_REQUEST_FWDED calls rtp_relay_offer(sess, RTP_RELAY_CALLER), which reads the transcode-to profile from RTP_RELAY_PEER(CALLER) = sess->legs[CALLEE] → empty type/peer → rtpengine offers RTP/AVP → 488. The callee leg is only linked on the 18x/200 (type=1 push), which is too late for the offer.

Proposed fix — link the branch-provisioned callee leg into the session right before the initial offer:

/* rtp_relay_ctx.c, rtp_relay_ctx_initial_cb(), case TMCB_REQUEST_FWDED,
after the sess/disabled/late checks, before rtp_relay_offer(): */
struct rtp_relay_leg *leg =
rtp_relay_get_leg(ctx, NULL, rtp_relay_ctx_branch());
if (leg && leg != sess->legs[RTP_RELAY_CALLER] &&
leg != sess->legs[RTP_RELAY_CALLEE])
rtp_relay_push_sess_leg(sess, leg, RTP_RELAY_CALLEE);

With this, the offer reads type=[UDP/TLS/RTP/SAVPF] / peer=[ICE=force ...], rtpengine emits SAVPF+DTLS, and the WebRTC UA answers 200 (the later answer-side push reconciles the real to-tag leg, so the answer flow is unchanged). Plain SIP↔SIP is unaffected.

Does this look like the right place/approach to you, or would you prefer the linking to happen when $rtp_relay/$rtp_relay_peer is set in the branch route?

[razvancrainea]

@sukitha I actually think your proposal is right: can you please try the attached patch?

rtp_relay_reinvite_tag_v3.patch