draft-ietf-avtcore-idms-00.txt   draft-ietf-avtcore-idms-01.txt 
AVTCore R. van Brandenburg
Internet Draft H.M. Stokking
Intended status: Standards Track M.O. van Deventer
Expires: December 2011 TNO Netherlands
I. Vaishnavi
CWI Netherlands
F. Boronat
M. Montagud
Universidad Politecnica de Valencia
June 28, 2011
RTCP for inter-destination media synchronization AVTCore R. van Brandenburg
draft-ietf-avtcore-idms-00.txt Internet Draft H. Stokking
Intended status: Standards Track M. van Deventer
Expires: January 7, 2012 O. Niamut
F. Walraven
TNO Netherlands
I. Vaishnavi
CWI Netherlands
F. Boronat
M. Montagud
Universidad Politecnica de Valencia
July 6, 2011
RTCP for inter-destination media synchronization
draft-ietf-avtcore-idms-01.txt
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 28, 2011. This Internet-Draft will expire on January 5, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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.
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 with media synchronization (IDMS). The RTCP XR Block Type, registered with
IANA based on an ETSI specification, is used to collect media play- IANA based on an ETSI specification, is used to collect media play-
skipping to change at page 2, line 28 skipping to change at page 2, line 30
collected information so that the participants can synchronize play- collected information so that the participants can synchronize play-
out. out.
Typical applications for IDMS are social TV, shared service control Typical applications for IDMS are social TV, shared service control
(i.e. applications where two or more geographically separated users (i.e. applications where two or more geographically separated users
are watching a media stream together), distance learning, network are watching a media stream together), distance learning, network
quiz shows, multi-playing online games, etc. quiz shows, multi-playing online games, etc.
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Inter-destination Media Synchronization.................3 1.1. Inter-destination Media Synchronization . . . . . . . . . . 3
1.2. Applicability of RTCP to IDMS...........................3 1.2. Applicability of RTCP to IDMS . . . . . . . . . . . . . . . 3
1.3. Applicability of SDP to IDMS............................4 1.3. Applicability of SDP to IDMS . . . . . . . . . . . . . . . 4
1.4. This document and ETSI TISPAN...........................4 1.4. This document and ETSI TISPAN . . . . . . . . . . . . . . . 4
2. Terminology..................................................4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of IDMS operation...................................4 3. Overview of IDMS operation . . . . . . . . . . . . . . . . . . 4
4. Inter-destination media synchronization use cases............6 4. Inter-destination media synchronization use cases . . . . . . . 6
5. Architecture for inter-destination media synchronization.....6 5. Architecture for inter-destination media synchronization . . . 7
5.1. Media Synchronization Application Server (MSAS).........7 5.1. Media Synchronization Application Server (MSAS) . . . . . . 7
5.2. Synchronization Client (SC).............................7 5.2. Synchronization Client (SC) . . . . . . . . . . . . . . . . 7
5.3. Communication between MSAS and SCs......................7 5.3. Communication between MSAS and SCs . . . . . . . . . . . . 7
6. RTCP XR Block Type for IDMS..................................8 6. RTCP XR Block Type for IDMS . . . . . . . . . . . . . . . . . . 9
7. RTCP Packet Type for IDMS (IDMS report).....................10 7. RTCP Packet Type for IDMS (IDMS report) . . . . . . . . . . . . 11
8. Timing and NTP Considerations...............................11 8. Timing and NTP Considerations . . . . . . . . . . . . . . . . . 13
9. SDP Parameter for RTCP XR IDMS Block Type...................12 9. SDP Parameter for RTCP XR IDMS Block Type . . . . . . . . . . . 13
10. SDP Parameter for RTCP IDMS Packet Type....................13 10. SDP Parameter for RTCP IDMS Packet Type . . . . . . . . . . . 14
11. SDP parameter for clock source.............................13 11. SDP parameter for clock source . . . . . . . . . . . . . . . . 15
12. Compatibility with ETSI TISPAN.............................15 12. Compatibility with ETSI TISPAN . . . . . . . . . . . . . . . . 17
13. Operational Considerations.................................16 13. Operational Considerations . . . . . . . . . . . . . . . . . . 17
14. Security Considerations....................................16 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18
15. IANA Considerations........................................17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
16. Conclusions................................................18 16. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
17. References.................................................19 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
17.1. Normative References..................................19 17.1. Normative References . . . . . . . . . . . . . . . . . . . 21
17.2. Informative References................................19 17.2. Informative References . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
1.1. Inter-destination Media Synchronization 1.1. Inter-destination Media Synchronization
Inter-destination media synchronization (IDMS) refers to the play-out Inter-destination media synchronization (IDMS) refers to the play-out
of media streams at two or more geographically distributed locations of media streams at two or more geographically distributed locations
in a temporally synchronized manner. It can be applied to both in a temporally synchronized manner. It can be applied to both
unicast and multicast media streams and can be applied to any type unicast and multicast media streams and can be applied to any type
and/or combination of streaming media, such as audio, video and text and/or combination of streaming media, such as audio, video and text
skipping to change at page 5, line 6 skipping to change at page 5, line 7
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 IDMS RTCP This section provides a brief example of how the IDMS RTCP
functionality is used. The section is tutorial in nature and does not functionality is used. The section is tutorial in nature and does not
contain any normative statements. contain any normative statements.
Alice's . . . . . . .tv:abc.com . . . . . . . . . Bob's Alice's . . . . . . .tv:abc.com . . . . . . . . . Bob's
TV (SC) (MSAS) Laptop (SC) TV (Sync Client) (Sync Server) Laptop (SC)
| | | | | |
| 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 |
|<================================================>| |<================================================>|
skipping to change at page 5, line 41 skipping to change at page 5, line 42
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 program. set up, so that Alice and Bob can talk while watching the program.
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 the same time, their clients also the events in the football game at the same time, their clients also
periodically send an IDMS XR block to the MSAS function of the media periodically send an IDMS XR block to the sync server function of the
server. Included in the XR blocks are timestamps on when both Alice media server. Included in the XR blocks are timestamps on when both
and Bob have received (or played out) a particular RTP packet. Alice and Bob have received (or played out) a particular RTP packet.
The MSAS function in the media server calculates a reference client The sync server function in the media server calculates a reference
from the received IDMS XR blocks (e.g. by selecting whichever client client from the received IDMS XR blocks (e.g. by selecting whichever
received the packet the latest as the reference client). It then client received the packet the latest as the reference client). It
sends an RTCP IDMS packet containing the play-out information of this then sends an RTCP IDMS packet containing the play-out information of
reference client to both Alice and Bob. this reference client to both Alice and Bob.
In this case Bob has the slowest connection and the reference client In this case Bob has the slowest connection and the reference client
therefore includes a delay similar to the one experienced by Bob. therefore includes a delay similar to the one experienced by Bob.
Upon reception of this information, Alice's RTP client can choose Upon reception of this information, Alice's RTP client can choose
what to do with this information. In this case it decreases its play- what to do with this information. In this case it decreases its play-
out rate temporarily until it matches with the reference client play- out rate temporarily until it matches with the reference client play-
out (and thus matches Bob's play-out). Another option for Alice's TV out (and thus matches Bob's play-out). Another option for Alice's TV
would be to simply pause playback until it catches up. The exact would be to simply pause playback until it catches up. The exact
implementation of the synchronization algorithm is up to the client. implementation of the synchronization algorithm is up to the client.
skipping to change at page 6, line 47 skipping to change at page 6, line 48
Another example of Social TV is Shared Service Control, where two or Another example of Social TV is Shared Service Control, where two or
more users experience some content-on-demand together, while sharing more users experience some content-on-demand together, while sharing
the trick-play controls (play, pause, fast forward, rewind) of the the trick-play controls (play, pause, fast forward, rewind) of the
content on demand. content on demand.
Similar to the previous use case, without IDMS, differences in play- Similar to the previous use case, without IDMS, differences in play-
out speed and the effect of transit delay of trick-play control out speed and the effect of transit delay of trick-play control
signals would desynchronize content play-out. signals would desynchronize content play-out.
IDMS may be used for other purposes, such as synchronization of
multiple television outputs in a single physical location, or for the
synchronization of different networked speakers throughout a house.
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
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 8, line 11 skipping to change at page 9, line 11
(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 in Section 7. defined in 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 [RFC5760] or a Third Party Monitor [RFC3611], a Feedback Target [RFC5576] 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 10, line 7 skipping to change at page 11, line 7
packet to which the XR relates. packet to which the XR relates.
Packet Received NTP timestamp: 64 bits. This timestamp reflects the Packet Received NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the moment of arrival of the first octet of the wall clock time at the moment of arrival of the first octet of the
RTP packet to which the XR relates. It is formatted based on the NTP RTP packet to which the XR relates. It is formatted based on the NTP
timestamp format as specified in [RFC5905]. See section 8 for more timestamp format as specified in [RFC5905]. See section 8 for more
information on how this field is set. information on how this field is set.
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 time stamp carried in the RTP header [RFC3550] of the RTP of the RTP time stamp carried in the RTP header [RFC3550] of the RTP
packet to which the XR relates. packet to which the XR relates. Several consecutive RTP packets will
have equal timestamps if they are (logically) generated at once,
e.g., belong to the same video frame. It may well be the case that
one receiver reports on the first RTP packet having a certain RTP
timestamp and a second receiver reports on the last RTP packet having
that same RTP timestamp. This would lead to an error in the
synchronization algorithm due to the faulty interpretation of
considering both reports to be on the same RTP packet. To solve this,
an SC SHOULD report on RTP packets in which a certain RTP timestamp
shows up for the first time.
Packet Presented NTP timestamp: 32 bits. This timestamp reflects the Packet Presented NTP timestamp: 32 bits. This timestamp reflects the
wall clock time at the moment the data contained in the first octet wall clock time at the moment the data contained in the first octet
of the associated RTP packet is presented to the user. It is based on of the associated RTP packet is presented to the user. It is based on
the time format used by NTP and consists of the least significant 16 the time format used by NTP and consists of the least significant 16
bits of the NTP seconds part and the most significant 16 bits of the bits of the NTP seconds part and the most significant 16 bits of the
NTP fractional second part. If this field is empty, then it SHALL be NTP fractional second part. If this field is empty, then it SHALL be
set to 0 and the Packet Presented NTP timestamp flag (P) SHALL be set set to 0 and the Packet Presented NTP timestamp flag (P) SHALL be set
to 0. to 0. Presented here means the moment the data is presented to the
user of the system, i.e. sound played out through speakers, video
images being displayed on some display, etc. For applications
requiring high accuracy, they should be able to determine this in any
case to achieve their required accuracy. The accuracy resulting from
the synchronization algorithm will only be as good as the accuracy
with which the receivers can determine and control their playout
timing. By adding this parameter, the protocol supports very high
accuracy if supported by the receivers.
7. RTCP Packet Type for IDMS (IDMS report) 7. RTCP Packet Type for IDMS (IDMS report)
This section specifies the RTCP Packet Type for indicating This section specifies the RTCP Packet Type for indicating
synchronization settings instructions to a receiver of the RTP media synchronization settings instructions to a receiver of the RTP media
stream. Its definition is based on [RFC3550]. stream. Its definition is based on [RFC3550].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 26 skipping to change at page 12, line 40
Packet Received NTP timestamp: 64 bits. This timestamp reflects the Packet Received NTP timestamp: 64 bits. This timestamp reflects the
wall clock time at the reference client at the moment it received the wall clock time at the reference client at the moment it received the
first octet of the RTP packet to which this packet relates. It can be first octet of the RTP packet to which this packet relates. It can be
used by the synchronization algorithm on the receiving SC to set the used by the synchronization algorithm on the receiving SC to set the
required playout delay. The timestamp is formatted based on the NTP required playout delay. The timestamp is formatted based on the NTP
timestamp format as specified in [RFC5905]. See section 8 for more timestamp format as specified in [RFC5905]. See section 8 for more
information on how this field is set. information on how this field is set.
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 time stamp carried in the RTP header [RFC3550] of the RTP of the RTP time stamp carried in the RTP header [RFC3550] of the RTP
packet to which the XR relates. packet to which the XR relates. This SHOULD relate to the first RTP
packet containing this particular RTP timestamp, in case multiple RTP
packets contain the same RTP timestamp.
Packet Presented NTP timestamp: 32 bits. This timestamp reflects the Packet Presented NTP timestamp: 32 bits. This timestamp reflects the
wall clock time at the 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. It is based on the time format used by NTP and consists of the user. It is based on the time format used by NTP and consists of
the least significant 16 bits of the NTP seconds part and the most the least significant 16 bits of the NTP seconds part and the most
significant 16 bits of the NTP fractional second part. If this field significant 16 bits of the NTP fractional second part. If this field
is empty, then it SHALL be set to 0. This field MAY be left empty if is empty, then it SHALL be set to 0. This field MAY be left empty if
none or only one of the receivers reported on presentation none or only one of the receivers reported on presentation
timestamps. timestamps. Presented here means the moment the data is presented to
the user of the system.
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
clocks as a common timeline for synchronization. Depending on the clocks as a common timeline for synchronization. Depending on the
synchronization accuracy required, different clock synchronization synchronization accuracy required, different clock synchronization
methods can be used. For social TV, synchronization accuracy should methods can be used. For social TV, synchronization accuracy should
be achieved in order of hundreds of milliseconds. In that case, be achieved in order of hundreds of milliseconds. In that case,
correct use of NTP on receivers will in most situations achieve the correct use of NTP on receivers will in most situations achieve the
required accuracy. As a guideline, to deal with clock drift of required accuracy. As a guideline, to deal with clock drift of
receivers, receivers should synchronize their clocks at the beginning receivers, receivers should synchronize their clocks at the beginning
of a synchronized session. of a synchronized session. In case of high required accuracy, the
synchronized clocks of different receivers should not drift beyond
IDMS may be used for other purposes, such as synchronization of the accuracy required for the synchronization mechanism. In practice
multiple television outputs in a single physical location, or for the this can mean that receivers need to synchronize their clocks
synchronization of different networked speakers throughout a house. repeatedly during a synchronization session.
Because of the stringent synchronization requirements for achieving Because of the stringent synchronization requirements for achieving
good audio, a high accuracy will be needed. In this case, NTP usage good audio, a high accuracy will be needed. In this case, NTP usage
may not be sufficient. Either a local NTP server could be setup, or may not be sufficient. Either a local NTP server could be setup, or
some other more accurate clock synchronization mechanism could be some other more accurate clock synchronization mechanism could be
used, such as using GPS time or the Precision Time Protocol [IEEE- used, such as using GPS time or the Precision Time Protocol [IEEE-
1588]. 1588].
In this document, a new SDP parameter is introduced to signal the In this document, a new SDP parameter is introduced to signal the
clock synchronization source or sources used or able to be used (see clock synchronization source or sources used or able to be used (see
skipping to change at page 13, line 43 skipping to change at page 15, line 13
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
11. SDP parameter for clock source 11. SDP parameter for clock source
The SDP parameter clocksource is used to signal the source for clock The SDP parameter clocksource is used to signal the source for clock
synchronization. This SDP parameter is specified as follows, using synchronization. This SDP parameter is specified as follows, using
Augmented Backus-Naur Form [RFC5234]. Augmented Backus-Naur Form [RFC5234].
clocksource = "a=" "clocksource" ":" source SP [last-synced] CRLF clocksource = "a=" "clocksource" ":" source SP [last-synced] CRLF
source = local / ntp / gps / gal / ptp source = local / ntp / gps / gal / ptp
local = "local" local = "local"
ntp = "ntp" ["=" ntp-server] ntp = "ntp" ["=" ntp-server]
ntp-server = host [ ":" port ] ntp-server = host [ ":" port ]
host = hostname / IPv4address / IPv6reference host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ] hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum / alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]" IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ] IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG hex4 = 1*4HEXDIG
port = 1*DIGIT port = 1*DIGIT
gps = "gps" gps = "gps"
gal = "gal" gal = "gal"
ptp = "ptp" ["=" ptp-id] ptp = "ptp" SP ptp-version [ ":" ptp-id]
ptp-version = "IEEE 1588-2002" / "IEEE 1588-2008" / "IEEE 802.1AS-
2011"
ptp-id = 1*alphanum ptp-id = 1*alphanum
last-synced = date SP time last-synced = date SP time UTCoffset
date = 2DIGIT "-" 2DIGIT "-" 4DIGIT date = 2DIGIT "-" 2DIGIT "-" 4DIGIT
; day month year (e.g., 02-06-1982) ; day month year (e.g., 02-06-1982)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT "." 3DIGIT
; 00:00:00 - 23:59:59 ; 00:00:00.000 - 23:59:59.999
alphanum = ALPHA / DIGIT UTCoffset = plusoffset / minusoffset
plusoffset = + 2DIGIT ":" 2DIGIT
; +01:00 (+HH:MM)
minusoffset = - 2DIGIT ":" 2DIGIT
; -00:00 (-HH:MM)
alphanum = ALPHA / DIGIT
EXAMPLE EXAMPLE
a=clocksource:ntp=139.63.192.5:123 19-02-2011 21:03:20 a=clocksource:ntp=139.63.192.5:123 19-02-2011 21:03:20.345+01:00
A client MAY include this attribute multiple times. If multiple time A client MAY include this attribute multiple times. If multiple time
synchronization sources were used in the past, the client MUST only synchronization sources were used in the past, the client MUST only
report the 'last synced' parameter on the latest synchronization report the 'last synced' parameter on the latest synchronization
performed. If a client supports a specific synchronization method, performed. If a client supports a specific synchronization method,
but does not know any sources to use for synchronization, it SHOULD but does not know any sources to use for synchronization, it SHOULD
indicate the method without specifying the source. A client MAY indicate the method without specifying the source. A client MAY
indicate itself as source if it is a clock synchronization source, indicate itself as source if it is a clock synchronization source,
but it SHOULD do so using a publicly reachable address. but it SHOULD do so using a publicly reachable address.
The parameter can be used as both a session or media level attribute. The parameter can be used as both a session or media level attribute.
It will normally be a session level parameter, since it is not It will normally be a session level parameter, since it is not
directly media-related. In case of IDMS however, it can be used in directly media-related. In case of IDMS however, it can be used in
conjunction with the rtcp-idms SDP parameter, and then it SHOULD be conjunction with the rtcp-idms SDP parameter, and then it SHOULD be
used as a media-level parameter as well. used as a media-level parameter as well.
The meaning of 'local' is that no clock synchronization is performed. The meaning of 'local' is that no clock synchronization is performed.
Allthough not re-used, the meaning of 'gps' (Global Positioning
System), 'gal' (Galileo Positioning System) and ptp (Precision Time
Protocol) follows the use of reference identifiers in NTP [RFC5905].
When using ptp, the ptp-id MUST contain the proper identifier from
the used IEEE specification.
The 'last synced' parameter is used as an indication for the receiver The 'last synced' parameter is used as an indication for the receiver
of the parameter on the accuracy of the clock. If the indicated last of the parameter on the accuracy of the clock. If the indicated last
synchronization time is very recent, this is an indication that the synchronization time is very recent, this is an indication that the
clock can be trusted to be accurate, given the method of clock clock can be trusted to be accurate, given the method of clock
synchronization used. If the indicated last synchronization time is synchronization used. If the indicated last synchronization time is
longer ago or in the future, either the clock synchronization has longer ago or in the future, either the clock synchronization has
been performed long ago, or the clock is synchronized to an incorrect been performed long ago, or the clock is synchronized to an incorrect
synchronization source. Either way, this shows that the clock used synchronization source. Either way, this shows that the clock used
can not be trusted to be accurate. can not be trusted to be accurate.
12. Compatibility with ETSI TISPAN 12. Compatibility with ETSI TISPAN
As described in section 1.4, ETSI TISPAN has also described a As described in section 1.4, ETSI TISPAN has also described a
mechanism for IDMS in [TS 183 063]. One of the main differences mechanism for IDMS in [TS 183 063]. One of the main differences
between the TISPAN document and this document is the fact that the between the TISPAN document and this document is the fact that the
TISPAN solution uses an RTPC XR block for both the SC->MSAS message TISPAN solution uses an RTPC XR block for both the SC->MSAS message
as well as for the MSAS->SC message (by selecting different SPST- as well as for the MSAS->SC message (by selecting different SPST-
types), while this document specifies a new RTCP Packet Type for the types), while this document specifies a new RTCP Packet Type for the
MSAS->SC message. 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 then the XR block solution
chosen in ETSI TISPAN.
In order to maintain backward-compatibility, the RTCP XR block used In order to maintain backward-compatibility, the RTCP XR block used
for SC->MSAS signaling specified in this document is fully compatible for SC->MSAS signaling specified in this document is fully compatible
with the TISPAN defined XR block. with the TISPAN defined XR block.
For the MSAS->SC signaling, it is recommended to use the RTCP IDMS For the MSAS->SC signaling, it is recommended to use the RTCP IDMS
Packet Type defined in this document. The TISPAN XR block with SPST=2 Packet Type defined in this document. The TISPAN XR block with SPST=2
MAY be used for purposes of compatibility with the TISPAN solution, 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 but MUST NOT be used if all nodes involved support the new RTCP IDMS
Packet Type. Packet Type.
skipping to change at page 19, line 9 skipping to change at page 21, line 9
This document describes the RTCP XR block type for IDMS, the RTCP This document describes the RTCP XR block type for IDMS, the RTCP
IDMS report and the associated SDP parameters for inter-destination IDMS report and the associated SDP parameters for inter-destination
media synchronization. It also describes an SDP parameter for media synchronization. It also describes an SDP parameter for
indicating which source is used for synchronizing a (systems) (wall) indicating which source is used for synchronizing a (systems) (wall)
clock. clock.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC5234] Crocker, D. and Overell, P., "Augmented BNF for Syntax [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Specifications: ABNF", RFC 5234, January 2008. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Applications", RFC 3550, July 2003. Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
[RFC3551] Schulzrinne, H. and Casner S., "RTP Profile for Audio and [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Video Conferences with Minimal Control", RFC 3551, July Jacobson, "RTP: A Transport Protocol for Real-Time
2003 Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T. "RTP Control Protocol Extended Reports (RTCP [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
XR)", RFC 3611, November 2003. Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC4566] Handley, M., "SDP: Session Description Protocol", RFC 4566, [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
July 2006. "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, November 2003.
[RFC5576] Lennox, J., "Source-Specific Media Attributes in the [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Session Description Protocol (SDP)", RFC 5576, June 2009. Description Protocol", RFC 4566, July 2006.
[RFC5905] Mills, D., "Network Time Protocol Version 4: Protocol and [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Algorithms Specification", RFC 5905, June 2010. Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC5968] Ott, J., Guidelines on Extending the RTP Control Protocol [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
(RTCP), September 2010. Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[TS 183 063] ETSI TISPAN, "IMS-based IPTV stage 3 specification", [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
TS 183 063 v3.4.1, June 2010. "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[TS 183 063] ETSI TISPAN, "IMS-based IPTV stage 3 specification", TS
183 063 v3.4.1, June 2010.
17.2. Informative References 17.2. Informative References
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010.
[Boronat2009] Boronat, F., et al, "Multimedia group and inter-stream [Boronat2009] Boronat, F., et al, "Multimedia group and inter-stream
synchronization techniques: A comparative study", Elsevier synchronization techniques: A comparative study", Elsevier
Information Systems 34 (2009), pp. 108-131 Information Systems 34 (2009), pp. 108-131
[IEEE-1588] IEEE Standards Association, "1588-2008 - IEEE Standard [IEEE-1588] IEEE Standards Association, "1588-2008 - IEEE Standard
for a Precision Clock Synchronization Protocol for for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems", 2008 Networked Measurement and Control Systems", 2008
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
TNO TNO
Brassersplein 2, Delft, the Netherlands Brassersplein 2, Delft, the Netherlands
Phone: +31 88 86 63609 Phone: +31 88 86 63609
Email: ray.vanbrandenburg@tno.nl Email: ray.vanbrandenburg@tno.nl
skipping to change at page 20, line 28 skipping to change at page 23, line 28
Phone: +31 88 86 67278 Phone: +31 88 86 67278
Email: hans.stokking@tno.nl Email: hans.stokking@tno.nl
M. Oskar van Deventer M. Oskar van Deventer
TNO TNO
Brassersplein 2, Delft, the Netherlands Brassersplein 2, Delft, the Netherlands
Phone: +31 88 86 67078 Phone: +31 88 86 67078
Email: oskar.vandeventer@tno.nl Email: oskar.vandeventer@tno.nl
Omar A. Niamut
TNO
Brassersplein 2, Delft, the Netherlands
Phone: +31 88 86 67218
Email: omar.niamut@tno.nl
Fabian A. Walraven
TNO
Brassersplein 2, Delft, the Netherlands
Phone: +31 88 86 67722
Email: fabian.walraven@tno.nl
Ishan Vaishnavi Ishan Vaishnavi
CWI CWI
Science Park 123, Amsterdam, the Netherlands Science Park 123, Amsterdam, the Netherlands
Phone: +31 20 592 4323 Phone: +31 20 592 4323
Email: i.vaishnavi@cwi.nl Email: i.vaishnavi@cwi.nl
Fernando Boronat Fernando Boronat
IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia
C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, 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
IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia IGIC Institute, Universidad Politecnica de Valencia-Campus de Gandia
C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain C/ Paraninfo, 1, Grao de Gandia, 46730, Valencia, Spain
 End of changes. 60 change blocks. 
114 lines changed or deleted 187 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/