draft-ietf-avtcore-idms-12.txt   draft-ietf-avtcore-idms-13.txt 
AVTCore R. van Brandenburg AVTCore R. van Brandenburg
Internet-Draft H. Stokking Internet-Draft H. Stokking
Intended status: Standards Track O. van Deventer Intended status: Standards Track O. van Deventer
Expires: January 30, 2014 TNO Expires: March 02, 2014 TNO
F. Boronat F. Boronat
M. Montagud M. Montagud
Universitat Politecnica de Valencia Universitat Politecnica de Valencia
K. Gross K. Gross
AVA Networks AVA Networks
July 29, 2013 August 29, 2013
Inter-destination Media Synchronization using the RTP Control Protocol Inter-destination Media Synchronization using the RTP Control Protocol
(RTCP) (RTCP)
draft-ietf-avtcore-idms-12 draft-ietf-avtcore-idms-13
Abstract Abstract
This document defines a new RTP Control Protocol (RTCP) Packet Type This document defines a new RTP Control Protocol (RTCP) Packet Type
and an RTCP Extended Report (XR) Block Type to be used for achieving and an RTCP Extended Report (XR) Block Type to be used for achieving
Inter-Destination Media Synchronization (IDMS). IDMS is the process Inter-Destination Media Synchronization (IDMS). IDMS is the process
of synchronizing playout across multiple geographically distributed of synchronizing playout across multiple geographically distributed
media receivers. Using the RTCP XR IDMS Report Block defined in this media receivers. Using the RTCP XR IDMS Report Block defined in this
document, media playout information from participants in a document, media playout information from participants in a
synchronization group can be collected. Based on the collected synchronization group can be collected. Based on the collected
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 30, 2014. This Internet-Draft will expire on March 02, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 38 skipping to change at page 2, line 38
4. Inter-Destination Media Synchronization (IDMS) use cases . . 4 4. Inter-Destination Media Synchronization (IDMS) use cases . . 4
5. Overview of IDMS operation . . . . . . . . . . . . . . . . . 5 5. Overview of IDMS operation . . . . . . . . . . . . . . . . . 5
6. Architecture for Inter-Destination Media Synchronization . . 7 6. Architecture for Inter-Destination Media Synchronization . . 7
6.1. Media Synchronization Application Server (MSAS) . . . . . 7 6.1. Media Synchronization Application Server (MSAS) . . . . . 7
6.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8 6.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8
6.3. Communication between MSAS and SCs . . . . . . . . . . . 8 6.3. Communication between MSAS and SCs . . . . . . . . . . . 8
7. RTCP XR Block for IDMS (IDMS Report Block) . . . . . . . . . 8 7. RTCP XR Block for IDMS (IDMS Report Block) . . . . . . . . . 8
8. RTCP Packet Type for IDMS (IDMS Settings) . . . . . . . . . . 11 8. RTCP Packet Type for IDMS (IDMS Settings) . . . . . . . . . . 11
9. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13 9. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13
10. On the use of presentation timestamps . . . . . . . . . . . . 14 10. On the use of presentation timestamps . . . . . . . . . . . . 14
11. SDP Signalling for RTCP IDMS Packet Type . . . . . . . . . . 14 11. SDP Signalling for RTCP IDMS Packet Type . . . . . . . . . . 15
12. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . 15 12.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . 16
12.2. Declarative cases . . . . . . . . . . . . . . . . . . . 17 12.2. Declarative cases . . . . . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
14.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . 18 14.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . 18
14.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . 18 14.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . 19
14.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 18 14.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 19
14.4. IDMS XR Block SPST Registry . . . . . . . . . . . . . . 19 14.4. IDMS XR Block SPST Registry . . . . . . . . . . . . . . 19
14.5. Contact Information for Registrations . . . . . . . . . 19 14.5. Contact Information for Registrations . . . . . . . . . 20
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Inter-Destination Media Synchronization (IDMS) refers to the playout 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 time synchronized manner. It can be applied to both unicast and in a time synchronized manner. It can be applied to both unicast and
multicast media streams and can be applied to any type and/or multicast media streams and can be applied to any type and/or
combination of streaming media, such as audio, video and text combination of streaming media, such as audio, video and text
(subtitles).[Ishibashi2006] and [Boronat2009] provide an overview of (subtitles).[Ishibashi2006] and [Boronat2009] provide an overview of
technologies and algorithms for IDMS. technologies and algorithms for IDMS.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
2. Rationale 2. Rationale
2.1. Applicability of RTCP to IDMS 2.1. Applicability of RTCP to IDMS
Currently, a large share of real-time applications make use of RTP Currently, a large share of real-time applications make use of RTP
and RTCP [RFC3550]. RTP provides end-to-end network transport and RTCP [RFC3550]. RTP provides end-to-end network transport
functions suitable for applications requiring real-time data functions suitable for applications requiring real-time data
transport, such as audio, video or data, over multicast or unicast transport, such as audio, video or data, over multicast or unicast
network services. The timestamps, sequence numbers, and payload network services. The timestamps, sequence numbers, and payload
(content) type identification mechanisms provided by RTP packets are (content) type identification mechanisms provided by RTP packets are
very useful for reconstructing the original media timing, and for very useful for reconstructing the original media timing, the
reordering and detecting packet loss at the client side. original order of packets and for 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
groups, and to provide minimal control and identification groups, and to provide minimal control and identification
functionality. RTP receivers and senders provide reception quality functionality. RTP receivers and senders provide reception quality
feedback by sending out RTCP Receiver Report (RR) and Sender Report feedback by sending out RTCP Receiver Report (RR) and Sender Report
(SR) packets [RFC3550], respectively, which may be augmented by (SR) packets [RFC3550], respectively, which may be augmented by
eXtended Reports (XR) [RFC3611]. Both RTP and RTCP are intended to eXtended Reports (XR) [RFC3611]. Both RTP and RTCP are intended to
be tailored through modifications in order to include profile- be tailored to modifications in order to include profile-specific
specific information required by particular applications, and the information required by particular applications, and the guidelines
guidelines on doing so are specified in [RFC5868]. on doing so are specified in [RFC5868].
IDMS involves the collection, summarizing and distribution of RTP IDMS involves the collection, summarizing and distribution of RTP
packet arrival and playout times. As information on RTP packet packet arrival and playout times. As information on RTP packet
arrival times and playout times can be considered reception quality arrival times and playout times can be considered reception quality
feedback information, RTCP is well suited for carrying out IDMS, feedback information, RTCP is well suited for carrying out IDMS,
which may facilitate the implementation and deployment in typical which may facilitate the implementation and deployment in typical
multimedia applications. multimedia applications.
2.2. IDMS and ETSI 2.2. IDMS and ETSI
skipping to change at page 4, line 25 skipping to change at page 4, line 26
the result of that effort. the result of that effort.
Although the IDMS protocol described in this document has evolved Although the IDMS protocol described in this document has evolved
significantly from the version that was originally specified by ETSI significantly from the version that was originally specified by ETSI
TISPAN, it is still backwards compatible with the ETSI version. As TISPAN, it is still backwards compatible with the ETSI version. As
such, it had been decided in ETSI to update the TS 183 063 document such, it had been decided in ETSI to update the TS 183 063 document
to reference this document as the normative specification of IDMS. to reference this document as the normative specification of IDMS.
This update can be found in newer versions of TS 183 063 (>3.5.2). This update can be found in newer versions of TS 183 063 (>3.5.2).
In accordance, this document proposes to update the IANA registration In accordance, this document proposes to update the IANA registration
for the RTCP IDMS XR Block to point to this document. Finally, this for the RTCP IDMS XR Block to point to this document. Finally, this
document proposes an IANA registry for SPST values, allowing ETSI to document proposes an IANA registry for SPST values, allowing the
register extensions to this document. registration of extensions to this document.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119].
indicate requirement levels for compliant implementations.
4. Inter-Destination Media Synchronization (IDMS) use cases 4. Inter-Destination Media Synchronization (IDMS) use cases
There are a large number of use cases in which IDMS might be useful. There are a large number of use cases in which IDMS might be useful.
This section will highlight some of them. It should be noted that This section will highlight some of them. It should be noted that
this section is in no way meant to be exhaustive. this section is in no way meant to be exhaustive.
A first usage scenario for IDMS is social TV. Social TV is the A first usage scenario for IDMS is social TV. Social TV is the
combination of media content consumption by two or more users at combination of media content consumption by two or more users at
different devices and locations combined with the real-time different devices and locations combined with the real-time
skipping to change at page 5, line 14 skipping to change at page 5, line 14
Another potential use case for IDMS is a networked video wall. A Another potential use case for IDMS is a networked video wall. A
video wall consists of multiple computer monitors, video projectors, video wall consists of multiple computer monitors, video projectors,
or television sets tiled together contiguously or overlapped in order or television sets tiled together contiguously or overlapped in order
to form one large screen. Each of the screens reproduces a portion to form one large screen. Each of the screens reproduces a portion
of the larger picture. In some implementations, each screen may be of the larger picture. In some implementations, each screen may be
individually connected to the network and receive its portion of the individually connected to the network and receive its portion of the
overall image from a network-connected video server or video scaler. overall image from a network-connected video server or video scaler.
Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
potentially faster. If the refresh is not synchronized, the effect potentially faster. If the refresh is not synchronized, the effect
of multiple screens acting as one is broken. of multiple screens acting as one is broken, with users noticing
tearing effects and no longer perceiving a single image.
A third usage scenario is that of the networked loudspeakers, in A third usage scenario is that of 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.
skipping to change at page 5, line 37 skipping to change at page 5, line 38
This section provides a brief example of how the RTCP functionality This section provides a brief example of how the RTCP functionality
is used for achieving IDMS. The section is tutorial in nature and is used for achieving IDMS. The section is tutorial in nature and
does not contain any normative statements. does not contain any normative statements.
Alice's . . . . . . .tv:abc.com . . . . . . . Bob's Alice's . . . . . . .tv:abc.com . . . . . . . Bob's
TV (Sync Client) (Sync Server) Laptop (Sync Client) TV (Sync Client) (Sync Server) Laptop (Sync Client)
| | | | | |
| Media Session | | | Media Session | |
|<=====================>| | |<=====================>| |
| Invite(URL,Sync-group ID) | | Invite(URL, SyncGroupId) |
|------------------------------------------------->| |------------------------------------------------->|
| | Media Session Set-up | | | Media Session Set-up |
| |<========================>| | |<========================>|
| | | | | |
| Call set-up | | Call set-up |
|<================================================>| |<================================================>|
| | | | | |
| RTP Packets | RTP Packets | | RTP Packets | RTP Packets |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| RR + XR IDMS Report | | | RR + XR IDMS Report | |
skipping to change at page 8, line 43 skipping to change at page 8, line 43
of RTP packets from a single RTP stream in a certain synchronization of RTP packets from a single RTP stream in a certain synchronization
group. In some cases, however, an RTP receiver may be a member of group. In some cases, however, an RTP receiver may be a member of
multiple synchronization groups for the same RTP stream, e.g. multiple synchronization groups for the same RTP stream, e.g.
watching a single television program simultaneously with different watching a single television program simultaneously with different
groups. In even further cases, a receiver may wish to synchronize groups. In even further cases, a receiver may wish to synchronize
different RTP streams at the same time, either as part of the same different RTP streams at the same time, either as part of the same
synchronization group or as part of multiple synchronization groups. synchronization group or as part of multiple synchronization groups.
These are all valid scenarios for IDMS, and will require multiple These are all valid scenarios for IDMS, and will require multiple
reports by an SC. reports by an SC.
SCs SHOULD report on a recently received RTP packets. This document This document does not define new rules on when to send RTCP reports,
does not define new rules on when to send RTCP reports, but uses the but uses the existing rules specified in [RFC3550] for sending RTCP
existing rules specified in [RFC3550] for sending RTCP reports. When reports. When the RTCP reporting timer allows an SC to send an IDMS
the RTCP reporting timer allows an SC to send an IDMS report, the SC report, the SC SHOULD report on an RTP packet received during the
SHOULD report on an RTP packet received during the period since the period since the last RTCP XR IDMS Report Block was sent. Because of
last RTCP XR IDMS Report Block was sent. For more details on which RTP timestamp rollover, there is ambiguity in mapping RTP timestamps
to NTP timestamps. The recommendation to report on recent RTP
packets serves to manage this ambiguity. For more details on which
packet to report on, see below under 'Packet Received RTP timestamp'. packet to report on, see below under 'Packet Received RTP timestamp'.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=12 | SPST |Resrv|P| block length=7 | | BT=12 | SPST |Resrv|P| block length=7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Resrv | | PT | Resrv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Stream Correlation Identifier | | Media Stream Correlation Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, most significant word | | Packet Received NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received NTP timestamp, least significant word | | Packet Received NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Received RTP timestamp | | Packet Received RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Presented NTP timestamp | | Packet Presented NTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IDMS report block consists of 8 32-bit words, with the following The 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. is set to 12.
Synchronization Packet Sender Type (SPST): 4 bits. This field Synchronization Packet Sender Type (SPST): 4 bits. This field
identifies the role of the packet sender for this specific eXtended identifies the role of the packet sender for this specific eXtended
Report. It can have the following values, as maintained by IANA (see Report. It can have the following values, as maintained by IANA (see
Section 14.4): Section 14.4):
SPST=0 Reserved for future use. SPST=0 Reserved for future use.
SPST=1 The packet sender is an SC. It uses this XR to report SPST=1 The packet sender is an SC. It uses this XR to report
synchronization status information. Timestamps relate to the SC synchronization status information. Timestamps relate to the SC
input. input.
SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]). SPST=2-4 Values defined by ETSI TISPAN (see [TS183063]).
SPST=5-15 Reserved for future use. SPST=5-15 Unassigned.
Reserved bits (Resrv): 3 bits. These bits are reserved for future Reserved bits (Resrv): 3 bits. These bits are reserved for future
definition. In the absence of such a definition, the bits in this definition. In the absence of such a definition, the bits in this
field MUST be set to zero at transmission and MUST be ignored by the field MUST be set to zero at transmission and MUST be ignored by the
receiver. receiver.
Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the
Packet Presented NTP timestamp field contains a value, 0 if it is Packet Presented NTP timestamp field contains a value, 0 if it is
empty. If this flag is set to zero, then the Packet Presented NTP empty. If this flag is set to zero, then the Packet Presented NTP
timestamp SHALL be ignored by the receiver. timestamp SHALL be ignored by the receiver.
Block Length: 16 bits. This field indicates the length of the block Block Length: 16 bits. This field indicates the length of the block
in 32 bit words minus one and SHALL be set to 7, as this RTCP Block in 32 bit words minus one and is set to 7, as this RTCP Block Type
Type has a fixed length. has a fixed length.
Payload Type (PT): 7 bits. This field identifies the format of the Payload Type (PT): 7 bits. This field identifies the format of the
media payload, according to [RFC3551]. This is the payload type of media payload, according to [RFC3551]. This is the payload type of
the RTP packet reported upon. The PT field is needed in the case the RTP packet reported upon. The PT field is needed in the case
where the MSAS is neither the Media Server nor a receiver of the where the MSAS is neither the Media Server nor a receiver of the
media stream, i.e. it is implemented as a third-part entity. In such media stream, i.e. it is implemented as a third-part entity. In such
cases, the MSAS needs the PT to determine the rate of advancement of cases, the MSAS needs the PT to determine the rate of advancement of
the timestamps of the RTP media stream to be able to relate reports the timestamps of the RTP media stream to be able to relate reports
from different SCs on different RTP timestamp values. from different SCs on different RTP timestamp values.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
receiver. receiver.
Media Stream Correlation Identifier: 32 bits. This identifier is Media Stream Correlation Identifier: 32 bits. This identifier is
used to correlate synchronized media streams. The value 0 (all bits used to correlate synchronized media streams. The value 0 (all bits
are set "0") indicates that this field is empty. The value 2^32-1 are set "0") indicates that this field is empty. The value 2^32-1
(all bits are set "1") is reserved for future use. If the RTCP (all bits are set "1") is reserved for future use. If the RTCP
Packet Sender is an SC (SPST=1), then the Media Stream Correlation Packet Sender is an SC (SPST=1), then the Media Stream Correlation
Identifier field contains the Synchronization Group Identifier Identifier field contains the Synchronization Group Identifier
(SyncGroupId) to which the report applies. (SyncGroupId) to which the report applies.
SSRC: 32 bits. The SSRC of the media source SHALL be set to the SSRC: 32 bits. The SSRC of the media source is set to the value of
value of the SSRC identifier carried in the RTP header [RFC3550] of the SSRC identifier carried in the RTP header [RFC3550] of the RTP
the RTP packet to which the XR IDMS relates. packet to which the XR IDMS relates.
Packet Received NTP timestamp: 64 bits. This timestamp reflects the Packet Received NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the moment of arrival of the first octet of the wall clock time at the moment of arrival of the first octet of the
RTP packet to which the XR IDMS relates. It is formatted based on RTP packet to which the XR IDMS relates. It is formatted based on
the NTP timestamp format as specified in [RFC5905]. See Section 9 the NTP timestamp format as specified in [RFC5905]. See Section 9
for more information on how this field is used. for more information on how this field is used.
Packet Received RTP timestamp: 32 bits. This timestamp has the value Packet Received RTP timestamp: 32 bits. This timestamp has the value
of the RTP timestamp carried in the RTP header [RFC3550] of the RTP of the RTP timestamp carried in the RTP header [RFC3550] of the RTP
packet to which the XR IDMS relates. Several consecutive RTP packets packet to which the XR IDMS relates. Several consecutive RTP packets
skipping to change at page 11, line 20 skipping to change at page 11, line 20
RTP packets just received, not from an earlier time before the last RTP packets just received, not from an earlier time before the last
wrap-around of RTP timestamps (unless this wrap-around occurs during wrap-around of RTP timestamps (unless this wrap-around occurs during
the sequence with equal RTP timestamps). the sequence with equal RTP timestamps).
Packet Presented NTP timestamp: 32 bits. This timestamp reflects the Packet Presented NTP timestamp: 32 bits. This timestamp reflects the
wall clock time at the moment the rendered media unit (e.g. video wall clock time at the moment the rendered media unit (e.g. video
frame or audio sample) contained in the first byte of the associated frame or audio sample) contained in the first byte of the associated
RTP packet is presented to the user. It is based on the time format RTP packet is presented to the user. It is based on the time format
used by NTP and consists of the least significant 16 bits of the NTP used by NTP and consists of the least significant 16 bits of the NTP
seconds part and the most significant 16 bits of the NTP fractional seconds part and the most significant 16 bits of the NTP fractional
second part. If this field is empty, then it SHALL be set to 0 and second part. If no Packet Presented NTP timestamp is available, this
the Packet Presented NTP timestamp flag (P) SHALL be set to 0. With field SHALL be set to 0 and be considered empty and the Packet
regards to NTP epoch and rollover, the value of the Packet Presented Presented NTP timestamp flag (P) SHALL be set to 0. With regards to
NTP timestamp is considered to always be greater than the Packet NTP epoch and rollover, the value of the Packet Presented NTP
Received NTP Timestamp and to be within 2^16 seconds of it. timestamp is considered to always be greater than the Packet Received
Presented in this context means the moment the data is played out to NTP Timestamp and to be within 2^16 seconds of it. Presented in this
the user of the system, i.e. sound played out through speakers, video context means the moment the data is played out to the user of the
images being displayed on some display, etc. The accuracy resulting system, i.e. sound played out through speakers, video images being
from the synchronization algorithm will only be as good as the displayed on some display, etc. The accuracy resulting from the
accuracy with which the SCs can determine the delay between receiving synchronization algorithm will only be as good as the accuracy with
packets and presenting them to the end-user. which the SCs can determine the delay between receiving packets and
presenting them to the end-user.
8. RTCP Packet Type for IDMS (IDMS Settings) 8. RTCP Packet Type for IDMS (IDMS Settings)
This section specifies the RTCP Packet Type for indicating This section specifies the RTCP Packet Type for indicating
synchronization settings instructions to the receivers of the RTP synchronization settings instructions to the receivers of the RTP
media stream. Its definition is based on [RFC3550]. media stream. Its definition is based on [RFC3550].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 22 skipping to change at page 12, line 23
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:
PT: To be determined upon registration with IANA, inserted by the RFC PT: To be determined upon registration with IANA, inserted by the RFC
Editor upon registration with IANA. Editor upon registration with IANA.
SSRC: 32 bits. The SSRC of the media source SHALL be set to the SSRC: 32 bits. The SSRC of the media source is set to the value of
value of the SSRC identifier of the media source carried in the RTP the SSRC identifier of the media source carried in the RTP header
header [RFC3550] of the RTP packet to which the RTCP IDMS packet [RFC3550] of the RTP packet to which the RTCP IDMS packet relates.
relates.
Media Stream Correlation Identifier: 32 bits. This identifier is Media Stream Correlation Identifier: 32 bits. This identifier is
used to correlate synchronized media streams. The value 0 (all bits used to correlate synchronized media streams. The value 0 (all bits
are set "0") indicates that this field is empty. The value 2^32-1 are set "0") indicates that this field is empty. The value 2^32-1
(all bits are set "1") is reserved for future use. The Media Stream (all bits are set "1") is reserved for future use. The Media Stream
Correlation Identifier contains the SyncGroupId of the group to which Correlation Identifier contains the SyncGroupId of the group to which
this packet is sent. this packet is sent.
Packet Received NTP timestamp: 64 bits. This timestamp reflects the Packet Received NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the reference client at the moment it received the wall clock time at the reference client at the moment it received the
first octet of the RTP packet to which this packet relates. It can first octet of the RTP packet to which this packet relates. It can
be used by the synchronization algorithm on the receiving SC to be used by the synchronization algorithm on the receiving SC to
adjust its playout timing in order to achieve synchronization, e.g. adjust its playout timing in order to achieve synchronization, e.g.
to set the required playout delay. The timestamp is formatted based to set the required playout delay. The timestamp is formatted based
on the NTP timestamp format as specified in [RFC5905]. See Section 9 on the NTP timestamp format as specified in [RFC5905]. See Section 9
for more information on how this field is used. Because RTP for more information on how this field is used. Because RTP
timestamps do wrap around, the sender of this packet SHOULD use timestamps do wrap around, the sender of this packet MUST use recent
recent values, i.e. choose NTP timestamps that reflect current time values, i.e. choose NTP timestamps that reflect current time and not
and not too far in the future or in the past. too far in the future or in the past so as to create ambiguity with
regards to RTP timestamp wrap around.
Packet Received RTP timestamp: 32 bits. This timestamp has the value Packet Received RTP timestamp: 32 bits. This timestamp has the value
of the RTP timestamp carried in the RTP header [RFC3550] of the RTP of the RTP timestamp carried in the RTP header [RFC3550] of the RTP
packet to which the XR IDMS relates. This SHOULD relate to the first packet to which the XR IDMS relates. This SHOULD relate to the first
arriving RTP packet containing this particular RTP timestamp, in case arriving RTP packet containing this particular RTP timestamp, in case
multiple RTP packets contain the same RTP timestamp. multiple RTP packets contain the same RTP timestamp.
Packet Presented NTP timestamp: 64 bits. This timestamp reflects the Packet Presented NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the reference client at the moment it presented wall clock time at the reference client at the moment it presented
the rendered media unit (e.g. video frame or audio sample) contained the rendered media unit (e.g. video frame or audio sample) contained
in the first octet of the associated RTP packet to the user. The in the first octet of the associated RTP packet to the user. The
timestamp is formatted based on the NTP timestamp format as specified timestamp is formatted based on the NTP timestamp format as specified
in [RFC5905]. If this field is empty, then it SHALL be set to 0. in [RFC5905]. If no Packet Presented NTP timestamp is available,
This field MAY be left empty if none or only one of the receivers this field SHALL be set to 0 and be considered empty. This field MAY
reported on presentation timestamps. Presented here means the moment be left empty if none or only one of the receivers reported on
the data is played out to the user of the system. presentation timestamps. Presented here 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 an MSAS might need to have over the exact moment of playout control an MSAS might need to have over the exact moment of playout
is so precise that a 32bit Presented Timestamp will not suffice. For is so precise that a 32bit Presented Timestamp will not suffice. For
this reason, this RTCP Packet Type for IDMS includes a 64bit this reason, this RTCP Packet Type for IDMS includes a 64bit
Presented Timestamp field. Since an MSAS will in practice always add Presented Timestamp field. Since an MSAS will in practice always add
some extra delay to the delay reported by the most lagged receiver some extra delay to the delay reported by the most lagged receiver
(to account for packet jitter), it suffices for the IDMS XR Block (to account for packet jitter), it suffices for the IDMS XR Block
Type with which the SCs report on their playout to have a 32bit Type with which the SCs report on their playout to have a 32bit
Presented Timestamp field. Presented Timestamp field.
skipping to change at page 15, line 21 skipping to change at page 15, line 27
solutions, i.e. using Sender Reports based on a common clock source. solutions, i.e. using Sender Reports based on a common clock source.
Basic guidelines for choosing the media stream for IDMS is to choose Basic guidelines for choosing the media stream for IDMS is to choose
audio above video, as humans are more sensitive to degradation in audio above video, as humans are more sensitive to degradation in
audio quality than in video quality. When using multi-description or audio quality than in video quality. When using multi-description or
multi-view codecs, the IDMS control should be performed on the base multi-view codecs, the IDMS control should be performed on the base
layer. layer.
This SDP attribute is defined as follows, using Augmented Backus-Naur This SDP attribute is defined as follows, using Augmented Backus-Naur
Form [RFC5234]. Form [RFC5234].
rtcp-idms = "a=" "rtcp-idms" ":" [sync-grp] CRLF rtcp-idms = "a=" "rtcp-idms" ":" sync-grp CRLF
sync-grp = "sync-group=" SyncGroupId sync-grp = "sync-group=" SyncGroupId
SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294 SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294
DIGIT = %x30-39 DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer and represented in decimal. SyncGroupId is a 32-bit unsigned integer and represented in decimal.
SyncGroupId identifies a group of SCs for IDMS. The value SyncGroupId identifies a group of SCs for IDMS. The value
SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295
skipping to change at page 17, line 39 skipping to change at page 17, line 51
Errors in the information, either accidental or malicious, may lead Errors in the information, either accidental or malicious, may lead
to undesired behavior. For example, if one device erroneously or to undesired behavior. For example, if one device erroneously or
maliciously reports a two-hour delayed playout, then another device maliciously reports a two-hour delayed playout, then another device
in the same synchronization group could decide to delay its playout in the same synchronization group could decide to delay its playout
by two hours as well, in order to keep its playout synchronized. A by two hours as well, in order to keep its playout synchronized. A
user would likely interpret this two hour delay as a malfunctioning user would likely interpret this two hour delay as a malfunctioning
service. service.
Therefore, the application logic of both SCs and MSASs should check Therefore, the application logic of both SCs and MSASs should check
for inconsistent information. Differences in playout time exceeding for out-of-bound information. Differences in playout time exceeding
configured limits (e.g. more than ten seconds) could be an indication configured limits (e.g. more than ten seconds) could be an indication
of such inconsistent information. of such out-of-bound information.
No new mechanisms are introduced in this document to ensure Apart from checking for out-of-bound information in the end-points,
confidentiality. Encryption procedures, such as those being an IDMS implementation can reduce its vulnerability to attacks by
suggested for a Secure RTP (SRTP) at the time that this document was including source authentication and message integrity measures,
written, can be used when confidentiality is a concern to end hosts. reducing the potential for man-in-the-middle attacks.
[I-D.draft-ietf-avtcore-rtp-security-options] provides an overview of
the security options in RTP environments, and includes a set of
recommendations for message integrity and source authentication which
are applicable to IDMS. In addition to preventing man-in-the-middle
attacks from inserting erroneous IDMS Reports, the message
confidentiality mechanisms outlined in
[I-D.draft-ietf-avtcore-rtp-security-options] also prevent third
parties from determining that two or more end hosts are receiving the
same stream by looking at the Media Stream Correlation Identifier.
Apart from attacking an IDMS session directly by sending incorrect
IDMS Reports, and with it introducing delays for all devices in a
synchronization group, another potential vulnerability comes from the
used clock synchronization method. Should an attacker succeed in
adjusting an SC's wallclock, that SC will report incorrect IDMS
Reports. In order to prevent such clock synchronization attacks, it
is recommended to use a secure time synchronization service.
14. IANA Considerations 14. IANA Considerations
This document defines a new RTCP packet type, the RTCP IDMS Packet This document defines a new RTCP packet type, the RTCP IDMS Packet
(IDMS Settings), within the existing Internet Assigned Numbers (IDMS Settings), within the existing Internet Assigned Numbers
Authority (IANA) registry of RTCP Control Packet Types. This Authority (IANA) registry of RTCP Control Packet Types. This
document also defines a new RTCP XR Block Type, the IDMS XR Report document also defines a new RTCP XR Block Type, the IDMS XR Report
Block, within the existing IANA registry of RTCP Extended Reports Block, within the existing IANA registry of RTCP Extended Reports
(RTCP XR) Block Types. (RTCP XR) Block Types.
skipping to change at page 18, line 21 skipping to change at page 18, line 50
(media level only)". Finally, this document defines a new IANA (media level only)". Finally, this document defines a new IANA
registry subordinate to the IANA RTCP Extended Reports (RTCP XR) registry subordinate to the IANA RTCP Extended Reports (RTCP XR)
Block Type Registry: the IDMS XR Block SPST Registry. Block Type Registry: the IDMS XR Block SPST Registry.
14.1. RTCP IDMS Packet Type 14.1. RTCP IDMS Packet Type
This document assigns the packet type value TBD in the IANA 'RTCP This document assigns the packet type value TBD in the IANA 'RTCP
Control Packet types (PT) Registry' to the RTCP IDMS Packet Type. Control Packet types (PT) Registry' to the RTCP IDMS Packet Type.
[Note to RFC Editor: please replace TBD with the IANA-provided RTCP [Note to RFC Editor: please replace TBD with the IANA-provided RTCP
Packet Type value for this packet type] Packet Type value for this packet type, both in this section as well
as in the figure and text in Section 8]
14.2. RTCP XR IDMS Report Block 14.2. RTCP XR IDMS Report Block
This document updates the assignment of value 12 from the RTCP XR This document updates the assignment of value 12 from the RTCP XR
Block Type for reporting IDMS information as per [TS183063] to the Block Type for reporting IDMS information as per [TS183063] to the
RTCP XR IDMS Report Block defined in this document. RTCP XR IDMS Report Block defined in this document.
[Note to RFC Editor: this block type value is currently assigned to [Note to RFC Editor: this block type value is currently assigned to
[TS183063]. This document replaces [TS183063] as the normative [TS183063]. This document replaces [TS183063] as the normative
specification of the RTCP XR IDMS Report Block. Upon publication of specification of the RTCP XR IDMS Report Block. Upon publication of
skipping to change at page 19, line 22 skipping to change at page 20, line 4
Values: see this document Values: see this document
14.4. IDMS XR Block SPST Registry 14.4. IDMS XR Block SPST Registry
This document defines a new IANA registry subordinate to the IANA This document defines a new IANA registry subordinate to the IANA
RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR RTCP Extended Reports (RTCP XR) Block Type Registry: the IDMS XR
Block SPST Registry. Block SPST Registry.
Initial values for the IDMS XR Block SPST Registry are given below; Initial values for the IDMS XR Block SPST Registry are given below;
future assignments are to be made through the Specification Required future assignments are to be made through the Specification Required
policy [RFC5226]. policy [RFC5226]. The registry is limited to 16 entries (numbered
0-15), with 0 being Reserved. Values 5-15 are available for
assignment.
In accordance with [RFC5226], a Designated Expert will review any
applications made to IANA for the registry. Primary criteria for the
Designated Expert to use when reviewing new applications are clarity
of the specification and, due to the relative small value range of
SPST values available, potential overlap in functionality with
existing SPST registrations.
Value Name Reference Value Name Reference
----- ---- --------- ----- ---- ---------
1 Synchronization Client section 7 1 Synchronization Client section 7
2 MSAS [TS183063]
3 SC Prime Input [TS183063]
4 SC Prime Output [TS183063]
14.5. Contact Information for Registrations 14.5. Contact Information for Registrations
The contact information for the registrations is: The contact information for the registrations is:
Ray van Brandenburg (ray.vanbrandenburg@tno.nl) Ray van Brandenburg (ray.vanbrandenburg@tno.nl)
Brassersplein 2 Brassersplein 2
2612CT, Delft, The Netherlands 2612CT, Delft, The Netherlands
skipping to change at page 20, line 47 skipping to change at page 21, line 41
Specifications, RFC5905", February 2010. Specifications, RFC5905", February 2010.
16.2. Informative References 16.2. Informative References
[Boronat2009] [Boronat2009]
Boronat, F., Lloret, J., and M. Garcia, "Multimedia group Boronat, F., Lloret, J., and M. Garcia, "Multimedia group
and inter-stream synchronization techniques: a comparative and inter-stream synchronization techniques: a comparative
study, Elsevier Information Systems 34 (2009), pp. study, Elsevier Information Systems 34 (2009), pp.
108-131", 2009. 108-131", 2009.
[I-D.draft-ietf-avtcore-rtp-security-options]
Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", July 2013.
[I-D.draft-ietf-leap-seconds] [I-D.draft-ietf-leap-seconds]
Gross, K. and R. Brandenburg, van, "RTP and Leap Seconds, Gross, K. and R. Brandenburg, van, "RTP and Leap Seconds,
draft-ietf-avtcore-leap-second-02", October 2012. draft-ietf-avtcore-leap-second-02", October 2012.
[IEEE-1588] [IEEE-1588]
, "1588-2008 - IEEE Standard for a Precision Clock , "1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", 2008. Control Systems", 2008.
[Ishibashi2006] [Ishibashi2006]
Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective Ishibashi, Y., Nagasaka, M., and N. Fujiyoshi, "Subjective
Assessment of Fairness among users in multipoint Assessment of Fairness among users in multipoint
communications, Proceedings of the 2006 ACM SIGCHI communications, Proceedings of the 2006 ACM SIGCHI
internation conference on Advances in computer internation conference on Advances in computer
entertainment technology, 2006", . entertainment technology, 2006", .
[RFC3711] Baughner, M., McGrew, D., Naslund, M., Carrara, E., and K.
Normann, "The Secure Real-time Transport Protocol (SRTP)",
March 2004.
[RFC5868] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5868] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP), RFC5968", September 2010. Control Protocol (RTCP), RFC5968", September 2010.
[TS183063] [TS183063]
, "IMS-based IPTV stage 3 specification, TS 183 063 , "IMS-based IPTV stage 3 specification, TS 183 063
v3.5.2", March 2011. v3.5.2", March 2011.
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
 End of changes. 35 change blocks. 
70 lines changed or deleted 113 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/