draft-ietf-avtcore-idms-03.txt   draft-ietf-avtcore-idms-04.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: September 10, 2012 TNO Expires: November 23, 2012 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
March 9, 2012 May 22, 2012
RTCP for inter-destination media synchronization RTCP for inter-destination media synchronization
draft-ietf-avtcore-idms-03 draft-ietf-avtcore-idms-04
Abstract Abstract
This document gives information on an RTCP Packet Type and RTCP XR This document gives information on an RTCP Packet Type and RTCP XR
Block Type including associated SDP parameters for Inter-Destination Block Type including associated SDP parameters for Inter-Destination
Media Synchronization (IDMS). The RTCP XR Block Type, registered Media Synchronization (IDMS). The RTCP XR Block Type, registered
with IANA based on an ETSI specification, is used to collect media with IANA based on an ETSI specification, 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. The RTCP (watching, listening, etc.) a specific RTP media stream. The RTCP
packet type specified by this document is used to distribute a common packet type specified by this document is used to distribute a common
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 September 6, 2012. This Internet-Draft will expire on November 23, 2012.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Inter-destination Media Synchronization . . . . . . . . . 4 1.1. Inter-Destination Media Synchronization . . . . . . . . . 4
1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4 1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4
1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 5 1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 5
1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . 5 1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 5 3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 5
4. Inter-destination media synchronization use cases . . . . . . 7 4. Inter-Destination Media Synchronization use cases . . . . . . 7
5. Architecture for inter-destination media synchronization . . . 8 5. Architecture for Inter-Destination Media Synchronization . . . 8
5.1. Media Synchronization Application Server (MSAS) . . . . . 8 5.1. Media Synchronization Application Server (MSAS) . . . . . 8
5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 9 5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 9
5.3. Communication between MSAS and SCs . . . . . . . . . . . . 9 5.3. Communication between MSAS and SCs . . . . . . . . . . . . 9
6. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9 6. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9
7. RTCP Packet Type for IDMS (IDMS report) . . . . . . . . . . . 11 7. RTCP Packet Type for IDMS (IDMS report) . . . . . . . . . . . 11
8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13 8. Timing and NTP Considerations . . . . . . . . . . . . . . . . 13
8.1. Leap Seconds . . . . . . . . . . . . . . . . . . . . . . . 14
9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 14 9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 14
10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 15 10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 15
11. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 16 11. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 15
12. On the use of presentation timestamps . . . . . . . . . . . . 16 12. On the use of presentation timestamps . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
16. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 16. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . . 19 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . . 19 17.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
1.1. Inter-Destination Media Synchronization 1.1. Inter-Destination Media Synchronization
Inter-Destination Media Synchronization (IDMS) refers to the 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 (subtitles).[Ishibashi2006] and [Boronat2009] provide an overview of
of technologies and 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 among participants in an IDMS session. It may also playout times among participants in an IDMS session. It may also
require signaling for the initiation and maintenance of IDMS sessions require signaling for the initiation and maintenance of IDMS sessions
and groups of receivers. and groups of receivers.
The presented RTCP specification for IDMS is independent of the used The presented RTCP specification for IDMS is independent of the used
synchronization algorithm, which is out-of-scope of this document. synchronization algorithm, which is out-of-scope of this document.
1.2. Applicability of RTCP to IDMS 1.2. Applicability of RTCP to IDMS
Currently, most multimedia applications make use of RTP and RTCP Currently, a large share of real-time applications make use of RTP
[RFC3550]. RTP provides end-to-end network transport functions and RTCP [RFC3550]. RTP provides end-to-end network transport
suitable for applications requiring real-time data transport, such as functions suitable for applications requiring real-time data
audio, video or data, over multicast or unicast network services. transport, such as audio, video or data, over multicast or unicast
The timestamps, sequence numbers, and payload (content) type network services. The timestamps, sequence numbers, and payload
identification mechanisms provided by RTP packets are very useful for (content) type identification mechanisms provided by RTP packets are
reconstructing the original media timing, and for reordering and very useful for reconstructing the original media timing, and for
detecting packet loss at the client side. reordering and detecting packet loss at the client side.
The data transport is augmented by a control protocol (RTCP) to allow The data transport is augmented by a control protocol (RTCP) to allow
monitoring of the data delivery in a manner that is scalable to large monitoring of the data delivery in a manner that is scalable to large
multicast networks, and to provide minimal control and identification multicast networks, and to provide minimal control and identification
functionality. functionality. RTP receivers and senders provide reception quality
feedback by sending out RTCP Receiver Report (RR) and Sender Report
RTP receivers and senders provide reception quality feedback by (SR) packets [RFC3550], respectively, which may be augmented by
sending out RTCP Receiver Report (RR) and Sender Report (SR) packets eXtended Reports (XR) [RFC3611]. Both RTP and RTCP are intended to
[RFC3550], respectively, which may be augmented by eXtended Reports be tailored through modifications in order to include profile-
(XR) [RFC3611]. Thus, the feedback reporting features provided by specific information required by particular applications, and the
RTCP make QoS monitoring possible and can be used for troubleshooting guidelines on doing so are specified in [RFC5868].
and fault tolerance management in multicast distribution services
such as IPTV.
These protocols are intended to be tailored through modifications and
additions in order to include profile-specific information required
by particular applications, and the guidelines 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.
1.3. Applicability of SDP to IDMS 1.3. Applicability of SDP to IDMS
skipping to change at page 6, line 5 skipping to change at page 6, line 5
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Overview of IDMS operation 3. Overview of IDMS operation
This section provides a brief example of how the 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,Sync-group ID) |
|------------------------------------------------->| |------------------------------------------------->|
| | Media Session Set-up | | | Media Session Set-up |
| |<========================>| | |<========================>|
| | | | | |
| Call set-up | | Call set-up |
|<================================================>| |<================================================>|
| | | | | |
| RTP Packet | RTP Packet | | RTP Packet | RTP Packet |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| RR + IDMS XR | | | RR + IDMS XR | |
|---------------------->| RR + IDMS XR | |---------------------->| RR + IDMS XR |
| |<-------------------------| | |<-------------------------|
| RTCP IDMS packet | RTCP IDMS packet | | RTCP IDMS packet | RTCP IDMS packet |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| | | | | |
Alice is watching TV in her living room. At some point she sees that Alice is watching TV in her living room. At some point she sees that
a football game of Bob's favorite team is on. She sends him an a football game of Bob's favorite team is on. She sends him an
invite to watch the program together. Embedded in the invitation is invite to watch the program together. Embedded in the invitation is
the link to the media server and a unique sync-group identifier. the link to the media server and a unique sync-group identifier.
Bob, who is also at home, receives the invite on his laptop. He Bob, who is also at home, receives the invite on his laptop. He
accepts Alice's invitation and the RTP client on his laptop sets up a accepts Alice's invitation and the RTP client on his laptop sets up a
session to the media server. A VoIP connection to Alice's TV is also session to the media server. A VoIP connection to Alice's TV is also
set up, so that Alice and Bob can talk while watching the game set up, so that Alice and Bob can talk while watching the game
skipping to change at page 7, line 52 skipping to change at page 8, line 4
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.
A third usage scenario is that of the networked loudspeakers, in A third usage scenario is that of the networked loudspeakers, in
which two or more speakers are connected to the network individually. which two or more speakers are connected to the network individually.
Such situations can for example be found in large conference rooms,
Such situations can for example be found in large conference rooms,
legislative chambers, classrooms (especially those supporting legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as distance learning) and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in audio stadiums. Since humans are more susceptible to differences in audio
delay, this use case needs even more accuracy than the video wall use delay, this use case needs even more accuracy than the video wall use
case. Depending on the exact application, the need for accuracy can case. Depending on the exact application, the need for accuracy can
then be in the range of microseconds. then be in the range of microseconds.
5. Architecture for Inter-Destination Media Synchronization 5. Architecture for Inter-Destination Media Synchronization
The architecture for IDMS, which is based on a sync-maestro The architecture for IDMS, which is based on a sync-maestro
skipping to change at page 9, line 14 skipping to change at page 9, line 14
5.2. Synchronization Client (SC) 5.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.
5.3. Communication between MSAS and SCs 5.3. Communication between MSAS and SCs
Two different message types are used for the communication between Two different message types are used for the communication between
MSAS and SCs. For the SC->MSAS message containing the playout MSAS and SCs. For the SC->MSAS message containing the play-out
information of a particular client, an RTCP XR Block Type is used information of a particular client, an RTCP XR Block Type is used
(see Section 6). For the MSAS->SC message containing the (see Section 6). For the MSAS->SC message containing the
synchronization settings instructions, a new RTCP Packet Type is synchronization settings instructions, a new RTCP Packet Type is
defined (see Section 7). defined (see Section 7).
6. RTCP XR Block Type for IDMS 6. RTCP XR Block Type for IDMS
This section describes the RTCP XR Block Type for reporting IDMS This section describes the RTCP XR Block Type for reporting IDMS
information on an RTP media stream. Its definition is based on information on an RTP media stream. Its definition is based on
[RFC3611]. The RTCP XR is used to provide feedback information on [RFC3611]. The RTCP XR is used to provide feedback information on
receipt times and presentation times of RTP packets to e.g. a Sender receipt times and presentation times of RTP packets to e.g. a Sender
[RFC3611], a Feedback Target [RFC5576] or a Third Party Monitor [RFC3611], a Feedback Target [RFC5760] or a Third Party Monitor
[RFC3611]. [RFC3611].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| Resrv | PT=XR=207 | length | |V=2|P| Resrv | PT=XR=207 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| BT=12 | SPST |Resrv|P| block length=7 | | BT=12 | SPST |Resrv|P| block length=7 |
skipping to change at page 13, line 11 skipping to change at page 13, line 13
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 8 on the NTP timestamp format as specified in [RFC5905]. See Section 8
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 relates. This SHOULD relate to the first packet to which the XR 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 data contained in the first octet of the associated RTP packet to the data contained in the first octet of the associated RTP packet to
the user. The timestamp is formatted based on the NTP timestamp the user. The timestamp is formatted based on the NTP timestamp
format as specified in [RFC5905]. If this field is empty, then it format as specified in [RFC5905]. If this field is empty, then it
SHALL be set to 0. This field MAY be left empty if none or only one SHALL be set to 0. This field MAY be left empty if none or only one
of the receivers reported on presentated timestamps. Presented here of the receivers reported on presentation timestamps. Presented here
means the moment the data is played out to the user of the system. means the moment the data is played out to the user of the system.
In some use cases (e.g. phased array transducers), the level of In some use cases (e.g. phased array transducers), the level of
control 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.
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
skipping to change at page 14, line 24 skipping to change at page 14, line 27
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, because this may be a synchronization method for the system clock, because this may be a
system-wide setting which the application cannot change. How system-wide setting which the application cannot change. How
applications deal with this is up to the implementation. The applications deal with this is up to the implementation. The
application might control the system clock, or it might use a application might control the system clock, or it might use a
separate application clock or even a separate IDMS session clock. It separate application clock or even a separate IDMS session clock. It
might also report on the system clock and the synchronization method might also report on the system clock and the synchronization method
used, without being able to change it. used, without being able to change it.
[I-D.draft-williams-avtcore-clksrc] also presents some general [I-D.draft-gross-leap-second] presents some guidelines on how RTP
guidelines on dealing with leap seconds within an RTP context. When senders and receivers should deal with leap seconds. When relying on
relying on NTP for clock synchronization, IDMS is particularly NTP for clock synchronization, IDMS is particularly sensitive to leap
sensitive to leap second induced timing discrepancies. second induced timing discrepancies. It is therefore recommended to
9. SDP Parameter for RTCP XR IDMS Block Type take the guideline specified in [I-D.draft-gross-leap-second] into
account when implementing IDMS.
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 IDMS. It is also used to carry an identifier of the block for IDMS. It is also used to carry an identifier of the
synchronization group to which clients belong or will belong. This synchronization group to which clients belong or will belong. This
SDP parameter extends rtcp-xr-attrib as follows, using Augmented SDP parameter extends rtcp-xr-attrib as follows, using Augmented
Backus-Naur Form [RFC5234]. Backus-Naur Form [RFC5234].
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
; Original definition from [RFC3611], section 5.1 ; Original definition from [RFC3611], section 5.1
skipping to change at page 14, line 45 skipping to change at page 15, line 4
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
; Original definition from [RFC3611], section 5.1 ; Original definition from [RFC3611], section 5.1
xr-format =/ grp-sync ; Extending xr-format for Inter-Destination xr-format =/ grp-sync ; Extending xr-format for Inter-Destination
Media Synchronization Media Synchronization
grp-sync = "grp-sync" [",sync-group=" SyncGroupId] grp-sync = "grp-sync" [",sync-group=" SyncGroupId]
SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295
DIGIT = %x30-39 DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer represented in decimal. SyncGroupId is a 32-bit unsigned integer represented in decimal.
SyncGroupId identifies a group of SCs for IDMS. It maps on the Media SyncGroupId identifies a group of SCs for IDMS. It maps on the Media
Stream Correlation Identifier as described in sections 6 and 7. The Stream Correlation Identifier as described in Section 6 and
value SyncGroupId=0 represents an empty SyncGroupId. The value Section 7. The value SyncGroupId=0 represents an empty SyncGroupId.
4294967295 (2^32-1) is reserved for future use. The value 4294967295 (2^32-1) is reserved for future use.
The following is an example of the SDP attribute for IDMS The following is an example of the SDP attribute for IDMS
a=rtcp-xr:grp-sync,sync-group=42 a=rtcp-xr:grp-sync,sync-group=42
10. SDP Parameter for RTCP IDMS Packet Type 10. SDP Parameter for RTCP IDMS Packet Type
The SDP parameter rtcp-idms is used to signal the use of the RTCP The SDP parameter rtcp-idms is used to signal the use of the RTCP
IDMS Packet Type for IDMS. It is also used to carry an identifier IDMS Packet Type for IDMS. It is also used to carry an identifier of
for the synchronization group to which clients belong or will belong. the synchronization group to which clients belong or will belong.
The SDP parameter is used as a media-level attribute during session The SDP parameter is used as a media-level attribute during session
setup. This SDP parameter is defined as follows, using Augmented setup. This SDP parameter is defined as follows, using Augmented
Backus-Naur Form [RFC5234]. Backus-Naur Form [RFC5234].
rtcp-idms = "a=" "rtcp-idms" ":" [sync-grp] CRLF rtcp-idms = "a=" "rtcp-idms" ":" [sync-grp] CRLF
sync-grp = "sync-group=" SyncGroupId sync-grp = "sync-group=" SyncGroupId
SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295 SyncGroupId = 1*DIGIT ; Numerical value from 0 till 4294967295
skipping to change at page 16, line 26 skipping to change at page 16, line 34
12. On the use of presentation timestamps 12. On the use of presentation timestamps
A receiver can report on different timing events, i.e. on packet A receiver can report on different timing events, i.e. on packet
arrival times and on playout times. A receiver SHALL report on arrival times and on playout times. A receiver SHALL report on
arrival times and a receiver MAY report on playout times. RTP packet arrival times and a receiver MAY report on playout times. RTP packet
arrival times are relatively easy to report on. Normally, the arrival times are relatively easy to report on. Normally, the
processing and playout of the same media stream by different processing and playout of the same media stream by different
receivers will take roughly the same amount of time. It can suffice receivers will take roughly the same amount of time. It can suffice
for many applications, such as social TV, to synchronize on packet for many applications, such as social TV, to synchronize on packet
arrival times. Also, if the receivers are in some way controlled, arrival times. Also, if the receivers are in some way controlled,
e.g. having the same buffer settings and decoding times, high e.g. having the same buffer settings and decoding times, high
accuracy can be achieved. However, if all receivers in a accuracy can be achieved. However, if all receivers in a
synchronization session have the ability to report on, and thus synchronization session have the ability to report on, and thus
synchronize on packet presented times, this may be more accurate. It synchronize on packet presented times, this may be more accurate. It
is up to applications and implementations of this RTCP extension is up to applications and implementations of this RTCP extension
whether to implement and use this. whether to implement and use this.
13. Security Considerations 13. Security Considerations
The specified RTCP XR Block Type in this document is used to collect, The specified RTCP XR Block Type in this document is used to collect,
skipping to change at page 19, line 32 skipping to change at page 19, line 15
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR), "RTP Control Protocol Extended Reports (RTCP XR),
RFC3611", November 2003. RFC3611", November 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol, RFC4566", July 2006. Description Protocol, RFC4566", July 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications, RFC5234", January 2008. Specifications, RFC5234", January 2008.
[RFC5576] Lenox, J., Ott, J., and T. Schierl, "Source-Specific Media
Atrributes in the Session Description Protocol, RFC5576",
June 2009.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback, RFC5760", February 2010. Sessions with Unicast Feedback, RFC5760", February 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specifications, RFC5905", February 2010. Specifications, RFC5905", February 2010.
[TS183063] [TS183063]
"IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1", "IMS-based IPTV stage 3 specification, TS 183 063 v3.4.1",
June 2010. June 2010.
17.2. Informative References 17.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. 108- study, Elsevier Information Systems 34 (2009), pp. 108-
131". 131".
[I-D.draft-gross-leap-second]
Gross, K. and R. Brandenburg, van, "RTP and Leap Seconds,
draft-gross-leap-seconds-01".
[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".
[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.
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
TNO TNO
skipping to change at page 21, line 4 skipping to change at page 20, line 30
the Netherlands the Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: hans.stokking@tno.nl Email: hans.stokking@tno.nl
M. Oskar van Deventer M. Oskar van Deventer
TNO TNO
Brassersplein 2 Brassersplein 2
Delft 2612CT Delft 2612CT
the Netherlands the Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: oskar.vandeventer@tno.nl Email: oskar.vandeventer@tno.nl
Fernando Boronat Fernando Boronat
Universidad Politecnica de Valencia Universitat Politecnica de Valencia
IGIC Institute, Universitat Politecnica de Valencia-Campus IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia, C/ Paraninfo, 1, Grao de Gandia
de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia
Valencia 46730 Valencia 46730
Spain 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
Universidad Politecnica de Valencia Universitat Politecnica de Valencia
IGIC Institute, Universitat Politecnica de Valencia-Campus IGIC Institute, Universitat Politecnica de Valencia-Campus de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia, C/ Paraninfo, 1, Grao de Gandia
de Gandia (UPV), C/ Paraninfo, 1, Grao de Gandia
Valencia 46730 Valencia 46730
Spain Spain
Phone: +34 962 849 341 Phone: +34 962 849 341
Email: mamontor@posgrado.upv.es Email: mamontor@posgrado.upv.es
Kevin Gross Kevin Gross
AVA Networks AVA Networks
Phone: +1-303-447-0517 Phone: +1-303-447-0517
 End of changes. 35 change blocks. 
89 lines changed or deleted 82 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/