Skip to content

Fix SDP media transport defaulting to RTP/AVP regardless of SRTP - #22

Open
geejay101 wants to merge 1 commit into
yatevoip:masterfrom
geejay101:fix-srtp-sips-transport
Open

Fix SDP media transport defaulting to RTP/AVP regardless of SRTP#22
geejay101 wants to merge 1 commit into
yatevoip:masterfrom
geejay101:fix-srtp-sips-transport

Conversation

@geejay101

Copy link
Copy Markdown

The SDP-building paths in SDPSession (updateSDP, updateRtpSDP, and the two early/fallback media construction spots) always set a media's transport to RTP/AVP. That happened even when SRTP was on (secure=enable) and we were attaching an a=crypto attribute. That's wrong per RFC 4568: crypto belongs under the RTP/SAVP profile, not RTP/AVP. Offering crypto under AVP isn't conformant, and some softphone/PBX peers reject it outright with 488 INCOMPATIBLE_DESTINATION.

The fix is to default transport to RTP/SAVP whenever secure is set, at each place we build a media descriptor, rather than hardcoding RTP/AVP. While we're there, we drop the a=encryption:optional line once transport is already RTP/SAVP, since it's redundant at that point.

  • modules/ysipchan.cpp
    Outgoing calls to a sips: destination now default m_secure to true for that leg. (sips() is resolved from the parsed destination URI just before this.) We also clear any transport/transport_* params that a previous leg's media negotiation may have left on the message, otherwise they'd pre-empt the corrected default and it'd never apply.
  • Incoming calls now default m_secure to true on their own leg unconditionally, so SRTP offered by a caller is always preserved regardless of the global [general] secure= setting. This is still overridable per call via the secure= message param, since YateSIPConnection::callAccept already narrows m_secure from an explicit secure param on the call.execute message.
  • libs/ysdp/session.cpp + yatesdp.h
    updateRtpSDP is a static member and can't see m_secure, so it takes an explicit secure parameter instead. Both call sites pass m_secure through.

SDPSession's SDP-building code (updateSDP, updateRtpSDP, and the two
early/default-fallback media construction sites) always defaulted a
media's transport to the literal "RTP/AVP", even when SRTP (m_secure)
was in effect and an a=crypto attribute was being attached. Per RFC 4568,
crypto attributes require the RTP/SAVP profile, not RTP/AVP -- offering
crypto under AVP is non-conformant, and at least one common softphone/PBX
peer rejects it outright with 488/INCOMPATIBLE_DESTINATION.

Default the transport to RTP/SAVP when m_secure is set, at every media
construction site, instead of hardcoding RTP/AVP unconditionally. Also
suppress the a=encryption:optional line once transport is already
RTP/SAVP, since it's redundant there.

modules/ysipchan.cpp: an outgoing call to a sips: destination now defaults
m_secure to true for that leg (sips() is resolved from the parsed
destination URI immediately beforehand), and clears any transport/
transport_* parameters that may have already been set on the message from
an unrelated leg's own media negotiation, so the corrected default above
actually gets a chance to apply instead of being silently pre-empted. An
incoming call's own leg now defaults m_secure to true unconditionally, so
SRTP offered by a caller is always recognized/preserved regardless of the
global [general] secure= setting; this remains fully overridable per call
via the existing secure= message parameter, since YateSIPConnection::
callAccept already narrows m_secure from an explicit "secure" parameter
on the call.execute message.

libs/ysdp/session.cpp + yatesdp.h: SDPSession::updateRtpSDP is a static
member function and has no access to m_secure, so it gains an explicit
"secure" parameter instead, passed as m_secure from both call sites.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant