draft-ietf-avtcore-idms-13.txt   rfc7272.txt 
AVTCore R. van Brandenburg Internet Engineering Task Force (IETF) R. van Brandenburg
Internet-Draft H. Stokking Request for Comments: 7272 H. Stokking
Intended status: Standards Track O. van Deventer Category: Standards Track O. van Deventer
Expires: March 02, 2014 TNO ISSN: 2070-1721 TNO
F. Boronat F. Boronat
M. Montagud M. Montagud
Universitat Politecnica de Valencia UPV
K. Gross K. Gross
AVA Networks AVA Networks
August 29, 2013 June 2014
Inter-destination Media Synchronization using the RTP Control Protocol Inter-Destination Media Synchronization (IDMS)
(RTCP) Using the RTP Control Protocol (RTCP)
draft-ietf-avtcore-idms-13
Abstract Abstract
This document defines a new RTP Control Protocol (RTCP) Packet Type This document defines a new RTP Control Protocol (RTCP) Packet Type
and an RTCP Extended Report (XR) Block Type to be used for achieving and an RTCP Extended Report (XR) Block Type to be used for achieving
Inter-Destination Media Synchronization (IDMS). IDMS is the process Inter-Destination Media Synchronization (IDMS). IDMS is the process
of synchronizing playout across multiple geographically distributed of synchronizing playout across multiple media receivers. Using the
media receivers. Using the RTCP XR IDMS Report Block defined in this RTCP XR IDMS Report Block defined in this document, media playout
document, media playout information from participants in a information from participants in a synchronization group can be
synchronization group can be collected. Based on the collected collected. Based on the collected information, an RTCP IDMS Settings
information, an RTCP IDMS Settings Packet can then be sent to Packet can then be sent to distribute a common target playout point
distribute a common target playout point to which all the distributed to which all the distributed receivers, sharing a media experience,
receivers, sharing a media experience, can synchronize. can synchronize.
Typical use cases in which IDMS is useful are social TV, shared Typical use cases in which IDMS is useful are social TV, shared
service control (i.e. applications where two or more geographically service control (i.e., applications where two or more geographically
separated users are watching a media stream together), distance separated users are watching a media stream together), distance
learning, networked video walls, networked loudspeakers, etc. learning, networked video walls, networked loudspeakers, etc.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7272.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 02, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 3 2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 3
2.2. IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . . 4 2.2. IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Inter-Destination Media Synchronization (IDMS) Use Cases . . 4
4. Inter-Destination Media Synchronization (IDMS) use cases . . 4 4. Overview of IDMS Operation . . . . . . . . . . . . . . . . . 5
5. Overview of IDMS operation . . . . . . . . . . . . . . . . . 5 5. Architecture for Inter-Destination Media Synchronization . . 7
6. Architecture for Inter-Destination Media Synchronization . . 7 5.1. Media Synchronization Application Server (MSAS) . . . . . 7
6.1. Media Synchronization Application Server (MSAS) . . . . . 7 5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8
6.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8 5.3. Communication between MSAS and SCs . . . . . . . . . . . 8
6.3. Communication between MSAS and SCs . . . . . . . . . . . 8 6. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . . . . 8
7. RTCP XR Block for IDMS (IDMS Report Block) . . . . . . . . . 8 7. RTCP Packet Type for IDMS (IDMS Settings Packet) . . . . . . 11
8. RTCP Packet Type for IDMS (IDMS Settings) . . . . . . . . . . 11 8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13
9. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13 9. On the Use of Presentation Timestamps . . . . . . . . . . . . 14
10. On the use of presentation timestamps . . . . . . . . . . . . 14 10. SDP Signaling for RTCP IDMS Settings Packet . . . . . . . . . 15
11. SDP Signalling for RTCP IDMS Packet Type . . . . . . . . . . 15 11. SDP Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Offer/Answer Rules . . . . . . . . . . . . . . . . . . . 16
12.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . 16 11.2. Declarative Cases . . . . . . . . . . . . . . . . . . . 17
12.2. Declarative cases . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . 18
14.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . 18 13.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . 19
14.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . 19 13.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 19
14.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 19 13.4. IDMS XR Block SPST Registry . . . . . . . . . . . . . . 19
14.4. IDMS XR Block SPST Registry . . . . . . . . . . . . . . 19 13.5. Contact Information for Registrations . . . . . . . . . 20
14.5. Contact Information for Registrations . . . . . . . . . 20 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . . 21
16.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Inter-Destination Media Synchronization (IDMS) refers to the playout IDMS refers to the playout of media streams at two or more
of media streams at two or more geographically distributed locations geographically distributed locations in a time-synchronized manner.
in a time synchronized manner. It can be applied to both unicast and It can be applied to both unicast and multicast media streams and can
multicast media streams and can be applied to any type and/or be applied to any type and/or combination of streaming media, such as
combination of streaming media, such as audio, video and text audio, video, and text (subtitles). [Ishibashi2006] and
(subtitles).[Ishibashi2006] and [Boronat2009] provide an overview of [Boronat2009] provide an overview of technologies and algorithms for
technologies and algorithms for IDMS. IDMS.
IDMS requires the exchange of information on media receipt and Inter-Destination Media Synchronization (IDMS) requires the exchange
playout times among participants in an IDMS session. It may also of information on media arrival and presentation times among
require signaling for the initiation and maintenance of IDMS sessions participants in an IDMS session. It may also require signaling for
and groups of receivers. the initiation and maintenance of IDMS sessions and groups of
receivers.
The presented RTCP specification for IDMS is independent of the used The presented RTCP specification for IDMS is independent of the
synchronization algorithm, which is out-of-scope of this document. synchronization algorithm employed, which is out of scope of this
document.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Rationale 2. Rationale
2.1. Applicability of RTCP to IDMS 2.1. Applicability of RTCP to IDMS
Currently, a large share of real-time applications make use of RTP Currently, a large share of real-time applications make use of RTP
and RTCP [RFC3550]. RTP provides end-to-end network transport and RTCP [RFC3550]. RTP provides end-to-end network transport
functions suitable for applications requiring real-time data functions suitable for applications requiring real-time data
transport, such as audio, video or data, over multicast or unicast transport, such as audio, video, or data, over multicast or unicast
network services. The timestamps, sequence numbers, and payload network services. The timestamps, sequence numbers, and payload
(content) type identification mechanisms provided by RTP packets are (content) type identification mechanisms provided by RTP packets are
very useful for reconstructing the original media timing, the very useful for reconstructing the original media timing and the
original order of packets and for detecting packet loss at the client original order of packets and for detecting packet loss at the
side. receiver.
The data transport is augmented by a control protocol (RTCP) to allow The data transport is augmented by a control protocol (RTCP) to allow
monitoring of the data delivery in a manner that is scalable to large monitoring of the data delivery in a manner that is scalable to large
groups, and to provide minimal control and identification groups and to provide minimal control and identification
functionality. RTP receivers and senders provide reception quality functionality. RTP receivers and senders provide reception quality
feedback by sending out RTCP Receiver Report (RR) and Sender Report feedback by sending out RTCP receiver report (RR) and sender report
(SR) packets [RFC3550], respectively, which may be augmented by (SR) packets [RFC3550], respectively, which may be augmented by
eXtended Reports (XR) [RFC3611]. Both RTP and RTCP are intended to extended report (XR) blocks [RFC3611].
be tailored to modifications in order to include profile-specific
information required by particular applications, and the guidelines
on doing so are specified in [RFC5868].
IDMS involves the collection, summarizing and distribution of RTP IDMS involves the collection, summarization, and distribution of RTP
packet arrival and playout times. As information on RTP packet packet arrival and presentation times. As information on RTP packet
arrival times and playout times can be considered reception quality arrival times and presentation times can be considered reception
feedback information, RTCP is well suited for carrying out IDMS, quality feedback information, RTCP is well suited for carrying out
which may facilitate the implementation and deployment in typical IDMS.
multimedia applications.
2.2. IDMS and ETSI 2.2. IDMS and ETSI
A first version of IDMS for use with RTP/RTCP was standardized by A first version of IDMS for use with RTP/RTCP was standardized by
ETSI TISPAN in [TS183063], resulting in an IANA registration for an ETSI Telecommunications and Internet converged Services and Protocols
RTCP IDMS XR Block. At some point in time, this work was brought as for Advanced Networking (TISPAN) in [TS183063], resulting in an IANA
input to the IETF AVTCORE WG for further standardization, leveraging registration for an RTCP XR Block Type. This work was then brought
the RTP/RTCP expertise present in the AVTCORE WG. This document is as input to the IETF AVTCORE WG for further standardization,
the result of that effort. leveraging the RTP/RTCP expertise present in the AVTCORE WG. This
document is the result of that effort.
Although the IDMS protocol described in this document has evolved Although the IDMS protocol described in this document has evolved
significantly from the version that was originally specified by ETSI significantly from the version that was originally specified by ETSI
TISPAN, it is still backwards compatible with the ETSI version. As TISPAN, it is still backwards compatible with the ETSI version. As
such, it had been decided in ETSI to update the TS 183 063 document such, it had been decided in ETSI to update the TS 183 063 document
to reference this document as the normative specification of IDMS. to reference this document as the normative specification of IDMS.
This update can be found in newer versions of TS 183 063 (>3.5.2). This update can be found in newer versions of TS 183 063 (i.e.,
In accordance, this document proposes to update the IANA registration versions higher than 3.5.2). In accordance, this document proposes
for the RTCP IDMS XR Block to point to this document. Finally, this to update the IANA registration for the RTCP XR IDMS Report Block to
document proposes an IANA registry for SPST values, allowing the point to this document. Finally, this document proposes an IANA
registration of extensions to this document. registry for Synchronization Packet Sender Type (SPST) values,
allowing the registration of extensions to this document.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Inter-Destination Media Synchronization (IDMS) use cases 3. Inter-Destination Media Synchronization (IDMS) Use Cases
There are a large number of use cases in which IDMS might be useful. There is a large number of use cases in which IDMS might be useful.
This section will highlight some of them. It should be noted that This section will highlight some of them. It should be noted that
this section is in no way meant to be exhaustive. this section is in no way meant to be exhaustive.
A first usage scenario for IDMS is social TV. Social TV is the A first usage scenario for IDMS is social TV. Social TV is the
combination of media content consumption by two or more users at combination of media content consumption by two or more users at
different devices and locations combined with the real-time different devices and locations combined with real-time communication
communication between those users. An example of social TV is when between those users. An example of social TV is when two or more
two or more users are watching the same television broadcast at users are watching the same television broadcast at different devices
different devices and locations, while communicating with each other and locations, while communicating with each other using text, audio,
using text, audio and/or video. A skew in their media playout and/or video. A skew in their media playout processes can have
processes can have adverse effects on their experience. A well-known adverse effects on their experience. A well-known use case here is
use case here is one friend experiencing a goal in a football match one friend experiencing a goal in a football match well before or
well before or after other friend(s). after another friend(s).
Another potential use case for IDMS is a networked video wall. A Another potential use case for IDMS is a networked video wall. A
video wall consists of multiple computer monitors, video projectors, video wall consists of multiple computer monitors, video projectors,
or television sets tiled together contiguously or overlapped in order or television sets tiled together contiguously or overlapped in order
to form one large screen. Each of the screens reproduces a portion to form one large screen. Each of the screens reproduces a portion
of the larger picture. In some implementations, each screen may be of the larger picture. In some implementations, each screen may be
individually connected to the network and receive its portion of the individually connected to the network and receive its portion of the
overall image from a network-connected video server or video scaler. overall image from a network-connected video server or video scaler.
Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
potentially faster. If the refresh is not synchronized, the effect potentially faster. If the refresh is not synchronized, the effect
of multiple screens acting as one is broken, with users noticing of multiple screens acting as one is broken, with users noticing
tearing effects and no longer perceiving a single image. tearing effects and no longer perceiving a single image.
A third usage scenario is that of the networked loudspeakers, in A third usage scenario is that of networked loudspeakers in which two
which two or more speakers are connected to the network individually. or more speakers are connected to the network individually. Such
Such situations can for example be found in large conference rooms, situations can, for example, be found in large conference rooms,
legislative chambers, classrooms (especially those supporting legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as distance learning), and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in audio stadiums. Since humans are more sensitive to differences in audio
delay, this use case needs even more accuracy than the video wall use delay compared to video delay, this use case needs even more accuracy
case. Depending on the exact application, the need for accuracy can than the video wall use case. Depending on the exact application,
then be in the range of microseconds. the need for accuracy can then be in the range of microseconds.
5. Overview of IDMS operation 4. Overview of IDMS Operation
This section provides a brief example of how the RTCP functionality This section provides a brief example of how the RTCP functionality
is used for achieving IDMS. The section is tutorial in nature and is used for achieving IDMS. The section is tutorial in nature and
does not contain any normative statements. does not contain any normative statements.
Alice's . . . . . . .tv:abc.com . . . . . . . Bob's Alice's . . . . . . .tv:abc.com . . . . . . . Bob's
TV (Sync Client) (Sync Server) Laptop (Sync Client) TV (Sync Client) (Sync Server) Laptop (Sync Client)
| | | | | |
| Media Session | | | Media Session | |
|<=====================>| | |<=====================>| |
| Invite(URL, SyncGroupId) | | Invite(URL, SyncGroupId) |
|------------------------------------------------->| |------------------------------------------------->|
| | Media Session Set-up | | | Media Session Setup |
| |<========================>| | |<========================>|
| | | | | |
| Call set-up | | Call Setup |
|<================================================>| |<================================================>|
| | | | | |
| RTP Packets | RTP Packets | | RTP Packets | RTP Packets |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| RR + XR IDMS Report | | | RR + XR IDMS Report | |
|---------------------->| RR + XR IDMS Report | |---------------------->| RR + XR IDMS Report |
| |<-------------------------| | |<-------------------------|
| RTCP IDMS Settings | RTCP IDMS Settings | | RTCP IDMS Settings | RTCP IDMS Settings |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| | | | | |
Figure 1: Example of a typical IDMS session Figure 1: Example of a Typical IDMS Session
Alice is watching TV in her living room. At some point she sees that Alice is watching TV in her living room. At some point, she sees
a football game of Bob's favorite team is on. She sends him an that Bob's favorite team is playing football. She sends him an
invite to watch the program together. Embedded in the invitation is invite to watch the program together. Embedded in the invitation is
the link to the media server and a unique sync-group identifier. the link to the media server and a unique sync-group identifier.
Bob, who is also at home, receives the invite on his laptop. He Bob, who is also at home, receives the invite on his laptop. He
accepts Alice's invitation and the RTP client on his laptop sets up a accepts Alice's invitation, and the RTP client on his laptop sets up
session to the media server. A VoIP connection to Alice's TV is also a session with the media server. A Voice over IP (VoIP) connection
set up, so that Alice and Bob can talk while watching the game to Alice's TV is also set up, so that Alice and Bob can talk while
together. watching the game together.
As is common with RTP, both the RTP client in Alice's TV as well as As is common with RTP, both the RTP client in Alice's TV as well as
the one in Bob's laptop send periodic RTCP Receiver Reports (RR) to the one in Bob's laptop send periodic RTCP RRs to the media server.
the media server. However, in order to make sure Alice and Bob see However, in order to make sure Alice and Bob see the events in the
the events in the football game at (approximately) the same time, football game at the same time, their clients also periodically send
their clients also periodically send an RTCP XR IDMS Report Block to an RTCP XR IDMS Report Block to the Sync Server function of the media
the Sync Server function of the media server. Included in the XR server. Included in the RTCP XR IDMS Report Blocks are timestamps on
IDMS blocks are timestamps on when both Alice and Bob received (and, when both Alice and Bob received (and, optionally, when they played
optionally, when they played out) a particular RTP packet. out) a particular RTP packet.
The Sync Server function in the media server calculates a reference The Sync Server function in the media server calculates a reference
client from the received XR IDMS Report Blocks (e.g. by selecting the client from the received RTCP XR IDMS Report Blocks (e.g., by
most lagged client as the reference for IDMS). It then sends an RTCP selecting the most lagged client as the reference for IDMS). It then
IDMS Settings packet containing the playout information of this sends an RTCP IDMS Settings Packet containing the playout information
reference client to the sync clients of both Alice and Bob. of this reference client to the sync clients of both Alice and Bob.
In this case Bob's connection has the longest delay and the reference In this case, Bob's connection has the longest delay and the
client therefore includes a delay similar to the one experienced by reference client, therefore, includes a delay similar to the one
Bob. Upon reception of this information, Alice's RTP client can experienced by Bob. Upon reception of this information, Alice's RTP
choose what to do with this information. In this case it decreases client can choose what to do with this information. In this case, it
its playout rate temporarily until the playout time matches with the decreases its playout rate temporarily until the playout time matches
reference client playout (and thus matches Bob's playout). Another with the reference client playout (and, thus, matches Bob's playout).
option for Alice's TV would be to simply pause playback until it Another option for Alice's TV would be to simply pause playback until
catches up. The exact implementation of the synchronization it catches up. The exact implementation of the synchronization
algorithm is up to the client. algorithm is up to the client.
Upon reception of the RTCP IDMS Settings packet, Bob's client does Upon reception of the RTCP IDMS Settings Packet, Bob's client does
not have to do anything since it is already synchronized to the not have to do anything since it is already synchronized to the
reference client (since it is based on Bob's delay). Note that other reference client (since it is based on Bob's delay). Note that other
synchronization algorithms may introduce even more delay than the one synchronization algorithms may introduce even more delay than the one
experienced by the most delayed client, e.g. to account for delay experienced by the most delayed client, e.g., to account for delay
variations, for new clients joining an existing synchronization variations, for new clients joining an existing synchronization
group, etc. group, etc.
For this functionality to work correctly, it is necessary that the For this functionality to work correctly, it is necessary that the
wall clocks of the receivers are synchronized with each other. Alice wallclocks of the receivers are synchronized with each other. While
and Bob both report when they receive, and optionally when they play Alice and Bob both report when they receive, and optionally when they
out, certain RTP packets. In order to correlate their reports to playout, certain RTP packets, in order to correlate their reports to
each other, it is necessary that their wallclocks are synchronized. each other, it is necessary that their wallclocks are synchronized.
6. Architecture for Inter-Destination Media Synchronization 5. Architecture for Inter-Destination Media Synchronization
The architecture for IDMS, which is based on a sync-maestro The architecture for IDMS, which is based on a sync-maestro
architecture [Boronat2009], is sketched below. In this particular architecture [Boronat2009], is diagrammed below. In this particular
case, the Synchronization Client (SC) and Media Synchronization case, the Synchronization Client (SC) and Media Synchronization
Application Server (MSAS) entities are shown as additional Application Server (MSAS) entities are shown as additional
functionality for the RTP receiver and sender respectively. functionality for the RTP receiver and sender, respectively.
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| | SR + | | | | SR + | |
| RTP Receiver | RTCP | RTP Sender | | RTP Receiver | RTCP | RTP Sender |
| | IDMS | | | | IDMS | |
| +-----------------+ | <----- | +-----------------+ | | +-----------------+ | <----- | +-----------------+ |
| | | | | | | | | | | | | | | |
| | Synchronization | | | | Media | | | | Synchronization | | | | Media | |
| | Client | | | | Synchronization | | | | Client | | | | Synchronization | |
| | (SC) | | | | Application | | | | (SC) | | | | Application | |
| | | | | | Server | | | | | | | | Server | |
| | | | RR+XR | | (MSAS) | | | | | | RR+XR | | (MSAS) | |
| | | | -----> | | | | | | | | -----> | | | |
| +-----------------+ | | +-----------------+ | | +-----------------+ | | +-----------------+ |
| | | | | | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
IDMS Architecture Diagram Figure 2: IDMS Architecture Diagram
6.1. Media Synchronization Application Server (MSAS) 5.1. Media Synchronization Application Server (MSAS)
An MSAS collects RTP packet arrival times and playout times from one An MSAS collects RTP packet arrival times and presentation times from
or more SC(s) in a synchronization group by receiving RTCP IDMS XR one or more SCs in a synchronization group by receiving RTCP XR IDMS
Reports. The MSAS summarizes and distributes this information to the reports. The MSAS summarizes and distributes this information to the
SCs in the synchronization group as synchronization settings via the SCs in the synchronization group as synchronization settings via the
RTCP IDMS Settings messages, e.g. by determining the SC with the most RTCP IDMS Settings Packet messages, e.g., by determining the SC with
lagged playout and using its reported RTP packet arrival time and the most lagged playout and using its reported RTP packet arrival
playout time as a summary. time and presentation time as a summary.
It should be noted that while the figure above shows the MSAS as part It should be noted that while the diagram above shows the MSAS as
of the RTP Sender, this is not necessary. For example, an MSAS might part of the RTP sender, this is not necessary. For example, an MSAS
also be implemented as an independent function in the network or in a might also be implemented as an independent function in the network
master/slave type of architecture where one of the SC devices also or in a master/slave type of architecture where one of the SC devices
acts as an MSAS. Wherever the MSAS is implemented, it is important also acts as an MSAS. Wherever the MSAS is implemented, it is
that the MSAS has access to the RTP stream to which the XR Reports important that the MSAS has access to the RTP stream to which the XR
apply, so that it is able to correlate the IDMS XR Reports coming reports apply, so that it is able to correlate the RTCP XR IDMS
from different SCs. reports coming from different SCs.
6.2. Synchronization Client (SC) 5.2. Synchronization Client (SC)
An SC reports on RTP packet arrival times and playout times of a An SC reports on RTP packet arrival times and presentation times of a
media stream. It can receive summaries of such information, and use media stream. It can receive IDMS Settings Packets containing
that to adjust its playout buffer. The SC sends RTCP IDMS XR Reports summaries of such information and use that to adjust its playout
to the MSAS. buffer. The SC sends RTCP XR IDMS reports to the MSAS.
6.3. Communication between MSAS and SCs 5.3. Communication between MSAS and SCs
Two different message types are used for the communication between Two different message types are used for the communication between
MSAS and SCs. For the SC->MSAS message containing the playout MSAS and SCs. For the SC->MSAS message containing the arrival and
information of a particular client, an RTCP XR IDMS Report Block is playout information of a particular client, an RTCP XR IDMS Report
used (see Section 7). For the MSAS->SC message containing the Block is used (see Section 6). For the MSAS->SC message containing
synchronization settings instructions, a new RTCP IDMS Settings the synchronization settings instructions, a new RTCP IDMS Settings
Packet Type is defined (see Section 8). Packet is defined (see Section 7).
7. RTCP XR Block for IDMS (IDMS Report Block) 6. RTCP XR IDMS Report Block
This section specifies a new RTCP XR Block Type, the RTCP XR IDMS This section specifies a new RTCP XR Block Type, the RTCP XR IDMS
Report Block, for reporting IDMS information to an MSAS. In Report Block, for reporting IDMS information to an MSAS. In
particular it is used to provide feedback information on receipt particular, it is used to provide feedback information on arrival
times and presentation times of RTP packets. Its definition is based times and presentation times of RTP packets. Its definition is based
on [RFC3550] and [RFC3611]. on [RFC3550] and [RFC3611].
In most cases, a single RTP receiver will only be part of a single In most cases, a single RTP receiver will only be part of a single
IDMS session, i.e. it will report on receipt and presentation times IDMS session, i.e., it will report on arrival and presentation times
of RTP packets from a single RTP stream in a certain synchronization of RTP packets from a single RTP stream in a certain synchronization
group. In some cases, however, an RTP receiver may be a member of group. In some cases, however, an RTP receiver may be a member of
multiple synchronization groups for the same RTP stream, e.g. multiple synchronization groups for the same RTP stream, e.g.,
watching a single television program simultaneously with different watching a single television program simultaneously with different
groups. In even further cases, a receiver may wish to synchronize groups. In even further cases, a receiver may wish to synchronize
different RTP streams at the same time, either as part of the same different RTP streams at the same time, either as part of the same
synchronization group or as part of multiple synchronization groups. synchronization group or as part of multiple synchronization groups.
These are all valid scenarios for IDMS, and will require multiple These are all valid scenarios for IDMS and will require multiple
reports by an SC. reports by an SC.
This document does not define new rules on when to send RTCP reports, This document does not define new rules for when to send RTCP
but uses the existing rules specified in [RFC3550] for sending RTCP reports, but uses the existing rules specified in [RFC3550] for
reports. When the RTCP reporting timer allows an SC to send an IDMS sending RTCP reports. When the RTCP reporting timer allows an SC to
report, the SC SHOULD report on an RTP packet received during the send an IDMS report, the SC SHOULD report on an RTP packet received
period since the last RTCP XR IDMS Report Block was sent. Because of during the period since the last RTCP XR IDMS Report Block was sent.
RTP timestamp rollover, there is ambiguity in mapping RTP timestamps Because of RTP timestamp rollover, there is ambiguity in mapping RTP
to NTP timestamps. The recommendation to report on recent RTP timestamps to NTP timestamps. The recommendation to report on recent
packets serves to manage this ambiguity. For more details on which RTP packets serves to manage this ambiguity. For more details on
packet to report on, see below under 'Packet Received RTP timestamp'. which packet to report on, see below under "Packet Received RTP
timestamp".
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=12 | SPST |Resrv|P| block length=7 | | BT=12 | SPST |Resrv|P| block length=7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Resrv | | PT | Resrv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier | | Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word | | Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word | | Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp | | Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp | | Packet Presented NTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IDMS report block consists of 8 32-bit words, with the following The RTCP XR IDMS Report Block consists of 8 32-bit words, with the
fields: following fields:
Block Type (BT): 8 bits. It identifies the block format. Its value Block Type (BT): 8 bits. It identifies the block format. Its value
is set to 12. is set to 12.
Synchronization Packet Sender Type (SPST): 4 bits. This field Synchronization Packet Sender Type (SPST): 4 bits. This field
identifies the role of the packet sender for this specific eXtended identifies the role of the packet sender for this specific Extended
Report. It can have the following values, as maintained by IANA (see Report. It can have the following values, as enumerated in a
Section 14.4): registry maintained by IANA (see Section 13.4):
SPST=0 Reserved for future use. SPST=0 Reserved for future use.
SPST=1 The packet sender is an SC. It uses this XR to report SPST=1 The packet sender is an SC. It uses this XR to report
synchronization status information. Timestamps relate to the SC synchronization status information. Timestamps relate to the SC
input. input.
SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]). SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]).
SPST=5-15 Unassigned. SPST=5-15 Unassigned.
Reserved bits (Resrv): 3 bits. These bits are reserved for future Reserved bits (Resrv): 3 bits. These bits are reserved for future
definition. In the absence of such a definition, the bits in this definition. In the absence of such a definition, the bits in this
field MUST be set to zero at transmission and MUST be ignored by the field MUST be set to zero at transmission and MUST be ignored by the
receiver. receiver.
Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the
Packet Presented NTP timestamp field contains a value, 0 if it is Packet Presented NTP timestamp field contains a value, 0 if it is
empty. If this flag is set to zero, then the Packet Presented NTP empty. If this flag is set to 0, then the Packet Presented NTP
timestamp SHALL be ignored by the receiver. timestamp SHALL be ignored by the receiver.
Block Length: 16 bits. This field indicates the length of the block Block Length: 16 bits. This field indicates the length of the block
in 32 bit words minus one and is set to 7, as this RTCP Block Type in 32-bit words minus one and is set to 7, as this RTCP XR IDMS Block
has a fixed length. Report has a fixed length.
Payload Type (PT): 7 bits. This field identifies the format of the Payload Type (PT): 7 bits. This field identifies the format of the
media payload, according to [RFC3551]. This is the payload type of media payload, according to [RFC3551]. This is the payload type of
the RTP packet reported upon. The PT field is needed in the case the RTP packet reported upon. The PT field is needed in the case
where the MSAS is neither the Media Server nor a receiver of the where the MSAS is neither the media server nor a receiver of the
media stream, i.e. it is implemented as a third-part entity. In such media stream, i.e., it is implemented as a third-party entity. In
cases, the MSAS needs the PT to determine the rate of advancement of such cases, the MSAS needs the PT to determine the rate of
the timestamps of the RTP media stream to be able to relate reports advancement of the timestamps of the RTP media stream to be able to
from different SCs on different RTP timestamp values. relate reports from different SCs on different RTP timestamp values.
Reserved bits (Resrv): 25 bits. These bits are reserved for future Reserved bits (Resrv): 25 bits. These bits are reserved for future
use and SHALL be set to 0 at transmission and MUST be ignored by the use and SHALL be set to 0 at transmission and MUST be ignored by the
receiver. receiver.
Media Stream Correlation Identifier: 32 bits. This identifier is Media Stream Correlation Identifier: 32 bits. This identifier is
used to correlate synchronized media streams. The value 0 (all bits used to correlate synchronized media streams. The value 0 (all bits
are set "0") indicates that this field is empty. The value 2^32-1 are set "0") indicates that this field is empty. The value 2^32-1
(all bits are set "1") is reserved for future use. If the RTCP (all bits are set "1") is reserved for future use. If the RTCP
Packet Sender is an SC (SPST=1), then the Media Stream Correlation Packet Sender is an SC (SPST=1), then the Media Stream Correlation
Identifier field contains the Synchronization Group Identifier Identifier field contains the Synchronization Group Identifier
(SyncGroupId) to which the report applies. (SyncGroupId) to which the report applies.
SSRC: 32 bits. The SSRC of the media source is set to the value of Synchronization Source (SSRC): 32 bits. The SSRC of the media source
the SSRC identifier carried in the RTP header [RFC3550] of the RTP is set to the value of the SSRC identifier carried in the RTP header
packet to which the XR IDMS relates. [RFC3550] of the RTP packet to which the XR IDMS relates.
Packet Received NTP timestamp: 64 bits. This timestamp reflects the Packet Received NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the moment of arrival of the first octet of the wallclock time at the moment of arrival of the first octet of the RTP
RTP packet to which the XR IDMS relates. It is formatted based on packet to which the XR IDMS relates. It is formatted based on the
the NTP timestamp format as specified in [RFC5905]. See Section 9 NTP timestamp format as specified in [RFC5905]. See Section 8 for
for more information on how this field is used. more information on how this field is used.
Packet Received RTP timestamp: 32 bits. This timestamp has the value Packet Received RTP timestamp: 32 bits. This timestamp has the value
of the RTP timestamp carried in the RTP header [RFC3550] of the RTP of the RTP timestamp carried in the RTP header [RFC3550] of the RTP
packet to which the XR IDMS relates. Several consecutive RTP packets packet to which the XR IDMS relates. Several consecutive RTP packets
will have equal timestamps if they are (logically) generated at once, will have equal timestamps if they are (logically) generated at once,
e.g., belong to the same video frame. It may well be the case that e.g., belong to the same video frame. It may well be the case that
one receiver reports on the first RTP packet having a certain RTP one receiver reports on the first RTP packet that has a certain RTP
timestamp and a second receiver reports on the last RTP packet having timestamp, and a second receiver reports on the last RTP packet that
that same RTP timestamp. This would lead to an error in the has that same RTP timestamp. This would lead to an error in the
synchronization algorithm due to the faulty interpretation of synchronization algorithm due to the faulty interpretation of
considering both reports to be on the same RTP packet. When considering both reports to be on the same RTP packet. When
reporting on an RTP packet which is one of several consecutive RTP reporting on an RTP packet, which is one of several consecutive RTP
packets having equal timestamps, an SC SHOULD report on the RTP packets having equal timestamps, an SC SHOULD report on the RTP
packet it received with the lowest sequence number. Note that with packet it received with the lowest sequence number. Note that
'lowest sequence number' here is meant the first in the sequence of 'lowest sequence number' here is meant to be the first in the
RTP packets just received, not from an earlier time before the last sequence of RTP packets just received, not from an earlier time
wrap-around of RTP timestamps (unless this wrap-around occurs during before the last wrap around of RTP timestamps (unless this wrap
the sequence with equal RTP timestamps). around occurs during the sequence with equal RTP timestamps).
Packet Presented NTP timestamp: 32 bits. This timestamp reflects the Packet Presented NTP timestamp: 32 bits. This timestamp reflects the
wall clock time at the moment the rendered media unit (e.g. video wallclock time at the moment the rendered media unit (e.g., video
frame or audio sample) contained in the first byte of the associated frame or audio sample) contained in the first byte of the associated
RTP packet is presented to the user. It is based on the time format RTP packet is presented to the user. It is based on the time format
used by NTP and consists of the least significant 16 bits of the NTP used by NTP and consists of the least significant 16 bits of the NTP
seconds part and the most significant 16 bits of the NTP fractional seconds part and the most significant 16 bits of the NTP fractional
second part. If no Packet Presented NTP timestamp is available, this second part. If no Packet Presented NTP timestamp is available, this
field SHALL be set to 0 and be considered empty and the Packet field SHALL be set to 0 and be considered empty, and the Packet
Presented NTP timestamp flag (P) SHALL be set to 0. With regards to Presented NTP timestamp flag (P) SHALL be set to 0. With regards to
NTP epoch and rollover, the value of the Packet Presented NTP NTP epoch and rollover, the value of the Packet Presented NTP
timestamp is considered to always be greater than the Packet Received timestamp is considered to always be greater than the Packet Received
NTP Timestamp and to be within 2^16 seconds of it. Presented in this NTP timestamp and to be within 2^16 seconds of it. Presented in this
context means the moment the data is played out to the user of the context means the moment the data is played out to the user of the
system, i.e. sound played out through speakers, video images being system, i.e., sound played out through speakers, video images being
displayed on some display, etc. The accuracy resulting from the displayed on some display, etc. The accuracy resulting from the
synchronization algorithm will only be as good as the accuracy with synchronization algorithm will only be as good as the accuracy with
which the SCs can determine the delay between receiving packets and which the SCs can determine the delay between receiving packets and
presenting them to the end-user. presenting them to the end user. If no presentation timestamps are
reported by SCs, the ability to accurately synchronize playout may be
limited.
8. RTCP Packet Type for IDMS (IDMS Settings) 7. RTCP Packet Type for IDMS (IDMS Settings Packet)
This section specifies the RTCP Packet Type for indicating This section specifies the RTCP packet type for indicating
synchronization settings instructions to the receivers of the RTP synchronization settings instructions to the receivers of the RTP
media stream. Its definition is based on [RFC3550]. media stream. Its definition is based on [RFC3550]. Synchronization
settings take the form of a report referencing a real or hypothetical
RTP packet selected or contrived by the MSAS.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Resrv | PT=TBD | length | |V=2|P| Resrv | PT=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier | | Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word | | Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word | | Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp | | Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, most significant word | | Packet Presented NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp, least significant word | | Packet Presented NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 64 bits form the header of the RTCP Packet Type, as defined The first 64 bits form the header of the RTCP packet type, as defined
in [RFC3550]. The SSRC of packet sender identifies the sender of the in [RFC3550]. The SSRC of the packet sender identifies the sender of
specific RTCP packet. the specific RTCP packet.
The RTCP IDMS packet consists of 7 32-bit words, with the following The RTCP IDMS Settings Packet consists of 7 32-bit words, with the
fields: following fields:
PT: To be determined upon registration with IANA, inserted by the RFC PT: 211, as registered by IANA.
Editor upon registration with IANA.
SSRC: 32 bits. The SSRC of the media source is set to the value of SSRC: 32 bits. The SSRC of the media source is set to the value of
the SSRC identifier of the media source carried in the RTP header the SSRC identifier of the media source carried in the RTP header
[RFC3550] of the RTP packet to which the RTCP IDMS packet relates. [RFC3550] of the RTP packet to which the RTCP IDMS Settings Packet
relates.
Media Stream Correlation Identifier: 32 bits. This identifier is Media Stream Correlation Identifier: 32 bits. This identifier is
used to correlate synchronized media streams. The value 0 (all bits used to correlate synchronized media streams. The value 0 (all bits
are set "0") indicates that this field is empty. The value 2^32-1 are set "0") indicates that this field is empty. The value 2^32-1
(all bits are set "1") is reserved for future use. The Media Stream (all bits are set "1") is reserved for future use. The Media Stream
Correlation Identifier contains the SyncGroupId of the group to which Correlation Identifier contains the SyncGroupId of the group to which
this packet is sent. this packet is sent.
Packet Received NTP timestamp: 64 bits. This timestamp reflects the Packet Received NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the reference client at the moment it received the wallclock time at the reference client at the moment it received the
first octet of the RTP packet to which this packet relates. It can first octet of the RTP packet to which this packet relates. It can
be used by the synchronization algorithm on the receiving SC to be used by the synchronization algorithm on the receiving SC to
adjust its playout timing in order to achieve synchronization, e.g. adjust its playout timing in order to achieve synchronization, e.g.,
to set the required playout delay. The timestamp is formatted based to set the required playout delay. The timestamp is formatted based
on the NTP timestamp format as specified in [RFC5905]. See Section 9 on the NTP timestamp format as specified in [RFC5905]. See Section 8
for more information on how this field is used. Because RTP for more information on how this field is used. Because RTP
timestamps do wrap around, the sender of this packet MUST use recent timestamps do wrap around, the sender of this packet MUST use recent
values, i.e. choose NTP timestamps that reflect current time and not values, i.e., choose NTP timestamps that reflect current time and not
too far in the future or in the past so as to create ambiguity with too far in the future or in the past so as to create ambiguity with
regards to RTP timestamp wrap around. regards to RTP timestamp wrap around.
Packet Received RTP timestamp: 32 bits. This timestamp has the value Packet Received RTP timestamp: 32 bits. This timestamp has the value
of the RTP timestamp carried in the RTP header [RFC3550] of the RTP of the RTP timestamp carried in the RTP header [RFC3550] of the RTP
packet to which the XR IDMS relates. This SHOULD relate to the first packet to which the XR IDMS relates. This SHOULD relate to the first
arriving RTP packet containing this particular RTP timestamp, in case arriving RTP packet containing this particular RTP timestamp, in case
multiple RTP packets contain the same RTP timestamp. multiple consecutive RTP packets contain the same RTP timestamp.
Packet Presented NTP timestamp: 64 bits. This timestamp reflects the Packet Presented NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the reference client at the moment it presented wallclock time at the reference client at the moment it presented the
the rendered media unit (e.g. video frame or audio sample) contained rendered media unit (e.g., video frame or audio sample) contained in
in the first octet of the associated RTP packet to the user. The the first octet of the associated RTP packet to the user. The
timestamp is formatted based on the NTP timestamp format as specified timestamp is formatted based on the NTP timestamp format as specified
in [RFC5905]. If no Packet Presented NTP timestamp is available, in [RFC5905]. If no Packet Presented NTP timestamp is available,
this field SHALL be set to 0 and be considered empty. This field MAY this field SHALL be set to 0 and be considered empty. This field MAY
be left empty if none or only one of the receivers reported on be left empty if none or only one of the receivers reported on
presentation timestamps. Presented here means the moment the data is presentation timestamps. Presented here means the moment the data is
played out to the user of the system. played out to the user of the system.
In some use cases (e.g. phased array transducers), the level of In some use cases (e.g., phased array transducers), the level of
control an MSAS might need to have over the exact moment of playout control an MSAS might need to have over the exact moment of playout
is so precise that a 32bit Presented Timestamp will not suffice. For is so precise that a 32-bit Presented timestamp will not suffice.
this reason, this RTCP Packet Type for IDMS includes a 64bit For this reason, this RTCP packet type for IDMS includes a 64-bit
Presented Timestamp field. Since an MSAS will in practice always add Presented Timestamp field. Since an MSAS will in practice always add
some extra delay to the delay reported by the most lagged receiver some extra delay to the delay reported by the most lagged receiver
(to account for packet jitter), it suffices for the IDMS XR Block (to account for packet jitter), it suffices for the RTCP XR IDMS
Type with which the SCs report on their playout to have a 32bit Report Block with which the SCs report on their playout to have a
Presented Timestamp field. 32-bit Presented Timestamp field.
9. Timing and NTP Considerations 8. Timing and NTP Considerations
To achieve IDMS, the different receivers involved need synchronized To achieve IDMS, the different receivers involved need synchronized
(wall) clocks as a common timeline for synchronization. This wallclocks as a common timeline for synchronization. This
synchronized clock is used for reporting the Packet Received NTP synchronized clock is used for reporting the Packet Received NTP
Timestamps and the Packet Presented NTP Timestamp, and for timestamp and the Packet Presented NTP timestamp, and for
interpretation of these fields in received IDMS reports. Depending interpretation of these fields in received IDMS Settings Packets.
on the synchronization accuracy required, different clock Depending on the synchronization accuracy required, different clock
synchronization methods can be used. For social TV, synchronization synchronization methods can be used. For social TV, synchronization
accuracy should be achieved on the order of hundreds of milliseconds. accuracy should be achieved on the order of hundreds of milliseconds.
In that case, correct use of NTP on receivers will in most situations In that case, correct use of NTP on receivers will in most situations
achieve the required accuracy. As a guideline, to deal with clock achieve the required accuracy. As a guideline, to deal with clock
drift of receivers, receivers should synchronize their clocks at the drift of receivers, receivers should synchronize their clocks at the
beginning of a synchronized session. In case of high required beginning of a synchronized session. In case of high required
accuracy, the synchronized clocks of different receivers should not accuracy, the synchronized clocks of different receivers should not
drift beyond the accuracy required for the synchronization mechanism. drift beyond the accuracy required for the synchronization mechanism.
In practice, this can mean that receivers need to synchronize their In practice, this can mean that receivers need to synchronize their
clocks repeatedly during a synchronization session. clocks repeatedly during a synchronization session.
skipping to change at page 14, line 4 skipping to change at page 14, line 12
achieve the required accuracy. As a guideline, to deal with clock achieve the required accuracy. As a guideline, to deal with clock
drift of receivers, receivers should synchronize their clocks at the drift of receivers, receivers should synchronize their clocks at the
beginning of a synchronized session. In case of high required beginning of a synchronized session. In case of high required
accuracy, the synchronized clocks of different receivers should not accuracy, the synchronized clocks of different receivers should not
drift beyond the accuracy required for the synchronization mechanism. drift beyond the accuracy required for the synchronization mechanism.
In practice, this can mean that receivers need to synchronize their In practice, this can mean that receivers need to synchronize their
clocks repeatedly during a synchronization session. clocks repeatedly during a synchronization session.
Because of the stringent synchronization requirements for achieving Because of the stringent synchronization requirements for achieving
good audio quality in some use cases, a high accuracy will be needed. good audio quality in some use cases, a high accuracy will be needed.
In this case, use of the global NTP system may not be sufficient. In this case, use of the global NTP system may not be sufficient.
For improved accuracy, a local NTP server could be set up, or some For improved accuracy, a local NTP server could be set up, or some
other more accurate clock synchronization mechanism can be used, such other more accurate clock synchronization mechanism can be used, such
as GPS time or the Precision Time Protocol [IEEE-1588]. as GPS time or the Precision Time Protocol [IEEE1588-2008].
[I-D.draft-ietf-avtcore-clksrc] defines a set of SDP parameters for [RFC7273] defines a set of Session Description Protocol (SDP)
signaling the clock synchronization source or sources available to parameters for signaling the clock synchronization source or sources
and used by the individual receivers. SCs MAY use this draft to available to and used by the individual receivers. SCs MAY use
indicate their clock synchronization source or sources in use and [RFC7273] to indicate their clock synchronization source or sources
available. Using these parameters, an SC can indicate which in use and available. Using these parameters, an SC can indicate
synchronization source is being used at the moment, the last time the which synchronization source is being used at the moment. An SC can
SC synchronized with this source and the synchronization frequency. also indicate any other synchronization sources available to it.
An SC can also indicate any other synchronization sources available This allows multiple SCs in an IDMS session to use the same or a
to it. This allows multiple SCs in an IDMS session to use the same similar clock source for their session.
or a similar clock source for their session.
Applications performing IDMS may or may not be able to choose a Applications performing IDMS may or may not be able to choose a
synchronization method for the system clock, because this may be a synchronization method for the system clock because this may be a
system-wide setting which the application cannot change. How system-wide setting that the application cannot change. How
applications deal with this is up to the implementation. The applications deal with this is up to the implementation. The
application might control the system clock, or it might use a application might control the system clock, or it might use a
separate application clock or even a separate IDMS session clock. It separate application clock or even a separate IDMS session clock. It
might also report on the system clock and the synchronization method might also report on the system clock and the synchronization method
used, without being able to change it. used, without being able to change it.
[I-D.draft-ietf-leap-seconds] presents some guidelines on how RTP [RFC7164] presents some guidelines on how RTP senders and receivers
senders and receivers should deal with leap seconds. When relying on should deal with leap seconds. When relying on NTP for clock
NTP for clock synchronization, IDMS is particularly sensitive to leap synchronization, IDMS is particularly sensitive to
second induced timing discrepancies. It is RECOMMENDED to take the leap-second-induced timing discrepancies. It is RECOMMENDED to take
guidelines specified in [I-D.draft-ietf-leap-seconds] into account the guidelines specified in [RFC7164] into account when implementing
when implementing IDMS. IDMS.
10. On the use of presentation timestamps 9. On the Use of Presentation Timestamps
A receiver can report on different timing events, i.e. on packet A receiver can report on different timing events, i.e., on packet
arrival times and on playout or presentation times. A receiver SHALL arrival times and on playout or presentation times. A receiver SHALL
report on arrival times and a receiver MAY report on playout times. report on arrival times and a receiver MAY report on playout times.
RTP packet arrival times are relatively easy to report on. Normally, RTP packet arrival times are relatively easy to report on. Normally,
the processing and playout of the same media stream by different the processing and playout of the same media stream by different
receivers will take roughly the same amount of time. Synchronizing receivers will take roughly the same amount of time. Synchronizing
on packet arrival times, may lead to some accuracy loss, but it will on packet arrival times may lead to some accuracy loss, but it will
be adequate for many applications, such as social TV. be adequate for many applications, such as social TV.
Also, if the receivers are in some way controlled, e.g. having the Also, if the receivers are in some way controlled, e.g., having the
same buffer settings, decoding and rendering times, high accuracy can same buffer settings and decoding and rendering times, high accuracy
be achieved. However, if all receivers in a synchronization session can be achieved. However, if all receivers in a synchronization
have the ability to report on, and thus synchronize on, actual session have the ability to report on and, thus, synchronize on
playout times, or packet presentation times, this may be more actual presentation times, this will be more accurate. It is up to
accurate. It is up to applications and implementations of this RTCP the applications and implementations of this RTCP extension whether
extension whether to implement and use this. to implement and use presentation timestamps.
11. SDP Signalling for RTCP IDMS Packet Type 10. SDP Signaling for RTCP IDMS Settings Packet
The SDP attribute rtcp-idms is used to signal the use of the RTCP The SDP attribute rtcp-idms is used to signal the use of the RTCP
IDMS Packet Type for IDMS and the associated RTCP XR Block for IDMS. IDMS Settings Packet and the associated RTCP XR IDMS Report Block.
It is also used to carry an identifier of the synchronization group It is also used to carry an identifier of the synchronization group
to which clients belong or will belong. The SDP attribute is used as to which clients belong or will belong. The SDP attribute is used as
a media-level attribute during session setup. This means that in a media-level attribute during session setup. This means that in
case of multiple related streams, IDMS is performed on one of them. case of multiple related streams, IDMS is performed on one of them.
The other streams will be synchronized to this reference or master The other streams will be synchronized to this reference or master
stream using existing inter-stream synchronization (i.e. lip-sync) stream using existing inter-stream synchronization (such as lip-sync)
solutions, i.e. using Sender Reports based on a common clock source. solutions, i.e., using sender reports based on a common clock source.
Basic guidelines for choosing the media stream for IDMS is to choose Basic guidelines for choosing the media stream for IDMS is to choose
audio above video, as humans are more sensitive to degradation in audio above video, as humans are most sensitive to degradation in
audio quality than in video quality. When using multi-description or audio synchronization. When using multi-description or multi-view
multi-view codecs, the IDMS control should be performed on the base codecs, the IDMS control should be performed on the base layer.
layer.
This SDP attribute is defined as follows, using Augmented Backus-Naur This SDP attribute is defined as follows, using Augmented Backus-Naur
Form [RFC5234]. Form [RFC5234].
rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF
sync-grp = "sync-group=" SyncGroupId sync-grp = "sync-group=" SyncGroupId
SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294 SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294
DIGIT = %x30-39 DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer and represented in decimal. SyncGroupId is a 32-bit unsigned integer and represented in decimal.
SyncGroupId identifies a group of SCs for IDMS. The value SyncGroupId identifies a group of SCs for IDMS. The value
SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295
(2^32-1) is reserved for future use. For a description on the value (2^32-1) is reserved for future use. For a description on the value
of SyncGroupId to include, see Section 12. of SyncGroupId to include, see Section 11.
The following is an example of the SDP attribute for IDMS. The following is an example of the SDP attribute for IDMS.
a=rtcp-idms:sync-group=42 a=rtcp-idms:sync-group=42
12. SDP rules 11. SDP Rules
12.1. Offer/Answer rules
11.1. Offer/Answer Rules
The SDP usage for IDMS follows the rules defined in [RFC4566] and The SDP usage for IDMS follows the rules defined in [RFC4566] and
section 5 of [RFC3611] on SDP signalling, with the exception of what Section 5 of [RFC3611] on SDP signaling with the exception of what is
is stated here. The IDMS usage of RTCP is a (loosely coupled) stated here. The IDMS usage of RTCP is a loosely coupled
collaborative attribute, in the sense that receivers send their collaborative attribute, in the sense that receivers send their
status information and, in response, the MSAS (asynchronously) sends status information and, in response, the MSAS asynchronously sends
synchronization setting instructions. The rtcp-idms attribute thus synchronization setting instructions. The rtcp-idms attribute, thus,
indicates the ability to send and receive indicated RTCP messages. indicates the ability to send and receive indicated RTCP messages.
This section defines how this SDP attribute should be used with This section defines how this SDP attribute should be used with
regard to an offer/answer context. regard to an offer/answer context.
It is expected that, in most cases, the rtcp-idms attribute will be It is expected that, in most cases, the rtcp-idms attribute will be
used in an offer/answer context where receivers will have pre- used in an offer/answer context where receivers will have
determined, through some means outside the scope of this document, a predetermined, through some means outside the scope of this document,
SyncGroupId before the media session is setup. However, it is also a SyncGroupId before the media session is set up. However, A sender
supported that the MSAS assigns such a SyncGroupId, for example if that assigns a SyncGroupId is also supported for cases, for example,
the MSAS contains group management functionality. Thus, both the where the MSAS contains group management functionality and is
MSAS and the SCs can insert the attribute and the SyncGroupId. co-located with or otherwise communicates with the sender. Thus,
Furthermore, it is allowed to insert the attribute for more than one both senders and receivers can insert the attribute and the
media stream, allowing an SC to become part of multiple SyncGroupId. Furthermore, the attribute is allowed to be inserted
synchronization groups simultaneously. This effectively couples two for more than one media stream, allowing an SC to become part of
(or more) synchronization groups to each other. If the rtcp-idms multiple synchronization groups simultaneously. This effectively
attribute is inserted more than once for a particular media session, couples two (or more) synchronization groups to each other. If the
each SyncGroupId SHALL only be inserted once. rtcp-idms attribute is inserted more than once for a particular media
session, each SyncGroupId SHALL only be inserted once.
In order to join an IDMS session, the receiver (the SC) inserts the In order to join an IDMS session, the receiver (the SC) inserts the
rtcp-idms attribute as a media level attribute in the SDP offer. rtcp-idms attribute as a media-level attribute in the SDP offer.
This SDP offer can be an initial offer, if the media session is This SDP offer can be an initial offer if the media session is
starting as a synchronized session. The SDP offer can also be an starting as a synchronized session. The SDP offer can also be an
update to an existing media session, converting the session to an update to an existing media session, converting the session to an
IDMS session. If the receiver has a pre-determined SyncGroupId IDMS session. If the receiver has a predetermined SyncGroupId value,
value, it SHOULD use this value for setting the SyncGroupId parameter it SHOULD use this value for setting the SyncGroupId parameter in the
in the rtcp-idms attribute. If the receiver does not know the rtcp-idms attribute. If the receiver does not know the SyncGroupId
SyncGroupId to be used, it MAY leave the SyncGroupId parameter empty to be used, it MAY leave the SyncGroupId parameter empty by setting
by setting its value to 0. its value to 0.
The MSAS SHALL include the rtcp-idms attribute in its answer. If the The sender SHALL include the rtcp-idms attribute in its answer. If
value of the SyncGroupId parameter in the offer was not empty (not the value of the SyncGroupId parameter in the offer is not empty (not
equal to 0), the MSAS SHOULD NOT change the SyncGroupId in its equal to 0), the sender SHOULD NOT change the SyncGroupId in its
answer. If the SyncGroupId was empty, the MSAS SHALL include the answer. If the SyncGroupId is empty, the sender SHALL include the
proper SyncGroupId in its answer. If the MSAS receives an offer with proper SyncGroupId in its answer. If the sender receives an offer
the value of the SyncGroupId parameter set to 0, and cannot determine with the value of the SyncGroupId parameter set to 0, and cannot
the proper SyncGroupId, it SHALL remove the attribute from its determine the proper SyncGroupId, it SHALL remove the attribute from
answer. its answer.
An MSAS receiving an SDP offer without the rtcp-idms attribute can A sender receiving an SDP offer without the rtcp-idms attribute can
also decide that IDMS is applicable to that media session. In such a also decide that IDMS is applicable to that media session. In such a
case, the MSAS MAY insert the rtcp-idms attribute, including a non- case, the sender MAY insert the rtcp-idms attribute, including a non-
empty SyncGroupId, as part of its answer. empty SyncGroupId, as part of its answer.
A receiver receiving an rtcp-idms attribute as part of the SDP answer A receiver receiving an rtcp-idms attribute as part of the SDP answer
from an MSAS, SHALL start sending IDMS XR reports (following all the from a sender SHALL start sending RTCP XR IDMS reports (following all
normal RTCP rules for sending RTCP XR blocks) and SHALL be ready to the normal RTCP rules for sending RTCP XR IDMS Report Blocks) and
start receiving IDMS Settings. As usual, if a receiver does not SHALL be ready to start receiving IDMS Settings. As usual, if a
support the attribute (e.g. in case of an MSAS-inserted IDMS receiver does not support the attribute (e.g., in case of an MSAS-
attribute), it SHALL ignore the attribute. inserted IDMS attribute), it SHALL ignore the attribute.
Different updates are applicable to such an IDMS session. Updates Different updates are applicable to such an IDMS session. Updates
can be sent ommitting the rtcp-idms attribute, thereby ending the can be sent omitting the rtcp-idms attribute, thereby ending
(involvement in) the synchronization session. Updates can also be involvement in the synchronization session. Updates can also be sent
sent including the rtcp-idms attribute, but with a different including the rtcp-idms attribute, but with a different SyncGroupId.
SyncGroupId. This indicates a switch in synchronization group. This indicates a switch in the synchronization group.
Updates can also be sent including another rtcp-idms attribute,
indicating a membership of another synchronization group, effectively
merging the current group(s) with the new one.
12.2. Declarative cases 11.2. Declarative Cases
In certain situations, there is no offer/answer context, but only a In certain situations, there is no offer/answer context, but only a
declarative modus. In this case, the MSAS just inserts the rtcp-idms declarative modus. In this case, the MSAS just inserts the rtcp-idms
attribute and a valid SyncGroupId. Any receiver receiving the rtcp- attribute and a valid SyncGroupId. Any receiver receiving the rtcp-
idms attribute in such a declarative case SHALL start sending IDMS XR idms attribute in such a declarative case SHALL start sending RTCP XR
Report Blocks and SHALL be ready to start receiving RTCP IDMS IDMS Report Blocks and SHALL be ready to start receiving RTCP IDMS
Settings packets. Settings Packets.
13. Security Considerations 12. Security Considerations
The security considerations described in [RFC3611] apply to this The security considerations described in [RFC3611] apply to this
document as well. document as well.
The RTCP XR IDMS Report Block defined in this document is used to The RTCP XR IDMS Report Block defined in this document is used to
collect, summarize and distribute information on packet reception- collect, summarize, and distribute information on packet reception
and playout-times of streaming media. The information may be used to and playout times of streaming media. The information may be used to
orchestrate the media playout at multiple devices. orchestrate the media playout at multiple devices.
Errors in the information, either accidental or malicious, may lead Errors in the information, either accidental or malicious, may lead
to undesired behavior. For example, if one device erroneously or to undesired behavior. For example, if one device erroneously or
maliciously reports a two-hour delayed playout, then another device maliciously reports a two-hour delayed playout, then another device
in the same synchronization group could decide to delay its playout in the same synchronization group could decide to delay its playout
by two hours as well, in order to keep its playout synchronized. A by two hours as well, in order to keep its playout synchronized. A
user would likely interpret this two hour delay as a malfunctioning user would likely interpret this two-hour delay as a malfunctioning
service. service.
Therefore, the application logic of both SCs and MSASs should check Therefore, the application logic of both SCs and MSASs should check
for out-of-bound information. Differences in playout time exceeding for out-of-bound information. Differences in playout time exceeding
configured limits (e.g. more than ten seconds) could be an indication configured limits (e.g., more than ten seconds) could be an
of such out-of-bound information. indication of such out-of-bound information.
Apart from checking for out-of-bound information in the end-points, Apart from checking for out-of-bound information in the endpoints, an
an IDMS implementation can reduce its vulnerability to attacks by IDMS implementation can reduce its vulnerability to attacks by
including source authentication and message integrity measures, including source authentication and message integrity measures,
reducing the potential for man-in-the-middle attacks. reducing the potential for man-in-the-middle attacks. [RFC7201]
[I-D.draft-ietf-avtcore-rtp-security-options] provides an overview of provides an overview of the security options in RTP environments and
the security options in RTP environments, and includes a set of includes a set of recommendations for message integrity and source
recommendations for message integrity and source authentication which authentication that are applicable to IDMS. In addition to
are applicable to IDMS. In addition to preventing man-in-the-middle preventing man-in-the-middle attacks from inserting erroneous IDMS
attacks from inserting erroneous IDMS Reports, the message reports, the message confidentiality mechanisms outlined in [RFC7201]
confidentiality mechanisms outlined in also prevent third parties from determining that two or more end
[I-D.draft-ietf-avtcore-rtp-security-options] also prevent third hosts are receiving the same stream by looking at the Media Stream
parties from determining that two or more end hosts are receiving the Correlation Identifier.
same stream by looking at the Media Stream Correlation Identifier.
Apart from attacking an IDMS session directly by sending incorrect Apart from attacking an IDMS session directly by sending incorrect
IDMS Reports, and with it introducing delays for all devices in a IDMS reports, and with it introducing delays for all devices in a
synchronization group, another potential vulnerability comes from the synchronization group, another potential vulnerability comes from the
used clock synchronization method. Should an attacker succeed in clock synchronization method used. Should an attacker succeed in
adjusting an SC's wallclock, that SC will report incorrect IDMS adjusting an SC's wallclock, that SC will report incorrect IDMS
Reports. In order to prevent such clock synchronization attacks, it reports. In order to prevent such clock synchronization attacks, it
is recommended to use a secure time synchronization service. is recommended to use a secure time synchronization service.
14. IANA Considerations 13. IANA Considerations
This document defines a new RTCP packet type, the RTCP IDMS Packet This document defines a new RTCP packet type, the RTCP IDMS Packet
(IDMS Settings), within the existing Internet Assigned Numbers (IDMS Settings), within the existing Internet Assigned Numbers
Authority (IANA) registry of RTCP Control Packet Types. This Authority (IANA) registry of RTCP Control Packet Types. This
document also defines a new RTCP XR Block Type, the IDMS XR Report document also defines a new RTCP XR Block Type, the RTCP XR IDMS
Block, within the existing IANA registry of RTCP Extended Reports Report Block, within the existing IANA registry of RTCP Extended
(RTCP XR) Block Types. Reports (RTCP XR) Block Types.
Further, this document defines a new SDP attribute "rtcp-idms" within Further, this document defines a new SDP attribute "rtcp-idms" within
the existing IANA registry of SDP Parameters, part of the "att-field the existing IANA registry of SDP Parameters, which is part of the
(media level only)". Finally, this document defines a new IANA "att-field (media level only)". Finally, this document defines a new
registry subordinate to the IANA RTCP Extended Reports (RTCP XR) IANA registry subordinate to the IANA RTCP Extended Reports (RTCP XR)
Block Type Registry: the IDMS XR Block SPST Registry. Block Type Registry: the IDMS XR Block SPST Registry.
14.1. RTCP IDMS Packet Type 13.1. RTCP IDMS Packet Type
This document assigns the packet type value TBD in the IANA 'RTCP
Control Packet types (PT) Registry' to the RTCP IDMS Packet Type.
[Note to RFC Editor: please replace TBD with the IANA-provided RTCP This document assigns the packet type value 211 in the IANA 'RTCP
Packet Type value for this packet type, both in this section as well Control Packet types (PT)' registry to the RTCP IDMS Packet (IDMS
as in the figure and text in Section 8] Settings).
14.2. RTCP XR IDMS Report Block 13.2. RTCP XR IDMS Report Block
This document updates the assignment of value 12 from the RTCP XR This document updates the assignment of value 12 from the RTCP XR
Block Type for reporting IDMS information as per [TS183063] to the Block Type for reporting IDMS information as per [TS183063] to the
RTCP XR IDMS Report Block defined in this document. RTCP XR IDMS Report Block defined in this document.
[Note to RFC Editor: this block type value is currently assigned to The RTCP XR IDMS Report Block contains an extensible SPST value
[TS183063]. This document replaces [TS183063] as the normative field; therefore, a new registry for this field is required. This
specification of the RTCP XR IDMS Report Block. Upon publication of new registry is defined in Section 13.4.
this document as RFC, [TS183063] will be changed to reflect this.
The RTCP XR IDMS Report Block contains an extensible SPST value field
and therefore a new registry for this field is required. This new
registry is defined in Section 14.4.
14.3. RTCP-IDMS SDP Attribute 13.3. RTCP-IDMS SDP Attribute
The SDP attribute "rtcp-idms" defined by this document is registered The SDP attribute "rtcp-idms" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rtcp-idms Attribute name: rtcp-idms
Long form: RTCP IDMS Parameters Long form: RTCP IDMS Parameters
Type of name: att-field Type of name: att-field
Type of attribute: media level Type of attribute: media level
Subject to charset: no Subject to charset: no
Purpose: see Section 11 of this document Purpose: see Section 10 of this document
Reference: this document Reference: this document
Values: see this document Values: see this document
14.4. IDMS XR Block SPST Registry 13.4. IDMS XR Block SPST Registry
This document defines a new IANA registry subordinate to the IANA This document defines a new IANA registry subordinate to the IANA
RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR
Block SPST Registry. Block SPST Registry.
Initial values for the IDMS XR Block SPST Registry are given below; Initial values for the IDMS XR Block SPST Registry are given below;
future assignments are to be made through the Specification Required future assignments are to be made through the Specification Required
policy [RFC5226]. The registry is limited to 16 entries (numbered policy [RFC5226]. The registry is limited to 16 entries (numbered
0-15), with 0 being Reserved. Values 5-15 are available for 0-15), with 0 being Reserved. Values 5-15 are available for
assignment. assignment.
In accordance with [RFC5226], a Designated Expert will review any In accordance with [RFC5226], a Designated Expert will review any
applications made to IANA for the registry. Primary criteria for the applications made to IANA for the registry. Primary criteria for the
Designated Expert to use when reviewing new applications are clarity Designated Expert to use when reviewing new applications are clarity
of the specification and, due to the relative small value range of of the specification and, due to the relatively small value range of
SPST values available, potential overlap in functionality with SPST values available, potential overlap in functionality with
existing SPST registrations. existing SPST registrations.
Value Name Reference Value Name Reference
----- ---- --------- ----- ---- ---------
1 Synchronization Client section 7 1 Synchronization Client This document, Section 7
2 MSAS [TS183063] 2 MSAS [TS183063]
3 SC Prime Input [TS183063] 3 SC Prime Input [TS183063]
4 SC Prime Output [TS183063] 4 SC Prime Output [TS183063]
14.5. Contact Information for Registrations 13.5. Contact Information for Registrations
The contact information for the registrations is: The contact information for the registrations is:
Ray van Brandenburg (ray.vanbrandenburg@tno.nl) Ray van Brandenburg (ray.vanbrandenburg@tno.nl)
Brassersplein 2 Brassersplein 2
2612CT, Delft, The Netherlands 2612CT, Delft, The Netherlands
15. Contributors 14. Contributors
The following people have participated as co-authors or provided
substantial contributions to this document: Omar Niamut, Fabian
Walraven, Ishan Vaishnavi and Rufael Mekuria. In addition, the
authors would like to thank Aidan Williams, Colin Perkins, Magnus
Westerlund, Roni Even, Peter Musgrave, Ali Begen, Qin Wu and Rob
Koenen for their review comments and contributions to the text.
16. References The following people have provided substantial contributions to this
document: Omar Niamut, Fabian Walraven, Ishan Vaishnavi, and Rufael
Mekuria. In addition, the authors would like to thank Aidan
Williams, Colin Perkins, Magnus Westerlund, Roni Even, Peter
Musgrave, Ali Begen, Qin Wu, and Rob Koenen for their review comments
and contributions to the text.
16.1. Normative References 15. References
[I-D.draft-ietf-avtcore-clksrc] 15.1. Normative References
Williams, A., Gross, K., van Brandenburg, R., and H.
Stokking, "RTP Clock Source Signalling, draft-ietf-
avtcore-clksrc-05", May 2013.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels, RFC 2119", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications, RFC3550", July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video conferences with Minimal Control, RFC3551", July Video Conferences with Minimal Control", STD 65, RFC 3551,
2003. July 2003.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
"RTP Control Protocol Extended Reports (RTCP XR), Protocol Extended Reports (RTCP XR)", RFC 3611, November
RFC3611", November 2003. 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol, RFC4566", July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", May 2008. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications, RFC5234", January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
"Network Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specifications, RFC5905", February 2010. Specification", RFC 5905, June 2010.
16.2. Informative References [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H.
Stokking, "RTP Clock Source Signalling", RFC 7273, June
2014.
15.2. Informative References
[Boronat2009] [Boronat2009]
Boronat, F., Lloret, J., and M. Garcia, "Multimedia group Boronat, F., Lloret, J., and M. Garcia, "Multimedia group
and inter-stream synchronization techniques: a comparative and inter-stream synchronization techniques: a comparative
study, Elsevier Information Systems 34 (2009), pp. study", Elsevier Information Systems 34, Pages 108-131,
108-131", 2009. March 2009,
<http://www.sciencedirect.com/science/article/pii/
[I-D.draft-ietf-avtcore-rtp-security-options] S0306437908000525>.
Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", July 2013.
[I-D.draft-ietf-leap-seconds]
Gross, K. and R. Brandenburg, van, "RTP and Leap Seconds,
draft-ietf-avtcore-leap-second-02", October 2012.
[IEEE-1588] [IEEE1588-2008]
, "1588-2008 - IEEE Standard for a Precision Clock IEEE, "1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", 2008. Control Systems", July 2008,
<http://standards.ieee.org/findstds/
standard/1588-2008.html>.
[Ishibashi2006] [Ishibashi2006]
Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective
Assessment of Fairness among users in multipoint assessment of fairness among users in multipoint
communications, Proceedings of the 2006 ACM SIGCHI communications", Proceedings of the 2006 ACM SIGCHI
internation conference on Advances in computer international conference on Advances in computer
entertainment technology, 2006", . entertainment technology, Article No. 69, June 2006,
<http://dl.acm.org/citation.cfm?id=1178905>.
[RFC3711] Baughner, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC
Normann, "The Secure Real-time Transport Protocol (SRTP)", 7164, March 2014.
March 2004.
[RFC5868] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Control Protocol (RTCP), RFC5968", September 2010. Sessions", RFC 7201, April 2014.
[TS183063] [TS183063] ETSI, "Telecommunications and Internet converged Services
, "IMS-based IPTV stage 3 specification, TS 183 063 and Protocols for Advanced Networking (TISPAN); IMS-based
v3.5.2", March 2011. IPTV stage 3 specification", TS 183 063 v3.5.2, March
2011.
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
TNO TNO
Brassersplein 2 Brassersplein 2
Delft 2612CT Delft 2612CT
the Netherlands The Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl EMail: ray.vanbrandenburg@tno.nl
Hans Stokking Hans Stokking
TNO TNO
Brassersplein 2 Brassersplein 2
Delft 2612CT Delft 2612CT
the Netherlands The Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: hans.stokking@tno.nl EMail: hans.stokking@tno.nl
M. Oskar van Deventer M. Oskar van Deventer
TNO TNO
Brassersplein 2 Brassersplein 2
Delft 2612CT Delft 2612CT
the Netherlands The Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: oskar.vandeventer@tno.nl EMail: oskar.vandeventer@tno.nl
Fernando Boronat Fernando Boronat
Universitat Politecnica de Valencia
Universitat Politecnica de Valencia (UPV) Universitat Politecnica de Valencia (UPV)
Valencia 46730 Valencia 46730
Spain Spain
Phone: +34 962 849 341 Phone: +34 962 849 341
Email: fboronat@dcom.upv.es EMail: fboronat@dcom.upv.es
Mario Montagud Mario Montagud
Universitat Politecnica de Valencia
Universitat Politecnica de Valencia (UPV) Universitat Politecnica de Valencia (UPV)
Valencia 46730 Valencia 46730
Spain Spain
Phone: +34 962 849 341 Phone: +34 962 849 341
Email: mamontor@posgrado.upv.es EMail: mamontor@posgrado.upv.es
Kevin Gross Kevin Gross
AVA Networks AVA Networks
Phone: +1-303-447-0517 Phone: +1-303-447-0517
Email: Kevin.Gross@AVAnw.com EMail: Kevin.Gross@AVAnw.com
 End of changes. 187 change blocks. 
536 lines changed or deleted 512 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/