Fix SDP extraction from multipart/mixed SIP message bodies#862
Merged
lemenkov merged 2 commits intoSIPp:masterfrom Apr 27, 2026
Merged
Fix SDP extraction from multipart/mixed SIP message bodies#862lemenkov merged 2 commits intoSIPp:masterfrom
lemenkov merged 2 commits intoSIPp:masterfrom
Conversation
The Content-Type check in process_incoming() only matched "application/sdp" exactly, causing SIPp to skip SDP media extraction entirely when the body was multipart/mixed (e.g. SIP messages carrying both SDP and PIDF-LO geolocation per RFC 5765). This meant rtp_stream, PCAP play, and SRTP parameter extraction never ran for multipart messages. The fix extends the check to also match multipart/* bodies that contain an application/sdp part. The existing find_in_sdp() and extract_rtp_remote_addr() functions already search raw message text and work correctly with multipart content — they just were never called. Fixes UAS scenarios where the incoming INVITE carries geolocation data alongside SDP in a multipart/mixed body, resulting in zero outbound RTP despite rtp_stream being configured.
Contributor
|
Thank you! Can you please add a unit test for this? |
Author
You bet and sorry for the delay, I'll hopefully get some time to get this in this weekend. |
Member
|
LGTM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Content-Type check in
process_incoming()(call.cpp:4575) only matchedapplication/sdpexactly, causing SIPp to skip SDP media extraction entirely when the body wasmultipart/mixed. This meantrtp_stream, PCAP play, and SRTP parameter extraction never ran for multipart messages.Problem
SIP messages carrying both SDP and PIDF-LO geolocation data (per RFC 5621 / RFC 5765) use
Content-Type: multipart/mixedwith the SDP in one MIME part. This is standard for E911 call flows. When SIPp received such an INVITE as a UAS, it never extracted the remote media address, sortp_streamhad no destination and sent zero RTP packets.Fix
Extend the Content-Type check to also match
multipart/*bodies that contain anapplication/sdppart. The existingfind_in_sdp()andextract_rtp_remote_addr()functions already search raw message text and work correctly with multipart content — they just were never called.Test plan
Content-Type: multipart/mixedcontaining SDP + PIDF-LOrtp_streamsends audio (previously sent 0 packets)application/sdpINVITEs still work as before