draft-ietf-avtcore-idms-06.txt   draft-ietf-avtcore-idms-07.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 17, 2013 TNO Expires: April 14, 2013 TNO
F. Boronat F. Boronat
M. Montagud M. Montagud
Universitat Politecnica de Universitat Politecnica de
Valencia Valencia
K. Gross K. Gross
AVA Networks AVA Networks
July 16, 2012 October 11, 2012
Inter-destination Media Synchronization using the RTP Control Protocol Inter-destination Media Synchronization using the RTP Control Protocol
(RTCP) (RTCP)
draft-ietf-avtcore-idms-06 draft-ietf-avtcore-idms-07
Abstract Abstract
This document gives information on an RTP Control Protocol (RTCP) This document gives information on an RTP Control Protocol (RTCP)
Packet Type and RTCP Extended Report (XR) Block Type including Packet Type and RTCP Extended Report (XR) Block Type including
associated Session Description Protocol (SDP) parameters for Inter- associated Session Description Protocol (SDP) parameters for Inter-
Destination Media Synchronization (IDMS). This document mandates the Destination Media Synchronization (IDMS). This document mandates the
use of the RTCP XR Block Type 12, which is used to collect media use of the RTCP XR Block Type 12, which is used to collect media
playout information from participants in a group playing out playout information from participants in a group playing out
(watching, listening, etc.) a specific RTP media stream. This RTCP (watching, listening, etc.) a specific RTP media stream. This RTCP
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 17, 2013. This Internet-Draft will expire on April 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
7. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9 7. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9
8. RTCP Packet Type for IDMS (IDMS Settings) . . . . . . . . . . 12 8. RTCP Packet Type for IDMS (IDMS Settings) . . . . . . . . . . 12
9. Timing and NTP Considerations . . . . . . . . . . . . . . . . 14 9. Timing and NTP Considerations . . . . . . . . . . . . . . . . 14
10. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 15 10. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 15
11. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 16 11. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 16
12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 17 12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 17
13. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . . 17 13.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . . 17
13.2. Declarative cases . . . . . . . . . . . . . . . . . . . . 19 13.2. Declarative cases . . . . . . . . . . . . . . . . . . . . 19
14. On the use of presentation timestamps . . . . . . . . . . . . 19 14. On the use of presentation timestamps . . . . . . . . . . . . 19
15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 15. Security Considerations . . . . . . . . . . . . . . . . . . . 20
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.1. Normative References . . . . . . . . . . . . . . . . . . . 21 18.1. Normative References . . . . . . . . . . . . . . . . . . . 21
18.2. Informative References . . . . . . . . . . . . . . . . . . 22 18.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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
skipping to change at page 9, line 5 skipping to change at page 8, line 50
| | Synchronization | | | | Media | | | | Synchronization | | | | Media | |
| | Client | | | | Synchronization | | | | Client | | | | Synchronization | |
| | (SC) | | | | Application | | | | (SC) | | | | Application | |
| | | | | | Server | | | | | | | | Server | |
| | | | RR+XR | | (MSAS) | | | | | | RR+XR | | (MSAS) | |
| | | | -----> | | | | | | | | -----> | | | |
| +-----------------+ | | +-----------------+ | | +-----------------+ | | +-----------------+ |
| | | | | | | |
+-----------------------+ +-----------------------+ +-----------------------+ +-----------------------+
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. The MSAS summarizes and
distributes this information to the SCs in the synchronization group distributes this information to the SCs in the synchronization group
as synchronization settings, e.g. by determining the SC with the most as synchronization settings, e.g. by determining the SC with the most
lagged 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.
6.2. Synchronization Client (SC) 6.2. Synchronization Client (SC)
skipping to change at page 10, line 9 skipping to change at page 10, line 9
even further cases, a receiver may wish to synchronize different RTP even further cases, a receiver may wish to synchronize different RTP
streams at the same time, either as part of the same synchronization streams at the same time, either as part of the same synchronization
group or as part of multiple synchronization groups. These are all group or as part of multiple synchronization groups. These are all
valid scenario's for IDMS, and will require multiple reports by an valid scenario's for IDMS, and will require multiple reports by an
SC. SC.
SCs SHOULD report on a recently received RTP packets. This document SCs SHOULD report on a recently received RTP packets. This document
does not define new rules on when to sent RTCP reports, but uses the does not define new rules on when to sent RTCP reports, but uses the
existing rules specified in [RFC3550] for sending RTCP reports. When existing rules specified in [RFC3550] for sending RTCP reports. When
the RTCP reporting timer allows an SC to send an IDMS report, the SC the RTCP reporting timer allows an SC to send an IDMS report, the SC
SHOULD report on the latest RTP packet received or played out SHOULD report on an RTP packet received during the period since the
(depending on whether the SC reports on presentation timestamps or last IDMS XR Report Block was sent. For more details on which packet
receipt timestamps). For more details on which packet to report on, to report on, see below under 'Packet Received RTP timestamp'.
see below under 'Packet Received RTP timestamp'.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Resrv | PT=XR=207 | length | |V=2|P| Resrv | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| BT=12 | SPST |Resrv|P| block length=7 | | BT=12 | SPST |Resrv|P| block length=7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 12 skipping to change at page 11, line 12
identifies the role of the packet sender for this specific eXtended identifies the role of the packet sender for this specific eXtended
Report. It can have the following values: Report. It can have the following values:
SPST=0 Reserved For future use. SPST=0 Reserved For future use.
SPST=1 The packet sender is an SC. It uses this XR to report SPST=1 The packet sender is an SC. It uses this XR to report
synchronization status information. Timestamps relate to the SC synchronization status information. Timestamps relate to the SC
input. input.
SPST=2 This setting is reserved in order to preserve compatibility SPST=2 This setting is reserved in order to preserve compatibility
with ETSI TISPAN [TS183063]. See Section 12 for more information. with ETSI TISPAN [TS183063] and is used when the packet sender is
an MSAS (see Section 12 for when to use this SPST).
SPST=3-15 Reserved For future use. SPST=3-4 These settings are reserved in order to preserve
compatibility with ETSI TISPAN [TS183063].
SPST=5-15 Reserved for future use.
Reserved bits (Resrv): 3 bits. These bits are reserved for future Reserved bits (Resrv): 3 bits. These bits are reserved for future
definition. In the absence of such a definition, the bits in this definition. In the absence of such a definition, the bits in this
field MUST be set to zero and MUST be ignored by the receiver. field MUST be set to zero and MUST be ignored by the receiver.
Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the Packet Presented NTP timestamp flag (P): 1 bit. Bit set to 1 if the
Packet Presented NTP timestamp field contains a value, 0 if it is Packet Presented NTP timestamp field contains a value, 0 if it is
empty. If this flag is set to zero, then the Packet Presented NTP empty. If this flag is set to zero, then the Packet Presented NTP
timestamp SHALL be ignored. timestamp SHALL be ignored.
skipping to change at page 11, line 44 skipping to change at page 11, line 48
MSAS to relate reports from different SCs on different RTP timestamp MSAS to relate reports from different SCs on different RTP timestamp
values. values.
Reserved bits (Resrv): 25 bits. These bits are reserved for future Reserved bits (Resrv): 25 bits. These bits are reserved for future
use and SHALL be set to 0. use and SHALL be set to 0.
Media Stream Correlation Identifier: 32 bits. This identifier is Media Stream Correlation Identifier: 32 bits. This identifier is
used to correlate synchronized media streams. The value 0 (all bits used to correlate synchronized media streams. The value 0 (all bits
are set "0") indicates that this field is empty. The value 2^32-1 are set "0") indicates that this field is empty. The value 2^32-1
(all bits are set "1") is reserved for future use. If the RTCP (all bits are set "1") is reserved for future use. If the RTCP
Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then the Media Packet Sender is an SC (SPST=1), then the Media Stream Correlation
Stream Correlation Identifier field contains the Synchronization Identifier field contains the Synchronization Group Identifier
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 SHALL be set to the
value of the SSRC identifier carried in the RTP header [RFC3550] of value of the SSRC identifier carried in the RTP header [RFC3550] of
the RTP packet to which the XR relates. the RTP packet to which the XR relates.
Packet Received NTP timestamp: 64 bits. This timestamp reflects the Packet Received NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the moment of arrival of the first octet of the wall clock time at the moment of arrival of the first octet of the
RTP packet to which the XR relates. It is formatted based on the NTP RTP packet to which the XR relates. It is formatted based on the NTP
timestamp format as specified in [RFC5905]. See Section 9 for more timestamp format as specified in [RFC5905]. See Section 9 for more
information on how this field is used. information on how this field is used.
skipping to change at page 13, line 34 skipping to change at page 13, line 34
| Packet Presented NTP timestamp, least significant word | | Packet Presented NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first 64 bits form the header of the RTCP Packet Type, as defined The first 64 bits form the header of the RTCP Packet Type, as defined
in [RFC3550]. The SSRC of packet sender identifies the sender of the in [RFC3550]. The SSRC of packet sender identifies the sender of the
specific RTCP packet. specific RTCP packet.
The RTCP IDMS packet consists of 7 32-bit words, with the following The RTCP IDMS packet consists of 7 32-bit words, with the following
fields: fields:
PT: To be determined upon registration with IANA, inserted by the RFC
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 SHALL be set to the
value of the SSRC identifier of the media source carried in the RTP value of the SSRC identifier of the media source carried in the RTP
header [RFC3550] of the RTP packet to which the RTCP IDMS packet header [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
skipping to change at page 20, line 29 skipping to change at page 20, line 37
No new mechanisms are introduced in this document to ensure No new mechanisms are introduced in this document to ensure
confidentiality. Encryption procedures, such as those being confidentiality. Encryption procedures, such as those being
suggested for a Secure RTP (SRTP) at the time that this document was suggested for a Secure RTP (SRTP) at the time that this document was
written, can be used when confidentiality is a concern to end hosts. written, can be used when confidentiality is a concern to end hosts.
16. IANA Considerations 16. IANA Considerations
This document defines a new RTCP packet type called IDMS Settings This document defines a new RTCP packet type called IDMS Settings
packet in the IANA registry of RTP parameters, part of RTCP Control packet in the IANA registry of RTP parameters, part of RTCP Control
Packet types (PT), based on the specification in Section 11. Packet types (PT), based on the specification in Section 8.
Further, this document defines a new SDP parameter "rtcp-idms" within Further, this document defines a new SDP parameter "rtcp-idms" within
the existing IANA registry of SDP Parameters, part of the "att-field the existing IANA registry of SDP Parameters, part of the "att-field
(media level only)". (media level only)".
The SDP attribute "rtcp-idms" defined by this document is registered The SDP attribute "rtcp-idms" defined by this document is registered
with the IANA registry of SDP Parameters as follows: with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
 End of changes. 12 change blocks. 
15 lines changed or deleted 23 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/