H.2 MPD Delta MIME Type

26.2473GPPProgressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)Release 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

H.2.1 Introduction

This Annex provides the formal MIME type registration for the MPD Delta. The MIME type is registered with IANA and available at http://www.iana.org/assignments/media-types/application/dashdelta.

H.2.2 MIME Type and Subtype

The MIME Type and Subtype are defined as follows:

– Media Type Name: application

– Subtype name: Standards Tree – dashdelta

– Required parameters: none

– Optional parameters: none

– Encoding considerations: 8-bit text

– Security considerations:

A Media Presentation Description (MPD) Delta contains text changes to an MPD. An MPD Delta is used together with a first MPD to construct a second MPD. As such, any security considerations for an MPD (media type application/dash+xml) may also be applicable to an MPD Delta. A MIME type handler would not launch a service with only an MPD Delta.

Further to this, as an MPD Delta performs editing operations on an MPD there are risks that deliberately malformed editing operations could cause security issues.

– Interoperability considerations:

– Published specification: 3GPP TS 26.247

– Applications which use this media type:

various including but not limited to On-Demand Streaming over the Internet, Live Streaming over the Internet, Internet Video, Internet Radio

– Additional information:

1) 1. Magic number(s) : none

2) 2. File extension(s) : mpdd

3) 3. Macintosh file type code : none

4) 4. Object Identifiers: none

– Person to contact for further information:

1) 1. Name : David Furbeck

2) 2. Email : dfurbeck@blackberry.com

– Intended usage : Common

– Author/Change controller : 3GPP TSG SA WG4

Annex I (informative):
Signalling of DASH AVP values for QoS handling in the PCC

The PCC architecture is defined in TS 23.203 [31] and provides the Rx reference point, which enables the application layer to authorize a specific usage. In this architecture the DASH HTTP streaming server or any other function in the HTTP streaming path (e.g. an HTTP proxy) can act as Application Function and interact with the PCRF via the Rx reference point for QoS control. It is assumed here that the AF has knowledge of the application type and of the MPD.

The relevant AVPs are the ones enabling the PCRF to establish bearers with correct characteristics for DASH users. The AVPs are defined in TS 29.214 [33]. The further PCRF mapping from AVP to IP QoS parameter mapping is defined in TS 29.213 [32]

Table I.1: Example mapping of MPD parameters to Rx AVPs for 3GP-DASH (PSS)

AVP	Value	Comment
AF-Application-Identifier	"DASH"	Allows to signal the DASH based application hence giving the opportunity to enforce application specific policies
Max-Requested-Bandwidth-DL (NOTE 1)	B1	B1 = sum of all MPD@maxBandwidth (see clause 8.4.3.3) of all media components simultaneously (not mutually exclusive) selectable by the DASH client plus HTTP/TCP/IP overhead and TCP messages for flow control. If this attribute is not present then B1 = sum of MPD@bandwidth attributes of all media components of the available media presentation corresponding to representations or subrepresentations with highest bandwidth simultaneously selectable (not mutually exclusive) by the DASH client plus HTTP/TCP/IP overhead and TCP messages for flow control. Note: the mapping rules to derive the TCP message flow control bandwidth are FFS.
Max-Requested-Bandwidth-UL (NOTE 1)	FFS	For Further Study. If included, should be greater than or equal to Min-Requested-Bandwidth-UL
Min-Requested-Bandwidth-DL (NOTE 1)	B2	B2 = sum of all MPD@minBandwidth (see clause 8.4.3.3) of all media components simultaneously (not mutually exclusive) selectable by the DASH client plus HTTP/TCP/IP overhead and TCP messages for flow control. If this attribute is not present then B2 = sum of MPD@bandwidth attributes of all media components of the available media presentation corresponding to representations or subrepresentations with lowest bandwidth simultaneously (not mutually exclusive) selectable by the DASH client plus HTTP/TCP/IP overhead and TCP messages for flow control. Note: the mapping rules to derive the TCP message flow control bandwidth are FFS.
Min-Requested-Bandwidth-UL (NOTE 1)	FFS	For Further Study. Enough bitrate to cover TCP and HTTP GET requests.
Flow-Description AVP (NOTE 1)	IP addresses and ports

NOTE 1: AVPs provided within the Media-Component-Description AVP, except Flow-Description AVP that is included within the Media-Sub-Component AVP. Omitted AVPs are not relevant for this functionality.

Annex J (normative):
MIME Type Registration for QoE Reports