draft-ietf-avtcore-idms-07.txt   draft-ietf-avtcore-idms-08.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: April 14, 2013 TNO Expires: July 21, 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
October 11, 2012 January 17, 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-07 draft-ietf-avtcore-idms-08
Abstract Abstract
This document gives information on an RTP Control Protocol (RTCP) This document defines a new RTP Control Protocol (RTCP) Packet Type
Packet Type and RTCP Extended Report (XR) Block Type including and RTCP Extended Report (XR) Block Type to be used for achieving
associated Session Description Protocol (SDP) parameters for Inter- Inter-Destination Media Synchronization (IDMS). IDMS is the process
Destination Media Synchronization (IDMS). This document mandates the of synchronizing playout across multiple geographically distributed
use of the RTCP XR Block Type 12, which is used to collect media media receivers. Using the RTCP XR IDMS Reporting Block defined in
playout information from participants in a group playing out this document, media playout information from participants in a
(watching, listening, etc.) a specific RTP media stream. This RTCP synchronization group can be collected. Based on the collected
XR Block Type is specified and registered with IANA by ETSI. The information, an RTCP IDMS Settings Packet can then be send to
RTCP packet type specified by this document is used to distribute a distribute a common target playout point to which all the distributed
common target playout point to which all the distributed receivers, receivers, sharing a media experience, can synchronize.
sharing a media experience, can synchronize.
Typical use cases in which IDMS is usefull are social TV, shared Typical use cases in which IDMS is usefull are social TV, shared
service control (i.e. applications where two or more geographically service control (i.e. applications where two or more geographically
separated users are watching a media stream together), distance separated users are watching a media stream together), distance
learning, networked video walls, networked loudspeakers, etc. learning, networked video walls, networked loudspeakers, etc.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 7 skipping to change at page 2, line 6
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 April 14, 2013. This Internet-Draft will expire on July 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4 2.1. Applicability of RTCP to IDMS . . . . . . . . . . . . . . 4
2.2. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 5
2.3. This document and ETSI TISPAN . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 5 4. Inter-Destination Media Synchronization use cases . . . . . . 5
5. Inter-Destination Media Synchronization use cases . . . . . . 7 5. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 6
6. Architecture for Inter-Destination Media Synchronization . . . 8 6. Architecture for Inter-Destination Media Synchronization . . . 7
6.1. Media Synchronization Application Server (MSAS) . . . . . 9 6.1. Media Synchronization Application Server (MSAS) . . . . . 8
6.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 9 6.2. Synchronization Client (SC) . . . . . . . . . . . . . . . 8
6.3. Communication between MSAS and SCs . . . . . . . . . . . . 9 6.3. Communication between MSAS and SCs . . . . . . . . . . . . 8
7. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . 9 7. RTCP XR Block for IDMS (IDMS Report Block) . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . 13
10. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . 15 10. On the use of presentation timestamps . . . . . . . . . . . . 15
11. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 16 11. SDP Signalling for RTCP IDMS Packet Type . . . . . . . . . . . 15
12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 17 12. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13. SDP rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . . 16
13.1. Offer/Answer rules . . . . . . . . . . . . . . . . . . . . 17 12.2. Declarative cases . . . . . . . . . . . . . . . . . . . . 17
13.2. Declarative cases . . . . . . . . . . . . . . . . . . . . 19 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14. On the use of presentation timestamps . . . . . . . . . . . . 19 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
15. Security Considerations . . . . . . . . . . . . . . . . . . . 20 14.1. RTCP IDMS Packet Type . . . . . . . . . . . . . . . . . . 18
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 14.2. RTCP XR IDMS Report Block . . . . . . . . . . . . . . . . 18
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.3. RTCP-IDMS SDP Attribute . . . . . . . . . . . . . . . . . 19
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.4. Contact Information for Registrations . . . . . . . . . . 19
18.1. Normative References . . . . . . . . . . . . . . . . . . . 21 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
18.2. Informative References . . . . . . . . . . . . . . . . . . 22 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 16.1. Normative References . . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . . 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
(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 5, line 6 skipping to change at page 5, line 6
specific information required by particular applications, and the specific information required by particular applications, and the
guidelines on doing so are specified in [RFC5868]. 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.
2.2. Applicability of SDP to IDMS
RTCP XR [RFC3611] defines the Extended Report (XR) packet type for
the RTP Control Protocol (RTCP), and defines how the use of XR
packets can be signaled by an application using the Session
Description Protocol (SDP) [RFC4566].
SDP signaling is used to set up and maintain a synchronization group
between Synchronization Clients (SCs). This document describes two
SDP parameters for doing this, one for the RTCP XR block type and one
for the new RTCP packet type.
2.3. This document and ETSI TISPAN
ETSI TISPAN [TS183063] has specified architecture and protocol for
IDMS using RTCP XR exchange and SDP signaling. For more information
on how this document relates to [TS183063], see Section 12.
This document mandates the use of an ETSI specified RTCP XR block for
the purpose of collecting RTP packet arrival and playout times. For
completeness, that XR block is contained in this document in section
7.
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] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
4. Overview of IDMS operation 4. Inter-Destination Media Synchronization use cases
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 is in no way meant to be exhaustive.
A first usage scenario for IDMS is Social TV. Social TV is the
combination of media content consumption by two or more users at
different devices and locations combined with the real-time
communication between those users. An example of Social TV is when
two or more users are watching the same television broadcast at
different devices and locations, while communicating with each other
using text, audio and/or video. A skew in their media playout
processes can have adverse effects on their experience. A well-known
use case here is one friend experiencing a goal in a football match
well before or after other friend(s).
Another potential use case for IDMS is a networked video wall. A
video wall consists of multiple computer monitors, video projectors,
or television sets tiled together contiguously or overlapped in order
to form one large screen. Each of the screens reproduces a portion
of the larger picture. In some implementations, each screen may be
individually connected to the network and receive its portion of the
overall image from a network-connected video server or video scaler.
Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
potentially faster. If the refresh is not synchronized, the effect
of multiple screens acting as one is broken.
A third usage scenario is that of the networked loudspeakers, in
which two or more speakers are connected to the network individually.
Such situations can for example be found in large conference rooms,
legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in audio
delay, this use case needs even more accuracy than the video wall use
case. Depending on the exact application, the need for accuracy can
then be in the range of microseconds.
5. 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 + XR IDMS Report | |
|---------------------->| RR + IDMS XR | |---------------------->| RR + XR IDMS Report |
| |<-------------------------| | |<-------------------------|
| RTCP IDMS packet | RTCP IDMS packet | | RTCP IDMS Settings | RTCP IDMS Settings |
|<----------------------|------------------------->| |<----------------------|------------------------->|
| | | | | |
Figure 1: Example of a typical IDMS session Figure 1: Example of a typical IDMS session
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
together. together.
As is common with RTP, both the RTP client in Alice's TV as well as As is common with RTP, both the RTP client in Alice's TV as well as
the one in Bob's laptop send periodic RTCP Receiver Reports (RR) to the one in Bob's laptop send periodic RTCP Receiver Reports (RR) to
the media server. However, in order to make sure Alice and Bob see the media server. However, in order to make sure Alice and Bob see
the events in the football game at (approximately) the same time, the events in the football game at (approximately) the same time,
their clients also periodically send an IDMS XR block to the sync their clients also periodically send an RTCP XR IDMS Report Block to
server function of the media server. Included in the XR blocks are the sync server function of the media server. Included in the XR
timestamps on when both Alice and Bob received (and, optionally, when blocks are timestamps on when both Alice and Bob received (and,
they played out) a particular RTP packet. optionally, when they played out) a particular RTP packet.
The sync server function in the media server calculates a reference The sync server function in the media server calculates a reference
client from the received IDMS XR blocks (e.g. by selecting whichever client from the received IDMS Report Blocks (e.g. by selecting
client received the packet the latest as the reference client). It whichever client received the packet the latest as the reference
then sends an RTCP IDMS packet containing the playout information of client). It then sends an RTCP IDMS Settings packet containing the
this reference client to the sync clients of both Alice and Bob. playout information of this reference client to the sync clients of
both Alice and Bob.
In this case Bob's connection has the longest delay and the reference In this case Bob's connection has the longest delay and the reference
client therefore includes a delay similar to the one experienced by client therefore includes a delay similar to the one experienced by
Bob. Upon reception of this information, Alice's RTP client can Bob. Upon reception of this information, Alice's RTP client can
choose what to do with this information. In this case it decreases choose what to do with this information. In this case it decreases
its playout rate temporarily until the playout time matches with the its playout rate temporarily until the playout time matches with the
reference client playout (and thus matches Bob's playout). Another reference client playout (and thus matches Bob's playout). Another
option for Alice's TV would be to simply pause playback until it option for Alice's TV would be to simply pause playback until it
catches up. The exact implementation of the synchronization catches up. The exact implementation of the synchronization
algorithm is up to the client. algorithm is up to the client.
Upon reception of the reference client RTCP IDMS packet, Bob's client Upon reception of the reference client RTCP IDMS Settings packet,
does not have to do anything since it is already synchronized to the Bob's client does not have to do anything since it is already
reference client (since it is based on Bob's delay). Note that other synchronized to the reference client (since it is based on Bob's
synchronization algorithms may introduce even more delay than the one delay). Note that other synchronization algorithms may introduce
experienced by the most delayed client, e.g. to account for delay even more delay than the one experienced by the most delayed client,
variations, for new clients joining an existing synchronization e.g. to account for delay variations, for new clients joining an
group, etc. existing synchronization group, etc.
For this functionality to work correctly, it is nessecary that the For this functionality to work correctly, it is nessecary 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.
5. Inter-Destination Media Synchronization use cases
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 is in no way meant to be exhaustive.
A first usage scenario for IDMS is Social TV. Social TV is the
combination of media content consumption by two or more users at
different devices and locations combined with the real-time
communication between those users. An example of Social TV is when
two or more users are watching the same television broadcast at
different devices and locations, while communicating with each other
using text, audio and/or video. A skew in their media playout
processes can have adverse effects on their experience. A well-known
use case here is one friend experiencing a goal in a football match
well before or after other friend(s).
Another potential use case for IDMS is a networked video wall. A
video wall consists of multiple computer monitors, video projectors,
or television sets tiled together contiguously or overlapped in order
to form one large screen. Each of the screens reproduces a portion
of the larger picture. In some implementations, each screen may be
individually connected to the network and receive its portion of the
overall image from a network-connected video server or video scaler.
Screens are refreshed at 60 hertz (every 16-2/3 milliseconds) or
potentially faster. If the refresh is not synchronized, the effect
of multiple screens acting as one is broken.
A third usage scenario is that of the networked loudspeakers, in
which two or more speakers are connected to the network individually.
Such situations can for example be found in large conference rooms,
legislative chambers, classrooms (especially those supporting
distance learning) and other large-scale environments such as
stadiums. Since humans are more susceptible to differences in audio
delay, this use case needs even more accuracy than the video wall use
case. Depending on the exact application, the need for accuracy can
then be in the range of microseconds.
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. The Synchronization
Client (SC) and Media Synchronization Application Server (MSAS) Client (SC) and Media Synchronization Application Server (MSAS)
entities are shown as additional functionality for the RTP receiver entities are shown as additional functionality for the RTP receiver
and sender respectively. and sender respectively.
It should be noted that a master/slave type of architecture is also It should be noted that a master/slave type of architecture is also
supported by having one of the SC devices also act as an MSAS. In supported by having one of the SC devices also act as an MSAS. In
skipping to change at page 9, line 24 skipping to change at page 8, line 42
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.
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 Block Type is used information of a particular client, an RTCP XR IDMS Report Block used
(see Section 6). For the MSAS->SC message containing the (see Section 7). For the MSAS->SC message containing the
synchronization settings instructions, a new RTCP Packet Type is synchronization settings instructions, a new RTCP IDMS Settings
defined (see Section 8). Packet Type is defined (see Section 8).
7. RTCP XR Block Type for IDMS
For reporting IDMS information, SCs SHALL use the ETSI specified RTCP 7. RTCP XR Block for IDMS (IDMS Report Block)
XR Block Type 12. For completeness, that RTCP XR Block Type is
repeated here fully.
The definition of the XR block type is based on [RFC3611]. The RTCP This section specifies a new RTCP XR Block Type, the RTCP XR IDMS
XR is used to provide feedback information on receipt times and Report Block, for reporting IDMS information to an MSAS. In
presentation times of RTP packets to e.g. a Sender [RFC3611], a particular it is used to provide feedback information on receipt
Feedback Target [RFC5760] or a Third Party Monitor [RFC3611]. times and presentation times of RTP packets. Its definition is based
on [RFC3550] and [RFC3611].
In most cases, a single RTP receiver will only be part of single IDMS In most cases, a single RTP receiver will only be part of single IDMS
session, i.e. it will report on receipt and presentation times of RTP session, i.e. it will report on receipt and presentation times of RTP
packets from a single RTP stream in a certain synchronization group. packets from a single RTP stream in a certain synchronization group.
In some cases however, an RTP receiver may be a member of multiple In some cases however, an RTP receiver may be a member of multiple
synchronization groups for the same RTP stream, e.g. watching a synchronization groups for the same RTP stream, e.g. watching a
single television program simultaneously with different groups. In single television program simultaneously with different groups. In
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 an RTP packet received during the period since the SHOULD report on an RTP packet received during the period since the
last IDMS XR Report Block was sent. For more details on which packet last RTCP XR IDMS Report Block was sent. For more details on which
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 5 skipping to change at page 10, line 18
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. SHALL be 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: 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-4 Values defined by ETSI TISPAN (see [TS183063]).
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-4 These settings are reserved in order to preserve
compatibility with ETSI TISPAN [TS183063].
SPST=5-15 Reserved for future use. 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
skipping to change at page 15, line 17 skipping to change at page 14, line 23
In practice, this can mean that receivers need to synchronize their In practice, this can mean that receivers need to synchronize their
clocks repeatedly during a synchronization session. clocks repeatedly during a synchronization session.
Because of the stringent synchronization requirements for achieving Because of the stringent synchronization requirements for achieving
good audio in some use cases, a high accuracy will be needed. In good audio in some use cases, a high accuracy will be needed. In
this case, use of the global NTP system may not be sufficient. For this case, use of the global NTP system may not be sufficient. For
improved accuracy, a local NTP server could be set up, or some other improved accuracy, a local NTP server could be set up, or some other
more accurate clock synchronization mechanism can be used, such as more accurate clock synchronization mechanism can be used, such as
GPS time or the Precision Time Protocol [IEEE-1588]. GPS time or the Precision Time Protocol [IEEE-1588].
[I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters [I-D.draft-ietf-avtcore-clksrc] defines a set of SDP parameters for
for signaling the clock synchronization source or sources available signaling the clock synchronization source or sources available to
to and used by the individual receivers. SCs MAY use this draft to and used by the individual receivers. SCs MAY use this draft to
indicate their clock synchronization source or sourced in use and indicate their clock synchronization source or sourced in use and
available. Using these paramenters, an SC can indicate which available. Using these paramenters, an SC can indicate which
synchronization source is being used at the moment, the last time the synchronization source is being used at the moment, the last time the
SC synchronized with this source and the synchronization frequency. SC synchronized with this source and the synchronization frequency.
An SC can also indicate any other synchronization sources available An SC can also indicate any other synchronization sources available
to it. This allows multiple SCs in an IDMS session to use the same to it. This allows multiple SCs in an IDMS session to use the same
or a similar clock source for their session. or a similar clock source for their session.
Applications performing IDMS may or may not be able to choose a Applications performing IDMS may or may not be able to choose a
synchronization method for the system clock, 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-gross-leap-second] presents some guidelines on how RTP [I-D.draft-ietf-leap-seconds] presents some guidelines on how RTP
senders and receivers should deal with leap seconds. When relying on senders and receivers should deal with leap seconds. When relying on
NTP for clock synchronization, IDMS is particularly sensitive to leap NTP for clock synchronization, IDMS is particularly sensitive to leap
second induced timing discrepancies. It is RECOMMENDED to take the second induced timing discrepancies. It is RECOMMENDED to take the
guideline specified in [I-D.draft-gross-leap-second] into account guideline specified in [I-D.draft-ietf-leap-seconds] into account
when implementing IDMS. when implementing IDMS.
10. SDP Parameter for RTCP XR IDMS Block Type 10. On the use of presentation timestamps
The SDP parameter sync-group is used to signal the use of the RTCP XR
block for IDMS, as specified by ETSI, included here for completeness.
It is also used to carry an identifier of the synchronization group
to which clients belong or will belong. This SDP parameter extends
rtcp-xr-attrib as follows, using Augmented Backus-Naur Form
[RFC5234].
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
; Original definition from [RFC3611], section 5.1
xr-format =/ grp-sync ; Extending xr-format for Inter-Destination
Media Synchronization
grp-sync = "grp-sync" [",sync-group=" SyncGroupId]
SyncGroupId = 1*10DIGIT ; Numerical value from 0 through 4294967294
DIGIT = %x30-39
SyncGroupId is a 32-bit unsigned integer represented in decimal.
SyncGroupId identifies a group of SCs for IDMS. It maps on the Media
Stream Correlation Identifier as described in Section 7 and
Section 8. The value SyncGroupId=0 represents an empty SyncGroupId.
The value 4294967294 (2^32-1) is reserved for future use.
The following is an example of the SDP attribute for IDMS 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 a receiver MAY report on playout times. RTP packet
arrival times are relatively easy to report on. Normally, the
processing and playout of the same media stream by different
receivers will take roughly the same amount of time. Synchronizing
on packet arrival times, may lead to some accuracy loss, but it will
be adequate for many applications, such as social TV.
a=rtcp-xr:grp-sync,sync-group=42 Also, if the receivers are in some way controlled, e.g. having the
same buffer settings and decoding times, high accuracy can be
achieved. However, if all receivers in a synchronization session
have the ability to report on, and thus synchronize on, actual
playout times, or packet presentation times, this may be more
accurate. It is up to applications and implementations of this RTCP
extension whether to implement and use this.
11. SDP Parameter for RTCP IDMS Packet Type 11. SDP Signalling for RTCP IDMS Packet Type
The SDP parameter rtcp-idms is used to signal the use of the RTCP The SDP attribute rtcp-idms is used to signal the use of the RTCP
IDMS Packet Type for IDMS. It is also used to carry an identifier of IDMS Packet Type for IDMS and the associated RTCP XR Block for IDMS.
the synchronization group to which clients belong or will belong. It is also used to carry an identifier of the synchronization group
The SDP parameter is used as a media-level attribute during session to which clients belong or will belong. The SDP attribute is used as
setup. This means that in case of multiple related streams, IDMS is a media-level attribute during session setup. This means that in
performed on one of them. The other streams will be synchronized to case of multiple related streams, IDMS is performed on one of them.
this first stream using existing inter-stream synchronization (i.e. The other streams will be synchronized to this first stream using
lip-sync) solutions, i.e. using Sender Reports based on a common existing inter-stream synchronization (i.e. lip-sync) solutions, i.e.
clock source. Basic guidelines for choosing the media stream for using Sender Reports based on a common clock source. Basic
IDMS is to choose audio above video, as humans are more sensitive to guidelines for choosing the media stream for IDMS is to choose audio
degradation in audio quality then in video quality. When using above video, as humans are more sensitive to degradation in audio
mutli-description or multi-view codecs, the IDMS control should be quality then in video quality. When using mutli-description or
performed on the base layer. multi-view codecs, the IDMS control should be performed on the base
layer.
This SDP parameter 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 ; Numerical 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 4294967294 SyncGroupId=0 represents an empty SyncGroupId. The value 4294967294
(2^32-1) is reserved for future use. (2^32-1) is reserved for future use. For a description on the value
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.
a=rtcp-idms:sync-group=42 a=rtcp-idms:sync-group=42
12. Compatibility with ETSI TISPAN 12. SDP rules
As described in Section 2.3, ETSI TISPAN has described its mechanism
for IDMS in [TS183063]. One of the main differences between the
TISPAN document and this document is the fact that the TISPAN
solution uses an RTCP XR block for both the SC->MSAS message and the
MSAS->SC message (by selecting SPST-type 2), while this document
specifies a new RTCP Packet Type for the MSAS->SC message. The
message from MSAS to SC is not in any way a report on how a receiver
sees a session, and therefore a separate RTCP packet type is more
appropriate than the XR block solution chosen in ETSI TISPAN. To
achieve compatibility, MSAS implementations SHOULD implement both the
TISPAN RTCP block and the new RTCP IDMS Settings packet for MSAS->SC
messages. SCs MAY implement support for both types of messages. For
the MSAS->SC signaling, it is recommended to use the RTCP IDMS
Settings packet defined in this document. The TISPAN RTCP XR block
with SPST=2 MAY be used for purposes of compatibility with the TISPAN
solution, but MUST NOT be used if all nodes involved support the new
RTCP IDMS Settings packet.
13. SDP rules
13.1. Offer/Answer rules 12.1. Offer/Answer rules
The SDP usage for IDMS follows the rules defined in RFC3611 in The SDP usage for IDMS follows the rules defined in RFC3611 in
section 5 on SDP signalling, with the exception of what is stated section 5 on SDP signalling, with the exception of what is stated
here. The IDMS usage of RTCP is a (loosely coupled) collaborative here. The IDMS usage of RTCP is a (loosely coupled) collaborative
parameter, in the sense that receivers sent their status information attribute, in the sense that receivers sent their status information
and in response (asynchronously) the MSAS sents synchronization and in response the MSAS (asynchronously) sends synchronization
instructions. Both the sync-group parameter (defined by ETSI TISPAN) instructions. The rtcp-idms attribute thus indicates the ability to
and the rtcp-idms parameter (defined in this document) thus indicate send and receive indicated RTCP messages. This section defines how
the ability to sent and the ability to receive indicated RTCP this SDP attribute should be used with regards to offer/answer.
messages. This section defines how these SDP parameters should be
used.
Most of the times, the IDMS SDP parameters will be used in the offer/
answer context. Receivers will indicate in their SDP which RTCP
messages they support.
For a unicast situation, three situations are possible in offer/
answer context:
- If a receiver indicates at least the rtcp-idms SDP parameter, the
MSAS SHOULD reply with only the rtcp-idms parameter and use only
the RTCP IDMS Settings packet for MSAS->SC communication
- If a receiver indicates only the sync-group SDP parameter, and the
MSAS also supports this, it SHOULD reply with only the sync-group
parameter and use only the RTCP XR block with SPST=2 for MSAS->SC
communication
- If a receiver indicates only the sync-group SDP parameter, and the
MSAS does not support this, the media sender MUST ignore the
parameter. This receiver will not become part of the
synchronization session
Note that it is possible that for a certain synchronization group,
that the MSAS sends RTCP IDMS packets to one receiver and RTCP XR
IDMS blocks with SPST=2 to another receiver.
In a multicast situation using the offer/answer context, it will work
a bit differently. The negotiation is the same as in the unicast
situation. But, the MSAS will multicast all RTCP messages to all
receivers. So:
- If all receivers support the RTCP IDMS Settings packet, the MSAS
SHOULD only sent the RTCP IDMS Settings packet for MSAS->SC
messages
- If not all receivers support the RTCP IDMS Settings packet, but It is expected that in most cases, the rtcp-idms attribute will be
all receivers support the TISPAN solution, the MSAS SHOULD only used in an offer/answer context where receivers will have pre-
sent the RTCP XR block with SPST=2 for MSAS->SC messages. determined, through some means outside the scope of this document, a
SyncGroupId before the media session is setup. However, it is also
supported that the MSAS assigns such a SyncGroupId, for example if
the MSAS contains group management functionality. Thus, both the
MSAS and the SC can insert the attribute and the SyncGroupId.
Furthermore, it is allowed to insert the attribute for more than one
media stream, allowing an SC to become part of multiple
synchronization groups simultaneously. This effectively couples two
(or more) synchronization groups to each other. If the rtcp-idms
attribute is inserted more than once for a particular media session,
each SyncGroupId SHALL only be inserted once.
- If some receivers support only the RTCP IDMS Settings packet and In order to join an IDMS session, the receiver (the SC) inserts the
other receivers support only the TISPAN solution, the MSAS SHOULD rtcp-idms attribute as a media level attribute in the SDP offer.
sent both the RTCP IDMS Settings packet and the RTCP XR block with This SDP offer can be an initial offer, if the media session is
SPST=2 for MSAS->SC messages. This is less efficient, since the starting as a synchronized session. The SDP offer can also be an
information sent is duplicated, but this is the only way to update to an existing media session, converting the session to an
include all receivers in a synchronization session in this IMDS session. If the receiver has a pre-determined SyncGroupId
scenario. value, it SHOULD use this value for setting the SyncGroupId parameter
in the rtcp-idms attribute. If the receiver does not know the
SyncGroupId to be used, it MAY leave the SyncGroupId parameter empty
by setting its value to 0.
In certain multicast situations, there is no offer/answer context, The MSAS SHALL include the rtcp-idms attribute in its answer. If the
but only a declarative modus. In that case, the MSAS SHOULD use only value of the SyncGroupId parameter in the offer was not empty (not
the RTCP IDMS packet type and thus use only the SDP parameter rtcp- equal to 0), the MSAS SHOULD NOT change the SyncGroupId in its
idms. Receivers that do not support the RTCP IDMS packet will just answer. If the SyncGroupId was empty, the MSAS SHALL include the
ignore both the SDP parameter and the RTCP IDMS packets, and will proper SyncGroupId in its answer. If the MSAS receives an offer with
thus not join the synchronization session. For compatability with the value of the SyncGroupId parameter set to 0, and cannot determine
the TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS the proper SyncGroupId, it SHALL remove the attribute from its
block type instead, using the SDP parameter sync-group. The media answer.
sender SHOULD NOT use both parameters at the same time in this case
of no offer/answer context.
13.2. Declarative cases An MSAS receiving an SDP offer without the rtcp-idms attribute can
also decide that IDMS is applicable to that media session. In such a
case, the MSAS MAY insert the rtcp-idms attribute, including a non-
empty SyncGroupId, as part of its answer.
In certain multicast situations, there is no offer/answer context, A receiver receiving an rtcp-idms attribute as part of the SDP answer
but only a declarative modus. In that case, the MSAS SHOULD use only from an MSAS, SHALL start sending IDMS XR reports (following all the
the RTCP IDMS packet type and thus use only the SDP parameter rtcp- normal RTCP rules for sending RTCP XR blocks) and SHALL be ready to
idms. Receivers that do not support the RTCP IDMS packet will just start receiving IDMS Settings. As usual, if a receiver does not
ignore both the SDP parameter and the RTCP IDMS packets, and will support the attribute (e.g. in case of an MSAS-inserted IDMS
thus not join the synchronization session. For compatability with attribute), it SHALL ignore the attribute.
the TISPAN solution, the MSAS MAY choose to use the RTCP XR IDMS
block type instead, using the SDP parameter sync-group. The media
sender SHOULD NOT use both parameters at the same time in this case
of no offer/answer context.
14. On the use of presentation timestamps Different updates are applicable to such an IDMS session. Updates
can be sent ommitting the rtcp-idms attribute, thereby ending the
(involvement in) the synchronization session. Updates can also be
sent including the rtcp-idms attribute, but with a different
SyncGroupId. This indicates a switch in synchronization group.
Updates can also be sent including another rtcp-idms attribute,
indicating a membership of another synchronization group, effectively
merging the current group(s) with the new one.
A receiver can report on different timing events, i.e. on packet 12.2. Declarative cases
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 are relatively easy to report on. Normally, the
processing and playout of the same media stream by different
receivers will take roughly the same amount of time. Synchronizing
on packet arrival times, may lead to some accuracy loss, but it will
be adequate for many applications, such as social TV.
Also, if the receivers are in some way controlled, e.g. having the In certain situations, there is no offer/answer context, but only a
same buffer settings and decoding times, high accuracy can be declarative modus. In this case, the MSAS just inserts the rtcp-idms
achieved. However, if all receivers in a synchronization session attribute and a valid SyncGroupId. Any receiver receiving the rtcp-
have the ability to report on, and thus synchronize on, actual idms attribute in such a declarative case, SHALL start sending IDMS
playout times, or packet presentation times, this may be more XR Report Blocks and SHALL be ready to start receiving RTCP IDMS
accurate. It is up to applications and implementations of this RTCP Settings packets.
extension whether to implement and use this.
15. Security Considerations 13. Security Considerations
The security considerations described in [RFC3611] apply to this The security considerations described in [RFC3611] apply to this
document as well. document as well.
The specified RTCP XR Block Type in this document is used to collect, The RTCP XR IDMS Report Block defined in this document is used to
summarize and distribute information on packet reception- and collect, summarize and distribute information on packet reception-
playout-times of streaming media. The information may be used to and playout-times of streaming media. The information may be used to
orchestrate the media playout at multiple devices. orchestrate the media playout at multiple devices.
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 to undesired behavior. For example, if one device erroneously or
reports a two-hour delayed playout, then another device in the same maliciously reports a two-hour delayed playout, then another device
synchronization group could decide to delay its playout by two hours in the same synchronization group could decide to delay its playout
as well, in order to keep its playout synchronized. A user would by two hours as well, in order to keep its playout synchronized. A
likely interpret this two hour delay as a malfunctioning service. user would likely interpret this two hour delay as a malfunctioning
service.
Therefore, the application logic of both Synchronization Clients and Therefore, the application logic of both Synchronization Clients and
Media Synchronization Application Servers should check for Media Synchronization Application Servers should check for
inconsistent information. Differences in playout time exceeding inconsistent 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 inconsistent information.
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 14. IANA Considerations
This document defines a new RTCP packet type called IDMS Settings This document defines a new RTCP packet type, the RTCP IDMS Packet
packet in the IANA registry of RTP parameters, part of RTCP Control (IDMS Settings), within the existing Internet Assigned Numbers
Packet types (PT), based on the specification in Section 8. Authority (IANA) registry of RTCP Control Packet Types. This
document also defines a new RTCP XR Block Type, the IDMS XR Report
Block, within the existing IANA registry of RTCP Extended Reports
(RTCP XR) Block Types.
Further, this document defines a new SDP parameter "rtcp-idms" within Further, this document defines a new SDP attribute "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)"
14.1. RTCP IDMS Packet Type
This document assigns the packet type value TBD in the IANA 'RTCP
Control Packet types (PT) Registry' to the RTCP IDMS Packet Type.
[Note to RFC Editor: please replace TBD with the IANA-provided RTCP
Packet Type value for this packet type]
14.2. RTCP XR IDMS Report Block
This document assigns the block type value 12 in the IANA "RTCP XR
Block Type Registry" to the RTCP XR IDMS Report Block.
[Note to RFC Editor: this block type value is currently assigned to
[TS183063]. This document replaces [TS183063] as the normative
specification of the RTCP XR IDMS Report Block. Upon publication of
this document as RFC, [TS183063] will be changed to reflect this.
14.3. RTCP-IDMS SDP Attribute
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"):
Attribute name: rtcp-idms Attribute name: rtcp-idms
Long form: RTCP report block for IDMS Long form: RTCP IDMS Parameters
Type of name: att-field Type of name: att-field
Type of attribute: media level Type of attribute: media level
Subject to charset: no Subject to charset: no
Purpose: see sections 7 and 10 of this document Purpose: see Section 11 of this document
Reference: this document Reference: this document
Values: see this document Values: see this document
17. Contributors 14.4. Contact Information for Registrations
The contact information for the registrations is:
Ray van Brandenburg (ray.vanbrandenburg@tno.nl)
Brassersplein 2
2612CT, Delft, The Netherlands
15. Contributors
The following people have participated as co-authors or provided The following people have participated as co-authors or provided
substantial contributions to this document: Omar Niamut, Fabian substantial contributions to this document: Omar Niamut, Fabian
Walraven, Ishan Vaishnavi, Rufael Mekuria and Rob Koenen. Walraven, Ishan Vaishnavi and Rufael Mekuria. In addition the
authors would like to thank Aidan Williams, Colin Perkins, Magnus
Westerlund, Roni Even, Peter Musgrave, Ali Begen, Qin Wu and Rob
Koenen for their review comments and contributions to the text.
18. References 16. References
18.1. Normative References 16.1. Normative References
[I-D.draft-williams-avtcore-clksrc] [I-D.draft-ietf-avtcore-clksrc]
Williams, A., van Brandenburg, R., Stokking, H., and K. Williams, A., van Brandenburg, R., Stokking, H., and K.
Gross, "RTP Clock Source Signalling, Gross, "RTP Clock Source Signalling,
draft-williams-avtcore-clksrc-00", March 2012. draft-ietf-avtcore-clksrc-01", October 2012.
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels, RFC 2119", March 1997. Requirement Levels, RFC 2119", March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications, RFC3550", July 2003. Applications, RFC3550", July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video conferences with Minimal Control, RFC3551", Video conferences with Minimal Control, RFC3551",
skipping to change at page 22, line 23 skipping to change at page 21, line 5
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.
18.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. 108- study, Elsevier Information Systems 34 (2009), pp. 108-
131". 131".
[I-D.draft-gross-leap-second] [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-gross-leap-seconds-01". draft-ietf-leap-seconds-01", 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
 End of changes. 64 change blocks. 
329 lines changed or deleted 277 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/