draft-ietf-avtcore-idms-01.txt   draft-ietf-avtcore-idms-02.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 M. van Deventer
Expires: January 7, 2012 O. Niamut Expires: May 3, 2012 TNO Netherlands
F. Walraven
TNO Netherlands
I. Vaishnavi
CWI Netherlands
F. Boronat F. Boronat
M. Montagud M. Montagud
Universidad Politecnica de Valencia Universidad Politecnica de Valencia
July 6, 2011 Kevin Gross
AVA Networks
October 31, 2011
RTCP for inter-destination media synchronization RTCP for inter-destination media synchronization
draft-ietf-avtcore-idms-01.txt draft-ietf-avtcore-idms-02.txt
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), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 5, 2012. 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) 2011 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
skipping to change at page 2, line 25 skipping to change at page 2, line 23
media synchronization (IDMS). The RTCP XR Block Type, registered with media synchronization (IDMS). The RTCP XR Block Type, registered with
IANA based on an ETSI specification, is used to collect media play- IANA based on an ETSI specification, is used to collect media play-
out information from participants in a group playing-out (watching, out information from participants in a group playing-out (watching,
listening, etc.) a specific RTP media stream. The RTCP packet type listening, etc.) a specific RTP media stream. The RTCP packet type
specified by this document is used to distribute a summary of the specified by this document is used to distribute a summary of the
collected information so that the participants can synchronize play- collected information so that the participants can synchronize play-
out. out.
Typical applications for IDMS are social TV, shared service control Typical applications for IDMS are social TV, shared service control
(i.e. applications where two or more geographically separated users (i.e. applications where two or more geographically separated users
are watching a media stream together), distance learning, network are watching a media stream together), distance learning, networked
quiz shows, multi-playing online games, etc. video walls, networked speakers, etc.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Inter-destination Media Synchronization . . . . . . . . . . 3 1.1. Inter-destination Media Synchronization . . . . . . . . . . 3
1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . . 3 1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . . 3
1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 4 1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 4
1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . . 4 1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 4 3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 4
4. Inter-destination media synchronization use cases . . . . . . . 6 4. Inter-destination media synchronization use cases . . . . . . . 6
5. Architecture for inter-destination media synchronization . . . 7 5. Architecture for inter-destination media synchronization . . . 7
5.1. Media Synchronization Application Server (MSAS) . . . . . . 7 5.1. Media Synchronization Application Server (MSAS) . . . . . . 7
5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . . 7 5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . . 8
5.3. Communication between MSAS and SCs . . . . . . . . . . . . 7 5.3. Communication between MSAS and SCs . . . . . . . . . . . . 8
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
9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . . 13 8.1. Leap Seconds . . . . . . . . . . . . . . . . . . . . . . . 14
10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 14 9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . . 15
11. SDP parameter for clock source . . . . . . . . . . . . . . . . 15 10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 15
12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 17 11. SDP parameter for clock source . . . . . . . . . . . . . . . . 16
13. Operational Considerations . . . . . . . . . . . . . . . . . . 17 12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13. On the use of presentation timestamps . . . . . . . . . . . . 19
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
17.1. Normative References . . . . . . . . . . . . . . . . . . . 21 17. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21
17.2. Informative References . . . . . . . . . . . . . . . . . . 21 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
18.1. Normative References . . . . . . . . . . . . . . . . . . . 22
18.2. Informative References . . . . . . . . . . . . . . . . . . 22
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 play-out
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 temporally synchronized manner. It can be applied to both
unicast and multicast media streams and can be applied to any type unicast and multicast media streams and can be applied to any type
and/or combination of streaming media, such as audio, video and text and/or combination of streaming media, such as audio, video and text
(subtitles). [Boronat2009] provides an overview of technologies and (subtitles). [Ishibashi2006] and [Boronat2009] provide an overview of
algorithms for IDMS. 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. It may also require signaling for the initiation and
maintenance of IDMS sessions and groups. maintenance of IDMS sessions and groups.
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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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
Social TV is the combination of media content consumption by two or There are a large number of use cases imaginable in which IDMS might
more users at different devices and locations and real-time be useful. This section will highlight some of them. It should be
communication between those users. noted that this section is in no way meant to be exhaustive
An example of Social TV, is when two or more users are watching the
same television broadcast at different devices and 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 can have
adverse effects on their experience. A well-known use case here is
one friend experiencing a goal in a football match well before or
after other friend(s). Thus IDMS is required to provide play-out
synchronization.
Another example of Social TV is Shared Service Control, where two or A first usage scenario for IDMS is Social TV. Social TV is the
more users experience some content-on-demand together, while sharing combination of media content consumption by two or more users at
the trick-play controls (play, pause, fast forward, rewind) of the different devices and locations and real-time communication between
content on demand. those users. An example of Social TV, is when two or more users are
watching the same television broadcast at different devices and
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
can have adverse effects on their experience. A well-known use case
here is one friend experiencing a goal in a football match well
before or after other friend(s). Thus IDMS is required to provide
play-out synchronization.
Similar to the previous use case, without IDMS, differences in play- Another potential use case for IDMS is the video wall. A video wall
out speed and the effect of transit delay of trick-play control consists of multiple computer monitors, video projectors, or
signals would desynchronize content play-out. television sets tiled together contiguously or overlapped in order to
form one large screen. Each of the screens reproduces a portion of
the larger picture. In some implementations, each screen may be
individually connected to the network and receive its portion of the
overall image from a network-connected video server or video scaler.
Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
potentially faster. If the refresh is not synchronized, the effect of
multiple screens acting as one is broken.
IDMS may be used for other purposes, such as synchronization of A third usage scenario is that of the networked loudspeakers, in
multiple television outputs in a single physical location, or for the which two or more speakers are connected to the network individually.
synchronization of different networked speakers throughout a house. Such situations can for example be found in large conference rooms,
legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in audio
delay, this use case needs even more accuracy than the video wall use
case. Depending on the exact application, the need for accuracy can
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
skipping to change at page 11, line 27 skipping to change at page 11, line 27
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 on
the time format used by NTP and consists of the least significant 16 the time format used by NTP and consists of the least significant 16
bits of the NTP seconds part and the most significant 16 bits of the bits of the NTP seconds part and the most significant 16 bits of the
NTP fractional second part. If this field is empty, then it SHALL be NTP fractional second part. If this field is empty, then it SHALL be
set to 0 and the Packet Presented NTP timestamp flag (P) SHALL be set set to 0 and the Packet Presented NTP timestamp flag (P) SHALL be set
to 0. Presented here means the moment the data is presented to the to 0. Presented here means the moment the data is presented to the
user of the system, i.e. sound played out through speakers, video user of the system, i.e. sound played out through speakers, video
images being displayed on some display, etc. For applications images being displayed on some display, etc. The accuracy resulting
requiring high accuracy, they should be able to determine this in any from the synchronization algorithm will only be as good as the
case to achieve their required accuracy. The accuracy resulting from accuracy with which the receivers can determine the delay between
the synchronization algorithm will only be as good as the accuracy receiving packets and presenting them to the end-user.
with which the receivers can determine and control their playout
timing. By adding this parameter, the protocol supports very high
accuracy if supported by the receivers.
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 a receiver of the RTP media
stream. Its definition is based on [RFC3550]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 9 skipping to change at page 12, line 6
| 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 | | Packet Presented NTP timestamp, most 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 6 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 value
of the SSRC identifier carried in the RTP header [RFC3550] of the RTP of the SSRC identifier carried in the RTP header [RFC3550] of the RTP
packet to which the RTCP IDMS packet relates. 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 used
to correlate synchronized media streams. The value 0 (all bits are to correlate synchronized media streams. The value 0 (all bits are
set "0") indicates that this field is empty. The value 2^32-1 (all 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 bits are set "1") is reserved for future use. The Media Stream
skipping to change at page 12, line 44 skipping to change at page 12, line 43
required playout delay. The timestamp is formatted based on the NTP required playout delay. The timestamp 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 set.
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 time stamp 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 RTP
packet containing this particular RTP timestamp, in case multiple RTP packet containing this particular RTP timestamp, in case multiple RTP
packets contain the same RTP timestamp. packets contain the same RTP timestamp.
Packet Presented NTP timestamp: 32 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. It is based on the time format used by NTP and consists of the user. The timestamp is formatted based on the NTP timestamp
the least significant 16 bits of the NTP seconds part and the most format as specified in [RFC5905]. If this field is empty, then it
significant 16 bits of the NTP fractional second part. If this field SHALL be set to 0. This field MAY be left empty if none or only one
is empty, then it SHALL be set to 0. This field MAY be left empty if of the receivers reported on presentation timestamps. Presented here
none or only one of the receivers reported on presentation means the moment the data is presented to the user of the system.
timestamps. Presented here means the moment the data is presented to
the user of the system. 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
so precise that a 32bit Presentation Timestamp might not suffice. For
this reason, this RTCP Packet Type for IDMS includes a 64bit
Presentation Timestamp field. Since an MSAS will in practice always
add some extra delay to the delay reported by the most lagged
receiver (to account for packet jitter), it suffices for the IDMS XR
Block Type with which the SCs report on their playout to have a 32bit
Presentation 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 in 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
skipping to change at page 13, line 46 skipping to change at page 14, line 5
the same or a similar clock synchronization source for their session. the same or a similar clock synchronization 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. How applications deal
with this is up to the implementation. The application might control with this is up to the implementation. The application might control
the system clock, or it might use a separate application clock or the system clock, or it might use a separate application clock or
even a separate IDMS session clock. It might also report on the even a separate IDMS session clock. It might also report on the
system clock and the synchronization method used, without being able system clock and the synchronization method used, without being able
to change it. 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 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 inter-destination media synchronization. It is also used to
carry an identifier for the synchronization group to which clients carry an identifier for the synchronization group to which clients
belong or will belong. This SDP parameter extends rtcp-xr-attrib as belong or will belong. This SDP parameter extends rtcp-xr-attrib as
follows, using Augmented Backus-Naur Form [RFC5234]. 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
skipping to change at page 17, line 48 skipping to change at page 19, line 11
MAY be used for purposes of compatibility with the TISPAN solution, MAY be used for purposes of compatibility with the TISPAN solution,
but MUST NOT be used if all nodes involved support the new RTCP IDMS but MUST NOT be used if all nodes involved support the new RTCP IDMS
Packet Type. 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. Operational Considerations 13. On the use of presentation timestamps
On Echo Cancellation:
In the case of social TV: If the two locations have a "side channel"
audio conference so the viewers can talk about what they are
watching, this may cause an audio problem that will not be solved by
just applying IDMS. The audio output of the television of one viewer
will pass through the audio conference, and arrive at the second
viewer out of sync with the television output of that second viewer.
Different methods can be used to deal with this effect, e.g. using
directional microphones to prevent this or applying echo cancellation
to filter out the unwanted audio signals.
On Reception vs. Presentation Timing:
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 play-out 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. By synchronizing
on packet arrival times, you may loose some accuracy, but it will be on packet arrival times, you may loose some accuracy, but it will be
adequate for many applications, such as social TV. Also, if the adequate for many applications, such as social TV. Also, if the
receivers are in some way controlled, e.g. having the same buffer receivers are in some way controlled, e.g. having the same buffer
skipping to change at page 20, line 30 skipping to change at page 21, line 24
Reference: this document Reference: this document
Values: see this document and registrations below Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a The attribute has an extensible parameter field and therefore a
registry for these parameters is required. This document creates an registry for these parameters is required. This document creates an
IANA registry called the Clocksource Source Parameters Registry. It IANA registry called the Clocksource Source Parameters Registry. It
contains the five parameters defined in Section 11: "local", "ntp", contains the five parameters defined in Section 11: "local", "ntp",
"gps", "gal" and "ptp". "gps", "gal" and "ptp".
16. Conclusions 16. Contributors
The following people have participated as co-authors or provided
substantial contributions to this document: Omar Niamut, Fabian
Walraven, Ishan Vaishnavi, Rufael Mekuria
17. 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. It also describes an SDP parameter for
indicating which source is used for synchronizing a (systems) (wall) indicating which source is used for synchronizing a (systems) (wall)
clock. clock.
17. References 18. References
17.1. Normative References 18.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008. 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
skipping to change at page 21, line 46 skipping to change at page 22, line 46
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", RFC 5760, 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. Specification", RFC 5905, June 2010.
[TS 183 063] ETSI TISPAN, "IMS-based IPTV stage 3 specification", TS [TS 183 063] ETSI TISPAN, "IMS-based IPTV stage 3 specification", TS
183 063 v3.4.1, June 2010. 183 063 v3.4.1, June 2010.
17.2. Informative References 18.2. Informative References
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, September 2010.
[Boronat2009] Boronat, F., et al, "Multimedia group and inter-stream [Boronat2009] Boronat, F., et al, "Multimedia group and inter-stream
synchronization techniques: A comparative study", Elsevier synchronization techniques: A comparative study", Elsevier
Information Systems 34 (2009), pp. 108-131 Information Systems 34 (2009), pp. 108-131
[Ishibashi2006] Ishibashi Y. et al, "Subjective Assesment of Fairness
among users in multipoint communications". Proceedings of
the 2006 ACM SIGCHI international conference on Advances
in computer entertainment technology, 2006.
[IEEE-1588] IEEE Standards Association, "1588-2008 - IEEE Standard [IEEE-1588] IEEE Standards Association, "1588-2008 - IEEE Standard
for a Precision Clock Synchronization Protocol for for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems", 2008 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, the Netherlands
skipping to change at page 23, line 28 skipping to change at page 24, line 28
Phone: +31 88 86 67278 Phone: +31 88 86 67278
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, the Netherlands
Phone: +31 88 86 67078 Phone: +31 88 86 67078
Email: oskar.vandeventer@tno.nl Email: oskar.vandeventer@tno.nl
Omar A. Niamut
TNO
Brassersplein 2, Delft, the Netherlands
Phone: +31 88 86 67218
Email: omar.niamut@tno.nl
Fabian A. Walraven
TNO
Brassersplein 2, Delft, the Netherlands
Phone: +31 88 86 67722
Email: fabian.walraven@tno.nl
Ishan Vaishnavi
CWI
Science Park 123, Amsterdam, the Netherlands
Phone: +31 20 592 4323
Email: i.vaishnavi@cwi.nl
Fernando Boronat Fernando Boronat
IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia
C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, 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 IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia
C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain
Phone: +34 962 849 341 Phone: +34 962 849 341
Email: mamontor@posgrado.upv.es Email: mamontor@posgrado.upv.es
Kevin Gross
AVA Networks
 End of changes. 26 change blocks. 
104 lines changed or deleted 152 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/