Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)
Extracted elements (28)
RTCP was chosen as the carrier for IDMS because IDMS involves collection and distribution of RTP packet arrival and presentation times — information that is inherently reception quality feedback, exactly what RTCP (including RTCP XR) is designed to carry. This avoids the need for a separate out-of-band signaling channel.
The rtcp-idms SDP attribute is defined at the media level rather than the session level because IDMS is performed on a single reference stream; other streams are synchronized to it using existing inter-stream mechanisms (lip-sync via sender reports). Audio is recommended as the IDMS reference stream because humans are more sensitive to audio synchronization errors than video.
The RTCP IDMS Settings Packet uses a 64-bit Presented NTP timestamp while the RTCP XR IDMS Report Block uses only a 32-bit truncated form. The MSAS always adds extra delay beyond the most lagged receiver, so 32 bits suffice for SC reporting; however, fine-grained MSAS control (e.g., phased-array transducers) requires the full 64-bit precision in the settings distribution.
The IDMS protocol defined in this document is backwards compatible with the earlier ETSI TISPAN TS 183 063 version. SPST values 2–4 are reserved for ETSI TISPAN definitions, and the RTCP XR Block Type 12 registration is updated from the ETSI original to this document as the normative reference.
A receiver SHALL report on RTP packet arrival times and MAY additionally report on presentation (playout) times. If no Packet Presented NTP timestamp is available, the field SHALL be set to 0 and the P flag SHALL be set to 0.
A receiver that receives the rtcp-idms attribute in an SDP answer SHALL start sending RTCP XR IDMS Report Blocks (following normal RTCP rules) and SHALL be ready to receive IDMS Settings Packets. In the declarative case, the same obligation applies upon receiving the attribute.
If the rtcp-idms attribute appears more than once for a media session (to couple multiple synchronization groups), each SyncGroupId SHALL only be inserted once, ensuring uniqueness of group identifiers within a session.
In SDP offer/answer, the sender SHALL include the rtcp-idms attribute in its answer; if the offered SyncGroupId is non-empty, the sender SHOULD NOT change it. If the SyncGroupId is empty (0) and the sender cannot determine the proper value, it SHALL remove the attribute from its answer.
It is RECOMMENDED to take the leap-second guidelines specified in RFC 7164 into account when implementing IDMS, because IDMS is particularly sensitive to leap-second-induced timing discrepancies when relying on NTP for clock synchronization.
Reserved bits in the RTCP XR IDMS Report Block MUST be set to zero at transmission and MUST be ignored by the receiver, as they are reserved for future definition.
The sender of an RTCP IDMS Settings Packet MUST use recent NTP timestamp values for the Packet Received NTP timestamp field — values that reflect current time and not too far in the future or past — to avoid ambiguity from RTP timestamp wrap-around.
When reporting on an RTP packet that is one of several consecutive packets sharing the same RTP timestamp, an SC SHOULD report on the packet with the lowest sequence number in the received sequence (not from a prior wrap-around period), to avoid synchronization errors caused by ambiguous multi-packet frames.
When the RTCP reporting timer allows, a Synchronization Client SHOULD report on an RTP packet received during the period since the last RTCP XR IDMS Report Block was sent, in order to manage ambiguity arising from RTP timestamp rollover.
The Media Stream Correlation Identifier is a 32-bit field present in both the RTCP XR IDMS Report Block and the RTCP IDMS Settings Packet. When the sender is an SC (SPST=1), it carries the SyncGroupId identifying the synchronization group. The value 0 indicates an empty field; 2^32-1 is reserved.
The Media Synchronization Application Server (MSAS) collects RTCP XR IDMS reports from Synchronization Clients (SCs) in a group, determines a reference playout point (e.g., the most lagged client), and distributes synchronization settings via RTCP IDMS Settings Packets. The MSAS may be co-located with the RTP sender or implemented as an independent network function.
The Packet Presented NTP timestamp in the RTCP IDMS Settings Packet uses the full 64-bit NTP format, unlike the 32-bit truncated form in the XR block, to support use cases (e.g., phased-array transducers) requiring sub-millisecond playout precision from the MSAS.
The Packet Received NTP timestamp (64 bits, full NTP format per RFC 5905) records the wallclock time of arrival of the first octet of the reported RTP packet at the SC. In the RTCP IDMS Settings Packet it reflects the reference client's reception time and is used by SCs to adjust playout delay.
The SDP media-level attribute 'rtcp-idms' signals participation in IDMS and carries the SyncGroupId (a decimal 32-bit unsigned integer, 0=empty, 4294967295 reserved). Both senders and receivers may insert it; it may appear multiple times for a session to couple multiple synchronization groups.
The Synchronization Packet Sender Type (SPST) is a 4-bit field in the RTCP XR IDMS Report Block that identifies the role of the packet sender. SPST=0 is reserved, SPST=1 indicates a Synchronization Client (SC), SPST=2–4 are defined by ETSI TISPAN, and SPST=5–15 are unassigned.
This document assigns RTCP Control Packet Type value 211 (PT=211) in the IANA 'RTCP Control Packet types (PT)' registry for the RTCP IDMS Settings Packet.
This document creates the IDMS XR Block SPST Registry subordinate to the IANA RTCP XR Block Type Registry. It is limited to 16 entries (0–15); value 0 is Reserved, values 1–4 are initially assigned (SC, MSAS, SC Prime Input, SC Prime Output), and values 5–15 are available via Specification Required policy.
This document registers the SDP media-level attribute 'rtcp-idms' (long form: RTCP IDMS Parameters) in the IANA SDP Parameters registry under att-field (media level only).
This document updates the IANA 'RTCP XR Block Types' registry, reassigning Block Type value 12 (BT=12) from the ETSI TISPAN IDMS block to the RTCP XR IDMS Report Block defined here.
Erroneous or malicious RTCP XR IDMS reports can cause other devices in the synchronization group to introduce large, unintended playout delays (e.g., a falsely reported two-hour delay). Both SCs and MSASs SHOULD check for out-of-bound information and reject reports where playout differences exceed configured limits.
IDMS implementations SHOULD include source authentication and message integrity measures (as surveyed in RFC 7201) to reduce vulnerability to man-in-the-middle attacks that could insert erroneous IDMS reports. Message confidentiality also prevents third parties from correlating receivers via the Media Stream Correlation Identifier.
If an attacker succeeds in manipulating an SC's wallclock, the SC will report incorrect IDMS timestamps, corrupting synchronization for the entire group. It is recommended to use a secure time synchronization service to prevent such clock synchronization attacks.
The RTCP IDMS Settings Packet (PT=211) is 7 32-bit words containing a standard RTCP header (V=2, P, Reserved, PT=211, length, SSRC of packet sender) followed by SSRC of media source (32 bits), Media Stream Correlation Identifier (32 bits), Packet Received NTP timestamp (64 bits), Packet Received RTP timestamp (32 bits), and Packet Presented NTP timestamp (64 bits).
The RTCP XR IDMS Report Block (BT=12) is 8 32-bit words (256 bits) containing: BT (8 bits), SPST (4 bits), Reserved (3 bits), P flag (1 bit), block length=7 (16 bits), PT (7 bits), Reserved (25 bits), Media Stream Correlation Identifier (32 bits), SSRC of media source (32 bits), Packet Received NTP timestamp (64 bits), Packet Received RTP timestamp (32 bits), and Packet Presented NTP timestamp (32 bits).