ISO/IEC 23009-6:2017 pdf download – Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 6: DASH with server push and WebSockets.
4 Background The basic mechanisms of MPEG-DASH over HTTP/1.1 can be augmented by utilizing the new features and capabilities that are provided by the more recent Internet protocols such as HTTP/2 and WebSocket; see Annex A for several illustrative use cases. While HTTP/2 and WebSocket are quite different in details, they both allow server-initiated and client-initiated transactions, data request cancelation and multiplexing of multiple data responses. While in the case of HTTP/2 it is possible to carry DASH presentations without additional support, these new capabilities can be used to reduce the transmission delay (latency). Also, both HTTP/2 and WebSocket are designed to interoperate with existing HTTP/1.1 infrastructure, allowing for graceful fallback to HTTP/1.1 when the more recent protocol is not available. The overall workflow of MPEG-DASH over these protocols is shown in Figure 1. The client and server first initiate a media channel, where the server can actively push data to the other (enabled by HTTP/2 server push or WebSocket messaging). The media channel may be established via the HTTP/1.1 protocol upgrade mechanism or by some other means. After the connection is established, the DASH client requests the media or the MPD from the server, with a URI and a push strategy. This strategy informs the server about how the client would like media delivery to occur (initiated by the server or initiated by the client). Once the server receives the request, it responds with the requested data and initializes the push cycle as defined in the push strategy. Annex B shows a typical end-to-end video streaming system over HTTP/2 that can benefit from signalling and messages defined in this document. Figure 1 shows an example DASH session wherein the client requests the MPD first and then the media segments with a push strategy. Initialization data are pushed in response to a push strategy associated to the MPD request.
This document defines the signalling and message formats for driving the delivery of MPEG-DASH media presentations over full-duplex HTTP-compatible protocols. Details are provided for utilizing this signalling over the HTTP/2 (Clause 7) and the WebSocket (Clause 8) protocols. Annex C provides examples of HTTP/2 client/server behaviour implementing signalling and message formats defined in this document. Annex D provides examples of WebSocket client/server behaviour implementing signalling and message formats defined in this document. Annex E illustrates the HTTP protocol upgrade and fallback procedure for WebSocket. These informational annexes are provided to demonstrate the use of the specified signalling and message formats to build streaming systems that take advantage of the full-duplex capabilities of the underlying transport protocol. 6? Definitions 6.1? Data? type? definitions 6.1.1 General Clause 6 describes a number of primitive data types (see Table 1) used to define the signalling over protocols addressed in this document. Details for implementing these primitives for a given protocol may be found in the subclause of this document defining that binding.
6.1.2 PushType A PushType is the description of a push strategy. It contains a name identifying the push strategy and possibly its associated parameters. The format of a PushType in the ABNF form is as follows: PUSH_TYPE = PUSH_TYPE_NAME [ OWS “;” OWS PUSH_PARAMS] PUSH_TYPE_NAME = DQUOTE <URN> DQUOTE PUSH_PARAMS = PUSH_PARAM *( OWS “;” OWS PUSH_PARAM ) PUSH_PARAM = 1*PPCHAR Where, ‘<URN>’ syntax is defined in RFC 2141. Valid values for this URN according to this document are defined in Table 3, ‘OWS’ is defined in RFC 7230, 3.2.3 and represents optional whitespace. The definition of PUSH_PARAMS is generic to allow the definition of new push strategies without any limitation on their parameters. Each push strategy adds some restriction on the number and on the definitions of the PUSH_PARAM instances used with it. Valid values for PUSH_PARAMS are defined in Table 4. EXAMPLE If the push strategy expects a parameter of type ‘INTEGER’, then there is only one ‘PUSH_PARAM’ defined by ‘INTEGER’ as in 3.2. If it expects a parameter of type ‘URLTemplate’, then there is only one ‘PUSH_ PARAM’ defined by ‘URLTemplate’ as in 6.1.6.