Encryption/Decryption issue with video from freeSwitch, when extension SIP Bypass was set to Proxy Media

[weic-harding]

Describe the bug
SoftPhone calling Physical Doorphone, Remote Video not coming back, when extension SIP Bypass was set to Proxy Media, mandatory Media Encryption, transport TLS

github_issue_log.txt

Environment
FreeSWITCH version: 1.11.1-release git c2c5964 2026-05-26 20:41:26Z 64bit
Install: FusionPBX on Debian 13, AWS EC2
SIP profile: internal, TLS transport, SDES-SRTP (AES_CM_128_HMAC_SHA1_80)
Media mode: extension configured with "Proxy Media" (SIP Bypass Media = Proxy Media) enabled
Call type: two-party bridge, audio + video (H.264), between an internal extension and a SIP video endpoint (door phone / hardware video intercom)
Summary

When Proxy Media is enabled on an extension carrying a video+SRTP call, a mid-call SDP refresh (observed here on hold/resume and on automatic video-port re-learning) causes one leg to send an outgoing "Local SDP" body that is actually the other leg's SDP — including that leg's own o= origin line pointing at the other party's device IP, and that leg's own SRTP key. The affected leg's own internally pre-computed candidate keys (logged via Set Local audio/video crypto Key) are never what actually ends up in its outgoing SDP.

Net effect: the endpoint on the affected leg ends up encrypting its own outgoing media with a key that was never negotiated with it, and receiving media it can never decrypt, for the rest of that media session. This reproduces on effectively every Proxy Media call that survives long enough to hit a refresh; it does not reproduce under Bypass Media or Default media mode.

Steps To Reproduce
Enable Proxy Media on an extension (FusionPBX: Extension → Advanced Settings → SIP Bypass Media = Proxy Media).
Place a bridged call from that extension to another SRTP+video-capable endpoint.
Let the call run long enough to trigger a mid-call SDP refresh — in our testing this happened naturally around 10-100 seconds in via automatic video port re-learning (Auto Changing video port ...), and can also be triggered on demand via a client-side hold/resume (pause/resume video).
Capture /var/log/freeswitch/freeswitch.log at DEBUG level (or at least switch_core_media / sofia_glue debug) for both channel UUIDs of the call, and take a simultaneous packet capture at the endpoint.
Expected behavior

Each leg continues to encrypt/decrypt using its own separately negotiated SRTP key after the refresh. Both directions of media remain valid for the life of the call.

Actual behavior

After the refresh (visible via sofia_glue.c:1625 Setting proxy route ... immediately preceding it in our logs), one leg's logged "Local SDP" block has:

o=- origin instead of o=FreeSWITCH ...
an IP address matching the other leg's remote endpoint, not this leg's own server IP
an a=crypto key that is identical to a key seen on the other channel UUID

We independently verified the practical impact by decrypting a matching packet capture with libsrtp, using the actual keys pulled from the log for both legs of one affected call:

The affected endpoint's outgoing media authenticated successfully (30/30 packets) against the other leg's key — i.e., it was using a key that was never negotiated with it, but did so consistently.
The same endpoint's incoming media failed SRTP authentication (0/30, "authentication failure") against every candidate key we had for that call, on both legs, in both crypto slots.

This is a permanent one-way break for the rest of that media session — not a transient glitch — and it recurs on every subsequent refresh, so client-side pause/resume never restores two-way video once it happens.

Log excerpt

See attached github_issue_log.txt (real domain, IP addresses, and SRTP key material redacted; the "same key appears on two different channel UUIDs" pattern is preserved by mapping each distinct key to a consistent placeholder).

Notes for triage

We haven't confirmed the exact line responsible, but the check in switch_core_media_build_crypto() in switch_core_media.c:

c
if (!force && engine->ssec[ctype].local_raw_key[0]) {
return SWITCH_STATUS_SUCCESS;
}

decides "key already generated" based only on the first byte of the key buffer being non-zero, rather than an explicit flag. Combined with whatever proxy-media re-negotiation path runs on refresh (sofia_glue.c proxy route handling), this looked like a plausible place for stale/cross-session state to leak, but we have not confirmed this with a debugger — flagging it only as a starting point, not a diagnosis.

Happy to provide the full (unredacted) log/pcap privately if that would help track this down.

[weic-harding]

Update: root-cause lead in the original report was incorrect; see PR #3138

Follow-up source reading (with a debugger-free trace through switch_rtp.c / switch_core_media.c, plus a live pcap + server-side key verification pass) turned up two things worth correcting/adding here before anyone spends time chasing the original lead.

The local_raw_key[0] check is not the mechanism

The switch_core_media_build_crypto() first-byte check flagged above assumed each Proxy Media leg holds its own independently-negotiated SRTP key that could get cross-contaminated. That premise doesn't hold: switch_rtp.c (~line 8330, the Fast PASS! block gated on SWITCH_RTP_FLAG_PROXY_MEDIA) shows FreeSWITCH never runs SRTP unprotect/protect on a Proxy Media leg at all — it relays raw ciphertext between the two legs. Both legs are therefore architecturally required to share one identical key; there's no per-leg key for this check to leak. Recommend deprioritizing this lead.

Actual defect found and fixed

The real path:

1. sofia.c (nua_callstate_completed handler) queues SWITCH_MESSAGE_INDICATE_MEDIA_REDIRECT to the bridge partner leg on refresh, carrying this leg's raw SDP.
2. mod_sofia.c (MEDIA_REDIRECT case) applies it via switch_core_media_set_local_sdp(..., SWITCH_TRUE), which intentionally overwrites the partner leg's outgoing SDP body wholesale — this whole-body copy is by design, since it's how the shared key gets mirrored between legs for the raw-relay design to work at all.
3. switch_core_media_patch_sdp() is supposed to then normalize the o=/c=/s=/m= lines back to the leg's own identity (never touching a=crypto, which must stay shared).
4. Bug: patch_sdp() had an unconditional early return ("Skip patch on hold SDP") that skipped step 3 entirely whenever the SDP looked hold-related (sendonly/inactive/0.0.0.0) on an already-answered channel, with no carve-out for Proxy Media. On a Proxy Media leg, a hold/resume-triggered redirect landing on this path shipped the raw, foreign SDP verbatim — including the other party's o= line and IP — and cached it, so every later refresh (including unrelated ones, like video port relearn) re-sent the same cached foreign body. This matches the o=- / foreign-IP / stuck-key evidence in the log extracts exactly.

Fix (submitted as PR #3138): excluded CF_PROXY_MEDIA channels from that early return, so Proxy Media legs always get o=/c=/s= normalized to their own identity even on a hold-related redirect. Non-proxy calls are unaffected. The PR also adds a diagnostic (switch_core_media_check_proxy_crypto_mismatch()) that logs loudly if the two bridge legs ever end up on different SRTP crypto suites — which cannot be corrected automatically given the raw-relay design, but was previously very hard to notice without an offline SRTP decrypt.

Still open

A separate live-testing pass (unmodified binary, pre-fix) found the two legs of one Proxy Media video call had negotiated different SRTP suites (AES_CM_128_HMAC_SHA1_80 vs AES_CM_128_NULL_AUTH), which alone is sufficient to break decryption independent of the patch_sdp bug above. That suite-selection issue is not fixed by PR #3138 and needs separate investigation into switch_core_media_build_crypto()'s offer/answer logic for Proxy Media. Will file separately once isolated.