Description
The Secure Real-time Transport Control Protocol (SRTCP) is defined by 3GPP as the mandatory security mechanism for protecting RTCP packets within an IP Multimedia Subsystem (IMS) and other 3GPP packet-switched services. SRTCP is not a separate protocol but a cryptographic transform applied to standard RTCP packets. It operates in conjunction with the Secure Real-time Transport Protocol (SRTP) to provide a complete security solution for RTP media streams and their associated control traffic. The protection is applied end-to-end between the communicating endpoints, such as User Equipment (UE) and application servers.
SRTCP works by adding a cryptographic trailer to each RTCP packet. This trailer contains a Message Authentication Code (MAC), which is computed over the entire RTCP packet (header and payload) using an authentication key. This ensures the integrity and source authentication of the control data, preventing tampering and spoofing. Optionally, SRTCP can also provide confidentiality by encrypting the RTCP payload, though this is less common as RTCP packets typically contain non-sensitive statistical information. A crucial feature is the use of a packet index and a replay list to protect against replay attacks, where an attacker re-sends previously captured packets.
Architecturally, SRTCP relies on a security context established through key management protocols like Multimedia Internet KEYing (MIKEY) or DTLS-SRTP. This context includes the cryptographic keys (encryption key, authentication key, salt key) and parameters like the cryptographic suite (e.g., AES-CM, HMAC-SHA1). The SRTCP processing layer sits between the RTCP application and the network transport layer. When sending, it takes an RTCP packet, generates the authentication tag, and appends the SRTCP index and the tag. When receiving, it validates the tag and checks the index against the replay list before passing the packet to the RTCP application. Its role is critical in 3GPP networks to secure service quality reports, participant identification, and session control messages, thereby protecting the overall multimedia session management.
Purpose & Motivation
SRTCP was created to address the security vulnerabilities inherent in the original, unprotected RTCP protocol. RTCP is a companion to RTP that carries control information for multimedia sessions, including participant reports, synchronization source (SSRC) identifiers, and packet loss statistics. In its plain form, RTCP is susceptible to attacks such as message forgery, replay attacks, and denial-of-service through false reporting. As 3GPP networks adopted IMS for delivering voice, video, and messaging over IP, securing these control channels became paramount for service integrity, billing accuracy, and user privacy.
The motivation for SRTCP stems from the need for a standardized, lightweight security mechanism that could be applied to the often small and frequent RTCP packets without introducing excessive overhead or latency. Previous approaches might have relied on network-level security like IPsec, but this is often terminated at network borders and does not provide true end-to-end security between application endpoints. SRTCP, as part of the SRTP framework, provides a session-layer security solution specifically tailored for real-time traffic. It solves the problem of authenticating control traffic in a way that is cryptographically bound to the media stream's security context, ensuring a unified security posture for the entire RTP session within 3GPP's all-IP architecture.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (45 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, new procedures and message coding were introduced for the SRTCP function to support functional alias within floor control operations. This included updates to the state transition diagram for the general floor control operation in the Floor Control Server. Furthermore, clarifications and a test vector were added for the MIKEY-SAKKE key management protocol used with SRTCP.
- Multi-Talker floor control server TS 24.380CR0178
- Mutli-talker – floor control towards the participant TS 24.380CR0179
- Updates to Non-controlling MCPTT function for Multi Talker TS 24.380CR0183
- Floor Control Server towards participant TS 24.380CR0187
- Coding of floor control messages to support functional alias TS 24.380CR0192
- Procedures for floor control messages to support functional alias TS 24.380CR0193
+ 5 more changes
In Release 16, the SRTCP function within MCPTT media plane control saw specific procedural corrections and enhancements to improve reliability. These included corrections to the timers and events for On-Network Floor Control procedures and to the Off-Network Floor Control procedures. Additionally, the release introduced the capability for simultaneous reception of media at the transmission control server as part of reception control.
- Incorrect reference to table for MBMS Subchannel Control TS 24.581CR0038
- Minor corrections in transmission control state machine TS 24.581CR0066
- New instance creation and release for basic / general reception control state m/c. TS 24.581CR0073
- Corrections to Off-Network Floor Control procedures TS 24.380CR0235
- Corrections to timers-events of On-Network Floor Control procedures TS 24.380CR0249
- MCVideo Reception control TS 24.581CR0044
+ 4 more changes
In Release 17, updates to SRTCP-related functions included clarifications and corrections for MIKEY-SAKKE I_Message validation within pre-established sessions, as well as enhancements for handling floor control messages during broadcast call upgrades or downgrades. These changes also addressed error conditions in floor control during group regrouping and refined the state transition diagrams for basic floor control operations. Additionally, corrections were made to the call setup control procedures over pre-established sessions and to the operation of the non-controlling MCPTT function within a group.
- Authentication of the MIKEY-SAKKE I_Message validation in pre-established session TS 24.380CR0230
- MCVideo Functional Alias usage in Transmission Control TS 24.581CR0079
- Corrections to floor indicator of On-Network Floor Control procedures TS 24.380CR0274
- Corrections to floor control messages handling for upgrade/downgrade of broadcast call TS 24.380CR0289
- Updates to clause 6.3.5 Floor control server state transition diagram for basic floor control operation towards the floor participant and related editorials TS 24.380CR0298
- Corrections in call setup control over pre-established session state machine TS 24.380CR0307
+ 6 more changes
In Release 18, enhancements for SRTCP were focused on supporting multiplexing over 5G Multicast-Broadcast Service (5MBS) for Mission Critical services. Specifically, the release clarified and specified the Synchronization Source (SSRC) identifiers to be used for RTP audio, media, and RTCP floor control or transmission control streams when multiplexed. These updates provided clearer guidance for differentiating media and control packets within multiplexed flows on MBMS bearers.
- Add timers and counters in the participating MCPTT function for MBS channel control TS 24.380CR0347
- MCPTT support of multiplexing - SSRC used in RTCP signalling over 5MBS TS 24.380CR0363
- MCPTT support of multiplexing - SSRCs used for RTP audio and RTCP floor control TS 24.380CR0356
- Add timers and counters in the participating MCVideo function for MBS channel control TS 24.581CR0111
- MCVideo support of multiplexing - SSRCs used for RTP media and RTCP transmission control TS 24.581CR0117
- MCVideo support of multiplexing - SSRC used in RTCP signalling over 5MBS TS 24.581CR0122
+ 4 more changes
In Release 19, the SRTCP function was enhanced with miscellaneous corrections to floor control procedures and an addition to the floor control release message. These updates refined the protocol's handling of the floor release mechanism, which is the process by which a user indicates the end of their talk burst. The changes ensured more precise signaling when a participant releases the Push-to-Talk button, directly impacting the flow of the Floor Release message as part of the overall floor control process.
Explore further
Broader topics and technologies where SRTCP plays a role.
Defining Specifications
3GPP specifications that define or reference SRTCP, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 24.380 vj10 | MCPTT Media Plane Control Protocol | Rel-19 |
| TS 24.581 vj00 | MCVideo Media Plane Control Protocol Specification | Rel-19 |
| TS 26.281 vj00 | MCVideo Codecs and Media Handling | Rel-19 |
| TS 26.880 ve00 | MBMS Enhancements for Mission Critical Video | Rel-14 |
| TR 26.998 vj00 | 5G AR/MR Glasses Integration Study | Rel-19 |
| TS 29.380 vj00 | MCPTT-LMR Interworking Media Plane Control | Rel-19 |
| TS 29.582 vj00 | MCData Interworking with LMR Systems | Rel-19 |
| TS 33.179 vdc0 | MCPTT Security Architecture and Procedures | Rel-13 |
| TS 33.180 vk00 | Security of Mission Critical (MC) Service | Rel-20 |
| TS 33.246 vj00 | MBMS Security Specification | Rel-19 |
| TS 33.879 vd10 | MCPTT Security Study | Rel-13 |
| TS 33.880 vf10 | Security Study for Enhanced Mission Critical Services | Rel-15 |
| TS 37.579 vi40 | Mission Critical services conformance testing | Rel-18 |