draft-ietf-avtcore-idms-02.txt   draft-ietf-avtcore-idms-03.txt 
AVTCore R. van Brandenburg AVTCore R. van Brandenburg
Internet Draft H. Stokking Internet-Draft H. Stokking
Intended status: Standards Track M. van Deventer Intended status: Standards Track O. van Deventer
Expires: May 3, 2012 TNO Netherlands Expires: September 10, 2012 TNO
F. Boronat F. Boronat
M. Montagud M. Montagud
Universidad Politecnica de Valencia Universitat Politecnica de Valencia
Kevin Gross K. Gross
AVA Networks AVA Networks
October 31, 2011 March 9, 2012
RTCP for inter-destination media synchronization RTCP for inter-destination media synchronization
draft-ietf-avtcore-idms-02.txt draft-ietf-avtcore-idms-03
Abstract
This document gives information on an RTCP Packet Type and RTCP XR
Block Type including associated SDP parameters for Inter-Destination
Media Synchronization (IDMS). The RTCP XR Block Type, registered
with IANA based on an ETSI specification, is used to collect media
playout information from participants in a group playing-out
(watching, listening, etc.) a specific RTP media stream. The 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
service control (i.e. applications where two or more geographically
separated users are watching a media stream together), distance
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), its areas, and its working groups. Note that other Task Force (IETF). Note that other groups may also distribute
groups may also distribute working documents as Internet-Drafts. working documents as Internet-Drafts. The list of current Internet-
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 September 6, 2012.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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.
Abstract
This document gives information on an RTCP Packet Type and RTCP XR
Block Type including associated SDP parameters for inter-destination
media synchronization (IDMS). The RTCP XR Block Type, registered with
IANA based on an ETSI specification, is used to collect media play-
out information from participants in a group playing-out (watching,
listening, etc.) a specific RTP media stream. The RTCP packet type
specified by this document is used to distribute a summary of the
collected information so that the participants can synchronize play-
out.
Typical applications for IDMS are social TV, shared service control
(i.e. applications where two or more geographically separated users
are watching a media stream together), distance learning, networked
video walls, networked speakers, etc.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Inter-destination Media Synchronization . . . . . . . . . . 3 1.1. Inter-destination Media Synchronization . . . . . . . . . 4
1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . . 3 1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4
1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 4 1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 5
1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . . 4 1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 4 3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 5
4. Inter-destination media synchronization use cases . . . . . . . 6 4. Inter-destination media synchronization use cases . . . . . . 7
5. Architecture for inter-destination media synchronization . . . 7 5. Architecture for inter-destination media synchronization . . . 8
5.1. Media Synchronization Application Server (MSAS) . . . . . . 7 5.1. Media Synchronization Application Server (MSAS) . . . . . 8
5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . . 8 5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 9
5.3. Communication between MSAS and SCs . . . . . . . . . . . . 8 5.3. Communication between MSAS and SCs . . . . . . . . . . . . 9
6. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . . 9 6. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9
7. RTCP Packet Type for IDMS (IDMS report) . . . . . . . . . . . . 11 7. RTCP Packet Type for IDMS (IDMS report) . . . . . . . . . . . 11
8. Timing and NTP Considerations . . . . . . . . . . . . . . . . . 13 8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13
8.1. Leap Seconds . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Leap Seconds . . . . . . . . . . . . . . . . . . . . . . . 14
9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . . 15 9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 14
10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 15 10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 15
11. SDP parameter for clock source . . . . . . . . . . . . . . . . 16 11. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 16
12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 18 12. On the use of presentation timestamps . . . . . . . . . . . . 16
13. On the use of presentation timestamps . . . . . . . . . . . . 19 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 16. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18
17. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 17.1. Normative References . . . . . . . . . . . . . . . . . . . 19
18.1. Normative References . . . . . . . . . . . . . . . . . . . 22 17.2. Informative References . . . . . . . . . . . . . . . . . . 19
18.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
1.1. Inter-destination Media Synchronization 1.1. Inter-Destination Media Synchronization
Inter-destination media synchronization (IDMS) refers to the play-out Inter-Destination Media Synchronization (IDMS) refers to the playout
of media streams at two or more geographically distributed locations of media streams at two or more geographically distributed locations
in a temporally synchronized manner. It can be applied to both in a time synchronized manner. It can be applied to both unicast and
unicast and multicast media streams and can be applied to any type multicast media streams and can be applied to any type and/or
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
technologies and algorithms for IDMS. of technologies and algorithms for IDMS.
IDMS requires the exchange of information on media receipt and IDMS requires the exchange of information on media receipt and
playout times. It may also require signaling for the initiation and playout times among participants in an IDMS session. It may also
maintenance of IDMS sessions and groups. require signaling for 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 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 1.2. Applicability of RTCP to IDMS
Currently, most multimedia applications make use of RTP and RTCP Currently, most multimedia applications make use of RTP and RTCP
[RFC3550]. RTP (Real-time Transport Protocol) provides end-to-end [RFC3550]. RTP provides end-to-end network transport functions
network transport functions suitable for applications requiring real- suitable for applications requiring real-time data transport, such as
time data transport, such as audio, video or data, over multicast or audio, video or data, over multicast or unicast network services.
unicast network services. The timestamps and sequence number The timestamps, sequence numbers, and payload (content) type
mechanisms provided by RTP are very useful to reconstruct the identification mechanisms provided by RTP packets are very useful for
original media timing, reorder and detect some packet loss at the reconstructing the original media timing, and for reordering and
receiver side. 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 multicast networks, and to provide minimal control and identification
functionality. functionality.
RTP receivers and senders provide reception quality feedback by RTP receivers and senders provide reception quality feedback by
sending out RTCP Receiver Report (RR) and Sender Report (SR) packets sending out RTCP Receiver Report (RR) and Sender Report (SR) packets
[RFC3550] respectively, which may be augmented by eXtended Reports [RFC3550], respectively, which may be augmented by eXtended Reports
(XR) [RFC3611]. Thus, the feedback reporting features provided by (XR) [RFC3611]. Thus, the feedback reporting features provided by
RTCP make QoS monitoring possible and can be used for troubleshooting RTCP make QoS monitoring possible and can be used for troubleshooting
and fault tolerance management in multicast distribution services and fault tolerance management in multicast distribution services
such as IPTV. such as IPTV.
These protocols are intended to be tailored through modification These protocols are intended to be tailored through modifications and
and/or additions in order to include profile-specific information additions in order to include profile-specific information required
required by particular applications, and the guidelines on doing so by particular applications, and the guidelines on doing so are
are specified in [RFC5968]. 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 becomes a promising candidate for carrying feedback information, RTCP is well suited for carrying out IDMS,
out IDMS, which may facilitate implementation in typical multimedia which may facilitate the implementation and deployment in typical
applications. multimedia applications.
1.3. Applicability of SDP to IDMS 1.3. 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.
This document also allows for a receiver to indicate a used clock 1.4. This document and ETSI TISPAN
source for synchronizing the receiver clock used in the IDMS session.
This is also done using an SDP parameter, which is described in this
document.
1.4. This document and ETSI TISPAN
ETSI TISPAN [TS 183 063] has specified architecture and protocol for ETSI TISPAN [TS183063] has specified architecture and protocol for
IDMS using RTCP XR exchange and SDP signaling. IDMS using RTCP XR exchange and SDP signaling. For more information
on how this document relates to [TS183063], see Section 11.
2. Terminology 2. 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 3. Overview of IDMS operation
This section provides a brief example of how the IDMS RTCP This section provides a brief example of how the RTCP functionality
functionality is used. The section is tutorial in nature and does not is used for achieving IDMS. The section is tutorial in nature and
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 (SC) 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 |
|<================================================>| |<================================================>|
| | | | | |
| 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 |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| | | | | |
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 invite a football game of Bob's favorite team is on. She sends him an
to watch the program together. Embedded in the invitation is the link invite to watch the program together. Embedded in the invitation is
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 program. set up, so that Alice and Bob can talk while 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 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 the same time, their clients also the events in the football game at (approximately) the same time,
periodically send an IDMS XR block to the sync server function of the their clients also periodically send an IDMS XR block to the sync
media server. Included in the XR blocks are timestamps on when both server function of the media server. Included in the XR blocks are
Alice and Bob have received (or played out) a particular RTP packet. timestamps on when both Alice and Bob received (or 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 both Alice and Bob. this reference client to the sync clients of both Alice and Bob.
In this case Bob has the slowest connection and the reference client In this case Bob has the slowest connection and the reference client
therefore includes a delay similar to the one experienced by Bob. therefore includes a delay similar to the one experienced by Bob.
Upon reception of this information, Alice's RTP client can choose Upon reception of this information, Alice's RTP client can choose
what to do with this information. In this case it decreases its play- what to do with this information. In this case it decreases its
out rate temporarily until it matches with the reference client play- playout rate temporarily until it matches with the reference client
out (and thus matches Bob's play-out). Another option for Alice's TV playout (and thus matches Bob's playout). Another option for Alice's
would be to simply pause playback until it catches up. The exact TV would be to simply pause playback until it catches up. The exact
implementation of the synchronization algorithm is up to the client. implementation of the synchronization 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 4. Inter-Destination Media Synchronization use cases
There are a large number of use cases imaginable in which IDMS might There are a large number of use cases imaginable in which IDMS might
be useful. This section will highlight some of them. It should be be useful. This section will highlight some of them. It should be
noted that this section is in no way meant to be exhaustive noted that 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 and real-time communication between different devices and locations and real-time communication between
those users. An example of Social TV, is when two or more users are those users. An example of Social TV, is when two or more users are
watching the same television broadcast at different devices and watching the same television broadcast at different devices and
locations, while communicating with each other using text, audio locations, while communicating with each other using text, audio
and/or video. A skew in the media play-out of the two or more users and/or video. A skew in their media playout processes can have
can have adverse effects on their experience. A well-known use case adverse effects on their experience. A well-known use case here is
here is one friend experiencing a goal in a football match well one friend experiencing a goal in a football match well before or
before or after other friend(s). Thus IDMS is required to provide after other friend(s).
play-out synchronization.
Another potential use case for IDMS is the video wall. A video wall Another potential use case for IDMS is a networked video wall. A
consists of multiple computer monitors, video projectors, or video wall consists of multiple computer monitors, video projectors,
television sets tiled together contiguously or overlapped in order to or television sets tiled together contiguously or overlapped in order
form one large screen. Each of the screens reproduces a portion of to form one large screen. Each of the screens reproduces a portion
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 of potentially faster. If the refresh is not synchronized, the effect
multiple screens acting as one is broken. of multiple screens acting as one is broken.
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 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. 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
instead of an RTP sender. instead of an RTP sender.
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
| | 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) | |
| | | | -----> | | | | | | | | -----> | | | |
| +-----------------+ | | +-----------------+ | | +-----------------+ | | +-----------------+ |
| | | | | | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
5.1. Media Synchronization Application Server (MSAS) 5.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) 5.2. Synchronization Client (SC)
An SC reports RTP packet arrival times and play-out times of a media An SC reports on RTP packet arrival times and playout times of a
stream. It can receive summaries of such information, and use that to media stream. It can receive summaries of such information, and use
adjust its play-out buffer. that to adjust its playout buffer.
5.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 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 in Section 7. defined (see Section 7).
6. RTCP XR Block Type for IDMS 6. RTCP XR Block Type for IDMS
This section describes the RTCP XR Block Type for reporting IDMS This section describes the RTCP XR Block Type for reporting IDMS
information on an RTP media stream. Its definition is based on information on an RTP media stream. Its definition is based on
[RFC3611]. The RTCP XR is used to provide feedback information on [RFC3611]. The RTCP XR is used to provide feedback information on
receipt times and presentation times of RTP packets to e.g. a Sender receipt times and presentation times of RTP packets to e.g. a Sender
[RFC3611], a Feedback Target [RFC5576] or a Third Party Monitor [RFC3611], a Feedback Target [RFC5576] or a Third Party Monitor
[RFC3611]. [RFC3611].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 first 64 bits form the header of the RTCP XR, as defined in The first 64 bits form the header of the RTCP XR, as defined in
[RFC3611]. The SSRC of packet sender identifies the sender of the [RFC3611]. The SSRC of packet sender identifies the sender of the
specific RTCP packet. specific RTCP packet.
The IDMS report block consists of 7 32-bit words, with the following The IDMS report block consists of 8 32-bit words, with the following
fields: 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
SHALL be set to 12. SHALL be 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: 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 [TS 183 063]. See section 12. for more information. with ETSI TISPAN [TS183063]. See Section 11 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 not be inspected. 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 and shall be set to 7, as this RTCP Block Type has a in 32 bit words minus one and SHALL be set to 7, as this RTCP Block
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]. The media payload is
associated with an RTP timestamp clock rate. This clock rate provides associated with an RTP timestamp clock rate. This clock rate
the time base for the RTP timestamp counter. provides the time base for the RTP timestamp counter.
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 used Media Stream Correlation Identifier: 32 bits. This identifier is
to correlate synchronized media streams. The value 0 (all bits are used to correlate synchronized media streams. The value 0 (all bits
set "0") indicates that this field is empty. The value 2^32-1 (all are set "0") indicates that this field is empty. The value 2^32-1
bits are set "1") is reserved for future use. If the RTCP Packet (all bits are set "1") is reserved for future use. If the RTCP
Sender is an SC (SPST=1), then the Media Stream Correlation Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then the Media
Identifier maps on the SyncGroupId to which the SC belongs. Stream Correlation Identifier maps on the Synchronization Group
Identifier (SyncGroupId) to which the report applies.
SSRC: 32 bits. The SSRC of the media source shall be set to the value SSRC: 32 bits. The SSRC of the media source SHALL be set to the
of the SSRC identifier carried in the RTP header [RFC3550] of the RTP value of the SSRC identifier carried in the RTP header [RFC3550] of
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 8 for more
information on how this field is set. 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 time stamp 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 this, considering both reports to be on the same RTP packet. To solve
an SC SHOULD report on RTP packets in which a certain RTP timestamp this, an SC SHOULD report on RTP packets in which a certain RTP
shows up for the first time. timestamp shows up for the first time.
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 data contained in the first octet wall clock time at the moment the data contained in the first octet
of the associated RTP packet is presented to the user. It is based on of the associated RTP packet is presented to the user. It is based
the time format used by NTP and consists of the least significant 16 on the time format used by NTP and consists of the least significant
bits of the NTP seconds part and the most significant 16 bits of the 16 bits of the NTP seconds part and the most significant 16 bits of
NTP fractional second part. If this field is empty, then it SHALL be the NTP fractional second part. If this field is empty, then it
set to 0 and the Packet Presented NTP timestamp flag (P) SHALL be set SHALL be set to 0 and the Packet Presented NTP timestamp flag (P)
to 0. Presented here means the moment the data is presented to the SHALL be set to 0. Presented here means the moment the data is
user of the system, i.e. sound played out through speakers, video played out to the user of the system, i.e. sound played out through
images being displayed on some display, etc. The accuracy resulting speakers, video images being displayed on some display, etc. The
from the synchronization algorithm will only be as good as the accuracy resulting from the synchronization algorithm will only be as
accuracy with which the receivers can determine the delay between good as the accuracy with which the receivers can determine the delay
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) 7. RTCP Packet Type for IDMS (IDMS report)
This section specifies the RTCP Packet Type for indicating This section specifies the RTCP Packet Type for indicating
synchronization settings instructions to a receiver of the RTP media synchronization settings instructions to the receivers of the RTP
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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 value SSRC: 32 bits. The SSRC of the media source SHALL be set to the
of the SSRC identifier carried in the RTP header [RFC3550] of the RTP value of the SSRC identifier carried in the RTP header [RFC3550] of
packet to which the RTCP IDMS packet relates. the RTP packet to which the RTCP IDMS packet relates.
Media Stream Correlation Identifier: 32 bits. This identifier is used Media Stream Correlation Identifier: 32 bits. This identifier is
to correlate synchronized media streams. The value 0 (all bits are used to correlate synchronized media streams. The value 0 (all bits
set "0") indicates that this field is empty. The value 2^32-1 (all are set "0") indicates that this field is empty. The value 2^32-1
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 maps on 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 be first octet of the RTP packet to which this packet relates. It can
used by the synchronization algorithm on the receiving SC to set the be used by the synchronization algorithm on the receiving SC to
required playout delay. The timestamp is formatted based on the NTP adjust its playout timing in order to achieve synchronization, e.g.
timestamp format as specified in [RFC5905]. See section 8 for more to set the required playout delay. The timestamp is formatted based
information on how this field is set. on the NTP timestamp format as specified in [RFC5905]. See Section 8
for 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 time stamp 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 RTP packet to which the XR relates. This SHOULD relate to the first
packet containing this particular RTP timestamp, in case multiple RTP arriving RTP packet containing this particular RTP timestamp, in case
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 data contained in the first octet of the associated RTP packet to the data contained in the first octet of the associated RTP packet to
the user. The timestamp is formatted based on the NTP timestamp the user. The timestamp is formatted based on the NTP timestamp
format as specified in [RFC5905]. If this field is empty, then it 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 only one SHALL be set to 0. This field MAY be left empty if none or only one
of the receivers reported on presentation timestamps. Presented here of the receivers reported on presentated timestamps. Presented here
means the moment the data is presented to the user of the system. means the moment the data is 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 a MSAS might need to have over the exact moment of playout is control an MSAS might need to have over the exact moment of playout
so precise that a 32bit Presentation Timestamp might 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
Presentation Timestamp field. Since an MSAS will in practice always Presented Timestamp field. Since an MSAS will in practice always add
add some extra delay to the delay reported by the most lagged some extra delay to the delay reported by the most lagged receiver
receiver (to account for packet jitter), it suffices for the IDMS XR (to account for packet jitter), it suffices for the IDMS XR Block
Block Type with which the SCs report on their playout to have a 32bit Type with which the SCs report on their playout to have a 32bit
Presentation Timestamp field. Presented Timestamp field.
8. 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
clocks as a common timeline for synchronization. Depending on the clocks as a common timeline for synchronization. Depending on the
synchronization accuracy required, different clock synchronization synchronization accuracy required, different clock synchronization
methods can be used. For social TV, synchronization accuracy should methods can be used. For social TV, synchronization accuracy should
be achieved in order of hundreds of milliseconds. In that case, be achieved on the order of hundreds of milliseconds. In that case,
correct use of NTP on receivers will in most situations achieve the correct use of NTP on receivers will in most situations achieve the
required accuracy. As a guideline, to deal with clock drift of required accuracy. As a guideline, to deal with clock drift of
receivers, receivers should synchronize their clocks at the beginning receivers, receivers should synchronize their clocks at the beginning
of a synchronized session. In case of high required accuracy, the of a synchronized session. In case of high required accuracy, the
synchronized clocks of different receivers should not drift beyond synchronized clocks of different receivers should not drift beyond
the accuracy required for the synchronization mechanism. In practice the accuracy required for the synchronization mechanism. In
this can mean that receivers need to synchronize their clocks practice, this can mean that receivers need to synchronize their
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, a high accuracy will be needed. In this case, NTP usage good audio in some use cases, a high accuracy will be needed. In
may not be sufficient. Either a local NTP server could be setup, or this case, use of the global NTP system may not be sufficient. For
some other more accurate clock synchronization mechanism could be improved accuracy, a local NTP server could be set up, or some other
used, such as using GPS time or the Precision Time Protocol [IEEE- more accurate clock synchronization mechanism can be used, such as
1588]. GPS time or the Precision Time Protocol [IEEE-1588].
In this document, a new SDP parameter is introduced to signal the [I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters
clock synchronization source or sources used or able to be used (see for signaling the clock synchronization source or sources available
section 10). An SC can indicate which synchronization source is being to and used by the individual receivers. Using these paramenters, an
used at the moment and the last time the SC synchronized with this SC can indicate which synchronization source is being used at the
source. An SC can also indicate any other synchronization sources moment, the last time the SC synchronized with this source and the
available to it. This allows multiple SCs in an IDMS session to use synchronization frequency. An SC can also indicate any other
the same or a similar clock synchronization source for their session. synchronization sources available 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. How applications deal synchronization method for the system clock, because this may be a
with this is up to the implementation. The application might control system-wide setting which the application cannot change. How
the system clock, or it might use a separate application clock or applications deal with this is up to the implementation. The
even a separate IDMS session clock. It might also report on the application might control the system clock, or it might use a
system clock and the synchronization method used, without being able separate application clock or even a separate IDMS session clock. It
to change it. might also report on the system clock and the synchronization method
used, without being able to change it.
8.1. Leap Seconds
IDMS implementation is simplified by using a clock reference with a
timescale which does not include leap seconds. IEEE 1588, GPS and
other TAI (Inernational Atomic Time) references do not include leap
seconds. NTP time, operating system clocks and other UTC (Coordinated
Universal Time) references include leap seconds (though the ITU is
studying a proposal which could eventually eliminate leap seconds
from UTC).
Leap seconds are potentially scheduled at the end of the last day of
December and June each year. NTP inserts a leap second at the
beginning of the last second of the day. This results in the clock
freezing for one second immediately prior to the last second of the
affected day. Most system clocks insert the leap second at the end of
the last second. This results in repetition of the last second of the
day. Generating or using timestamps during the entire last second of
a day on which a leap second has been scheduled should therefore be
avoided. Note that the period to be avoided has a real-time duration
of two seconds.
It is also important that all participants correctly implement leap
seconds and have a working communications channel to receive
notification of leap second scheduling. Without prior knowledge of
leap second schedule, NTP servers and clients may be offset by
exactly one second with respect to their UTC reference. This
potential discrepancy begins when a leap second occurs and ends when
all participants receive a time update from a server or peer (which,
depending on the operating system and/or implementation, could be
anywhere from a few minutes to a week). Such a long-lived discrepancy
can be particularly disruptive to RTP and IDMS operation.
Apart from the long-lived discrepancy due to dependence on both
timing (e.g. NTP) updates and leap seconds scheduling updates, there
is also the potential for a short-lived timing discontinuity having
an effect on RTP and IDMS playout (even though leap seconds are quite
rare).
If a timescale with leap seconds is used for IDMS:
- SCs must take care not to generate any IDMS XR reports in the
immediate vicinity of the leap second. An MSAS must ignore any such
reports that may be inadvertently generated.
- RTP Senders using a leap-second-bearing reference must not generate
sender reports (SR) containing an originating NTP timestamp in the
vicinity of a leap second. Receivers should ignore timestamps in any
such reports inadvertently generated.
- Receivers working to a leap-second-bearing reference must be
careful to take leap seconds into account if a leap second occurs
between the time a RTP packet is originated and when it is to be
presented.
9. SDP Parameter for RTCP XR IDMS Block Type [I-D.draft-williams-avtcore-clksrc] also presents some general
guidelines on dealing with leap seconds within an RTP context. When
relying on NTP for clock synchronization, IDMS is particularly
sensitive to leap second induced timing discrepancies.
9. 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 inter-destination media synchronization. It is also used to block for IDMS. It is also used to carry an identifier of the
carry an identifier for the synchronization group to which clients synchronization group to which clients belong or will belong. This
belong or will belong. This SDP parameter extends rtcp-xr-attrib as SDP parameter extends rtcp-xr-attrib as follows, using Augmented
follows, using Augmented Backus-Naur Form [RFC5234]. 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 till 4294967295 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295
DIGIT = %x30-39 DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer in network byte order and SyncGroupId is a 32-bit unsigned integer represented in decimal.
represented in decimal. SyncGroupId identifies a group of SCs for SyncGroupId identifies a group of SCs for IDMS. It maps on the Media
IDMS. It maps on the Media Stream Correlation Identifier as described Stream Correlation Identifier as described in sections 6 and 7. The
in sections 6 and 7. The value SyncGroupId=0 represents an empty value SyncGroupId=0 represents an empty SyncGroupId. The value
SyncGroupId. The value 4294967295 (2^32-1) is reserved for future 4294967295 (2^32-1) is reserved for future use.
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 10. 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 for IDMS Packet Type for IDMS. It is also used to carry an identifier
the synchronization group to which clients belong or will belong. The for the synchronization group to which clients belong or will belong.
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 SDP parameter is defined as follows, using Augmented
Backus-Naur Form [RFC5234]. 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 till 4294967295 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295
DIGIT = %x30-39 DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer in network byte order and SyncGroupId is a 32-bit unsigned integer and represented in decimal.
represented in decimal. SyncGroupId identifies a group of SCs for SyncGroupId identifies a group of SCs for IDMS. The value
IDMS. The value SyncGroupId=0 represents an empty SyncGroupId. The SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295
value 4294967295 (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. SDP parameter for clock source 11. Compatibility with ETSI TISPAN
The SDP parameter clocksource is used to signal the source for clock
synchronization. This SDP parameter is specified as follows, using
Augmented Backus-Naur Form [RFC5234].
clocksource = "a=" "clocksource" ":" source SP [last-synced] CRLF
source = local / ntp / gps / gal / ptp
local = "local"
ntp = "ntp" ["=" ntp-server]
ntp-server = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
gps = "gps"
gal = "gal"
ptp = "ptp" SP ptp-version [ ":" ptp-id]
ptp-version = "IEEE 1588-2002" / "IEEE 1588-2008" / "IEEE 802.1AS-
2011"
ptp-id = 1*alphanum
last-synced = date SP time UTCoffset
date = 2DIGIT "-" 2DIGIT "-" 4DIGIT
; day month year (e.g., 02-06-1982)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT
; 00:00:00.000 - 23:59:59.999
UTCoffset = plusoffset / minusoffset
plusoffset = + 2DIGIT ":" 2DIGIT
; +01:00 (+HH:MM)
minusoffset = - 2DIGIT ":" 2DIGIT
; -00:00 (-HH:MM)
alphanum = ALPHA / DIGIT
EXAMPLE
a=clocksource:ntp=139.63.192.5:123 19-02-2011 21:03:20.345+01:00
A client MAY include this attribute multiple times. If multiple time
synchronization sources were used in the past, the client MUST only
report the 'last synced' parameter on the latest synchronization
performed. If a client supports a specific synchronization method,
but does not know any sources to use for synchronization, it SHOULD
indicate the method without specifying the source. A client MAY
indicate itself as source if it is a clock synchronization source,
but it SHOULD do so using a publicly reachable address.
The parameter can be used as both a session or media level attribute.
It will normally be a session level parameter, since it is not
directly media-related. In case of IDMS however, it can be used in
conjunction with the rtcp-idms SDP parameter, and then it SHOULD be
used as a media-level parameter as well.
The meaning of 'local' is that no clock synchronization is performed.
Allthough not re-used, the meaning of 'gps' (Global Positioning
System), 'gal' (Galileo Positioning System) and ptp (Precision Time
Protocol) follows the use of reference identifiers in NTP [RFC5905].
When using ptp, the ptp-id MUST contain the proper identifier from
the used IEEE specification.
The 'last synced' parameter is used as an indication for the receiver
of the parameter on the accuracy of the clock. If the indicated last
synchronization time is very recent, this is an indication that the
clock can be trusted to be accurate, given the method of clock
synchronization used. If the indicated last synchronization time is
longer ago or in the future, either the clock synchronization has
been performed long ago, or the clock is synchronized to an incorrect
synchronization source. Either way, this shows that the clock used
can not be trusted to be accurate.
12. Compatibility with ETSI TISPAN
As described in section 1.4, ETSI TISPAN has also described a As described in Section 1.4, ETSI TISPAN has also described a
mechanism for IDMS in [TS 183 063]. One of the main differences mechanism for IDMS in [TS183063]. One of the main differences
between the TISPAN document and this document is the fact that the between the TISPAN document and this document is the fact that the
TISPAN solution uses an RTPC XR block for both the SC->MSAS message TISPAN solution uses an RTPC XR block for both the SC->MSAS message
as well as for the MSAS->SC message (by selecting different SPST- and the MSAS->SC message (by selecting different SPST-types), while
types), while this document specifies a new RTCP Packet Type for the this document specifies a new RTCP Packet Type for the MSAS->SC
MSAS->SC message. The message from MSAS to SC is not in any way a message. The message from MSAS to SC is not in any way a report on
report on how a receiver sees a session, and therefore a separate how a receiver sees a session, and therefore a separate RTCP packet
RTCP packet type is more appropriate then the XR block solution type is more appropriate than the XR block solution chosen in ETSI
chosen in ETSI TISPAN. TISPAN.
In order to maintain backward-compatibility, the RTCP XR block used In order to maintain backward-compatibility, the RTCP XR block used
for SC->MSAS signaling specified in this document is fully compatible for SC->MSAS signaling specified in this document is fully compatible
with the TISPAN defined XR block. with the TISPAN defined XR block.
For the MSAS->SC signaling, it is recommended to use the RTCP IDMS For the MSAS->SC signaling, it is recommended to use the RTCP IDMS
Packet Type defined in this document. The TISPAN XR block with SPST=2 Packet Type defined in this document. The TISPAN XR block with
MAY be used for purposes of compatibility with the TISPAN solution, SPST=2 MAY be used for purposes of compatibility with the TISPAN
but 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
Packet Type. RTCP IDMS Packet Type.
The above means that the IANA registry contains two SDP parameters The above means that the IANA registry contains two SDP parameters
for the MSAS->SC signaling; one for the ETSI TISPAN solution and one for the MSAS->SC signaling; one for the ETSI TISPAN solution and one
for the IETF solution. This also means that if all elements in the for the IETF solution. This also means that if all elements in the
SDP negotiation support the IETF solution they SHOULD use the new SDP negotiation support the IETF solution they SHOULD use the new
RTCP IDMS Packet Type. RTCP IDMS Packet Type.
13. On the use of presentation timestamps 12. 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 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 playout times. RTP packet arrival times and a receiver MAY report on playout times. RTP 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. By synchronizing receivers will take roughly the same amount of time. It can suffice
on packet arrival times, you may loose some accuracy, but it will be for many applications, such as social TV, to synchronize on packet
adequate for many applications, such as social TV. Also, if the arrival times. Also, if the receivers are in some way controlled,
receivers are in some way controlled, e.g. having the same buffer e.g. having the same buffer settings and decoding times, high
settings and decoding times, high accuracy can be achieved. However, accuracy can be achieved. However, if all receivers in a
if all receivers in a synchronization session have the ability to synchronization session have the ability to report on, and thus
report on, and thus synchronize on, actual playout times, or packet synchronize on packet presented times, this may be more accurate. It
presentation times, this may be more accurate. It is up to is up to applications and implementations of this RTCP extension
applications and implementations of this RTCP extension whether to whether to implement and use this.
implement and use this.
14. Security Considerations 13. Security Considerations
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 playout summarize and distribute information on packet reception- and
-times of streaming media. The information may be used to orchestrate playout-times of streaming media. The information may be used to
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 reports to undesired behavior. For example, if one device erroneously
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 suggested confidentiality. Encryption procedures, such as those being
for a Secure RTP (SRTP) at the time that this document was written, suggested for a Secure RTP (SRTP) at the time that this document was
can be used when confidentiality is a concern to end hosts. written, can be used when confidentiality is a concern to end hosts.
15. IANA Considerations 14. IANA Considerations
New RTCP Packet Types and RTCP XR Block Types are subject to IANA New RTCP Packet Types and RTCP XR Block Types are subject to IANA
registration. For general guidelines on IANA considerations for RTCP registration. For general guidelines on IANA considerations for RTCP
XR, refer to [RFC3611]. XR, refer to [RFC3611].
[TS 183 063] assigns the block type value 12 in the RTCP XR Block [TS 183 063] assigns the block type value 12 in the RTCP XR Block
Type Registry to "Inter-destination Media Synchronization Block". [TS Type Registry to "Inter-Destination Media Synchronization Block".
183 063] also registers the SDP [RFC4566] parameter "grp-sync" for [TS183063] also registers the SDP [RFC4566] parameter "grp-sync" for
the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry.
Further, this document defines a new RTCP packet type called IDMS Further, this document defines a new RTCP packet type called IDMS
report. This new packet type is registered with the IANA registry of report. This new packet type is registered with the IANA registry of
RTP parameters, based on the specification in section 7. RTP parameters, based on the specification in Section 10.
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.
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
Type of name: att-field
Type of attribute: media level
Subject to charset: no
Purpose: see sections 7 and 10 of this document
Reference: this document
Values: see this document
Further, this document defines a new SDP attribute, "clocksource",
within the existing IANA registry of SDP Parameters.
The SDP attribute "clocksource" defined by this document is
registered with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"):
Attribute name: clocksource
Long form: clock synchronization source
Type of name: att-field
Type of attribute: session level Long form: RTCP report block for IDMS
Subject to charset: no Type of name: att-field
Purpose: see sections 8 and 11 of this document Type of attribute: media level
Reference: this document Subject to charset: no
Values: see this document and registrations below Purpose: see sections 7 and 10 of this document
The attribute has an extensible parameter field and therefore a Reference: this document
registry for these parameters is required. This document creates an Values: see this document
IANA registry called the Clocksource Source Parameters Registry. It
contains the five parameters defined in Section 11: "local", "ntp",
"gps", "gal" and "ptp".
16. Contributors 15. 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 Walraven, Ishan Vaishnavi, Rufael Mekuria.
17. Conclusions 16. Conclusions
This document describes the RTCP XR block type for IDMS, the RTCP This document describes the RTCP XR block type for IDMS, the RTCP
IDMS report and the associated SDP parameters for inter-destination IDMS report and the associated SDP parameters for Inter-Destination
media synchronization. It also describes an SDP parameter for Media Synchronization.
indicating which source is used for synchronizing a (systems) (wall)
clock.
18. References
18.1. Normative References 17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.draft-williams-avtcore-clksrc]
Requirement Levels", BCP 14, RFC 2119, March 1997. Williams, A., van Brandenburg, R., Stokking, H., and K.
Gross, "RTP Clock Source Signalling,
draft-williams-avtcore-clksrc-00", March 2012.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Syntax Specifications: ABNF", STD 68, RFC 5234, January Requirement Levels, RFC 2119", March 1997.
2008.
[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", STD 64, RFC 3550, July 2003. Applications, RFC3550", 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", STD 65, RFC 3551, Video conferences with Minimal Control, RFC3551",
July 2003. July 2003.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR),
RFC 3611, November 2003. RFC3611", November 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol, RFC4566", July 2006.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Media Attributes in the Session Description Protocol Specifications, RFC5234", January 2008.
(SDP)", RFC 5576, June 2009.
[RFC5576] Lenox, J., Ott, J., and T. Schierl, "Source-Specific Media
Atrributes in the Session Description Protocol, RFC5576",
June 2009.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, 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
Specification", RFC 5905, June 2010. Specifications, RFC5905", February 2010.
[TS 183 063] ETSI TISPAN, "IMS-based IPTV stage 3 specification", TS [TS183063]
183 063 v3.4.1, June 2010. "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1",
June 2010.
18.2. Informative References 17.2. Informative References
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [Boronat2009]
Control Protocol (RTCP)", RFC 5968, September 2010. Boronat, F., Lloret, J., and M. Garcia, "Multimedia group
and inter-stream synchronization techniques: a comparative
study", Elsevier Information Systems 34 (2009), pp. 108-
131".
[Boronat2009] Boronat, F., et al, "Multimedia group and inter-stream [IEEE-1588]
synchronization techniques: A comparative study", Elsevier "1588-2008 - IEEE Standard for a Precision Clock
Information Systems 34 (2009), pp. 108-131 Synchronization Protocol for Networked Measurement and
Control Systems", 2008.
[Ishibashi2006] Ishibashi Y. et al, "Subjective Assesment of Fairness [Ishibashi2006]
among users in multipoint communications". Proceedings of Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective
the 2006 ACM SIGCHI international conference on Advances Assessment of Fairness among users in multipoint
in computer entertainment technology, 2006. communications", Proceedings of the 2006 ACM SIGCHI
internation conference on Advances in computer
entertainment technology, 2006".
[IEEE-1588] IEEE Standards Association, "1588-2008 - IEEE Standard [RFC5868] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
for a Precision Clock Synchronization Protocol for Control Protocol (RTCP), RFC5968", September 2010.
Networked Measurement and Control Systems", 2008
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
TNO TNO
Brassersplein 2, Delft, the Netherlands Brassersplein 2
Delft 2612CT
the Netherlands
Phone: +31 88 86 63609 Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl Email: ray.vanbrandenburg@tno.nl
Hans M. Stokking Hans Stokking
TNO TNO
Brassersplein 2, Delft, the Netherlands Brassersplein 2
Delft 2612CT
the Netherlands
Phone: +31 88 86 67278 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, Delft, the Netherlands Brassersplein 2
Delft 2612CT
Phone: +31 88 86 67078 the Netherlands
Phone: +31-88-866-7000
Email: oskar.vandeventer@tno.nl Email: oskar.vandeventer@tno.nl
Fernando Boronat Fernando Boronat
IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia Universidad Politecnica de Valencia
C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain IGIC Institute, Universitat Politecnica de Valencia-Campus
de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia
Valencia 46730
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
IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia Universidad Politecnica de Valencia
C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain IGIC Institute, Universitat Politecnica de Valencia-Campus
de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia
Valencia 46730
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
Email: Kevin.Gross@AVAnw.com
 End of changes. 173 change blocks. 
694 lines changed or deleted 521 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/