ISO IEC 23009-6:2017 pdf free download.Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 6: DASH with server push and WebSockets.
ISO IEC 23009-6 specifies carriage of MPEG-DASH media presentations over lull duplex HTTP.compatible protocols, particularly HTTP/2 and WebSocker. This carriage takes advantage of the features these protocols support over HTTP/1.1 to improve delivery performance, while still maintaining backwards compatibility, particularly for the delivery of low latency live video.
2 NormatIve references
The following documents are referred to In the text In such a way that some or all of their content constitutes requirements of ISO IEC 23009-6. For dated references, only the edition cited applies. For undated references, the latest edition of the refcrcncril document (including any amendments) applies. IEEE 1003.1-2008, IEEE Standard for Information Technology — Portable Operating System Interface
(P05(X). Base Specifications, Issue 7
IETF RFC 3986, UnIform Resource identifiers (URI): Generic Syntax.jonuory 2005
IETF RFC 6455. The WebSocket Protocol. December2011
IETF RFC 7158, The lavaScript Object Notation (ISON) Data Interchange Format, March 2013
IETF RFC 7231, Hypertext 7)ansfer Protocol (HTTP/l. 1): Semantics and Content june 2014
3 Terms, definitions, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of ISO IEC 23009-6, the following terms, definitions, abbreviated terms and
conventions apply.
ISO and IEC maintain teniiinological databases for use in standardization at the following addresses:
4 Background
The basic mechanisms of MPEG-DASH over HTTP/L1 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 AnnezA for several illustrative use cases. While HTTP/2 and WebSocket are quite different in details, they both allow server-initiated and dient-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 FigureJ. 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 IJRI 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 HT1’P/2 that can benefit from signalling and messages defined In this document.
ligurL1 shows an example DASH session wherein the client requests the MPD Iirst and then the media segments with a push strategy. Initialization data are pushed in response to a push strategy associated to the MPD request. After receiving the requested Ml’D. the client starts requesting video segments from the server with the respective DASH segment URL. and a segment push strategy. Then, the server responds with the requested video segment, followed by the push cycles as indicated by the segment push strategy. Typically, the client starts playing back the video after a minimum amount of data Is received and then the aforementioned process repeats until the end of the media streaming session.
6.13 PushDirective
A PushD tract ive signals the push strategy that a client would like the server to use for delivery of one or more future segments. A PushDirective has a type (described in Tahle3) and depending on the type. may have one or more additional parameters associated with it (described in Table 4).
In general, a client may signal one or more PushDlrectives for a single message. The server may select at most one of the provided push strategies. This mechanism allows for clients to interoperate with servers that allow different push strategies and for forward compatibility, as the new types of push strategies are introduced.
The format ola PushDirect ive in the ABNF form isas follows:
PUSHDIRECTIVE = PUSH3YPE lows ;“ OWS QVALUEI
PUSHTYPE cA PushTpe deli ned in 6.12>
QVAUJE. ‘Ca qvalue, as defined in kit 7231>
When multiple push directives are applied to a request, a client may apply a quality value (qvalue) as Is described for use in content negotiation In RFC 7231. A client may apply higher quality values to directives it wishes to take precedence over alternative directives with a lower quality value. Note that these values are hints to the server and do not Imply that the server will necessarily choose the strategy with the highest quality value. If the quality value qvalue Is not present, the default quality value is 1,0.
6.1.4 PushAck
A Push Acknowledgement (PushAck) is sent from the server to the client to Indicate that the server intends to follow a given push strategy. At most, one Push Acknowledgment may be returned, indicating the push strategy that is in effect at the server. A Push Acknowledgment. depending on the type. may have one or more additional parameters associated with it (described in table4).
The format of the PushAck in the ABNF form Is as follows:
PUSHACK=PUSHJYPE
Where PIJSHTYPE is defined in 6.12.
6.1.5 URLLIsL
A URLList describes a specific set of URIs as a delimited list. A client may use a list to explicitly signal the segments to be pushed during a push transaction. The list of URLs describes the sequence of segments to be pushed within this push transaction.
The URLLLst string format AHNF follows:
IJRL_LIST = LISTJTEM ( OWS ‘,“ OWS LIST_ITEM)
LISTJTEM s 1PPCHAR
Each list element is formed as a tJRL as defined in RFC 3986. If the URL is in relative form, It is considered relative to the segment being requested. See Annezf for examples of the IJRL list under various scenarios.
6.1.6 URlTemplate
A URLTeep1ate describes a specific set of URLs via a template and the corresponding parameters required to expand the template. A client may use a template to explicitly signal the segments to be pushed during a push transaction. The string is formed as a list of individual LJRL templates.