draft-ietf-avtcore-idms-11.txt   draft-ietf-avtcore-idms-12.txt 
AVTCore R. van Brandenburg AVTCore R. van Brandenburg
Internet-Draft H. Stokking Internet-Draft H. Stokking
Intended status: Standards Track O. van Deventer Intended status: Standards Track O. van Deventer
Expires: December 16, 2013 TNO Expires: January 30, 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
June 14, 2013 July 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-11 draft-ietf-avtcore-idms-12
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 December 16, 2013. This Internet-Draft will expire on January 30, 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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 3 2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 3
2.2. IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . . 4 2.2. IDMS and ETSI . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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) . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . 14
12. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . 15 12.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . 15
12.2. Declarative cases . . . . . . . . . . . . . . . . . . . 16 12.2. Declarative cases . . . . . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . 18
14.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 18 14.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . 19
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
For this functionality to work correctly, it is necessary that the For this functionality to work correctly, it is necessary that the
wall clocks of the receivers are synchronized with each other. Alice wall clocks of the receivers are synchronized with each other. Alice
and Bob both report when they receive, and optionally when they play and Bob both report when they receive, and optionally when they play
out, certain RTP packets. In order to correlate their reports to out, certain RTP packets. In order to correlate their reports to
each other, it is necessary that their wallclocks are synchronized. each other, it is necessary that their wallclocks are synchronized.
6. Architecture for Inter-Destination Media Synchronization 6. Architecture for Inter-Destination Media Synchronization
The architecture for IDMS, which is based on a sync-maestro The architecture for IDMS, which is based on a sync-maestro
architecture [Boronat2009], is sketched below. The Synchronization architecture [Boronat2009], is sketched below. In this particular
Client (SC) and Media Synchronization Application Server (MSAS) case, the Synchronization Client (SC) and Media Synchronization
entities are shown as additional functionality for the RTP receiver Application Server (MSAS) entities are shown as additional
and sender respectively. functionality for the RTP receiver and sender respectively.
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
this case the MSAS functionality is thus embedded in an RTP receiver
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 | |
skipping to change at page 7, line 45 skipping to change at page 7, line 40
| | | | -----> | | | | | | | | -----> | | | |
| +-----------------+ | | +-----------------+ | | +-----------------+ | | +-----------------+ |
| | | | | | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
IDMS Architecture Diagram IDMS Architecture Diagram
6.1. Media Synchronization Application Server (MSAS) 6.1. Media Synchronization Application Server (MSAS)
An MSAS collects RTP packet arrival times and playout times from one An MSAS collects RTP packet arrival times and playout times from one
or more SC(s) in a synchronization group. The MSAS summarizes and or more SC(s) in a synchronization group by receiving RTCP IDMS XR
distributes this information to the SCs in the synchronization group Reports. The MSAS summarizes and distributes this information to the
as synchronization settings, e.g. by determining the SC with the most SCs in the synchronization group as synchronization settings via the
RTCP IDMS Settings messages, e.g. by determining the SC with the most
lagged playout and using its reported RTP packet arrival time and lagged playout and using its reported RTP packet arrival time and
playout time as a summary. playout time as a summary.
It should be noted that while the figure above shows the MSAS as part
of the RTP Sender, this is not necessary. For example, an MSAS might
also be implemented as an independent function in the network or in a
master/slave type of architecture where one of the SC devices also
acts as an MSAS. Wherever the MSAS is implemented, it is important
that the MSAS has access to the RTP stream to which the XR Reports
apply, so that it is able to correlate the IDMS XR Reports coming
from different SCs.
6.2. Synchronization Client (SC) 6.2. Synchronization Client (SC)
An SC reports on RTP packet arrival times and playout times of a An SC reports on RTP packet arrival times and playout times of a
media stream. It can receive summaries of such information, and use media stream. It can receive summaries of such information, and use
that to adjust its playout buffer. that to adjust its playout buffer. The SC sends RTCP IDMS XR Reports
to the MSAS.
6.3. Communication between MSAS and SCs 6.3. Communication between MSAS and SCs
Two different message types are used for the communication between Two different message types are used for the communication between
MSAS and SCs. For the SC->MSAS message containing the playout MSAS and SCs. For the SC->MSAS message containing the playout
information of a particular client, an RTCP XR IDMS Report Block is information of a particular client, an RTCP XR IDMS Report Block is
used (see Section 7). For the MSAS->SC message containing the used (see Section 7). For the MSAS->SC message containing the
synchronization settings instructions, a new RTCP IDMS Settings synchronization settings instructions, a new RTCP IDMS Settings
Packet Type is defined (see Section 8). Packet Type is defined (see Section 8).
skipping to change at page 11, line 12 skipping to change at page 11, line 21
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 this field is empty, then it SHALL be set to 0 and
the Packet Presented NTP timestamp flag (P) SHALL be set to 0. the Packet Presented NTP timestamp flag (P) SHALL be set to 0. With
Presented here means the moment the data is played out to the user of regards to NTP epoch and rollover, the value of the Packet Presented
the system, i.e. sound played out through speakers, video images NTP timestamp is considered to always be greater than the Packet
being displayed on some display, etc. The accuracy resulting from Received NTP Timestamp and to be within 2^16 seconds of it.
the synchronization algorithm will only be as good as the accuracy Presented in this context means the moment the data is played out to
with which the SCs can determine the delay between receiving packets the user of the system, i.e. sound played out through speakers, video
and presenting them to the end-user. images being displayed on some display, etc. The accuracy resulting
from the synchronization algorithm will only be as good as the
accuracy with 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 15, line 12 skipping to change at page 15, line 25
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 ; Numerical value from 0 through 4294967294 SyncGroupId = 1*10DIGIT ; Decimal value from 0 through 4294967294
DIGIT = %x30-39 DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer and represented in decimal. SyncGroupId is a 32-bit unsigned integer and represented in decimal.
SyncGroupId identifies a group of SCs for IDMS. The value SyncGroupId identifies a group of SCs for IDMS. The value
SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295 SyncGroupId=0 represents an empty SyncGroupId. The value 4294967295
(2^32-1) is reserved for future use. For a description on the value (2^32-1) is reserved for future use. For a description on the value
of SyncGroupId to include, see Section 12. of SyncGroupId to include, see Section 12.
The following is an example of the SDP attribute for IDMS. The following is an example of the SDP attribute for IDMS.
 End of changes. 14 change blocks. 
28 lines changed or deleted 38 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/