draft-ietf-avtcore-idms-05.txt   draft-ietf-avtcore-idms-06.txt 
AVTCore R. van Brandenburg AVTCore R. van Brandenburg
Internet-Draft H. Stokking Internet-Draft H. Stokking
Intended status: Standards Track O. van Deventer Intended status: Standards Track O. van Deventer
Expires: December 15, 2012 TNO Expires: January 17, 2013 TNO
F. Boronat F. Boronat
M. Montagud M. Montagud
Universitat Politecnica de Universitat Politecnica de
Valencia Valencia
K. Gross K. Gross
AVA Networks AVA Networks
June 13, 2012 July 16, 2012
RTCP for inter-destination media synchronization Inter-destination Media Synchronization using the RTP Control Protocol
draft-ietf-avtcore-idms-05 (RTCP)
draft-ietf-avtcore-idms-06
Abstract Abstract
This document gives information on an RTCP Packet Type and RTCP XR This document gives information on an RTP Control Protocol (RTCP)
Block Type including associated SDP parameters for Inter-Destination Packet Type and RTCP Extended Report (XR) Block Type including
Media Synchronization (IDMS). The RTCP XR Block Type, registered associated Session Description Protocol (SDP) parameters for Inter-
with IANA based on an ETSI specification, is used to collect media Destination Media Synchronization (IDMS). This document mandates the
play-out information from participants in a group playing-out use of the RTCP XR Block Type 12, which is used to collect media
(watching, listening, etc.) a specific RTP media stream. The RTCP playout information from participants in a group playing out
packet type specified by this document is used to distribute a common (watching, listening, etc.) a specific RTP media stream. This RTCP
target play-out point to which all the distributed receivers, sharing XR Block Type is specified and registered with IANA by ETSI. The
a media experience, can synchronize. RTCP packet type specified by this document is used to distribute a
common target playout point to which all the distributed receivers,
sharing a media experience, can synchronize.
Typical use cases in which IDMS is usefull are social TV, shared Typical use cases in which IDMS is usefull 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2012.
This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Inter-Destination Media Synchronization . . . . . . . . . 4 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4 2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4
1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 5 2.2. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 5
1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . 5 2.3. This document and ETSI TISPAN . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 5 4. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 5
4. Inter-Destination Media Synchronization use cases . . . . . . 7 5. Inter-Destination Media Synchronization use cases . . . . . . 7
5. Architecture for Inter-Destination Media Synchronization . . . 8 6. Architecture for Inter-Destination Media Synchronization . . . 8
5.1. Media Synchronization Application Server (MSAS) . . . . . 8 6.1. Media Synchronization Application Server (MSAS) . . . . . 9
5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 9 6.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 9
5.3. Communication between MSAS and SCs . . . . . . . . . . . . 9 6.3. Communication between MSAS and SCs . . . . . . . . . . . . 9
6. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9 7. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9
7. RTCP Packet Type for IDMS (IDMS report) . . . . . . . . . . . 11 8. RTCP Packet Type for IDMS (IDMS Settings) . . . . . . . . . . 12
8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13 9. Timing and NTP Considerations . . . . . . . . . . . . . . . . 14
9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 14 10. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 15
10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 15 11. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 16
11. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 15 12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 17
12. On the use of presentation timestamps . . . . . . . . . . . . 17 13. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . . 17
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13.2. Declarative cases . . . . . . . . . . . . . . . . . . . . 19
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. On the use of presentation timestamps . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . . 19 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . . 20 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.1. Normative References . . . . . . . . . . . . . . . . . . . 21
18.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
1.1. Inter-Destination Media Synchronization Inter-Destination Media Synchronization (IDMS) refers to the playout
Inter-Destination Media Synchronization (IDMS) refers to the play-out
of media streams at two or more geographically distributed locations of media streams at two or more geographically distributed locations
in a time synchronized manner. It can be applied to both unicast and in a time synchronized manner. It can be applied to both unicast and
multicast media streams and can be applied to any type and/or multicast media streams and can be applied to any type and/or
combination of streaming media, such as audio, video and text combination of streaming media, such as audio, video and text
(subtitles).[Ishibashi2006] and [Boronat2009] provide an overview of (subtitles).[Ishibashi2006] and [Boronat2009] provide an overview of
technologies and algorithms for IDMS. technologies and algorithms for IDMS.
IDMS requires the exchange of information on media receipt and play- IDMS requires the exchange of information on media receipt and
out times among participants in an IDMS session. It may also require playout times among participants in an IDMS session. It may also
signaling for the initiation and maintenance of IDMS sessions and require signaling for the initiation and maintenance of IDMS sessions
groups of receivers. 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 used
synchronization algorithm, which is out-of-scope of this document. synchronization algorithm, which is out-of-scope of this document.
1.2. Applicability of RTCP to IDMS 2. Rationale
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, and for very useful for reconstructing the original media timing, and for
reordering and detecting packet loss at the client side. reordering and detecting packet loss at the client side.
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
multicast networks, 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 Reports (XR) [RFC3611]. Both RTP and RTCP are intended to
be tailored through modifications in order to include profile- be tailored through modifications in order to include profile-
specific information required by particular applications, and the specific information required by particular applications, and the
guidelines on doing so are specified in [RFC5868]. guidelines on doing so are specified in [RFC5868].
IDMS involves the collection, summarizing and distribution of RTP IDMS involves the collection, summarizing and distribution of RTP
packet arrival and play-out times. As information on RTP packet packet arrival and playout times. As information on RTP packet
arrival times and play-out times can be considered reception quality arrival times and playout times can be considered reception quality
feedback information, RTCP is well suited for carrying out IDMS, feedback information, RTCP is well suited for carrying out IDMS,
which may facilitate the implementation and deployment in typical which may facilitate the implementation and deployment in typical
multimedia applications. multimedia applications.
1.3. Applicability of SDP to IDMS 2.2. Applicability of SDP to IDMS
RTCP XR [RFC3611] defines the Extended Report (XR) packet type for RTCP XR [RFC3611] defines the Extended Report (XR) packet type for
the RTP Control Protocol (RTCP), and defines how the use of XR the RTP Control Protocol (RTCP), and defines how the use of XR
packets can be signaled by an application using the Session packets can be signaled by an application using the Session
Description Protocol (SDP) [RFC4566]. Description Protocol (SDP) [RFC4566].
SDP signaling is used to set up and maintain a synchronization group SDP signaling is used to set up and maintain a synchronization group
between Synchronization Clients (SCs). This document describes two between Synchronization Clients (SCs). This document describes two
SDP parameters for doing this, one for the RTCP XR block type and one SDP parameters for doing this, one for the RTCP XR block type and one
for the new RTCP packet type. for the new RTCP packet type.
1.4. This document and ETSI TISPAN 2.3. This document and ETSI TISPAN
ETSI TISPAN [TS183063] has specified architecture and protocol for ETSI TISPAN [TS183063] has specified architecture and protocol for
IDMS using RTCP XR exchange and SDP signaling. For more information IDMS using RTCP XR exchange and SDP signaling. For more information
on how this document relates to [TS183063], see Section 11. on how this document relates to [TS183063], see Section 12.
2. Terminology This document mandates the use of an ETSI specified RTCP XR block for
the purpose of collecting RTP packet arrival and playout times. For
completeness, that XR block is contained in this document in section
7.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. 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,Sync-group ID) | | Invite(URL,Sync-group ID) |
|------------------------------------------------->| |------------------------------------------------->|
| | Media Session Set-up | | | Media Session Set-up |
| |<========================>| | |<========================>|
| | | | | |
| Call set-up | | Call set-up |
skipping to change at page 6, line 27 skipping to change at page 6, line 27
| | | | | |
| RTP Packet | RTP Packet | | RTP Packet | RTP Packet |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| RR + IDMS XR | | | RR + IDMS XR | |
|---------------------->| RR + IDMS XR | |---------------------->| RR + IDMS XR |
| |<-------------------------| | |<-------------------------|
| RTCP IDMS packet | RTCP IDMS packet | | RTCP IDMS packet | RTCP IDMS packet |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| | | | | |
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 that
a football game of Bob's favorite team is on. She sends him an a football game of Bob's favorite team is on. 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 a
session to the media server. A VoIP connection to Alice's TV is also session to the media server. A VoIP connection to Alice's TV is also
set up, so that Alice and Bob can talk while watching the game set up, so that Alice and Bob can talk while watching the game
together. 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 Receiver Reports (RR) to
the media server. However, in order to make sure Alice and Bob see the media server. However, in order to make sure Alice and Bob see
the events in the football game at (approximately) the same time, the events in the football game at (approximately) the same time,
their clients also periodically send an IDMS XR block to the sync their clients also periodically send an IDMS XR block to the sync
server function of the media server. Included in the XR blocks are server function of the media server. Included in the XR blocks are
timestamps on when both Alice and Bob received (or played out) a timestamps on when both Alice and Bob received (and, optionally, when
particular RTP packet. they played 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 IDMS XR blocks (e.g. by selecting whichever client from the received IDMS XR blocks (e.g. by selecting whichever
client received the packet the latest as the reference client). It client received the packet the latest as the reference client). It
then sends an RTCP IDMS packet containing the play-out information of then sends an RTCP IDMS packet containing the playout information of
this reference client to the sync clients of both Alice and Bob. 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 reference
client therefore includes a delay similar to the one experienced by client therefore includes a delay similar to the one experienced by
Bob. Upon reception of this information, Alice's RTP client can Bob. Upon reception of this information, Alice's RTP client can
choose what to do with this information. In this case it decreases choose what to do with this information. In this case it decreases
its play-out rate temporarily until the play-out time matches with its playout rate temporarily until the playout time matches with the
the reference client play-out (and thus matches Bob's play-out). reference client playout (and thus matches Bob's playout). Another
Another option for Alice's TV would be to simply pause playback until option for Alice's TV would be to simply pause playback until it
it catches up. The exact implementation of the synchronization catches up. The exact implementation of the synchronization
algorithm is up to the client. algorithm is up to the client.
Upon reception of the reference client RTCP IDMS packet, Bob's client Upon reception of the reference client RTCP IDMS packet, Bob's client
does not have to do anything since it is already synchronized to the does 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.
4. Inter-Destination Media Synchronization use cases For this functionality to work correctly, it is nessecary that the
wall clocks of the receivers are synchronized with each other. Alice
and Bob both report when they receive, and optionally when they play
out, certain RTP packets. In order to correlate their reports to
each other, it is necessary that their wallclocks are synchronized.
5. Inter-Destination Media Synchronization use cases
There are a large number of use cases in which IDMS might be useful. There are 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 the real-time
communication between those users. An example of Social TV is when communication between those users. An example of Social TV is when
two or more users are watching the same television broadcast at two or more users are watching the same television broadcast at
different devices and locations, while communicating with each other different devices and locations, while communicating with each other
using text, audio and/or video. A skew in their media play-out using text, audio and/or video. A skew in their media playout
processes can have adverse effects on their experience. A well-known processes can have adverse effects on their experience. A well-known
use case here is one friend experiencing a goal in a football match use case here is one friend experiencing a goal in a football match
well before or after other friend(s). well before or after other 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
skipping to change at page 8, line 13 skipping to change at page 8, line 21
A third usage scenario is that of the networked loudspeakers, in A third usage scenario is that of the networked loudspeakers, in
which two or more speakers are connected to the network individually. which two or more speakers are connected to the network individually.
Such situations can for example be found in large conference rooms, Such 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 susceptible to differences in audio
delay, this use case needs even more accuracy than the video wall use delay, this use case needs even more accuracy than the video wall use
case. Depending on the exact application, the need for accuracy can case. Depending on the exact application, the need for accuracy can
then be in the range of microseconds. then be in the range of microseconds.
5. Architecture for Inter-Destination Media Synchronization 6. 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. The Synchronization architecture [Boronat2009], is sketched below. The Synchronization
Client (SC) and Media Synchronization Application Server (MSAS) Client (SC) and Media Synchronization Application Server (MSAS)
entities are shown as additional functionality for the RTP receiver entities are shown as additional functionality for the RTP receiver
and sender respectively. and sender respectively.
It should be noted that a master/slave type of architecture is also It should be noted that a master/slave type of architecture is also
supported by having one of the SC devices also act as an MSAS. In supported by having one of the SC devices also act as an MSAS. In
this case the MSAS functionality is thus embedded in an RTP receiver this case the MSAS functionality is thus embedded in an RTP receiver
skipping to change at page 8, line 42 skipping to change at page 9, line 5
| | Synchronization | | | | Media | | | | Synchronization | | | | Media | |
| | Client | | | | Synchronization | | | | Client | | | | Synchronization | |
| | (SC) | | | | Application | | | | (SC) | | | | Application | |
| | | | | | Server | | | | | | | | Server | |
| | | | RR+XR | | (MSAS) | | | | | | RR+XR | | (MSAS) | |
| | | | -----> | | | | | | | | -----> | | | |
| +-----------------+ | | +-----------------+ | | +-----------------+ | | +-----------------+ |
| | | | | | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
5.1. Media Synchronization Application Server (MSAS) 6.1. Media Synchronization Application Server (MSAS)
An MSAS collects RTP packet arrival times and play-out times from one An MSAS collects RTP packet arrival times and playout times from one
or more SC(s) in a synchronization group. The MSAS summarizes and or more SC(s) in a synchronization group. The MSAS summarizes and
distributes this information to the SCs in the synchronization group distributes this information to the SCs in the synchronization group
as synchronization settings, e.g. by determining the SC with the most as synchronization settings, e.g. by determining the SC with the most
lagged play-out and using its reported RTP packet arrival time and lagged playout and using its reported RTP packet arrival time and
play-out time as a summary. playout time as a summary.
5.2. Synchronization Client (SC) 6.2. Synchronization Client (SC)
An SC reports on RTP packet arrival times and play-out times of a An SC reports on RTP packet arrival times and playout times of a
media stream. It can receive summaries of such information, and use media stream. It can receive summaries of such information, and use
that to adjust its play-out buffer. that to adjust its playout buffer.
5.3. Communication between MSAS and SCs 6.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 play-out MSAS and SCs. For the SC->MSAS message containing the playout
information of a particular client, an RTCP XR Block Type is used information of a particular client, an RTCP XR Block Type is used
(see Section 6). For the MSAS->SC message containing the (see Section 6). For the MSAS->SC message containing the
synchronization settings instructions, a new RTCP Packet Type is synchronization settings instructions, a new RTCP Packet Type is
defined (see Section 7). defined (see Section 8).
6. RTCP XR Block Type for IDMS 7. RTCP XR Block Type for IDMS
This section describes the RTCP XR Block Type for reporting IDMS For reporting IDMS information, SCs SHALL use the ETSI specified RTCP
information on an RTP media stream. Its definition is based on XR Block Type 12. For completeness, that RTCP XR Block Type is
[RFC3611]. The RTCP XR is used to provide feedback information on repeated here fully.
receipt times and presentation times of RTP packets to e.g. a Sender
[RFC3611], a Feedback Target [RFC5760] or a Third Party Monitor The definition of the XR block type is based on [RFC3611]. The RTCP
[RFC3611]. XR is used to provide feedback information on receipt times and
presentation times of RTP packets to e.g. a Sender [RFC3611], a
Feedback Target [RFC5760] or a Third Party Monitor [RFC3611].
In most cases, a single RTP receiver will only be part of single IDMS
session, i.e. it will report on receipt and presentation times 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 multiple
synchronization groups for the same RTP stream, e.g. watching a
single television program simultaneously with different groups. In
even further cases, a receiver may wish to synchronize different RTP
streams at the same time, either as part of the same synchronization
group or as part of multiple synchronization groups. These are all
valid scenario's for IDMS, and will require multiple reports by an
SC.
SCs SHOULD report on a recently received RTP packets. This document
does not define new rules on when to sent RTCP reports, but uses the
existing rules specified in [RFC3550] for sending RTCP reports. When
the RTCP reporting timer allows an SC to send an IDMS report, the SC
SHOULD report on the latest RTP packet received or played out
(depending on whether the SC reports on presentation timestamps or
receipt timestamps). For more details on 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Resrv | PT=XR=207 | length | |V=2|P| Resrv | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| BT=12 | SPST |Resrv|P| block length=7 | | BT=12 | SPST |Resrv|P| block length=7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 26 skipping to change at page 11, line 12
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: Report. It can have the following values:
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 This setting is reserved in order to preserve compatibility SPST=2 This setting is reserved in order to preserve compatibility
with ETSI TISPAN [TS183063]. See Section 11 for more information. with ETSI TISPAN [TS183063]. See Section 12 for more information.
SPST=3-15 Reserved For future use. SPST=3-15 Reserved For future use.
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 and MUST be ignored by the receiver. field MUST be set to zero and MUST be ignored by the 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 zero, then the Packet Presented NTP
timestamp SHALL be ignored. timestamp SHALL be ignored.
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 SHALL be set to 7, as this RTCP Block in 32 bit words minus one and SHALL be set to 7, as this RTCP Block
Type has a fixed length. Type 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]. The media payload is media payload, according to [RFC3551]. This is the payload type of
associated with an RTP timestamp clock rate. This clock rate the RTP packet reported upon. The media payload is associated with
provides the time base for the RTP timestamp counter. an RTP timestamp clock rate. This clock rate provides the time base
for the RTP timestamp counter.This clock rate is nessecary for the
MSAS to 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. use and SHALL be set to 0.
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) or an MSAS (SPST=2), then the Media Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then the Media
Stream Correlation Identifier maps on the Synchronization Group Stream Correlation Identifier field contains the Synchronization
Identifier (SyncGroupId) to which the report applies. Group Identifier (SyncGroupId) to which the report applies.
SSRC: 32 bits. The SSRC of the media source SHALL be set to the SSRC: 32 bits. The SSRC of the media source SHALL be set to the
value of the SSRC identifier carried in the RTP header [RFC3550] of value of the SSRC identifier carried in the RTP header [RFC3550] of
the RTP packet to which the XR relates. the RTP packet to which the XR 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 wall clock time at the moment of arrival of the first octet of the
RTP packet to which the XR relates. It is formatted based on the NTP RTP packet to which the XR relates. It is formatted based on the NTP
timestamp format as specified in [RFC5905]. See Section 8 for more timestamp format as specified in [RFC5905]. See Section 9 for more
information on how this field is used. 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 relates. Several consecutive RTP packets will packet to which the XR relates. Several consecutive RTP packets will
have equal timestamps if they are (logically) generated at once, 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 having 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 having
that same RTP timestamp. This would lead to an error in the 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. To solve considering both reports to be on the same RTP packet. When
this, an SC SHOULD report on RTP packets in which a certain RTP reporting on an RTP packet which is one of several consecutive RTP
timestamp shows up for the first time. packets having equal timestamps, an SC SHOULD report on the RTP
packet it received with the lowest sequence number. Note that with
'lowest sequence number' here is meant the first in the sequence of
RTP packets just received, not from an earlier time before the last
wrap-around of RTP timestamps (unless this wrap-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 frame contained in the wall clock time at the moment the rendered frame contained in the
first byte of the associated RTP packet is presented to the user. It first byte of the associated RTP packet is presented to the user. It
is based on the time format used by NTP and consists of the least is based on the time format used by NTP and consists of the least
significant 16 bits of the NTP seconds part and the most significant significant 16 bits of the NTP seconds part and the most significant
16 bits of the NTP fractional second part. If this field is empty, 16 bits of the NTP fractional second part. If this field is empty,
then it SHALL be set to 0 and the Packet Presented NTP timestamp flag then it SHALL be set to 0 and the Packet Presented NTP timestamp flag
(P) SHALL be set to 0. Presented here means the moment the data is (P) SHALL be set to 0. Presented here means the moment the data is
played out to the user of the system, i.e. sound played out through played out to the user of the system, i.e. sound played out through
speakers, video images being displayed on some display, etc. The speakers, video images being displayed on some display, etc. The
accuracy resulting from the synchronization algorithm will only be as accuracy resulting from the synchronization algorithm will only be as
good as the accuracy with which the receivers can determine the delay good as the accuracy with which the receivers can determine the delay
between receiving packets and presenting them to the end-user. between receiving packets and presenting them to the end-user.
7. RTCP Packet Type for IDMS (IDMS report) 8. RTCP Packet Type for IDMS (IDMS Settings)
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].
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=TBD | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 36 skipping to change at page 13, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 packet sender identifies the sender of the
specific RTCP packet. specific RTCP packet.
The RTCP IDMS packet consists of 7 32-bit words, with the following The RTCP IDMS packet consists of 7 32-bit words, with the following
fields: fields:
SSRC: 32 bits. The SSRC of the media source SHALL be set to the SSRC: 32 bits. The SSRC of the media source SHALL be set to the
value of the SSRC identifier carried in the RTP header [RFC3550] of value of the SSRC identifier of the media source carried in the RTP
the RTP packet to which the RTCP IDMS packet relates. header [RFC3550] of the RTP packet to which the RTCP IDMS 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 maps on 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 wall clock 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 play-out timing in order to achieve synchronization, e.g. adjust its playout timing in order to achieve synchronization, e.g.
to set the required play-out 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 8 on the NTP timestamp format as specified in [RFC5905]. See Section 9
for more information on how this field is used. for more information on how this field is used. Because RTP
timestamps do wrap around, the sender of this packet SHOULD use
recent values, i.e. choose NTP timestamps that reflect current time
and not too far in the future or in the past.
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 relates. This SHOULD relate to the first packet to which the XR 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 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 wall clock time at the reference client at the moment it presented
the rendered frame contained in the first octet of the associated RTP the rendered frame contained in the first octet of the associated RTP
packet to the user. The timestamp is formatted based on the NTP packet to the user. The timestamp is formatted based on the NTP
timestamp format as specified in [RFC5905]. If this field is empty, timestamp format as specified in [RFC5905]. If this field is empty,
then it SHALL be set to 0. This field MAY be left empty if none or then it SHALL be set to 0. This field MAY be left empty if none or
only one of the receivers reported on presentation timestamps. only one of the receivers reported on presentation timestamps.
Presented here means the moment the data is played out to the user of Presented here means the moment the data is played out to the user of
the system. 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 play-out 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 32bit Presented Timestamp will not suffice. For
this reason, this RTCP Packet Type for IDMS includes a 64bit this reason, this RTCP Packet Type for IDMS includes a 64bit
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 IDMS XR Block
Type with which the SCs report on their play-out to have a 32bit Type with which the SCs report on their playout to have a 32bit
Presented Timestamp field. Presented Timestamp field.
8. Timing and NTP Considerations 9. Timing and NTP Considerations
To achieve IDMS, the different receivers involved need synchronized To achieve IDMS, the different receivers involved need synchronized
clocks as a common timeline for synchronization. Depending on the (wall) clocks as a common timeline for synchronization. This
synchronization accuracy required, different clock synchronization synchronized clock is used for reporting the Packet Received NTP
methods can be used. For social TV, synchronization accuracy should Timestamps and the Packet Presented NTP Timestamp, and for
be achieved on the order of hundreds of milliseconds. In that case, interpretation of these fields in received IDMS reports. Depending
correct use of NTP on receivers will in most situations achieve the on the synchronization accuracy required, different clock
required accuracy. As a guideline, to deal with clock drift of synchronization methods can be used. For social TV, synchronization
receivers, receivers should synchronize their clocks at the beginning accuracy should be achieved on the order of hundreds of milliseconds.
of a synchronized session. In case of high required accuracy, the In that case, correct use of NTP on receivers will in most situations
synchronized clocks of different receivers should not drift beyond achieve the required accuracy. As a guideline, to deal with clock
the accuracy required for the synchronization mechanism. In drift of receivers, receivers should synchronize their clocks at the
practice, this can mean that receivers need to synchronize their beginning of a synchronized session. In case of high required
accuracy, the synchronized clocks of different receivers should not
drift beyond the accuracy required for the synchronization mechanism.
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 in some use cases, a high accuracy will be needed. In good audio in some use cases, a high accuracy will be needed. In
this case, use of the global NTP system may not be sufficient. For 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 other improved accuracy, a local NTP server could be set up, or some other
more accurate clock synchronization mechanism can be used, such as more accurate clock synchronization mechanism can be used, such as
GPS time or the Precision Time Protocol [IEEE-1588]. GPS time or the Precision Time Protocol [IEEE-1588].
[I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters [I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters
for signaling the clock synchronization source or sources available for signaling the clock synchronization source or sources available
to and used by the individual receivers. Using these paramenters, an to and used by the individual receivers. SCs MAY use this draft to
SC can indicate which synchronization source is being used at the indicate their clock synchronization source or sourced in use and
moment, the last time the SC synchronized with this source and the available. Using these paramenters, an SC can indicate which
synchronization frequency. An SC can also indicate any other synchronization source is being used at the moment, the last time the
synchronization sources available to it. This allows multiple SCs in SC synchronized with this source and the synchronization frequency.
an IDMS session to use the same or a similar clock source for their An SC can also indicate any other synchronization sources available
session. to it. This allows multiple SCs in an IDMS session to use the same
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 which 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-gross-leap-second] presents some guidelines on how RTP [I-D.draft-gross-leap-second] presents some guidelines on how RTP
senders and receivers should deal with leap seconds. When relying on senders and receivers should deal with leap seconds. When relying on
NTP for clock synchronization, IDMS is particularly sensitive to leap NTP for clock synchronization, IDMS is particularly sensitive to leap
second induced timing discrepancies. It is therefore recommended to second induced timing discrepancies. It is RECOMMENDED to take the
take the guideline specified in [I-D.draft-gross-leap-second] into guideline specified in [I-D.draft-gross-leap-second] into account
account when implementing IDMS. when implementing IDMS.
9. SDP Parameter for RTCP XR IDMS Block Type 10. SDP Parameter for RTCP XR IDMS Block Type
The SDP parameter sync-group is used to signal the use of the RTCP XR The SDP parameter sync-group is used to signal the use of the RTCP XR
block for IDMS. It is also used to carry an identifier of the block for IDMS, as specified by ETSI, included here for completeness.
synchronization group to which clients belong or will belong. This It is also used to carry an identifier of the synchronization group
SDP parameter extends rtcp-xr-attrib as follows, using Augmented to which clients belong or will belong. This SDP parameter extends
Backus-Naur Form [RFC5234]. rtcp-xr-attrib as follows, using Augmented Backus-Naur Form
[RFC5234].
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
; Original definition from [RFC3611], section 5.1 ; Original definition from [RFC3611], section 5.1
xr-format =/ grp-sync ; Extending xr-format for Inter-Destination xr-format =/ grp-sync ; Extending xr-format for Inter-Destination
Media Synchronization Media Synchronization
grp-sync = "grp-sync" [",sync-group=" SyncGroupId] grp-sync = "grp-sync" [",sync-group=" SyncGroupId]
SyncGroupId = 1*DIGIT ; Numerical value from 0 through 4294967294
SyncGroupId = 1*10DIGIT ; Numerical value from 0 through 4294967294
DIGIT = %x30-39 DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer represented in decimal. SyncGroupId is a 32-bit unsigned integer represented in decimal.
SyncGroupId identifies a group of SCs for IDMS. It maps on the Media SyncGroupId identifies a group of SCs for IDMS. It maps on the Media
Stream Correlation Identifier as described in Section 6 and Stream Correlation Identifier as described in Section 7 and
Section 7. The value SyncGroupId=0 represents an empty SyncGroupId. Section 8. The value SyncGroupId=0 represents an empty SyncGroupId.
The value 4294967294 (2^32-1) is reserved for future use. The value 4294967294 (2^32-1) is reserved for future use.
The following is an example of the SDP attribute for IDMS The following is an example of the SDP attribute for IDMS
a=rtcp-xr:grp-sync,sync-group=42 a=rtcp-xr:grp-sync,sync-group=42
10. SDP Parameter for RTCP IDMS Packet Type 11. SDP Parameter for RTCP IDMS Packet Type
The SDP parameter rtcp-idms is used to signal the use of the RTCP The SDP parameter rtcp-idms is used to signal the use of the RTCP
IDMS Packet Type for IDMS. It is also used to carry an identifier of IDMS Packet Type for IDMS. It is also used to carry an identifier of
the synchronization group to which clients belong or will belong. the synchronization group to which clients belong or will belong.
The SDP parameter is used as a media-level attribute during session The SDP parameter is used as a media-level attribute during session
setup. This SDP parameter is defined as follows, using Augmented setup. This means that in case of multiple related streams, IDMS is
Backus-Naur Form [RFC5234]. performed on one of them. The other streams will be synchronized to
this first stream using existing inter-stream synchronization (i.e.
lip-sync) solutions, i.e. using Sender Reports based on a common
clock source. Basic guidelines for choosing the media stream for
IDMS is to choose audio above video, as humans are more sensitive to
degradation in audio quality then in video quality. When using
mutli-description or multi-view codecs, the IDMS control should be
performed on the base layer.
This SDP parameter is defined as follows, using Augmented Backus-Naur
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*DIGIT ; Numerical value from 0 through 4294967294 SyncGroupId = 1*10DIGIT ; Numerical 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 4294967294 SyncGroupId=0 represents an empty SyncGroupId. The value 4294967294
(2^32-1) is reserved for future use. (2^32-1) is reserved for future use.
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
11. Compatibility with ETSI TISPAN 12. Compatibility with ETSI TISPAN
The SDP usage for IDMS follows the rules defined in RFC3611 in
section 5 on SDP signalling, with the exception of what is stated
here. The IDMS usage of RTCP is a (loosely coupled) collaborative
parameter, in the sense that receivers sent their status information
and in response (asynchronously) the MSAS sents synchronization
instructions. Both the sync-group parameter (defined by ETSI TISPAN)
and the rtcp-idms parameter (defined in this document) thus indicate
the ability to sent and the ability to receive indicated RTCP
messages. This section defines how these SDP parameters should be
used, and thus also explains how compatibility with the TISPAN
solution is arranged for.
As described in Section 1.4, ETSI TISPAN has described its mechanism As described in Section 2.3, ETSI TISPAN has described its mechanism
for IDMS in [TS183063]. One of the main differences between the for IDMS in [TS183063]. One of the main differences between the
TISPAN document and this document is the fact that the TISPAN TISPAN document and this document is the fact that the TISPAN
solution uses an RTCP XR block for both the SC->MSAS message and the solution uses an RTCP XR block for both the SC->MSAS message and the
MSAS->SC message (by selecting SPST-type 2), while this document MSAS->SC message (by selecting SPST-type 2), while this document
specifies a new RTCP Packet Type for the MSAS->SC message. The specifies a new RTCP Packet Type for the MSAS->SC message. The
message from MSAS to SC is not in any way a report on how a receiver message from MSAS to SC is not in any way a report on how a receiver
sees a session, and therefore a separate RTCP packet type is more sees a session, and therefore a separate RTCP packet type is more
appropriate than the XR block solution chosen in ETSI TISPAN. To appropriate than the XR block solution chosen in ETSI TISPAN. To
achieve compatibility, MSAS implementations SHOULD implement both the achieve compatibility, MSAS implementations SHOULD implement both the
TISPAN RTCP block and the new RTCP IDMS report for MSAS->SC messages. TISPAN RTCP block and the new RTCP IDMS Settings packet for MSAS->SC
SCs MAY implement support for both types of messages. For the messages. SCs MAY implement support for both types of messages. For
MSAS->SC signaling, it is recommended to use the RTCP IDMS report the MSAS->SC signaling, it is recommended to use the RTCP IDMS
defined in this document. The TISPAN RTCP XR block with SPST=2 MAY Settings packet defined in this document. The TISPAN RTCP XR block
be used for purposes of compatibility with the TISPAN solution, but with SPST=2 MAY be used for purposes of compatibility with the TISPAN
MUST NOT be used if all nodes involved support the new RTCP IDMS solution, but MUST NOT be used if all nodes involved support the new
report. RTCP IDMS Settings packet.
13. SDP rules
13.1. Offer/Answer rules
The SDP usage for IDMS follows the rules defined in RFC3611 in
section 5 on SDP signalling, with the exception of what is stated
here. The IDMS usage of RTCP is a (loosely coupled) collaborative
parameter, in the sense that receivers sent their status information
and in response (asynchronously) the MSAS sents synchronization
instructions. Both the sync-group parameter (defined by ETSI TISPAN)
and the rtcp-idms parameter (defined in this document) thus indicate
the ability to sent and the ability to receive indicated RTCP
messages. This section defines how these SDP parameters should be
used.
Most of the times, the IDMS SDP parameters will be used in the offer/ Most of the times, the IDMS SDP parameters will be used in the offer/
answer context. Receivers will indicate in their SDP which RTCP answer context. Receivers will indicate in their SDP which RTCP
messages they support. messages they support.
For a unicast situation, three situations are possible in offer/ For a unicast situation, three situations are possible in offer/
answer context: answer context:
- If a receiver indicates at least the rtcp-idms SDP parameter, the - If a receiver indicates at least the rtcp-idms SDP parameter, the
MSAS SHOULD reply with only the rtcp-idms parameter and use only MSAS SHOULD reply with only the rtcp-idms parameter and use only
the RTCP IDMS report for MSAS->SC communication the RTCP IDMS Settings packet for MSAS->SC communication
- If a receiver indicates only the sync-group SDP parameter, and the - If a receiver indicates only the sync-group SDP parameter, and the
MSAS also supports this, it SHOULD reply with only the sync-group MSAS also supports this, it SHOULD reply with only the sync-group
parameter and use only the RTCP XR block with SPST=2 for MSAS->SC parameter and use only the RTCP XR block with SPST=2 for MSAS->SC
communication communication
- If a receiver indicates only the sync-group SDP parameter, and the - If a receiver indicates only the sync-group SDP parameter, and the
MSAS does not support this, the media sender MUST ignore the MSAS does not support this, the media sender MUST ignore the
parameter. This receiver will not become part of the parameter. This receiver will not become part of the
synchronization session synchronization session
Note that it is possible that for a certain synchronization group, Note that it is possible that for a certain synchronization group,
that the MSAS sends RTCP IDMS packets to one receiver and RTCP XR that the MSAS sends RTCP IDMS packets to one receiver and RTCP XR
IDMS blocks with SPST=2 to another receiver. IDMS blocks with SPST=2 to another receiver.
In a multicast situation using the offer/answer context, it will work In a multicast situation using the offer/answer context, it will work
a bit differently. The negotiation is the same as in the unicast a bit differently. The negotiation is the same as in the unicast
situation. But, the MSAS will multicast all RTCP messages to all situation. But, the MSAS will multicast all RTCP messages to all
receivers. So: receivers. So:
- If all receivers support the RTCP IDMS report, the MSAS SHOULD - If all receivers support the RTCP IDMS Settings packet, the MSAS
only sent the RTCP IDMS report for MSAS->SC messages SHOULD only sent the RTCP IDMS Settings packet for MSAS->SC
messages
- If not all receivers support the RTCP IDMS report, but all - If not all receivers support the RTCP IDMS Settings packet, but
receivers support the TISPAN solution, the MSAS SHOULD only sent all receivers support the TISPAN solution, the MSAS SHOULD only
the RTCP XR block with SPST=2 for MSAS->SC messages. sent the RTCP XR block with SPST=2 for MSAS->SC messages.
- If some receivers support only the RTCP IDMS report and other - If some receivers support only the RTCP IDMS Settings packet and
receivers support only the TISPAN solution, the MSAS SHOULD sent other receivers support only the TISPAN solution, the MSAS SHOULD
both the RTCP IDMS report and the RTCP XR block with SPST=2 for sent both the RTCP IDMS Settings packet and the RTCP XR block with
MSAS->SC messages. This is less efficient, since the information SPST=2 for MSAS->SC messages. This is less efficient, since the
sent is duplicated, but this is the only way to include all information sent is duplicated, but this is the only way to
receivers in a synchronization session in this scenario. include all receivers in a synchronization session in this
scenario.
In certain multicast situations, there is no offer/answer context. In certain multicast situations, there is no offer/answer context,
In that case, the MSAS SHOULD use only the RTCP IDMS packet type and but only a declarative modus. In that case, the MSAS SHOULD use only
thus use only the SDP parameter rtcp-idms. Receivers that do not the RTCP IDMS packet type and thus use only the SDP parameter rtcp-
support the RTCP IDMS packet will just ignore both the SDP parameter idms. Receivers that do not support the RTCP IDMS packet will just
and the RTCP IDMS packets, and will thus not join the synchronization ignore both the SDP parameter and the RTCP IDMS packets, and will
session. For compatability with the TISPAN solution, the MSAS MAY thus not join the synchronization session. For compatability with
choose to use the RTCP XR IDMS block type instead, using the SDP the TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS
parameter sync-group. The media sender SHOULD NOT use both block type instead, using the SDP parameter sync-group. The media
parameters at the same time in this case of no offer/answer context. sender SHOULD NOT use both parameters at the same time in this case
of no offer/answer context.
12. On the use of presentation timestamps 13.2. Declarative cases
In certain multicast situations, there is no offer/answer context,
but only a declarative modus. In that case, the MSAS SHOULD use only
the RTCP IDMS packet type and thus use only the SDP parameter rtcp-
idms. Receivers that do not support the RTCP IDMS packet will just
ignore both the SDP parameter and the RTCP IDMS packets, and will
thus not join the synchronization session. For compatability with
the TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS
block type instead, using the SDP parameter sync-group. The media
sender SHOULD NOT use both parameters at the same time in this case
of no offer/answer context.
14. 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 play-out times. A receiver SHALL report on arrival times and on playout times. A receiver SHALL report on
arrival times and a receiver MAY report on play-out times. RTP arrival times and a receiver MAY report on playout times. RTP packet
packet arrival times are relatively easy to report on. Normally, the arrival times are relatively easy to report on. Normally, the
processing and play-out of the same media stream by different 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 and decoding times, high accuracy can be same buffer settings and decoding times, high accuracy can be
achieved. However, if all receivers in a synchronization session achieved. However, if all receivers in a synchronization session
have the ability to report on, and thus synchronize on, actual play- have the ability to report on, and thus synchronize on, actual
out times, or packet presentation times, this may be more accurate. playout times, or packet presentation times, this may be more
It is up to applications and implementations of this RTCP extension accurate. It is up to applications and implementations of this RTCP
whether to implement and use this. extension whether to implement and use this.
13. Security Considerations 15. 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 specified RTCP XR Block Type in this document is used to collect, The specified RTCP XR Block Type in this document is used to collect,
summarize and distribute information on packet reception- and play- summarize and distribute information on packet reception- and
out-times of streaming media. The information may be used to playout-times of streaming media. The information may be used to
orchestrate the media play-out 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 to undesired behavior. For example, if one device erroneously
reports a two-hour delayed play-out, then another device in the same reports a two-hour delayed playout, then another device in the same
synchronization group could decide to delay its play-out by two hours synchronization group could decide to delay its playout by two hours
as well, in order to keep its play-out synchronized. A user would as well, in order to keep its playout synchronized. A user would
likely interpret this two hour delay as a malfunctioning service. likely interpret this two hour delay as a malfunctioning service.
Therefore, the application logic of both Synchronization Clients and Therefore, the application logic of both Synchronization Clients and
Media Synchronization Application Servers should check for Media Synchronization Application Servers should check for
inconsistent information. Differences in play-out time exceeding inconsistent 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 indication
of such inconsistent information. of such inconsistent information.
No new mechanisms are introduced in this document to ensure No new mechanisms are introduced in this document to ensure
confidentiality. Encryption procedures, such as those being confidentiality. Encryption procedures, such as those being
suggested for a Secure RTP (SRTP) at the time that this document was suggested for a Secure RTP (SRTP) at the time that this document was
written, can be used when confidentiality is a concern to end hosts. written, can be used when confidentiality is a concern to end hosts.
14. IANA Considerations 16. IANA Considerations
This document defines a new RTCP packet type called IDMS report in This document defines a new RTCP packet type called IDMS Settings
the IANA registry of RTP parameters, based on the specification in packet in the IANA registry of RTP parameters, part of RTCP Control
Section 10. Packet types (PT), based on the specification in Section 11.
Further, this document defines a new SDP parameter "rtcp-idms" within Further, this document defines a new SDP parameter "rtcp-idms" within
the existing IANA registry of SDP Parameters. the existing IANA registry of SDP Parameters, part of the "att-field
(media level only)".
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 report block for IDMS Long form: RTCP report block for IDMS
skipping to change at page 19, line 23 skipping to change at page 21, line 14
Type of attribute: media level Type of attribute: media level
Subject to charset: no Subject to charset: no
Purpose: see sections 7 and 10 of this document Purpose: see sections 7 and 10 of this document
Reference: this document Reference: this document
Values: see this document Values: see this document
15. Contributors 17. Contributors
The following people have participated as co-authors or provided The following people have participated as co-authors or provided
substantial contributions to this document: Omar Niamut, Fabian substantial contributions to this document: Omar Niamut, Fabian
Walraven, Ishan Vaishnavi, Rufael Mekuria and Rob Koenen. Walraven, Ishan Vaishnavi, Rufael Mekuria and Rob Koenen.
16. References 18. References
16.1. Normative References 18.1. Normative References
[I-D.draft-williams-avtcore-clksrc] [I-D.draft-williams-avtcore-clksrc]
Williams, A., van Brandenburg, R., Stokking, H., and K. Williams, A., van Brandenburg, R., Stokking, H., and K.
Gross, "RTP Clock Source Signalling, Gross, "RTP Clock Source Signalling,
draft-williams-avtcore-clksrc-00", March 2012. draft-williams-avtcore-clksrc-00", March 2012.
[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, RFC 2119", March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 20, line 27 skipping to change at page 22, line 17
Sessions with Unicast Feedback, RFC5760", February 2010. Sessions with Unicast Feedback, RFC5760", February 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specifications, RFC5905", February 2010. Specifications, RFC5905", February 2010.
[TS183063] [TS183063]
"IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1", "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1",
June 2010. June 2010.
16.2. Informative References 18.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. 108- study, Elsevier Information Systems 34 (2009), pp. 108-
131". 131".
[I-D.draft-gross-leap-second] [I-D.draft-gross-leap-second]
Gross, K. and R. Brandenburg, van, "RTP and Leap Seconds, Gross, K. and R. Brandenburg, van, "RTP and Leap Seconds,
draft-gross-leap-seconds-01". draft-gross-leap-seconds-01".
 End of changes. 80 change blocks. 
206 lines changed or deleted 297 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/