Internet Engineering Task Force M. Sparks Internet-Draft BBC Research and Development Intended status: Experimental June 28, 2012 Expires: December 30, 2012 Service synchronisation for Television And Related devices -- STAR draft-msparks-template-star-00 Abstract Service synchronisation for Television And Related devices (STAR) is a suite of application level protocols to enable network connected devices to correlate events on a broadcast system with events outside that broadcast system. It is a generic suite of protocols, that enables playback of content retrieved from over a network such that it is synchronised to a broadcast source. It also enables correlation of non-broadcast events (such as conversations) to broadcast events. Key features of STAR include: 1) The broadcast system does not require modification 2) It is designed to work with restricted clients limited to stream connections - such as web browsers 3) It is content agnostic. This specification describes the research implementation as it stands today, and is published as a starting point for further discussion. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 30, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Sparks Expires December 30, 2012 [Page 1] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Notational Conventions and Generic Grammar . . . . . . . . 7 2. STAR System Overview . . . . . . . . . . . . . . . . . . . . . 8 2.1. The Broadcast System . . . . . . . . . . . . . . . . . . . 9 2.2. The Broadcast Bridge and Broadcast System . . . . . . . . 9 2.3. Broadcast Bridge Time Services and STAR Client . . . . . . 10 2.4. Broadcast Bridge Programme Services and STAR Client . . . 11 2.5. STAR Additional Services Server . . . . . . . . . . . . . 12 2.5.1. Playout Scripts . . . . . . . . . . . . . . . . . . . 14 2.5.2. Additional data sources . . . . . . . . . . . . . . . 14 2.6. Full Glass System View . . . . . . . . . . . . . . . . . . 14 3. STAR Time Synchronisation . . . . . . . . . . . . . . . . . . 15 3.1. Broad View of Time synchronisation over TCP . . . . . . . 16 3.2. Network Delta Corrected Time Synchonisation over TCP . . . 17 4. STAR Broadcast Bridge Programme Services over TCP . . . . . . 19 4.1. command: time . . . . . . . . . . . . . . . . . . . . . . 20 4.1.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 20 4.1.2. Response format . . . . . . . . . . . . . . . . . . . 20 4.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. command: echotime . . . . . . . . . . . . . . . . . . . . 21 4.2.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 21 4.2.2. Response format . . . . . . . . . . . . . . . . . . . 21 4.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 22 4.3. command: summary . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 22 4.3.2. Response format . . . . . . . . . . . . . . . . . . . 22 4.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 23 4.4. command: services . . . . . . . . . . . . . . . . . . . . 23 4.4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 23 4.4.2. Response format . . . . . . . . . . . . . . . . . . . 23 Sparks Expires December 30, 2012 [Page 2] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 4.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 23 4.5. command: channels . . . . . . . . . . . . . . . . . . . . 23 4.5.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 24 4.5.2. Response format . . . . . . . . . . . . . . . . . . . 24 4.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 24 4.6. command: channel . . . . . . . . . . . . . . . . . . . . . 24 4.6.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 24 4.6.2. Response format . . . . . . . . . . . . . . . . . . . 24 4.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25 4.7. command: service . . . . . . . . . . . . . . . . . . . . . 26 4.7.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 26 4.7.2. Response format . . . . . . . . . . . . . . . . . . . 26 4.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26 5. STAR Broadcast Bridge Programme Services over HTTP . . . . . . 27 5.1. Mapping to HTTP from the TCP Service . . . . . . . . . . . 27 5.2. Example Mappings . . . . . . . . . . . . . . . . . . . . . 27 5.2.1. command: time . . . . . . . . . . . . . . . . . . . . 27 5.2.2. command: echotime . . . . . . . . . . . . . . . . . . 28 5.2.3. command: summary . . . . . . . . . . . . . . . . . . . 28 5.2.4. command: services . . . . . . . . . . . . . . . . . . 28 5.2.5. command: channels . . . . . . . . . . . . . . . . . . 28 5.2.6. command: channel . . . . . . . . . . . . . . . . . . 28 5.2.7. command: service . . . . . . . . . . . . . . . . . . 28 6. STAR Additional Services Server . . . . . . . . . . . . . . . 28 7. STAR Playout Scripts . . . . . . . . . . . . . . . . . . . . . 29 7.1. MIME type . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2. File Format . . . . . . . . . . . . . . . . . . . . . . . 29 7.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 29 7.4. Event types . . . . . . . . . . . . . . . . . . . . . . . 29 7.4.1. Datatype Tags . . . . . . . . . . . . . . . . . . . . 29 7.4.2. Encoding Tags . . . . . . . . . . . . . . . . . . . . 30 7.5. Event data encoding . . . . . . . . . . . . . . . . . . . 30 7.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Future Expansion . . . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10.1. Personal Information - Abuse of Server Logs . . . . . . . 32 10.2. Data encoding and decoding . . . . . . . . . . . . . . . . 32 10.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Sparks Expires December 30, 2012 [Page 3] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 1. Introduction The original specification of xml2rfc format is in RFC 2629 [RFC2629]. 1.1. Purpose Broadcast is a well understood single to many push medium, with modern television broadcast systems being digital broadcast systems. In the USA, the system is ATSC, in Europe DVB is common, with DVB-T, DVB-C and DVB-S widely deployed. Whilst such digital systems have variations, they fundamentally form a lossy data channel from a broadcaster to an audience at a fixed bit rate. This is generally then received by a display which is a shared resource, broadly controlled by the occupants of a single room. Thus what is displayed or played back on the shared display must be of interest to all users of that device (or well known arguments ensue). Digital broadcasts carry a variety of non audio/video data including subtitles, audio description (also called narrative subtitles for the blind), interactive applications, as well as information bundles similar to web pages. Each addition to the broadcast uses up the scarce resource. More data can be squeezed in at the expense (primarily) of picture quality. Each change presents diminishing returns for the broadcaster, despite benefits to the audience, due to the nature of broadcast being a single shared push channel. Furthermore, in order to "fake" a pull approach for data, information on a data channel - such as electronic programme guide (EPG) information - is has to be repeatedly pushed in order to allow clients timely access to data. This data carousel (as it is termed) squeezes the transmission channel even further. Unlike broadcast clients, network clients control their local communications channel, leading to clients pulling services from servers. Being pull based, they are by their nature elective and therefore extremely good for personalised experiences. They can tend to suffer efficiency concerns for very large concurrent audiences, in particular servicing large audiences efficiently without content injection concerns is still hard. Work has previously been done have investigating how to marry the broadcast and IP world. However in many cases they have sought to change the inherent nature of either broadcast from it's shared receiver audio or video nature, or to change network delivery to take control away from the receiver. That is to try and change the network delivery from a pull medium to a push medium. Sparks Expires December 30, 2012 [Page 4] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 Service Synchronisation for Television and Related Devices (STAR) is predicated on the principle of using the broadcast data channel for push aspects of a service in a form useful for the majority of an audience, and using pull-based network delivery for personalisation. These personalisations need to be synchronised relative to the programme being broadcast, and presented to the user at appropriate times. To do this we expose key information about the broadcast data channel over the network, along with defining a means of synchronising with the broadcast data channel, and also a standard play out data format which can be used by a generic client to play out content synchronised to the broadcast. STAR is also assumes that whilst custom clients are possible, clients are most likely to be implemented in restriction environments such as browsers or virtual machines residing in browsers. In practical terms this means that whilst it could operate on top of many transports, it is designed to primarily operate on top of either TCP or HTTP. Thus STAR comprises a small suite of application level protocols that seeks to work with each medium appropriately, forming initial research results in this area. This specification describes the research implementation as it stands today, and is published as a starting point for further discussion. In particular while each protocol could be specified separately, but describing them together retains important context. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant." 1.3. Terminology This specification uses a number of terms to refer to the roles played by participants in, and objects of, a STAR system. Sparks Expires December 30, 2012 [Page 5] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 broadcast An audio/visual transmission over radio or similar system that also includes a time and data signal - such as digital broadcasting or analogue broadcast with a teletext, etc. data channel. digital broadcast A broadcast using a digital broadcast standard such as Digital Video Broadcasting (DVB), or Advanced Television Systems Committee (ATSC). Digital broadcasts typically contain audio, video, subtitles, applications, and metadata regarding the broadcasts - in terms of content and transport. broadcast receiver A standard receiver for a given broadcast system. broadcast time The time specified in a broadcast signal, as recieved by a broadcast reciever. broadcast bridge A broadcast receiver that stores metadata from a given broadcast service. It acts as a server on the network available to be queried by a client. (ie it bridges the push of broadcast and the pull from a network client) play out script Data file that is used to schedule playback of events relative to given times based on event type content server A server that a client can retrieve play out scripts from as well as additional content. client A network connected device capable of playing out 1 or more form of synchronised content. Performs synchronisation with the broadcast bridge, retrieves content from the content server for play out. client clock The actual system clock of the client device. Assumed to be poor quality and unchangeable. application clock A corrected software clock based synchronisation with the broadcast bridge. Does not have a defined accuracy level. Sparks Expires December 30, 2012 [Page 6] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 broadcast time server port A TCP socket listening on the broadcast bridge for a client to connect to. Provides a basic "NOW" time service for client application clocks to synchronised against. Connection is closed by the server. echo broadcast time server port A TCP socket listening on the broadcast bridge for a client to connect to. Provides a basic "NOW" time service for client application clocks to synchronised against. Does this after receiving data from the client. All data sent by the client is echoed back to the client. Connection is closed by the server. repeating echo broadcast time server port A TCP socket listening on the broadcast bridge for a client to connect to. Provides a basic "NOW" time service for client application clocks to synchronised against. Does this after receiving data from the client. All data sent by the client is echoed back to the client. Connection is closed by the client. 1.4. Notational Conventions and Generic Grammar STAR uses the same notational conventions and generic grammar as HTTP/1.1 as defined in RFC 2616. For the purposes of this document: NUMBER = 1*DIGIT TIMESTAMP = NUMBER "." NUMBER COMMAND = 1*ALPHA ARGUMENT = *OCTET STATUS = "OK" | "ERROR" COMMANDTAG = 1*ALPHA JSONRESPONSE = 1*OCTET JSONRESPONSE is required to be a valid JSON object. JSON is defined in RFC 4627. Sparks Expires December 30, 2012 [Page 7] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 2. STAR System Overview +------------------------------------------------------------+ | | | RF IP | | +-----+ +-----+ +-----------------------------------+ | | | B <----> | | | | | | r | | B | | STAR ADDITIONAL SERVICES SERVER | | | | o | | r | | ^ ^ | | | | a | | i | +----|----------------------|-------+ | | | d | | d | | | | | | c | | g | +----|----------------------|-------+ | | | a | | e <-----> V V | | | | s | | | | STAR CLIENT | | | | t | | <-----> | | | +-----+ +-----+ +-----------------------------------+ | | | +------------------------------------------------------------+ Figure 1: Top level STAR consists of 4 main subsystems: o A broadcast system, including a broadcast system and a broadcast client o A broadcast bridge o A STAR client o A STAR additional services server The STAR client protocol is specifically designed to allow clients to be implemented inside a web browser or similarly restricted environment (eg flash or java plugins). Tighter synchronisation accuracy could be achieved by mandating a less restricted environment, but to do so would restrict STAR's applicability & implementability needlessly. Communications in a STAR system includes: o Broadcast within the broadcast system o The broadcast bridge's reception and analysis of the broadcast o Time synchronisation between the STAR client and the broadcast bridge Sparks Expires December 30, 2012 [Page 8] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o Programme information services provided by the broadcast bridge to the STAR client o Synchronised data services from the STAR additional services server provided to the STAR client. These fall into two categories: * Play out scripts * Additional data sources The rest of this section follows the communication in the system. 2.1. The Broadcast System The broadcast system is a digital television service. Such broadcast systems have the following core characteristics: o An audio and video (maybe) service per channel o A time service giving the current time. For example the time and date (TDT) table in DVB suffices here. TDT data is typically broadcast once per second, and represents the time "now". o A programme service describing what programme is on "now". In DVB the event information table information contains a "now and next" service. The now and next service data is sent regularly, but is additionally updated when the broadcast programme changes. Some analogue television services also contain this information, but for the purposes of discussion this document assumes a digital television service. This protocol assumes that the existing broadcast service and broadcast client (eg a TV) are left unmodified. If a service on a non-broadcast client is being played out simultaneously with the broadcast service, then this service needs to be synchronised to the time as received by a broadcast receiver. 2.2. The Broadcast Bridge and Broadcast System The broadcast bridge bridges the "push" of the broadcast world, and the "pull" of the IP based world. In particular, it is a server that contains a broadcast client receiver, and makes available a time service to synchronise against, and now/next programme services over IP for network based clients. The broadcast bridge uses the time signal to synchronise a local Sparks Expires December 30, 2012 [Page 9] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 server clock. In particular a DVB based broadcast bridge can retrieve TDT packets, and use their regularity to set a local clock time and rate of advance. The broadcast bridge also receives the now and next data services, and keeps track of what programmes are being broadcast. This information is then made available over IP. Additionally, the broadcast time at which the now and next information changes is monitored. For the purposes of STAR, this change time is denoted to be "time zero" for the given programme. It is worth noting that whether this is actually time zero depends upon the configuration of the broadcast service. Furthermore the accuracy of time zero also depends upon the configuration of the broadcast service. It is also possible for the broadcast service to include a special marker including the time the programme actually started via the related content table. Additionally, there may be other means to determine the start of the programme. The broadcast bridge is responsible for obtaining this time, and making this available to clients. 2.3. Broadcast Bridge Time Services and STAR Client The broadcast bridge makes available a time service for the STAR client to synchronise against. +------------------------------------------------------------+ | . | | . RF . . IP . | | . | | | . | | | <----> | . | | | S | | B | | | | | y | | r | |--------+ | | | s | | i | | | | | | t | | d <-----> TIME | . | | | e | | g | | SYNC | . | | | | m | | e | | | | | | | +-----+ +-----+ +-----------------------------------+ | | RF IP STAR CLIENT | | | +------------------------------------------------------------+ Figure 2: Time Synchronisation, Relevant subsystems This has the following characteristics: Sparks Expires December 30, 2012 [Page 10] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o The client can request the current time from the broadcast bridge. o The client can request the current time from the broadcast bridge with a payload which the broadcast bridge includes in its response. o The time services are available over both TCP and HTTP The current time service can be used to derive a broad view of time - that is the current time as seen by a broadcast receiver. This can be accurate within a delta proportional to the network round trip time. The echoing time service can be used to calculate an approximation of the network round trip time. This may be useful in circumstances where the network round trip time is likely to be too large relative to the additional service intended to be synchronised against the broadcast service. The reason for using TCP and HTTP and not UDP are as follows: o A tool - dvbdate - exists that provides a means of configuring an NTP server, which can then be used for synchronising time over UDP. o Restricted clients - such as browsers or plugins - were considered desirable. o UDP is not available to browser based components o TCP is commonly available from browser plugins o HTTP is natively available to browser based clients Thus UDP has not been viewed as appropriate. 2.4. Broadcast Bridge Programme Services and STAR Client IP based programme services available are provided by the broadcast bridge to enable a client to determine which programme is currently being broadcast. This can be correlated with other IP based services to locate appropriate data on for playback synchronous to the broadcast service. Prerequisites for this to work: o The programme services must include the actual start time of a programme as broadcast. Sparks Expires December 30, 2012 [Page 11] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o This may be queried over TCP or HTTP, for the same reasons as the time services. The broadcast bridge also provides facilities for: o Identifying what channels the bridge covers, by name and service id o Summary information across all channels o Detailed information on the channel's current state, based on channel or serviceid +------------------------------------------------------------+ | . +--------+ | | . RF . . IP . | | | | . | | <-----> PROG | | | | <----> | | SYNC | | | | S | | B | | | | | | y | | r | |--------+ | | | s | | i | . . | | | t | | d | . . | | | e | | g | . | | | | m | | e | . | | | | +-----+ +-----+ +-----------------------------------+ | | RF IP STAR CLIENT | | | +------------------------------------------------------------+ Figure 3: Programme Services interaction 2.5. STAR Additional Services Server The STAR additional services server provides 2 core services: o Play out scripts, which describe what events to play out when o Data storage for data to playback from playout scripts. Play out scripts are not required to be limited to playback of data from the data storage. In all cases it is expected that these scripts and data are to be retrieved over HTTP. Sparks Expires December 30, 2012 [Page 12] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 . - --------------------------------------+ | STAR ADDITIONAL SERVICES SERVER | +-----------------------------------+ | | | | | | . | Play out | Additional | | | Scripts | data sources | | | ^ | ^ | | -------|-----------|-------+ | | | | .---------|-----------V-------+ | | V | Output Dev 1 | | | |--------------| | | | Output Dev 2 | | | Play out |--------------| | --+ | Output Dev 3 | | | Core |--------------| | | | ... | | . | |--------------| | | | | Output Dev N | | . +-----------------------------------+ | . STAR CLIENT | | | +-----------------------------------------------+ Figure 4: Playout subsystems' interactions A client may have many output means, which can be considered to include text, links, audio, video, and event send messages to a serial port for controlling (for example) arduino based devices, synchronous to the broadcast. Three possible alternatives to a play out script delivered over HTTP are as follows: o To repeatedly poll the server with a "what do I do now message". For services with low levels of service, this may be appropriate, but for nationwide services, this is not a scalable approach, and was discounted on that basis. o To open a connection to the server, and wait for event data to be sent over the connection. Whilst this limits connection set up and tear down, this could for popular events require a server handle millions of connections held open for long periods of time and data delivered instantaneously to all the clients concurrently. This was not deemed scalable. Sparks Expires December 30, 2012 [Page 13] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o The client opens an XMPP connection, and receiving data over that connection from an XMPP group. This is a promising approach, but raises the implementation bar to that of implementing an XMPP client. It also requires the client to remain connected. In all 3 cases, unlike the downloaded file approach, these approaches preclude pre-caching data for playback. For this reason, a play out file was considered more appropriate. 2.5.1. Playout Scripts Playout scripts are files consisting of a list of events. This file is UTF8 encoded, and contains a JSON object. Events denote times into the programme, the type of the event, and an opaque data blob relating to the event. The interpretation of the blob depends on the type. 3 types are considered critical: o Plain text o Base 64 encoded data. o URLs 2.5.2. Additional data sources Due to the fact that additional data sources may be linked to by an URL may be audio, video, text, web pages, and more. If the client does not understand how to interpret the URL, it should pass the interpretation over to a web browser. 2.6. Full Glass System View Figure 5 shows all the subsystems and their interactions. Sparks Expires December 30, 2012 [Page 14] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 +------------------------------------------------------------+ | | | RF IP STAR ADDITIONAL SERVICES SERVER | | +-----+ +-----+ +-----------------------------------+ | | | B <----> B | | | | | | | | r | | r | | Content | Play out | Additional | | | | o | | o | | Server | Scripts | data sources | | | | a | | a | | ^ | ^ | ^ | | | | d | | d | +-----|---------|-----------|-------+ | | | c | | c | | | | | | | a | | a | +-----|---------|-----------V-------+ | | | s | | s | | V | V | Output Dev 1 | | | | t | | t <-----> PROG | |--------------| | | | | | | | SYNC | | Output Dev 2 | | | | S | | B | | | Play out |--------------| | | | y | | r | |--------+ | Output Dev 3 | | | | s | | i | | | Core |--------------| | | | t | | d <-----> TIME | | ... | | | | e | | g | | SYNC | |--------------| | | | m | | e | | | | Output Dev N | | | +-----+ +-----+ +-----------------------------------+ | | STAR CLIENT | | | +------------------------------------------------------------+ Figure 5: Glass view 3. STAR Time Synchronisation Clock synchronisation is a complex topic, and this specification takes a necessarily simplistic view for the following reasons: o Expected clients include javascript within a browser. This means sync will happen over HTTP. The many layers involved limit the effectiveness of aiming for extremely tight sync. o STAR time synchronisation is therefore primarily concerned with synchronising browser events, and simplicity aids implementation. o For some applications, accuracy of within a second or so is acceptable. For others, accuracy down to 40ms is desirable. Going beyond this would appear to require a UDP based service. Sparks Expires December 30, 2012 [Page 15] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 +------------------------------------------------------------+ | . | | . RF . . IP . | | . | | | . | | | <----> | . | | | S | | B | | | | | y | | r | |--------+ | | | s | | i | | | | | | t | | d <-----> TIME | . | | | e | | g | | SYNC | . | | | | m | | e | | | | | | | +-----+ +-----+ +-----------------------------------+ | | RF IP STAR CLIENT | | | +------------------------------------------------------------+ Figure 6: Time Synchronisation, Relevant subsystems Application clock synchronisation occurs as follows: o The client synchronises an application clock against a broad view of time with the broadcast bridge. o The client may attempt to calculate the error incurred by the network traversal - the network delta. The approach taken is deliberately simple at the possible expense of accuracy. 3.1. Broad View of Time synchronisation over TCP The client connects to the broadcast time server port on the broadcast bridge. The client does not send any data. The server's response is a sequence of octets, that are terminated by the server closing the connection. The sequence of octets sent forms a TIMESTAMP as defined above. That time-stamp is a string representation of a floating point value. That float represents the number of seconds since the beginning of the Unix epoch - ie the number of seconds since 00:00:00 UTC on 1 January 1970. The time obtained is a broadcast time as defined above. This defines the broadcast view of time (BVT) according to a broadcast receiver at a given instant. These are received by the client at a given local clock (LC) times from the client clock. In order to gain a broad view of time, the client needs to get two such timestamps - BVT1 and BVT2. These correspond to local clock times LC1 and LC2. The further these sets of timestamps, the better. Sparks Expires December 30, 2012 [Page 16] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 Using these times, the client can define a local application clock using BVT1, BVT2, LC1, and LC2. For brevity this is defined here in python: class BroadViewClock(object): def __init__(self, BVT1, BVT2, LC1, LC2): "Configure application clock" remote_elapsed = BVT2 - BVT1 local_elapsed = LC2 - LC1 self.ratio = remote_elapsed / local_elapsed self.remote_baseline = BVT1 self.local_baseline = LC1 def sleep(self, time_in_remote_seconds): "Sleep for a period time counted in broadcast seconds" sleeptime = time_in_remote_seconds / self.ratio time.sleep(sleeptime) def time(self): "Return the current time according to broadcast" now = time.time() local_elapsed = now - self.local_baseline remote_elapsed = local_elapsed * self.ratio remote_now = self.remote_baseline + remote_elapsed return remote_now ApplicationClock = BroadViewClock(BVT1, BVT2, LC1, LC2) The accuracy of this broad view of time application clock depends on the network latency between the client and the broadcast bridge. For some applications, this delay will be acceptable. For many applications it will be desirable to attempt to eliminate the network delta. 3.2. Network Delta Corrected Time Synchonisation over TCP The client initialises a client application clock which is a BroadViewClock as defined in 2.1 above. The client connects to the echo broadcast time server port on the broadcast bridge. Upon connecting the client sends time request of the following form: TIMEREQUEST = TIMESTAMP CRLF That is it send an octet stream which is a string representation of a float, representing a timestamp of the number of seconds since the start of the unix epoch, followed by a CRLF sequence. Sparks Expires December 30, 2012 [Page 17] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 The server response is as follows: BLOBRESPONSE = 1*OCTET ECHOTIME = BLOBRESPONSE " " TIMESTAMP The server then terminates the connection. BLOBRESPONSE as defined here is whatever data the client sends the server. Whilst the client MUST send data in the form defined as TIMEREQUEST, the server must be lenient and respond with whatever was sent as blob response. Using the BroadViewClock, the client can build on BroadViewClock to create a new application clock which removes the network delta as follows: class NetworkCorrectedBroadcastClock(object): def __init__(self, application_clock, network_delta): self.application_clock = application_clock self.network_delta = network_delta def sleep(self, delay): self.application_clock.sleep(delay) def time(self): self.application_clock.time() + self.network_delta BVT1, BVT2, LC1, LC2 -- Obtained as before CoarseApplicationClock = BroadViewClock(BVT1, BVT2, LC1, LC2) TOLERANCE = 0.01 # 10ms WITHIN_TOLERANCE = False while not WITHIN_TOLERANCE: sendtime = CoarseApplicationClock.time() sendtime_for_network = str(float(sendtime)) # sendtime_for_network and BLOBRESPONSE should be identical BLOBRESPONSE, TIMESTAMP = EchoTimeRequest(sendtime_for_network, server=broadcastbridge, port=echo_time_port) # Assuming network delays are constant within a certain delta, # the following two values should be identical or close to # identical remote_now = float(TIMESTAMP) now = CoarseApplicationClock.time() Sparks Expires December 30, 2012 [Page 18] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 if abs(remote_now - now) < TOLERANCE: WITHIN_TOLERANCE = True # Assume network is symmetrical network_delta = (remote_now - sendtime)/2 BetterApplicationClock = NetworkCorrectedBroadcastClock( CoarseApplicationClock, network_delta) At this point the client then has a network corrected local clock locked to the same clock as broadcast, within a reasonable tolerance. 4. STAR Broadcast Bridge Programme Services over TCP +------------------------------------------------------------+ | | . . . . +---------- - . | . . | | | | . . . <-----> PROG | | | | <----> | | SYNC | | | | S | | B | | | | | | y | | r | |--------+ | | | s | | i | | . | | | t | | d | . | | | e | | g | . | | | m | | e | | | +-----+ +-----+ STAR CLIENT | | RF IP | | | +------------------------------------------------------------+ Figure 7: Programme Time Synchronisation, Relevant subsystems Programme Services are provided on a request/response basis. The client connects to the broadcast bridge programme port and sends a REQUEST matching the following: REQUEST = COMMAND " " ARGUMENT CRLF Note that the command is terminated by a blank line. The server sends a RESPONSE as follows: Sparks Expires December 30, 2012 [Page 19] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 RESPONSE = STATUS " " COMMANDTAG " " JSONRESPONSE The response is terminated by closing the connection. If the status is ERROR, the client should handle the error gracefully. COMMANDTAG is always relative to the command the client sent to the server. Commands the broadcast bridge MUST implement: o time o echotime o summary Commands the broadcast bridge SHOULD implement: o services o channels o channel o service Note: The server is expected to lower case all commands and arguments on the way into the server. 4.1. command: time This provides an alternative interface to the timing subsystem, and can be used in much the same way. It has a higher parsing overhead, and hence speed penalty. 4.1.1. Arguments None 4.1.2. Response format The response is a JSON object with 3 name value pairs: o time - Number of seconds since the Unix Epoch. The timezone is defined to be UTC. o elemental - 9 element array representation of the same time, consisting of: Sparks Expires December 30, 2012 [Page 20] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 * year - integer representing the full year * month - integer in range 1..12 * day of month - integer day of the month * hour - integer * minute - integer * seconds - integer * weekday - integer in range 0..6, where monday is 0. * day of year - counting from 1 * daylight savings flag + 0 means no daylight savings adjustment has taken place + 1 means time is adjusted for daylight savings o textual - Again, the same time as a human readable time/date. This should be treated as human readable and machine opaque. 4.1.3. Example SEND: time RECV: OK TIME {"elemental": [2010, 7, 5, 17, 21, 10, 0, 186, 1], "textual": "Mon Jul 5 17:21:10 2010", "time": 1278346870.0} 4.2. command: echotime This provides an alternative interface to the timing subsystem, and can be used in much the same way. It has a higher parsing overhead, and hence speed penalty. 4.2.1. Arguments TIMESTAMP - as defined above 4.2.2. Response format The response is a JSON object with 4 name value pairs: o time - Number of seconds since the Unix Epoch. The timezone is defined to be UTC. Sparks Expires December 30, 2012 [Page 21] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o elemental - 9 element array representation of time as defined before in section 4.1.2 o textual - Same time as a human readable time/date. As in 4.1.2 this is defined as machine opaque and human readable. o echo - Contains whatever the client sent as TIMESTAMP 4.2.3. Example SEND: echotime 1278346870.0 RECV: OK TIME {"echo": "1278346870.0", "elemental": [2010, 7, 5, 17, 21, 15, 0, 186, 1], "textual": "Mon Jul 5 17:21:15 2010", "time": 1278346875.0} 4.3. command: summary Provides a quick lookup mechanism of channel name, programme and start time. 4.3.1. Arguments None 4.3.2. Response format The response is a JSON object with as many name value pairs as channels the broadcast bridge can receive. Each pair has the same format: o channelname - which may be either: * the human readable name of the channel from the broadcasting system * The symbolic service id for the channel on this broadcast system. o A value is an array consisting of 2 values * First value is TIMESTAMP when programme started * Second value is Programme name This format means that the summary contains duplication of information. The reason for this is to enable clients to be simpler to implement. Sparks Expires December 30, 2012 [Page 22] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 4.3.3. Example SEND: summary RECV: OK SUMMARY {"bbc one": [1278346448.0, "The Weakest Link"], "bbc two": [1278346554.0, "Escape to the Country"], "cbeebies": [1278346632.0, "ZingZillas"], "cbbc channel": [1278346613.0, "ROY"], "bbc radio 1": [1278342000.0, "Scott Mills"], "bbc radio 2": [1278345900.0, "Simon Mayo"], "bbc radio 3": [1278345610.0, "In Tune"], "bbc radio 4": [1278345610.0, "PM"], "4168": [1278346448.0, "The Weakest Link"], "4287": [1278346554.0, "Escape to the Country"], "4672": [1278346632.0, "ZingZillas"], "4608": [1278346613.0, "ROY"], "6720": [1278342000.0, "Scott Mills"], "6784": [1278345900.0, "Simon Mayo"], "6848": [1278345610.0, "In Tune"], "6912": [1278345610.0, "PM"]} 4.4. command: services This command returns the list of services available on the bridge. The reason for this is to accommodate automated lookups based upon service ids used in the broadcast system rather than based on channel name. 4.4.1. Arguments None 4.4.2. Response format The response is a JSON object which is an array of integers, each one representing the service ids which may be queried. 4.4.3. Example SEND: services RECV: OK SERVICES [4288, 4544, 6016, 5952, 6784, 4168, 5760, 6720, 5888, 4352, 4416, 6848, 5632, 4608, 4672, 7168, 4736, 5824, 6912, 5696, 4287] 4.5. command: channels This command returns the list of channels available on the bridge. This uses the names of the channels as used by the broadcast system. Sparks Expires December 30, 2012 [Page 23] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 4.5.1. Arguments None 4.5.2. Response format The response is a JSON object which is an array of strings, where each string is a channel name available on the bridge. 4.5.3. Example SEND: channels RECV: OK CHANNELS ["bbc one", "bbc two", "cbeebies", "cbbc channel", "bbc radio 1", "bbc radio 2", "bbc radio 3", "bbc radio 4"] 4.6. command: channel This command returns all the information the broadcast bridge has on a particular channel at that instant. This provides a bridged version of the current "now and next" information for the channel. In particular, the dates and time information are provided "as is" from the broadcast system. 4.6.1. Arguments *OCTET - String that represents a channel name 4.6.2. Response format Contains a JSON object with 2 name value pairs: o channel - value is a string with the channel name o info - value is another JSON object with 3 name value pairs: * changed - value is a floating point value which is the number of seconds since the Unix Epoch. Represents when the now and next information changed. * NOW - now/next JSON object (see below) where the "when" value is "NOW" * NEXT - now/next JSON object (see below) where the "when" value is "NEXT" A now/next JSON object is a JSON object with 8 name value pairs: Sparks Expires December 30, 2012 [Page 24] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o name - string with the name of the programme the now/next object refers to o description - a string containing a human readable description of the programme. o startdate - an array of integers, representing [year, month, day] o starttime - an array of integers, representing [hours, minutes, seconds] o duration - an array of integers, representing [hours, minutes, seconds] o when - a string which is either "NOW" or "NEXT" o service - an integer which is the broadcast service id o transportstream - an integer which is the broadcast service id 4.6.3. Example SEND: channel bbc one RECV: OK CHANNEL { "channel": "bbc one", "info": {"NEXT": {"startdate": [2010, 7, 5], "name": "BBC News at Six", "service": 4168, "when": "NEXT", "duration": [0, 30, 0], "starttime": [17, 0, 0], "transportstream": 4168, "description": "The latest national and international news stories from the BBC News team, followed by weather. [S]" }, "changed": 1278346448.0, Sparks Expires December 30, 2012 [Page 25] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 "NOW": {"startdate": [2010, 7, 5], "name": "The Weakest Link", "service": 4168, "when": "NOW", "duration": [0, 45, 0], "starttime": [16, 15, 0], "transportstream": 4168, "description": "Anne Robinson presents the quick- fire general knowledge quiz in which contestants must decide at the end of each round which of their number should be eliminated. [S]" } } } 4.7. command: service This command returns all the information the broadcast bridge has on a particular channel, identified by broadcast system service id at that instant. 4.7.1. Arguments *OCTET - String that represents a service number 4.7.2. Response format The response format is the same as the command "channel" 4.7.3. Example SEND: service 4287 RECV: OK CHANNEL { "info": { "channel": "bbc two" "NEXT": { "startdate": [2010, 7, 5], " "name": "Eggheads", "service": 4287, "when": "NEXT", "duration": [0, 30, 0], "starttime": [17, 0, 0], "transportstream": 4168, "description": "General knowledge quiz in which teams from all over the UK battle to beat the Eggheads, some of the country's top quiz champions. Also in HD. [S]"}, Sparks Expires December 30, 2012 [Page 26] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 "changed": 1278346554.0, "NOW": { "startdate": [2010, 7, 5], "name": "Escape to the Country", "service": 4287, "when": "NOW", "duration": [0, 45, 0], "starttime": [16, 15, 0], "transportstream": 4168, "description": "New Forest: Series in which prospective buyers are helped to find their dream home in the country. Jules Hudson helps a couple with a budget of 650,000 pounds find a house in the New Forest. [S]"} }, } 5. STAR Broadcast Bridge Programme Services over HTTP 5.1. Mapping to HTTP from the TCP Service This provides a basic web based API to access the same commands as the TCP command format. The broadcast bridge presents itself on the following form of URL: http://example.com/bridge?command= http://example.com/bridge?command=&args= The response type for URLs of the format above is application/json, and the format/structure matches the TCP version precisely. CMD is any command from the TCP version which does not take any arguments. CMDA is any command from the TCP version which takes at least one argument. The argument it takes is passed through in args. 5.2. Example Mappings 5.2.1. command: time http://example.com/bridge?command=time Sparks Expires December 30, 2012 [Page 27] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 5.2.2. command: echotime http://example.com/bridge?command=echotime&args=1278346870.0 5.2.3. command: summary http://example.com/bridge?command=summary 5.2.4. command: services http://example.com/bridge?command=services 5.2.5. command: channels http://example.com/bridge?command=channels 5.2.6. command: channel http://example.com/bridge?command=channel&args=bbc%20one 5.2.7. command: service http://example.com/bridge?command=service&args=4287 6. STAR Additional Services Server After synchronising a clock, and after retrieving programme start times, the STAR client (which may be a javascript based client inside a web page) can then choose to retrieve a play out script from the STAR additional services server. How this happens precisely is left as an exercise to an implementer. One approach that is feasible is as follows: o A broadcaster publishes a schedule online with programme names, times and a unique id. o Using the broadcast bridge, the STAR client identifies the current programme, allowing the identification of the unique id. o The STAR client can then request from a web service the specific play out script for that programme. There are clearly other feasible approaches, and STAR is not prescriptive about any particular approach. That play out script MAY be delivered over HTTP. Sparks Expires December 30, 2012 [Page 28] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 7. STAR Playout Scripts 7.1. MIME type The MIME type of play out script is application/json. 7.2. File Format The STAR play out script o is a UTF8 encoded o contains a JSON encoded object. The JSON object: o is an array of events Each event is an array consisting of 3 values: o The first value is a float representing a timestamp - see 7.3 o The second is an event type - see 7.4 o The third is event data - see 7.5 7.3. Timestamps Timestamps are defined to be relative to time zero of the programme as defined above. 7.4. Event types Event type is defined as follows EVENT TYPE = *ENCODINGTAG DATATYPETAG ENCODINGTAG = ( "INLINE" | "BASE64"|"URL") ";" DATATYPETAG = MIMETYPE | CUSTOMTYPE CUSTOMTYPE = DOMAIN "/" *OCTECT ie An optional (encoding tag and semicolon) preceding a base type. 7.4.1. Datatype Tags A base type may be: o a standard MIME Type Sparks Expires December 30, 2012 [Page 29] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o An application's custom type. As defined above an application's custom type is defined in terms of DOMAINNAME followed by a "/" followed by any text. It is up to the entity that owns the domain DOMAINNAME to publish and manage that namespace. 7.4.2. Encoding Tags The encoding tag defines how to interpret the encoding of the event data: o "INLINE" - means to treat the event data as raw data of the type given (eg textual) o "BASE64" - means that the event data inline is the data of the given datatype, but is base64 encoded. (This allows for example a small audio/wav file to be represented inline. This is expected to be a rare necessity but potentially useful) o "URL" - means to treat the event data as an URL to download and interpret at the given time. Given the encoding tag is optional, if the encoding tag is not supplied, then the following rules are used to determine the encoding: o If the datatype tag is the MIME type "text/plain" then the encoding tag is inline o Otherwise the encoding tag is assumed to be URL (This allows for example a small audio/wav file to be represented inline. This is expected to be a rare necessity but potentially useful) 7.5. Event data encoding The actual event data interpretation is just a string. If the data encoding is an URL: o Then the STAR client accesses the resource indicated by the URL and uses that resource as the event data. If the data encoding is BASE64: o Then the STAR client decodes the BASE64 encoded data, and uses that as the event data Otherwise the data encoding is INLINE: Sparks Expires December 30, 2012 [Page 30] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 o This means the STAR client just treats the raw data as the event data. The data is then interpreted according to local rules for the given MIME type. 7.6. Example Given the following (tidied) example: [[0, "text/plain", "Programme Start"], [0.5, "audio/wav", "http://www.example.com/example.wav"], [1.0, "BASE64;image/vnd.microsoft.icon", 'AAABAAIAEBAAAAAAABo...'], [1.5, "URL;example.com/game", "http://www.example.com/games/gam"], [2.0, "example.com/serial", "http://www.example.com/ardunio/robo"], ... ] Time 0 is interpreted as as text/plain - which may be displayed on a screen, or spoken. Time 0.5 is interpreted as an URL to download and then treat as an audio/wav file. Time 1.0 is interpreted an inline embedded ".ico" file, which is base 64 encoded in the data field. Time 1.5 is interpreted as an URL to download and then treat according to the rules defined by the entity owning "example.com" as the datatype "example.com/game". Time 2.0 is interpreted as an URL to download and then treat according to the rules defined by the entity owning "example.com" as the datatype "example.com/serial". For example, this could mean to take whatever data is sent back and to send that to the serial port, controlling an arduino controlled robot. 8. Future Expansion Future expansion of datatype tags is provided through the standard IANA MIME types, and also by the custom datatype tag formats which may be managed by the owner of a domain name. 9. IANA Considerations This memo includes no request to IANA. Sparks Expires December 30, 2012 [Page 31] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 This document describes an experimental protocol. It re-uses the existing IANA namespace for defining datatype tags, and additionally defines a mechanism for users of the protocol to define their own namespace for defining datatype tags, and maintaining this within their organisation. As a result this protocol has no IANA considerations. 10. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. This section is meant to inform application developers, information providers, and users of the security limitations in STAR as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks. It is not warranted to be exhaustive. 10.1. Personal Information - Abuse of Server Logs The server enables the maintainer of the broadcast bridge to identify what programmes particular IPs are using. If the maintainer of the broadcast bridge or additional services server store cookies, then they are potentially able to identify particular individuals. Since the event file format is defined to automatically download URLS in the file, if the client does this at the same time as the moment in the programme occurs, then the maintainer of the broadcast bridge is able to track which users are watching how much of what programme through the broadcast bridge log data. The client is not required to download the URLs at that instant, and may download the content beforehand, which mitigates this risk. 10.2. Data encoding and decoding JSON format data is directly interpretable in a number of languages, including actionscript, javascript, and python. If the creator of the client fails to use a parser, this opens the client up to well known attacks. Similarly, assuming BASE64 encoded data is BASE64 encoded without any conversion errors would open up the client to well known attacks. Sparks Expires December 30, 2012 [Page 32] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 10.3. Denial of Service It is possible for a badly crafted file to cause a denial of service attack on the additional services store. For example, if all the timestamps were "0", this would mean "interpret all these events as being at time 0". This could cause a very large number of concurrent requests against the additional services store, albeit by accident. Hijacking of a site and replacement of the play out script with a malicious play out script could result in a similar effect. 11. Acknowledgements This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822. Also, this specification is inspired by HTTP to be content agnostic and extensible, and additionally by the semantic web approach of allowing namespaces interpretation to be owned by a group. The time synchronisation approach is based very loosely on a simplification of the core ideas of a number of time synchronisation protocols. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Appendix A. Additional Stuff This becomes an Appendix. Sparks Expires December 30, 2012 [Page 33] Internet-Draft STAR: IP & Broadcast Synchronisation June 2012 Author's Address Michael Sparks BBC Research and Development BBC R & D North Lab Dock House MediaCityUK Salford, M50 2LH UK Phone: +44 303 040 9510 Email: michael.sparks@bbc.co.uk Sparks Expires December 30, 2012 [Page 34]