SRS sends non-standard multipart/mixed in 200 OK — breaks RFC-compliant SIP stacks (jambonz/drachtio)

[Ma91Wa]

Summary

loreste/siprec responds to SIPREC INVITEs with Content-Type: multipart/mixed in the 200 OK, combining the SDP answer with RS-Metadata XML. This is not required or specified by RFC 7866 for SRS responses, and it breaks RFC-compliant SIP stacks like jambonz/drachtio-srf.

Root Cause

RFC 7866 specifies that:

• The SRC includes multipart/mixed in the INVITE (SDP offer + RS-metadata) — this is correct
• The SRS 200 OK only needs to include an SDP answer (application/sdp)

loreste/siprec currently sends multipart/mixed in the SRS 200 OK response. This is non-standard behavior.

Impact

When drachtio-srf processes the 200 OK to createUAC(), it only sets uac.remote.sdp if the response body is application/sdp. With multipart/mixed, the SDP answer is embedded in the multipart body and not extracted — uac.remote.sdp remains undefined. rtpengine is never configured, and no RTP is forked to the SRS.

Symptom: SIP signaling succeeds (INVITE/200/ACK), but all recordings are empty (44-byte WAV headers, no audio data).

Affected Environments

• jambonz Voice Gateway as SRC (drachtio-srf createUAC)
• Cognigy Voice Gateway (jambonz-based)
• Any RFC-compliant SIP stack that does not special-case multipart bodies in 200 OK

Workaround

We added a PLAIN_SDP_RESPONSE=true environment variable to force application/sdp in the 200 OK:

plainSDPMode := os.Getenv("PLAIN_SDP_RESPONSE") == "true"
if recordingSession != nil && !plainSDPMode {
    // multipart/mixed (current default — non-standard)
} else {
    responseHeaders["Content-Type"] = "application/sdp"
    s.sendResponse(message, 200, "OK", responseHeaders, responseSDP)
}

Suggested Fix

Make application/sdp the default response for the SRS 200 OK (RFC-conformant). Optionally allow multipart/mixed as an opt-in via config for SRC implementations that specifically handle it.

This is similar to the workaround in our fork: see PR #35 (fix/cognigy-vgw-compat-and-rtp-race).

[loreste]

Good catch — you're right, the SRS 200 OK should just be application/sdp per RFC 7866. The multipart response was something I added early on without thinking through the interop implications, and it clearly doesn't play well with drachtio-srf or anything that expects a standard SDP-only answer.

Fixed in 5362eb7. The default is now plain application/sdp in the 200 OK for both initial INVITEs and re-INVITEs. If anyone has an SRC that actually wants the multipart response, they can set MULTIPART_RESPONSE=true, but I doubt anyone will need it.

The old PLAIN_SDP_RESPONSE env var is no longer needed — this is just the default behavior now.

Tested end-to-end with a full SIPREC call flow (INVITE → 200 → ACK → RTP streaming → BYE) and confirmed the Content-Type comes back as application/sdp and recordings still work fine.