SSRC

Synchronization Source Identifier

Protocol →
Introduced in Rel-8 Also in: Core Network, Security

SSRC is a unique identifier for the source of a media stream within an RTP session, distinguishing concurrent sources for proper synchronization and playback in IMS and VoLTE/VoNR.

Category
Protocol
Introduced
Rel-8
Where
Services › Codecs
Also touches
2 segments
Specifications
17 specs
SSRC Description Purpose Related Classification Detected Changes Specifications

Description

The Synchronization Source Identifier (SSRC) is a 32-bit numeric identifier defined within the Real-time Transport Protocol (RTP), which is used for delivering audio and video over IP networks. In an RTP session, each participant that generates a stream of RTP packets (e.g., a microphone, a camera, or a media mixer) is assigned a unique SSRC. This identifier is carried in the header of every RTP packet, allowing receivers to associate incoming packets with their specific source. The primary role of the SSRC is to provide a source-level distinction for synchronization and demultiplexing. The RTP Control Protocol (RTCP) uses the SSRC to associate control packets (containing reports on quality, participant membership, and source description) with the corresponding media source, enabling functionalities like participant identification and network monitoring.

Architecturally, the SSRC is a key component in the media plane of IP Multimedia Subsystem (IMS)-based services like Voice over LTE (VoLTE) and Voice over NR (VoNR). When a call is established, Session Description Protocol (SDP) negotiation during the SIP signaling phase agrees on media formats and ports, but the SSRCs are dynamically chosen by each media sender when the RTP stream begins. The mechanism for ensuring uniqueness is probabilistic; each source randomly picks a 32-bit number, with a very low chance of collision within a session. If a collision is detected (two sources pick the same SSRC), a conflict resolution procedure defined in RFC 3550 is invoked, where one source may change its SSRC. Related specifications like 3GPP TS 24.229 (IMS) and TS 26.114 (IMS Media) govern its usage in the 3GPP context.

How it works is integral to multi-party scenarios. In a conference call, each participant's device acts as a synchronization source with its own SSRC. A Media Resource Function (MRF) or conference bridge, which mixes the audio streams, may also become a synchronization source itself, generating a new composite stream with a new SSRC. Receivers use the SSRC to correctly render audio from different talkers, apply individual volume controls, or compute separate jitter and packet loss statistics per source via RTCP Receiver Reports. This per-source identification is crucial for quality of experience (QoE) monitoring and for advanced services like active speaker indication. The SSRC is also used in security contexts; for example, in Secure RTP (SRTP), cryptographic contexts are often bound to SSRC values to provide source authentication and confidentiality.

Purpose & Motivation

The SSRC exists to solve the fundamental problem of identifying and managing multiple concurrent media sources within a single RTP session. Before RTP's standardization, multimedia sessions over IP lacked a standardized way to distinguish between different contributors in a session, making features like audio conferencing, video switching, and independent stream quality assessment difficult to implement in an interoperable manner. The creation of the SSRC as part of RTP (standardized in IETF RFC 1889, later RFC 3550) provided a lightweight, in-band mechanism for source identification without requiring constant out-of-band signaling.

In the 3GPP ecosystem, the adoption of RTP/RTCP and thus the SSRC was motivated by the move to all-IP networks for voice and multimedia services with IMS. For circuit-switched voice, identifying speakers was handled by different, less flexible mechanisms. For packet-switched VoLTE and VoNR, the SSRC enables the network to deliver rich communication services (RCS), multi-party calls, and video telephony with standard Internet protocols. It addresses the limitation of simply using IP addresses and ports for stream identification, which is insufficient when a single host (like a conference server) generates multiple logical streams or when network address translation (NAT) is involved.

Historically, as 3GPP defined IMS in Rel-5 and later integrated it for LTE and 5G voice, the SSRC became a cornerstone for media handling. Its purpose extends to enabling detailed media analytics and lawful interception, as specified in 3GPP TS 33.179 and 33.180, where correlating media streams to specific parties is essential. The SSRC solves the problem of scalable, dynamic source management in real-time group communications, which is a critical requirement for modern telecom services beyond simple point-to-point calls.

Classification

Part ofRTP
Related approachesRTCPSRTP

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (14 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-15.

Rel-15 3 changes

In Release 15, specific procedures were defined for SSRC allocation and usage to support multiplexing of MCVideo media and control streams. The release introduced the requirement for a transmission control server to generate globally unique SSRCs to prevent collisions and detailed how SSRCs are exchanged via SDP and transmission control messages. Furthermore, it specified the use of the SSRC in RTP and RTCP headers to enable multiplexing of different communications over the same IP address and port.

  • Correct source of stored status in 6.3.4.3 TS 24.379CR0460
  • Correction on MCVideo Group Identity and SSRC field TS 24.581CR0041
  • RTCP mux correction TS 24.379CR0400
Rel-16 3 changes

In Release 16, the SSRC function was enhanced to support implicit floor request cases, requiring specific SSRC handling for that procedure. Furthermore, the release mandated the inclusion of the transmitter's SSRC within reception control messages to improve session control. These changes provided more defined rules for SSRC usage in transmission control protocols during session establishment and media stream multiplexing.

  • SSRC handling for implicit floor request case TS 24.379CR0613
  • SSRC handling for implicit floor request case TS 24.380CR0242
  • Adding SSRC of Transmitter in reception control messages TS 24.581CR0046
Rel-18 7 changes

In Release 18, the SSRC function was enhanced to support multiplexing of media and control streams for MCPTT and MCVideo services over 5G Multicast/Broadcast Service (5MBS) and unicast transports. This specifically involves defining and clarifying the distinct SSRCs to be used for RTP audio/video media streams and for RTCP signaling, floor control, and transmission control when multiplexed over shared IP addresses and ports. These updates ensure globally unique SSRC allocation by the transmission control server to prevent collisions and enable endpoints to determine mutual multiplexing support during session establishment.

  • 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
  • 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
  • RTP SSRC of audio and video media streams usage during call setup using implicit transmission request - sig plane TS 24.281CR0206
  • Clarification of the SSRC to be used in video, audio and transmission control (TC) streams in MCVideo TS 24.581CR0092

+ 1 more changes

Rel-19 1 change

In Release 19, the SSRC function was extended to support its use within an implicit floor request when operating in a non-controlling function role. This enhancement provides a specific mechanism for a non-controlling MCVideo function to utilize the SSRC identifier within transmission control messages for floor control procedures. The change integrates this SSRC usage as defined for session establishment and media stream multiplexing into the implicit floor request scenario.

  • SSRC in implicit floor request in non-controlling function TS 24.379CR1058

Explore further

Broader topics and technologies where SSRC plays a role.

Defining Specifications

3GPP specifications that define or reference SSRC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 24.281 vj40 MCVideo Signalling Control Specification Rel-19
TS 24.379 vj50 Mission Critical Push To Talk (MCPTT) call control Rel-19
TS 24.380 vj10 MCPTT Media Plane Control Protocol Rel-19
TS 24.581 vj00 MCVideo Media Plane Control Protocol Specification Rel-19
TS 25.414 vj00 UTRAN Iu Interface User Plane Transport Protocols Rel-19
TS 26.223 vj00 IMS Telepresence Client Specification Rel-19
TS 29.333 vj00 MRFC-MRFP Mp Interface Protocol Rel-19
TS 29.380 vj00 MCPTT-LMR Interworking Media Plane Control Rel-19
TS 29.414 vj00 Nb Interface Bearer Transport & Control Protocols 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.879 vd10 MCPTT Security Study Rel-13
TS 33.880 vf10 Security Study for Enhanced Mission Critical Services Rel-15
TS 36.579 3GPP TR 36.579 Rel-8
TS 37.579 vi40 Mission Critical services conformance testing Rel-18
TS 48.103 vj00 A Interface User Plane Transport Protocols Rel-19