5 Protocols
26.2343GPPProtocols and codecsRelease 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS
5.1 Session establishment
Session establishment refers to the method by which a PSS client obtains the initial session description. The initial session description can e.g. be a presentation description, a scene description or just an URL to the content.
A PSS client shall support initial session descriptions specified in one of the following formats: SDP, or plain RTSP URL.
In addition to rtsp:// the PSS client shall support URLs [60] to valid initial session descriptions starting with file:// (for locally stored files) and http:// (for presentation descriptions or scene descriptions delivered via HTTP).
Example for valid inputs to a PSS client: rtsp://example.com/morning_news.
URLs can be made available to a PSS client in many different ways. It is out of the scope of this specification to mandate any specific mechanism. However, an application using the 3GPP PSS shall at least support URLs of the above type, specified or selected by the user.
The preferred way would be to embed URLs to initial session descriptions within HTML or WML pages. Browser applications that support the HTTP protocol could then download the initial session description and pass the content to the PSS client for further processing. How exactly this is done is an implementation specific issue and out of the scope of this specification.
As an alternative to conventional streaming, a PSS client should also support progressive download of 3GP files [50] delivered via HTTP or the Dynamic Adaptive Streaming over HTTP as defined in 3GPP TS 26.247 [112]. Session Establishment for Progressive Download Dynamic Adaptive Streaming over HTTP as defined in 3GPP TS 26.247 [112], clause 5.
5.2 Capability exchange
5.2.1 General
Capability exchange is an important functionality in the PSS. It enables PSS servers to provide a wide range of devices with content suitable for the particular device in question. Another very important task is to provide a smooth transition between different releases of PSS. Therefore, PSS clients and servers should support capability exchange.
The specification of capability exchange for PSS is divided into two parts. The normative part contained in clause 5.2 and an informative part in clause A.4 in Annex A of the present document. The normative part gives all the necessary requirements that a client or server shall conform to when implementing capability exchange in the PSS. The informative part provides additional important information for understanding the concept and usage of the functionality. It is recommended to read clause A.4 in Annex A before continuing with clauses 5.2.2-5.2.7.
5.2.2 The device capability profile structure
A device capability profile is an RDF [41] document that follows the structure of the CC/PP framework [39] and the CC/PP application UAProf [40]. Attributes are used to specify device capabilities and preferences. A set of attribute names, permissible values and semantics constitute a CC/PP vocabulary, which is defined by an RDF schema. For PSS, the UAProf vocabulary is reused and an additional PSS specific vocabulary is defined. The details can be found in clause 5.2.3. The syntax of the attributes is defined in the vocabulary schema, but also, to some extent, the semantics. A PSS device capability profile is an instance of the schema (UAProf and/or the PSS specific schema) and shall follow the rules governing the formation of a profile given in the CC/PP specification [39]. The profile schema shall also be governed by the rules defined in UAProf [40] chapter 7, 7.1, 7.3 and 7.4.
5.2.3 Vocabularies for PSS
5.2.3.1 General
Clause 5.2.3 specifies the attribute vocabularies to be used by the PSS capability exchange.
PSS servers supporting capability exchange shall support the attributes in the four PSS components of the PSS base vocabulary. PSS servers should also support the recommended attributes from the UAProf vocabulary [40]. A server may additionally support other UAProf attributes.
5.2.3.2 PSS base vocabulary
The PSS base vocabulary contains three components called "PssCommon", "Streaming" and "ThreeGPFileFormat". The division of the vocabulary into these components is motivated by the fact that the PSS contains the following different base applications:
– pure RTSP/RTP-based streaming, HTTP-based streaming and progressive download, or both (described by the Streaming component);
– 3GP file download or progressive download (described by the ThreeGPFileFormat component).
The last application can consist of downloadable images, text, etc., as well as RTSP/RTP streaming and downloadable 3GP files. Capabilities that are common to all PSS applications are described by the PssCommon component. The three base applications are distinguished from each other by the source of synchronization: for pure streaming it is RTP, for 3GP files it is inherit in the 3GP file format.
The PSS base vocabulary is an extension to UAProf and is defined as an RDF schema in Annex F. Together with the description of the attributes in the present clause, it defines the vocabulary. The vocabulary is associated with an XML namespace, which combines a base URI with a local XML element name to yield an URI. Annex F provides the details.
The PSS specific components contain a number of attributes expressing capabilities. The following subclauses list all attributes for each component.
5.2.3.2.1 PssCommon component
Attribute name: AudioChannels
Attribute definition: This attribute describes the stereophonic capability of the natural audio device.
Component: PssCommon
Type: Literal
Legal values: "Mono", "Stereo"
Resolution rule: Locked
EXAMPLE: <AudioChannels>Mono</AudioChannels>
Attribute name: MaxPolyphony
Attribute definition: The MaxPolyphony attribute refers to the maximal polyphony that the synthetic audio device supports as defined in [44].
NOTE: The MaxPolyphony attribute is used to signal the maximum polyphony capabilities supported by the PSS client. This is a complementary mechanism for the delivery of compatible SP-MIDI content and thus by setting the MaxPolyphony attribute the PSS client is required to support Scalable Polyphony MIDI i.e. Channel Masking defined in [44].
Component: PssCommon
Type: Number
Legal values: Integer between 5 and 24
Resolution rule: Locked
EXAMPLE: <MaxPolyphony>8</MaxPolyphony>
Attribute name: NumOfGM1Voices
Attribute definition: The NumOfGM1Voices attribute refers to the maximum number of simultaneous GM1 voices that the synthetic audio engine supports.
Component: PssCommon
Type: Number
Legal values: Integer greater or equal than 5
Resolution rule: Locked
EXAMPLE: <NumOfGMIVoices>24</NumOfGMIVoices>
Attribute name: NumOfMobileDLSVoicesWithoutOptionalBlocks
Attribute definition: The NumOfMobileDLSVoicesWithoutOptionalBlocks attribute refers to the maximum number of simultaneous Mobile DLS [70] voices without optional group of processing blocks that the synthetic audio engine supports.
Component: PssCommon
Type: Number
Legal values: Integer greater or equal than 5
Resolution rule: Locked
EXAMPLE: <NumOfMobileDLSVoicesWithoutOptionalBlocks>24
</NumOfMobileDLSVoicesWithoutOptionalBlocks>
Attribute name: NumOfMobileDLSVoicesWithOptionalBlocks
Attribute definition: The NumOfMobileDLSVoicesWithOptionalBlocks attribute refers to the maximum number of simultaneous Mobile DLS voices with optional group of processing blocks that the synthetic audio engine supports. This attribute is set to zero for devices that do not support the optional group of processing blocks.
Component: PssCommon
Type: Number
Legal values: Integer greater than or equal to 0
Resolution rule: Locked
EXAMPLE: <NumOfMobileDLSVoicesWithOptionalBlocks>24
</NumOfMobileDLSVoicesWithOptionalBlocks>
Attribute name: PssVersion
Attribute definition: Latest PSS version supported by the client.
Component: PssCommon
Type: Literal
Legal values: "3GPP-R4", "3GPP-R5", "3GPP-R6", "3GPP-R7", "3GPP-R8", "3GPP-R9" and so forth.
Resolution rule: Locked
EXAMPLE: <PssVersion>3GPP-R6</PssVersion>
Attribute name: RenderingScreenSize
Attribute definition: The rendering size of the device’s screen in unit of pixels available for PSS media presentation. The horizontal size is given followed by the vertical size.
Component: PssCommon
Type: Dimension
Legal values: Two integer values equal or greater than zero. A value equal "0x0"means that there exists no possibility to render visual PSS presentations.
Resolution rule: Locked
EXAMPLE: <RenderingScreenSize>70×15</RenderingScreenSize>
Attribute name: RenderingScreenSizeMm
Attribute definition: The rendering size of the device’s screen in unit of millimetres available for PSS media presentation. The horizontal size is given followed by the vertical size.
Component: PssCommon
Type: Dimension
Legal values: Two floating values equal or greater than zero. A value equal "0.0×0.0"means that there exists no possibility to render visual PSS media presentations.
Resolution rule: Locked
EXAMPLE: < RenderingScreenSizeMm >110.5×56.0</RenderingScreenSizeMm>
5.2.3.2.2 Streaming component
Attribute name: StreamingMethod
Attribute definition: List of streaming methods supported by the PSS application. The client may support RTP streaming, HTTP streaming, Progressive Download, or all.
Component: Streaming
Type: Literal (Bag)
Legal values: "RTP", "HTTP", "Progressive"
Resolution rule: Append
EXAMPLE: <StreamingMethod>
<rdf:Bag>
<rdf:li>RTP</rdf:li>
<rdf:li>HTTP</rdf:li>
</rdf:Bag>
</StreamingMethod>
Attribute name: StreamingAccept
Attribute definition: List of content types (MIME types) relevant for streaming over RTP or HTTP supported by the PSS application. Content types listed shall be possible to stream over RTP. For each content type a set of MIME parameters can be specified to signal receiver capabilities. A content type that supports multiple parameter sets may occur several times in the list.
Component: Streaming
Type: Literal (Bag)
Legal values: List of MIME types with related parameters.
Resolution rule: Append
EXAMPLE: <StreamingAccept>
<rdf:Bag>
<rdf:li>audio/AMR-WB+</rdf:li>
<rdf:li>video/H264; profile-level-id=42e00a</rdf:li>
<rdf:li>video/richmedia+xml; Version-profile=10</rdf:li>
</rdf:Bag>
</StreamingAccept>
Attribute name: StreamingAccept-Subset
Attribute definition: List of content types for which the PSS application supports a subset. MIME types can in most cases effectively be used to express variations in support for different media types. Many MIME types, e.g. AMR-WB have several parameters that can be used for this purpose. There may exist content types for which the PSS application only supports a subset and this subset cannot be expressed with MIME-type parameters. In these cases the attribute StreamingAccept-Subset is used to describe support for a subset of a specific content type. If a subset of a specific content type is declared in StreamingAccept-Subset, this means that StreamingAccept-Subset has precedence over StreamingAccept. StreamingAccept shall always include the corresponding content types for which StreamingAccept-Subset specifies subsets of.
Subset identifiers and corresponding semantics shall only be defined by the TSG responsible for the present document.
Component: Streaming
Type: Literal (Bag)
Legal values: No subsets defined.
Resolution rule: Append
Attribute name: StreamingFramePackingFormatsRTP
Attribute definition: List of supported frame packing formats relevant for streaming of stereoscopic 3D video over RTP supported by the PSS application. The frame packing formats within scope for stereoscopic 3D video are defined in Table D-8 of [90].
Component: Streaming
Type: Literal (Bag)
Legal values: List of integer values corresponding to the supported frame packing formats. The integer values shall correspond to the ‘Value’ column as specified in Table D-8 of [90] and be interpreted according to the ‘Interpretation’ column in the same table.
Resolution rule: Append
EXAMPLE: <StreamingFramePackingFormatsRTP>
<rdf:Bag>
<rdf:li>3</rdf:li>
<rdf:li>4</rdf:li>
</rdf:Bag>
</StreamingFramePackingFormatsRTP>
Attribute name: StreamingFramePackingFormatsHTTP
Attribute definition: List of supported frame packing formats relevant for streaming of stereoscopic 3D video over HTTP supported by the PSS application. The frame packing formats within scope for stereoscopic 3D video are defined in Table D-8 of [90].
Component: Streaming
Type: Literal (Bag)
Legal values: List of integer values corresponding to the supported frame packing formats. The integer values shall correspond to the ‘Value’ column as specified in Table D-8 of [90] and be interpreted according to the ‘Interpretation’ column in the same table.
Resolution rule: Append
EXAMPLE: <StreamingFramePackingFormatsHTTP>
<rdf:Bag>
<rdf:li>3</rdf:li>
<rdf:li>4</rdf:li>
</rdf:Bag>
</StreamingFramePackingFormatsHTTP>
Attribute name: StreamingCVOCapable
Attribute definition: Indicates whether the client is a CVO capable receiver of RTP streams, i.e. provided that the video orientation information for the delivered content is communicated to the client in an RTP extension header as specified in clause 6.2.5 (corresponding to urn:3gpp:video-orientation), the client can interpret the video orientation and align the video correctly for rendering/display purposes. If this attribute is reported and the StreamingHighGranularityCVOCapable attribute is reported as a "Yes", then the value of this attribute shall be a "Yes".
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <StreamingCVOCapable>Yes</StreamingCVOCapable>
Attribute name: StreamingHighGranularityCVOCapable
Attribute definition: Indicates whether the client is a Higher Granularity CVO capable receiver of RTP streams, i.e. provided that the video orientation information of the delivered content is communicated to the client in an RTP extension header as specified in clause 6.2.5 (corresponding to urn:3GPP:video-orientation:6), the client can interpret the video orientation and align the video correctly for rendering/display purposes.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <StreamingHighGranularityCVOCapable>Yes</StreamingHighGranularityCVOCapable>
Attribute name: ThreeGPPLinkChar
Attribute definition: Indicates whether the device supports the 3GPP-Link-Char header according to clause 10.2.1.1.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Override
EXAMPLE: <ThreeGPPLinkChar>Yes</ThreeGPPLinkChar>
Attribute name: AdaptationSupport
Attribute definition: Indicates whether the device supports client buffer feedback signaling according to clause 10.2.3.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <AdaptationSupport>Yes</AdaptationSupport>
Attribute name: QoESupport
Attribute definition: Indicates whether the device supports QoE signaling according to clauses 5.3.2.3, 5.3.3.6, and 11 in case of RTSP/RTP-based streaming or according to clause 10 of 3GPP TS 26.247 [112] in case of HTTP-based streaming and progressive download.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <QoESupport>Yes</QoESupport>
Attribute name: ExtendedRtcpReports
Attribute definition: Indicates whether the device supports extended RTCP reports according to clause 6.2.3.1.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <ExtendedRtcpReports>Yes</ExtendedRtcpReports>
Attribute name: RtpRetransmission
Attribute definition: Indicates whether the device supports RTP retransmission according to clause 6.2.3.3.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <RtpRetransmission>Yes</RtpRetransmission>
Attribute name: MediaAlternatives
Attribute definition: Indicates whether the device interprets the SDP attributes "alt", "alt-default-id", and "alt-group", defined in clauses 5.3.3.3 and 5.3.3.4.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Override
EXAMPLE: <MediaAlternatives>Yes</MediaAlternatives>
Attribute name: RtpProfiles
Attribute definition: List of supported RTP profiles.
Component: Streaming
Type: Literal (Bag)
Legal values: Profile names registered through the Internet Assigned Numbers Authority (IANA), www.iana.org.
Resolution rule: Append
EXAMPLE: <RtpProfiles>
<rdf:Bag>
<rdf:li>RTP/AVP</rdf:li>
<rdf:li>RTP/AVPF</rdf:li>
</rdf:Bag>
</RtpProfiles>
Attribute name: ProtectedStreaming
Attribute definition: Indicates whether the device supports streamed protected PSS as defined by Annex R.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <ProtectedStreaming>Yes</ProtectedStreaming>
Attribute name: ThreeGPPPipelined
Attribute definition: Indicates whether the device supports fast content start-up with pipelining according to clause 5.5.3.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Override
EXAMPLE: <ThreeGPPPipelined>Yes</ThreeGPPPipelined>
Attribute name: ThreeGPPSwitch
Attribute definition: Indicates whether the device supports fast content switching with known SDP according to clause 5.5.4.3.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Override
EXAMPLE: <ThreeGPPSwitch>Yes</ThreeGPPSwitch>
Attribute name: ThreeGPPSwitchReqSDP
Attribute definition: Indicates whether the device supports fast content switching without SDP according to clause 5.5.4.4.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Override
EXAMPLE: <ThreeGPPSwitchReqSDP>Yes</ThreeGPPSwitchReqSDP>
Attribute name: ThreeGPPSwitchStream
Attribute definition: Indicates whether the device supports the fast switching of media streams according to clause 5.5.4.5.
Component: Streaming
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Override
EXAMPLE: <ThreeGPPSwitchStream>Yes</ThreeGPPSwitchStream>
Attribute name: AcceptRanges
Attribute definition: List of range indications that are accepted by the client. The client may support UTC or NPT or both.
Component: Streaming
Type: Literal (Bag)
Legal values: "NPT", "UTC"
Resolution rule: Append
EXAMPLE: <AcceptRanges>
<rdf:Bag>
<rdf:li>NPT</rdf:li>
<rdf:li>UTC</rdf:li>
</rdf:Bag>
</AcceptRanges>
Attribute name: ISMACryp
Attribute definition: Indicates whether the device supports streamed content in ISMACryp format as defined in ISMACryp and Annex R.
Component: Streaming
Type: Literal (Bag)
Legal values: ISMACryp Version numbers supported as a floating number. 0.0 indicates no support.
Resolution rule: Locked
EXAMPLE: <ISMACryp>
<rdf:Bag>
<rdf:li>2.0</rdf:li>
</rdf:Bag>
</ISMACryp>
Attribute name: VideoDecodingByteRate
Attribute definition: If Annex G is not supported, the attribute has no meaning. If Annex G is supported, this attribute defines the peak decoding byte rate the PSS client is able to support. In other words, the PSS client fulfils the requirements given in Annex G with the signalled peak decoding byte rate. The values are given in bytes per second and shall be greater than or equal to 16000.
Component: Streaming
Type: Number
Legal values: Integer value greater than or equal to 16000.
Resolution rule: Locked
EXAMPLE: <VideoDecodingByteRate>16000</VideoDecodingByteRate>
Attribute name: VideoInitialPostDecoderBufferingPeriod
Attribute definition: If Annex G is not supported, the attribute has no meaning. If Annex G is supported, this attribute defines the maximum initial post-decoder buffering period of video. Values are interpreted as clock ticks of a 90-kHz clock. In other words, the value is incremented by one for each 1/90 000 seconds. For example, the value 9000 corresponds to 1/10 of a second initial post-decoder buffering.
Component: Streaming
Type: Number
Legal values: Integer value equal to or greater than zero.
Resolution rule: Locked
EXAMPLE: <VideoInitialPostDecoderBufferingPeriod>9000
</VideoInitialPostDecoderBufferingPeriod>
Attribute name: VideoPreDecoderBufferSize
Attribute definition: This attribute signals if the optional video buffering requirements defined in Annex G are supported. It also defines the size of the hypothetical pre-decoder buffer defined in Annex G. A value equal to zero means that Annex G is not supported. A value equal to one means that Annex G is supported. In this case the size of the buffer is the default size defined in Annex G. A value equal to or greater than the default buffer size defined in Annex G means that Annex G is supported and sets the buffer size to the given number of octets.
Component: Streaming
Type: Number
Legal values: Integer value equal to or greater than zero. Values greater than one but less than the default buffer size defined in Annex G are not allowed.
Resolution rule: Locked
EXAMPLE: <VideoPreDecoderBufferSize>30720</VideoPreDecoderBufferSize>
5.2.3.2.3 ThreeGPFileFormat component
Attribute name: Brands
Attribute definition: List of supported 3GP profiles identified by brand.
Component: ThreeGPFileFormat
Type: Literal (Bag)
Legal values: Brand identifiers according to 5.3.4 and 5.4 in [50].
Resolution rule: Append
EXAMPLE: <Brands>
<rdf:Bag>
<rdf:li>3gp4</rdf:li>
<rdf:li>3gp5</rdf:li>
<rdf:li>3gp6</rdf:li>
<rdf:li>3gr6</rdf:li>
<rfd:li>3gp7</rdf:li>
<rfd:li>3gr7</rdf:li>
<rfd:li>3ge7</rdf:li>
</rdf:Bag>
</Brands>
Attribute name: ThreeGPAccept
Attribute definition: List of content types (MIME types) that can be included in a 3GP file and handled by the PSS application. The content types included in this attribute can be rendered in a 3GP file or a presentation contained therein. If the identifier "Streaming-Media" is included, streaming media can be included within a contained presentation. Details on the streaming support can then be found in the Streaming component. For each content type a set of supported parameters can be given. A content type that supports multiple parameter sets may occur several times in the list.
Component: ThreeGPFileFormat
Type: Literal (Bag)
Legal values: List of MIME types with related parameters and the "Streaming-Media" identifier.
Resolution rule: Append
EXAMPLE 1: <ThreeGPAccept>
<rdf:Bag>
<rdf:li>audio/AMR</rdf:li>
<rdf:li>audio/AMR-WB+</rdf:li>
<rdf:li>video/H264; profile-level-id=42e00a</rdf:li>
<rdf:li>image/jpeg</rdf:li>
<rdf:li>video/richmedia+xml; Version-profile=10</rdf:li>
<rdf:li>Streaming-Media</rdf:li>
</rdf:Bag>
</ThreeGPAccept>
Attribute name: ThreeGPAccept-Subset
Attribute definition: List of content types for which the PSS application supports a subset. MIME types can in most cases effectively be used to express variations in support for different media types. Many MIME types have several parameters that can be used for this purpose. There may exist content types for which the PSS application only supports a subset and this subset cannot be expressed with MIME-type parameters. In these cases the attribute ThreeGPAccept-Subset is used to describe support for a subset of a specific content type. If a subset of a specific content type is declared in ThreeGPAccept-Subset, this means that ThreeGPAccept-Subset has precedence over ThreeGPAccept. ThreeGPAccept shall always include the corresponding content types for which ThreeGPAccept-Subset specifies subsets of.
Subset identifiers and corresponding semantics shall only be defined by the TSG responsible for the present document.
Component: ThreeGPFileFormat
Type: Literal (Bag)
Legal values: No subsets defined.
Resolution rule: Append
Attribute name: ThreeGPFramePackingFormats
Attribute definition: List of supported frame packing formats relevant for stereoscopic 3D video that can be included in a 3GP file and handled by the PSS application.
Component: ThreeGPFileFormat
Type: Literal (Bag)
Legal values: List of integer values corresponding to the supported frame packing formats. Integer values shall be either 3 or 4 corresponding to the Side-by-Side and Top-and-Bottom frame packing formats respectively, as specified in the ‘Value’ column of Table D-8 of [90] and interpreted according to the ‘Interpretation’ column in the same table.
Resolution rule: Append
EXAMPLE: <ThreeGPFramePackingFormats>
<rdf:Bag>
<rdf:li>3</rdf:li>
<rdf:li>4</rdf:li>
</rdf:Bag>
</ThreeGPFramePackingFormats>
Attribute name: ThreeGPCVOCapable
Attribute definition: Indicates whether the client is a CVO capable receiver of 3GP files, i.e. provided that the video orientation information (corresponding to urn:3gpp:video-orientation) of the delivered content is communicated to the client in a 3GP file, the client can interpret the video orientation and align the video correctly for rendering/display purposes. If this attribute is reported and the ThreeGPHighGranularityCVOCapable attribute is reported as a "Yes", then the value of this attribute shall be a "Yes".
Component: ThreeGPFileFormat
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <ThreeGPCVOCapable>Yes</ThreeGPCVOCapable>
Attribute name: ThreeGPHighGranularityCVOCapable
Attribute definition: Indicates whether the client is a Higher Granularity CVO capable receiver of 3GP files, i.e. provided that the video orientation information (corresponding to urn:3gpp:video-orientation:6) of the delivered content is communicated to the client in a 3GP file, the client can interpret the video orientation and align the video correctly for rendering/display purposes.
Component: ThreeGPFileFormat
Type: Literal
Legal values: "Yes", "No"
Resolution rule: Locked
EXAMPLE: <ThreeGPHighGranularityCVOCapable>Yes</ThreeGPHighGranularityCVOCapable>
Attribute name: ThreeGPOmaDrm
Attribute definition: List of the OMA DRM versions that is supported to be used for DRM protection of content present in the 3GP file format.
Component: ThreeGPFileFormat
Type: Literal (Bag)
Legal values: OMA DRM version numbers as floating point values. 0.0 indicates no support.
Resolution rule: Locked
EXAMPLE: <3gpOMADRM>
<rdf:Bag>
<rdf:li>2.0 </rdf:li>
</rdf:Bag>
</3gpOMADRM>
5.2.3.2.4 Void
5.2.3.3 Attributes from UAProf
In the UAProf vocabulary [40] there are several attributes that are of interest for the PSS. The formal definition of these attributes is given in [40]. The following list of attributes is recommended for PSS applications:
Attribute name: BitsPerPixel
Component: HardwarePlatform
Attribute description: The number of bits of colour or greyscale information per pixel
EXAMPLE 1: <BitsPerPixel>8</BitsPerPixel>
Attribute name: ColorCapable
Component: HardwarePlatform
Attribute description: Whether the device display supports colour or not.
EXAMPLE 2: <ColorCapable>Yes</ColorCapable>
Attribute name: PixelAspectRatio
Component: HardwarePlatform
Attribute description: Ratio of pixel width to pixel height
EXAMPLE 3: <PixelAspectRatio>1×2</PixelAspectRatio>
Attribute name: PointingResolution
Component: HardwarePlatform
Attribute description: Type of resolution of the pointing accessory supported by the device.
EXAMPLE 4: <PointingResolution>Pixel</PointingResolution>
Attribute name: Model
Component: HardwarePlatform
Attribute description: Model number assigned to the terminal device by the vendor or manufacturer
EXAMPLE 5: <Model>Model B</Model>
Attribute name: Vendor
Component: HardwarePlatform
Attribute description: Name of the vendor manufacturing the terminal device
EXAMPLE 6: <Vendor>TerminalManufacturer A</Vendor>
Attribute name: CcppAccept-Charset
Component: SoftwarePlatform
Attribute description: List of character sets the device supports
EXAMPLE 7: <CcppAccept-Charset>
<rdf:Bag>
<rdf:li>UTF-8</rdf:li>
</rdf:Bag>
</CcppAccept-Charset>
Attribute name: CcppAccept-Encoding
Component: SoftwarePlatform
Attribute description: List of transfer encodings the device supports
EXAMPLE 8: <CcppAccept-Encoding>
<rdf:Bag>
<rdf:li>base64</rdf:li>
</rdf:Bag>
</CcppAccept-Encoding>
Attribute name: CcppAccept-Language
Component: SoftwarePlatform
Attribute description: List of preferred document languages
EXAMPLE 9: <CcppAccept-Language>
<rdf:Seq>
<rdf:li>en</rdf:li>
<rdf:li>se</rdf:li>
</rdf:Seq>
</CcppAccept-Language>
Attribute name: DMCapable
Component: SoftwarePlatform
Attribute description: Indicates whether the device provides Device Management capabilities.
EXAMPLE 10: <DMCapable>Yes</DMCapable>
Attribute name: DMVersion
Component: SoftwarePlatform
Attribute description: Version of the Device Management (DM) capability within the device
EXAMPLE 11: <DMVersion>1.2</DMVersion>
5.2.4 Extensions to the PSS schema/vocabulary
5.2.4.1 Vocabulary definitions
The use of RDF enables an extensibility mechanism for CC/PP-based schemas that addresses the evolution of new types of devices and applications. The Release-6 PSS profile schema specification has been updated from Release 5 and has thus been assigned a unique RDF schema. The same is true for the Release-7, Release 9, Release 11 and Release 12 PSS profiles schema specification. The following URIs uniquely identify the RDF schemas for Release 5, Release 6, Release 7, Release 9, Release 11 and Release 12:
PSS Release 5 URI: http://www.3gpp.org/profiles/PSS/ccppschema-PSS5#
PSS Release 6 URI: http://www.3gpp.org/profiles/PSS/ccppschema-PSS6#
PSS Release 7 URI: http://www.3gpp.org/profiles/PSS/ccppschema-PSS7#
PSS Release 9 URI: http://www.3gpp.org/profiles/PSS/ccppschema-PSS9#
PSS Release 11 URI: http://www.3gpp.org/profiles/PSS/ccppschema-PSS11#
PSS Release 12 URI: http://www.3gpp.org/profiles/PSS/ccppschema-PSS12#
In the future new usage scenarios might have need for expressing new attributes. If the base vocabulary is further updated, a new unique namespace will be assigned to the updated schema. The base vocabulary shall only be changed by the TSG responsible for the present document. All extensions to the profile schema shall be governed by the rules defined in [40] clause 7.7.
5.2.4.2 Backward compatibility
An important issue when introducing a new vocabulary is to ensure backward compatibility. PSS Release-6 clients should seamlessly work together with PSS Release-5 servers and vice versa. To obtain backward compatibility, a Release-6 client should provide servers with multiple device-capability profiles using PSS Release-5 and Release-6 vocabularies, respectively. This can be done by providing two URIs referring to two separate profiles or one URI referring to one combined profile that uses both the Relase-5 and the Release-6 namespaces. PSS Release-6 servers should handle both namespaces, whereas PSS Release-5 servers will ignore profiles with unknown namespaces.
5.2.5 Signalling of profile information between client and server
When a PSS client or server support capability exchange it shall support the profile information transport over both HTTP and RTSP between client and server as defined in clause 8.1 (including its subsections) of the WAP 2.0 UAProf specification [40] with the following amendments:
– The "x-wap-profile" and "x-wap-profile-diff" headers shall be present in at least one HTTP or RTSP request per session. That is, the requirement to send this header in all requests has been relaxed.
– The defined headers may be applied to both RTSP and HTTP.
– The "x-wap-profile-diff" header is only valid for the current request. The reason is that PSS does not have the WSP session concept of WAP.
– Push is not relevant for the PSS.
The following guidelines concern how and when profile information is sent between client and server:
– PSS content servers supporting capability exchange shall be able to receive profile information in all HTTP and RTSP requests.
– The terminal should not send the "x-wap-profile-diff" header over the air-interface since there is no compression scheme defined.
– RTSP: the client should send profile information in the DESCRIBE message. It may send it in any other request.
If the terminal has some prior knowledge about the file type it is about to retrieve, e.g. file extensions, the following apply:
– HTTP and SDP: when retrieving an SDP with HTTP the client should include profile information in the GET request. This way the HTTP server can deliver an optimised SDP to the client.
– HTTP and MPD: when retrieving an MPD with HTTP the client may include profile information in the GET request. This way the HTTP server may deliver an optimised MPD to the client.
5.2.6 Merging device capability profiles
Profiles need to be merged whenever the PSS server receives multiple device capability profiles. Multiple occurrences of attributes and default values make it necessary to resolve the profiles according to a resolution process.
The resolution process shall be the same as defined in UAProf [40] clause 6.4.1.
– Resolve all indirect references by retrieving URI references contained within the profile.
– Resolve each profile and profile-diff document by first applying attribute values contained in the default URI references and by second applying overriding attribute values contained within the category blocks of that profile or profile-diff.
– Determine the final value of the attributes by applying the resolved attribute values from each profile and profile-diff in order, with the attribute values determined by the resolution rules provided in the schema. Where no resolution rules are provided for a particular attribute in the schema, values provided in profiles or profile-diffs are assumed to override values provided in previous profiles or profile-diffs.
When several URLs are defined in the "x-wap-profile" header and there exists any attribute that occurs more than once in these profiles the rule is that the attribute value in the second URL overrides, or is overridden by, or is appended to the attribute value from the first URL (according to the resolution rule) and so forth. This is what is meant with "Determine the final value of the attributes by applying the resolved attribute values from each profile and profile-diff in order, with…" in the third bullet above. If the profile is completely or partly inaccessible or otherwise corrupted the server should still provide content to the client. The server is responsible for delivering content optimised for the client based on the received profile in a best effort manner.
NOTE: For the reasons explained in Annex A clause A.4.3 the usage of indirect references in profiles (using the CC/PP defaults element) is not recommended.
5.2.7 Profile transfer between the PSS server and the device profile server
The device capability profiles are stored on a device profile server and referenced with URLs. According to the profile resolution process in clause 5.2.6 of the present document, the PSS server ends up with a number of URLs referring to profiles and these shall be retrieved.
– The device profile server shall support HTTP 1.1 for the transfer of device capability profiles to the PSS server.
– If the PSS server supports capability exchange it shall support HTTP 1.1 for transfer of device capability profiles from the device profile server. A URL shall be used to identify a device capability profile.
– Normal content caching provisions as defined by HTTP apply.
5.3 Session set-up and control
5.3.1 General
Continuous media is media that has an intrinsic time line. Discrete media on the other hand does not itself contain an element of time. In this specification speech, audio, video and timed text belong to the first category and still images and text to the latter one.
Streaming of continuous media using RTP/UDP/IP (see clause 6.2) requires a session control protocol to set-up and control the individual media streams. For the transport of discrete media (images and text), vector graphics, timed text and synthetic audio this specification adopts the use of HTTP/TCP/IP (see clause 6.3). In this case there is no need for a separate session set-up and control protocol since this is built into HTTP. This clause describes session set-up and control of continuous media.
5.3.2 RTSP
RTSP [5] shall be used for session set-up and session control. PSS clients and servers shall follow the rules for minimal on-demand playback RTSP implementations in appendix D of [5]. In addition to this:
– PSS servers and clients shall implement the DESCRIBE method (see clause 10.2 in [5]);
– PSS servers and clients shall implement the Range header field (see clause 12.29 in [5]);
– PSS servers shall include the Range header field in all PLAY responses;
– PSS servers and clients should implement the SET_PARAMETER method (see clause 10.9 in [5]);
– PSS servers and clients should implement the Bandwidth header field (see clause 12.6 in [5].
Further additions to RTSP are specified in the following subclauses.
5.3.2.1 The 3GPP-Link-Char header
PSS servers and clients should implement the 3GPP-Link-Char header field.
To enable PSS clients to report the link characteristics of the radio interface to the PSS server, the "3GPP-Link-Char" RTSP header is defined. The header takes one or more arguments. The reported information should be taken from a QoS reservation (i.e. the QoS profile as defined in [56]). Note that this information is only valid for the wireless link and does not apply end-to-end. However, the parameters do provide constraints that can be used.
Three parameters are defined that can be included in the header, and future extensions are possible to define. Any unknown parameter shall be ignored. The three parameters are:
– "GBW": the link’s guaranteed bit-rate in kilobits per second as defined by [56];
– "MBW": the link’s maximum bit-rate in kilobits per second as defined by [56];
– "MTD": the link’s maximum transfer delay, as defined by [56] in milliseconds.
The "3GPP-Link-Char" header syntax is defined below using ABNF [53]:
3gpplinkheader = "3GPP-Link-Char" ":" link-char-spec *("," 0*1SP link-char-spec) CRLF
link-char-spec = char-link-url *(";" 0*1SP link-parameters)
char-link-url = "url" "=" <">url<">
link-parameters = Guaranteed-BW / Max-BW / Max-Transfer-delay / extension-type
Guaranteed-BW = "GBW" "=" 1*DIGIT ; kbps
Max-BW = "MBW" "=" 1*DIGIT ; kbps
Max-Transfer-delay = "MTD" "=" 1*DIGIT ; ms
extension-type = token "=" (token / quoted-string)
DIGIT = as defined in RFC 2326 [5]
token = as defined in RFC 2326 [5]
quoted-string = as defined in RFC 2326 [5]
url = as defined in RFC 2326 [5]
The "3GPP-Link-Char" header can be included in a request using any of the following RTSP methods: SETUP, PLAY, OPTIONS, and SET_PARAMETER. The header shall not be included in any response. The header can contain one or more characteristics specifications. Each specification contains a URI that can either be an absolute or a relative, any relative URI use the RTSP request URI as base. The URI points out the media component that the given parameters apply to. This can either be an individual media stream or a session aggregate.
If a QoS reservation (PDP context) is shared by several media components in a session the 3GPP-Link-Char header shall not be sent prior to the RTSP PLAY request. In this case the URI to use is the aggregated RTSP URI. If the QoS reservation is not shared (one PDP context per media) the media stream URI must be used in the 3GPP-Link-Char specification. If one QoS reservation (PDP context) per media component is used, the specification parameters shall be sent per media component.
The "3GPP-Link-Char" header should be included in a SETUP or PLAY request by the client, to give the initial values for the link characteristics. A SET_PARAMETER or OPTIONS request can be used to update the 3GPP-Link-Char values in a session currently playing. It is strongly recommended that SET_PARAMETER is used, as this has the correct semantics for the operation and also requires less overhead both in bandwidth and server processing. When performing updates of the parameters, all of the previous signalled values are undefined and only the given ones in the update are defined. This means that even if a parameter has not changed, it must be included in the update.
Example:
3GPP-LinkChar: url="rtsp://server.example.com/media.3gp"; GBW=32; MBW=128; MTD=2000
In the above example the header tells the server that its radio link has a QoS setting with a guaranteed bit-rate of 32 kbps, a maximum bit-rate of 128 kbps, and a maximum transfer delay of 2.0 seconds. These parameters are valid for the aggregate of all media components, as the URI is an aggregated RTSP URI.
5.3.2.2 The 3GPP-Adaptation header
PSS servers and clients should implement the 3GPP-Adaptation header field.
To enable PSS clients to set bit-rate adaptation parameters, a new RTSP request and response header is defined. The header can be used in the methods SETUP, PLAY, OPTIONS, and SET_PARAMETER. The header defined in ABNF [53] has the following syntax:
3GPP-adaptation-def = "3GPP-Adaptation" ":" adaptation-spec 0*("," adaptation-spec)
adaptation-spec = url-def *adapt-params
adapt-params = ";" buffer-size-def
/ ";" target-time-def
url-def = "url" "=" <"> url <">
buffer-size-def = "size" "=" 1*9DIGIT ; bytes
target-time-def = "target-time" "=" 1*9DIGIT; ms
url = ( absoluteURI / relativeURI )
absoluteURI and relativeURI are defined in RFC 3986 [60]. The base URI for any relative URI is the RTSP request URI.
The "3GPP-Adaptation" header shall be sent in responses to requests containing this header. The PSS server shall not change the values in the response header. The presence of the header in the response indicates to the client that the server acknowledges the request.
The buffer size signalled in the "3GPP-Adaptation" header shall correspond to reception, de-jittering, and, if used, de-interleaving buffer(s) that have this given amount of space for complete application data units (ADU), including the following RTP header and RTP payload header fields: RTP timestamp, and sequence numbers or decoding order numbers. The specified buffer size shall also include any Annex G pre-decoder buffer space used for this media, as the two buffers cannot be separated.
The target protection time signalled in the "target-time" parameter is the targeted minimum buffer level in milliseconds; that is, the minimum amount of playback time the client perceives necessary for interrupt-free playback. This value must be chosen such that the client is never in a buffering state if all media streams have reached or exceeded their target-time in buffered data and playout delay. Once this desired level of target protection is achieved, the server may utilize any additional resources to increase the quality of the media or to increase the buffer duration beyond that required by the target-time, or it may continue sending at the media rate in order to maintain a steady buffer state.
5.3.2.3 The Quality of Experience headers
5.3.2.3.1 Protocol initiation and termination
A new RTSP header is defined to enable the PSS client and server to negotiate which Quality of Experience (QoE) metrics the PSS client should send, how often they should be sent and how to turn the metrics transmission off. This header can be sent in requests and responses of RTSP methods SETUP, SET_PARAMETER, OPTIONS (with Session ID) and PLAY. The exact usage of this header is defined in clause 11. The header is defined in ABNF [53] as follows (see [53] for specifiers not defined here):
QoE-Header = "3GPP-QoE-Metrics" ":" ("Off" / Measure-Spec *("," Measure-Spec)) CRLF
Measure-Spec = Stream-URL";" ((Metrics ";" Sending-rate [";" Measure-Range]
[";" Measure-Resolution] *([";" Metrics-Server]) *([";" Parameter-Ext])) / "Off")
Stream-URL = "url" "=" <">Rtsp-URL<">
Metrics = "metrics" "=" "{"Metrics-Name *("|" Metrics-Name) " }"
Metrics-Name = 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}"
Sending-Rate = "rate" "=" 1*DIGIT / "End"
Measure-Resolution = "resolution" "=" 1*DIGIT ; in seconds
Metrics-Server = "server" "=" "{" Server-Name *("|" Server-Name) "}"
Server-Name = as defined in RFC 1123 [100]
Measure-Range = "range" ":" Ranges-Specifier
Parameter-Ext = "On"/"Off"/ (1*DIGIT ["." 1*DIGIT]) / (1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e))
Ranges-Specifier = as defined in RFC 2326 [5]
Rtsp-URL = as defined in RFC 2326 [5]
There are two ways to use this header:
– Using only the "Off" parameter is an indication that either server or client wants to cancel the metrics reporting.
– Using other parameters indicates a request to start the metrics transmission.
If "Stream-URL" is an RTSP Session Control URL, then "Metrics" applies to the RTSP session. If "Stream-URL" is an RTSP Media Control URL, then "Metrics" apply only to the indicated media component of the session.
QoE metrics with the same "Stream-URL", "Sending-rate" and "Measure-Range" shall be aggregated within a single "Measure-Spec" declaration. Otherwise, multiple "Stream-URL" declarations shall be used.
The "Metrics" field contains the list of names that describes the metrics/measurements that are required to be reported in a PSS session. The names that are not included in the "Metrics" field shall not be reported during the session.
The "Sending-Rate" shall be set, and it expresses the maximum time period in seconds between two successive QoE reports. If the "Sending-Rate" value is 0, then the client shall decide the sending time of the reports depending on the events occurred in the client. Values 1 indicate a precise reporting interval. The shortest interval is one second and the longest interval is undefined. The reporting interval can be different for different media, but it is recommended to maintain a degree of synchronization in order to avoid extra traffic in the uplink direction. The value "End" indicates that only one report is sent at the end of the session.
A default QoE reporting is done for each metric. The optional "Measure-Resolution" field, if present, indicates that XML QoE reporting shall be done instead. In this case the "Measure-Resolution" field splits the session duration into a number of equally sized periods where each period is of the length specified by the "Measure-Resolution" field. QoE metrics are calculated for each period and stored in the terminal, and all the stored metrics are then sent together according to the "Sending-Rate" field. This allows long reporting intervals (to save bandwidth) without losing good metric measurement resolution. It is recommended that the Sending-Rate is set to an integer multiple of the Measure-Resolution, or to "End".
Note that both "Sending-Rate" and "Measure-Resolution" shall be evaluated according to a real-time clock. This implies that the real-time intervals for measurements and reporting are not affected by changes in playback rate, for instance due to buffering.
The optional "Metrics-Server" field, if present, specifies that instead of the default RTSP reporting back to the streaming server, the QoE reports should be sent to a separate HTTP server. If more than one server is specified, the terminal shall randomly select one of them to be used during the session. The Metrics-Server parameter can only be used for XML reporting, that is, together with the Measure-Resolution parameter. The formatting of the HTTP reports is specified in sub-clause 5.3.2.3.3. If the PSS client does not support HTTP reporting it shall reject the "Metrics-Server" field during the QoE negotiation phase.
The optional "Measure-Range" field, if used, shall define the time range in the stream for which the QoE metrics will be reported. There shall be only one range per measurement specification. The range format shall be any of the formats allowed by the media. If the "Measure-Range" field is not present, the corresponding (media or session level) range attribute in SDP shall be used. If SDP information is not present, the metrics range shall be the whole session duration.
There shall be only one "3GPP-QoE-Metrics" header in one RTSP request or response.
5.3.2.3.2 Metrics feedback
The QoE metrics feedback can be conveyed in requests to the PSS server using the SET_PARAMETER, PAUSE or TEARDOWN methods by the "3GPP-QoE-Feedback" header. The header is defined in ABNF [53] as follows (see [53] for specifiers not defined here):
Feedbackheader = "3GPP-QoE-Feedback" ":" Feedback-Spec *("," Feedback-Spec) CRLF
Feedback-Spec = Stream-URL 1*(";" Parameters) [";" Measure-Range]
Stream-URL = as specified in clause 5.3.2.3.1
Parameters = Metrics-Name "=" "{" SP / (Measure *("|" Measure)) "}"
Metrics-Name = as defined in clause 5.3.2.3.1
Measure = Value [SP Timestamp]
Measure-Range = as defined in clause 5.3.2.3.1
Value = (["-"]1*DIGIT ["." *DIGIT]) / 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}"
Timestamp = NPT-Time
NPT-Time = as defined in RFC 2326 [5]
"Stream-URL" is the RTSP session or media control URL that identifies the media the feedback parameter applies to.
The "Metrics-Name" field in the "Parameters" definition contains the name of the metrics/measurements and uses the same identifiers as the "3GPP-QoE-Metrics" header in clause 5.3.2.3.1.
The "Value" field indicates the results. There is the possibility that the same event occurs more than once during a monitoring period. In that case the metrics value may occur more than once indicating the number of events to the server. For the XML reporting format only one value is reported for each measurement resolution period.
The optional "Timestamp" (defined in NPT time) indicates the time when the event occurred or when the metric was calculated. If no events have occurred, it shall be reported with an empty set (only containing a space). The "Timestamp" feedback shall not be used for the XML reporting format.
The optional "Measure-Range" indicates the actual measurement period, for which this report is valid.
QoE metrics reporting should be done by the PSS client by using the SET_PARAMETER method. However, for more efficiency, RTSP PAUSE and TEARDOWN methods may also be used in particular cases, such as:
CASE 1: When sending the very last QoE report, the client should embed the QoE information into a TEARDOWN message.
CASE 2: When the client wants to pause the streaming flow, QoE information should be embedded into a PAUSE method. The PSS client should not send any QoE reports to the PSS server when the system is paused, since there is no media flow.
5.3.2.3.3 Metrics feedback over HTTP
5.3.2.3.3.0 Requirements and semantics
If a specific metrics server has been configured the client should send QoE reports using the HTTP (RFC 2616 [73]) POST request carrying XML formatted metadata. Each QoE report is formatted in XML according to the XML schema defined in clause 5.3.2.3.3.1. An informative example of a single reception report XML object is also given in clause 5.3.2.3.3.2.
The following parameters shall be included in all reports:
– The sessionStartTime and sessionStopTime attributes identifies the client NTP time when the measurements included in the report were started and stopped. The time is based on the local real-time clock in the client, and might not be consistent with the server NTP time. However, assuming that the reporting is done without any extra delay the server can use the stopTime attribute to correct the timestamps if necessary.
– The sessionID attribute identifies the IP address of the server from which the content is fetched plus the destination port, separated by a colon (e.g. "10.11.12.13:5050").
The following parameters should be included in all reports:
– The clientId attribute is the receiver unique identifier, i.e. the MSISDN of the UE as defined in [110].
5.3.2.3.3.1 XML Syntax for a QoE Report
Below is the formal XML syntax of QoE report instances.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:3gpp:metadata:2009:PSS:receptionreport"
xmlns="urn:3gpp:metadata:2009:PSS:receptionreport"
elementFormDefault="qualified">
<xs:element name="receptionReport" type="receptionReportType"/>
<xs:complexType name="receptionReportType">
<xs:choice>
<xs:element name="statisticalReport" type="starType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="starType">
<xs:sequence>
<xs:element name="fileURI" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="qoeMetrics" type="qoeMetricsType" minOccurs="1" maxOccurs="1"/> <xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="clientId" type="xs:string" use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="qoeMetricsType">
<xs:sequence>
<xs:element name="medialevel_qoeMetrics" type="medialevel_qoeMetricsType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="totalRebufferingDuration" type="xs:doubleVectorType" use="optional"/>
<xs:attribute name="numberOfRebufferingEvents" type="xs:unsignedLongVectorType"
use="optional"/>
<xs:attribute name="initialBufferingDuration" type="xs:double" use="optional"/>
<xs:attribute name="contentSwitchTime" type="xs:doubleVectorType" use="optional"/>
<xs:attribute name="sessionStartTime" type="xs:unsignedLong"/>
<xs:attribute name="sessionStopTime" type="xs:unsignedLong"/>
<xs:attribute name="bufferDepth" type="xs:doubleVectorType" use="optional"/>
<xs:attribute name="allContentBuffered" type="xs:boolean" use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="medialevel_qoeMetricsType">
<xs:attribute name="sessionId" type="xs:string"/>
<xs:attribute name="totalCorruptionDuration" type="xs:unsignedLongVectorType" use="optional"/>
<xs:attribute name="numberOfCorruptionEvents" type="xs:unsignedLongVectorType" use="optional"/>
<xs:attribute name="t" type="xs:boolean" use="optional"/>
<xs:attribute name="d" type="xs:string" use="optional"/>
<xs:attribute name="totalNumberofSuccessivePacketLoss" type="xs:unsignedLongVectorType"
use="optional"/>
<xs:attribute name="numberOfSuccessiveLossEvents" type="xs:unsignedLongVectorType"
use="optional"/>
<xs:attribute name="numberOfReceivedPackets" type="xs:unsignedLongVectorType" use="optional"/>
<xs:attribute name="totalJitterDuration" type="xs:doubleVectorType" use="optional"/>
<xs:attribute name="numberOfJitterEvents" type="xs:unsignedLongVectorType" use="optional"/>
<xs:attribute name="framerate" type="xs:doubleVectorType" use="optional"/>
<xs:attribute name="codecInfo" type="stringVectorType" use="optional"/>
<xs:attribute name="codecProfileLevel" type="stringVectorType" use="optional"/>
<xs:attribute name="codecImageSize" type="stringVectorType" use="optional"/>
<xs:attribute name="averageCodecBitrate" type="doubleVectorType" use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:simpleType name="doubleVectorType"
<xs:list itemType="xs:double"/>
</xs:simpleType>
<xs:simpleType name="unsignedLongVectorType"
<xs:list itemType="xs:unsignedLong"/>
</xs:simpleType>
<xs:simpleType name="stringVectorType"
<xs:list itemType="xs:string"/>
</xs:simpleType>
</xs:schema>
5.3.2.3.3.2 Example XML for the QoE Report
The example shows a QoE report for a streaming session.
<?xml version="1.0" encoding="UTF-8"?>
<receptionReport xmlns="urn:3gpp:metadata:2009:PSS:receptionreport"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:3gpp:metadata:2009:PSS:receptionreport receptionreport.xsd">
<statisticalReport
clientId="79261234567"
<qoeMetrics
numberOfRebufferingEvents="0 1 0"
initialBufferingDuration="3.213"
totalRebufferingDuration="0 1.23 0"
contentAccessTime="2.621"
sessionStartTime="1219322514"
sessionStopTime="1219322541">
bufferDepth="3.571 2.123 2.241"
allContentBuffered="false">
<medialevel_qoeMetrics
sessionId="10.50.65.30:5050"
framerate="15.1 14.8 15.0"
t="false"
d="a"
numberOfSuccessiveLossEvents="5 0 3"
numberOfCorruptionEvents="6 5 2"
numberOfJitterEvents="0 1 0"
totalCorruptionDuration="152 234 147"
totalNumberofSuccessivePacketLoss="25 0 6"
numberOfReceivedPackets="456 500 478"
codecInfo=" video/H264/90000 = ="
codecProfileLevel=" profile-level-id=42e00= ="
codecImageSize="176×144 = ="
averageCodecBitRate="124.5 128.0 115.1"
totalJitterDuration="0 0.346 0"/>
</qoeMetrics>
</statisticalReport>
</receptionReport>
5.3.2.4 Video buffering headers
The following header fields are specified for the response of an RTSP PLAY request only:
– x-predecbufsize:<size of the pre-decoder buffer>
– x-initpredecbufperiod:<initial pre-decoder buffering period>
– x-initpostdecbufperiod:<initial post-decoder buffering period>
– 3gpp-videopostdecbufsize:<size of the video post-decoder buffer>
The header fields "x-predecbufsize", "x-initpredecbufperiod", "x-initpostdecbufperiod", and "3gpp-postdecbufsize" have the same definitions as the corresponding SDP attributes (see clause 5.3.3.2) "X-predecbufsize", "X-initpredecbufperiod", "X-initpostdecbufperiod", and "3gpp-postdecbufsize", respectively, with the exception that the RTSP video buffering header fields are valid only for the range specified in the RTSP PLAY response.
For H.264 (AVC) or H.265 (HEVC), PSS servers shall include these header fields in an RTSP PLAY response whenever the values are available in the 3GP file used for the streaming session. If the values are not available in the 3GP file, it is optional for the servers to signal the parameter values in RTSP PLAY responses.
5.3.3 SDP
5.3.3.1 General
RTSP requires a presentation description. SDP shall be used as the format of the presentation description for both PSS clients and servers. PSS servers shall provide and PSS clients interpret the SDP syntax according to the SDP specification [6] and appendix C of [5]. The SDP delivered to the PSS client shall declare the media types to be used in the session using a codec specific MIME media type for each media. MIME media types to be used in the SDP file are described in clause 5.4 of the present document.
The SDP [6] specification requires certain fields to always be included in an SDP file. Apart from this a PSS server shall always include the following fields in the SDP:
– "a=control:" according to clauses C.1.1, C.2 and C.3 in [5];
– "a=range:" according to clause C.1.5 in [5];
– "a=rtpmap:" according to clause 6 in [6];
– "a=fmtp:" according to clause 6 in [6].
When an SDP document is generated for media stored in a 3GP file, each control URL defined at the media-level "a=control:" field shall include a stream identifier in the last segment of the path component of the URL. The value of the stream id shall be defined by the track-ID field in the track header (tkhd) box associated with the media track. When a PSS server receives a set-up request for a stream, it shall use the stream identifier specified in the URL to map the request to a media track with a matching track-ID field in the 3GP file. Stream identifiers shall be expressed using the following syntax:
streamIdentifier = <stream-id-token>"="<stream-id>
stream-id-token = 1*alpha
stream-id = 1*digit
The bandwidth field in SDP is needed by the client in order to properly set up QoS parameters. Therefore, a PSS server shall include the "b=AS:" and "b=TIAS:" and "a=maxprate" [93] fields at the media level for each media stream in SDP, and should include "b=TIAS" and "a=maxprate" at session level. A PSS client shall interpret all of these fields. If both bandwidth modifiers are present, "b=TIAS" should be used; however it may be missing in content produced according to earlier releases. When a PSS client receives SDP, it should ignore the session level "b=AS:" parameter (if present), and instead calculate session bandwidth from the media level bandwidth values of the relevant streams. If "b=TIAS" and "a=maxprate" is present at session level, it should be used in preference over the media level values, as session level can provide a more accurate description of the needed session bandwidth when aggregating several media streams together. A PSS client shall also handle the case where the bandwidth parameters are not present, since this may occur when connecting to a Release-4 server.
Note that for RTP based applications, ‘b=AS:’ gives the RTP "session bandwidth” (including UDP/IP overhead) as defined in section 6.2 of [9].
The bandwidth for RTCP traffic shall be described using the "RS" and "RR" SDP bandwidth modifiers, as specified by [55]. The "RS" SDP bandwidth modifier indicates the RTCP bandwidth allocated to the sender (i.e. PSS server) and "RR" indicates the RTCP bandwidth allocated to the receiver (i.e. PSS client). A PSS server shall include the "b=RS:" and "b=RR:" fields at the media level for each media stream in SDP, and a PSS client shall interpret them. A PSS client shall also handle the case where the bandwidth modifier is not present according to section 3 of [55], since this may occur when connecting to a Release-4 server.
There shall be a limit on the allowed RTCP bandwidth for senders and receivers in a session. This limit is defined as follows:
– 4000 bps for the RS field (at media level);
– 5000 bps for the RR field (at media level).
In Annex A.2.1 an example SDP in which the limit for the total RTCP bandwidth is 5% of the session bandwidth is presented.
Media which has an SDP description that includes an open ended range (format=startvalue-) in any time format in the SDP attribute "a=range", e.g. "a=range: npt=now-", or "a=range: clock=20030825T152300Z-", shall be considered media of unknown length. Such a media shall be considered as non-seekable, unless other attributes override this property.
The "t=", "r=", and "z=" SDP parameters are used to indicate when the described session is active and can be used to filter out obsolete SDP files. PSS clients and servers shall support "t=", "r=", and "z=" as specified in [6]. The "a=etag" parameter may additionally be used to identify SDP validity. PSS clients should support "a=etag" as specified in [5].
When creating an SDP for a streaming session, one should try to come up with the most accurate estimate of time that the session is active. The "t=", "r=", and "z=" SDP parameters are used for this purpose, i.e., to indicate when the described session is active. If the time at which a session is active is known to be only for a limited period, the "t=", "r=", and "z=" attributes should be filled out appropriately (per [6], the "t=" shall be sent and usually contains non-zero values, possibly using the "r=" and "z=" parameters). If the stop-time is set to zero, the session is not bounded, though it will not become active until after the start-time. If the start-time is also zero, the session is regarded as permanent. A session should only be marked as permanent ("t=0 0") if the session is going to be available for a significantly long period of time or if the start and stop times are not known at the time of SDP file creation. Recommendations for what is considered a significant time is present in the SDP specification [6].
IPv6 addresses in SDP descriptions shall be supported according to RFC 4566 [6].
NOTE: The SDP parsers and/or interpreters shall be able to accept NULL values in the ‘c=’ field (e.g. 0.0.0.0 in IPv4 case). This may happen when the media content does not have a fixed destination address. For more details, see Section C.1.7 of [5] and Section 6 of [6].
5.3.3.2 Additional SDP fields
The following additional media level SDP fields are defined for PSS:
–
If the field is an attribute for an H.264 (AVC) stream, the H.264 (AVC) bitstream is constrained by the value of "CpbSize" equal to X-predecbufsize * 8 for NAL HRD parameters, as specified in [90]. For the VCL HRD parameters, the value of "CpbSize" is equal to X-predecbufsize * 40 / 6. The value of "X-predecbufsize" for H.264 (AVC) streams shall be smaller than or equal to 1200 * MaxCPB, in which the value of "MaxCPB" is derived according to the H.264 (AVC) profile and level of the stream, as specified in [90]. If "X-predecbufsize" is not present for an H.264 (AVC) stream, the value of "CpbSize" is calculated as specified in [90].
If the field is an attribute for an H.265 (HEVC) stream, the H.265 (HEVC) bitstream is constrained such that, for the NAL HRD parameters, the value of CpbSize[ i ] for at least one value of i in the range of 0 to cpb_cnt_minus1[ HighestTid ], inclusive, as specified in [117], is less than or equal to X-predecbufsize * 8, and for the VCL HRD parameters, the value of CpbSize[ i ] for at least one value of i in the range of 0 to cpb_cnt_minus1[ HighestTid ], is less than or equal to X-predecbufsize * 80 / 11. The value of "X-predecbufsize" for H.265 (HEVC) streams shall be smaller than or equal to 1100 * MaxCPB, in which the value of "MaxCPB" is derived according to the H.265 (HEVC) profile and level of the stream, as specified in [117]. If "X-predecbufsize" is not present for an H.265 (HEVC) stream, the value of "CpbSize" is calculated as specified in [117].
– "a=X-initpredecbufperiod:<initial pre-decoder buffering period>"
If the field is an attribute for an H.264 (AVC) stream, the H.264 (AVC) bitstream is constrained by the value of the nominal removal time of the first access unit from the coded picture buffer (CPB), tr,n( 0 ), equal to "X-initpredecbufperiod" as specified in [90]. If "X-initpredecbufperiod" is not present for an H.264 (AVC) stream, tr,n( 0 ) shall be equal to the earliest time when the first access unit in decoding order has been completely received.
If the field is an attribute for an H.265 (HEVC) stream, the H.265 (HEVC) bitstream is constrained such that the value of the nominal removal time of the first access unit from the coded picture buffer (CPB), AuNominalRemovalTime[ 0 ], as specified in [117], is equal to "X-initpredecbufperiod". If "X-initpredecbufperiod" is not present for an H.265 (HEVC) stream, the value of AuNominalRemovalTime[ 0 ] shall be equal to the earliest time when the first access unit in decoding order has been completely received.
– "a=X-initpostdecbufperiod:<initial post-decoder buffering period>" If the field is an attribute for an H.264 (AVC) stream, the H.264 (AVC) bitstream is constrained by the value of dpb_output_delay for the first decoded picture in output order equal to "X-initpostdecbufperiod" as specified in [90] assuming that the clock tick variable, tc, is equal to 1 / 90 000. If "X-initpostdecbufperiod" is not present for an H.264 (AVC) stream, the value of dpb_output_delay for the first decoded picture in output order is inferred to be equal to 0.
If the field is an attribute for an H.265 (HEVC) stream, the H.265 (HEVC) bitstream is constrained such that the value of pic_dpb_output_delay for the first decoded picture in output order, as specifeid in [117], is equal to "X-initpostdecbufperiod", assuming that the clock tick, ClockTick, is equal to 1 / 90 000. If "X-initpostdecbufperiod" is not present for an H.265 (HEVC) stream, the value of pic_dpb_output_delay for the first decoded picture in output order is inferred to be equal to 0.
– "a=X-decbyterate:<peak decoding byte rate>"
This field shall not be present for an H.264 (AVC) or H.265 (HEVC) stream.
– "a=3gpp-videopostdecbufsize:<size of the video post-decoder buffer>"
This attribute may be present for an H.264 (AVC) or H.265 (HEVC) stream and it shall not be present for other types of streams.
If the attribute is present for an H.264 (AVC) stream, the H.264 (AVC) bitstream is constrained by the value of "max_dec_frame_buffering" equal to Min( 16, Floor( 3gpp-videopostdecbufsize / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ) ) ) as specified in [90]. If "3gpp-videopostdecbufsize" is not present for an H.264 (AVC) stream, the value of "max_dec_frame_buffering" is inferred as specified in [90].
If the attribute is present for an H.265 (HEVC) Main profile stream, the H.265 (HEVC) bitstream is constrained such that the value of sps_max_dec_pic_buffering_minus1[ HighestTid ] + 1 as specified in [117] is less than or equal to Floor( 3gpp-videopostdecbufsize / ( PicSizeInSamplesY * 3 / 2 ) ), where PicSizeInSamplesY is as specified in [117]. If "3gpp-videopostdecbufsize" is not present for an H.265 (HEVC) stream, the value of sps_max_dec_pic_buffering_minus1[ HighestTid ] + 1 is inferred as specified in [117].
If the interleaved packetization mode of H.264 (AVC) is in use, attributes "a=X-predecbufsize:", "a=X-initpredecbufperiod:", "a=X-initpostdecbufperiod:", and "a=3gpp-videopostdecbufsize:" apply to an H.264 (AVC) bitstream when de-interleaving of the stream from transmission order to decoding order has been done.
For an H.265 (HEVC) stream transmitted over RTP using the RTP payload format as specified in [118], the attributes "a=X-predecbufsize:", "a=X-initpredecbufperiod:", "a=X-initpostdecbufperiod:", and "a=3gpp-videopostdecbufsize:" apply to the video stream that is the output of the de-packetization process.
The following media level SDP field is defined for PSS:
– "a=framesize:<payload type number> <width>-<height>"
The frame size field in SDP is needed by the client in order to properly allocate frame buffer memory. For H.264 (AVC) streams, the frame size shall be extracted from the sprop-parameters-sets parameter in the SDP, when present. For H.265 (HEVC) streams, the frame size shall be extracted from the sprop-sps parameter in the SDP, when present.
If this attribute is present, the frame size parameters shall exactly match the largest frame size defined in the video stream. The width and height values shall be expressed in pixels.
If RTP retransmission is supported, the following SDP attribute shall be supported by the client and server:
– "a=rtcp-fb" according to clause 4.2 in [57].
If CVO information is signalled in the RTP Header Extension as specified in clause 6.2.5, the PSS server shall signal this in the SDP by including the a=extmap attribute [114] indicating the CVO URN under the relevant media line scope. The CVO URN is: urn:3gpp:video-orientation. Here is an example usage of this URN to signal CVO relative to a media line:
a=extmap:7 urn:3gpp:video-orientation
The number 7 in the example may be replaced with any number in the range 1-14.
If Higher Granularity CVO information is signalled in the RTP Header Extension as specified in clause 6.2.5, the PSS server shall signal this in the SDP in a similar fashion with the CVO URN: urn:3gpp:video-orientation:6. Here is an example usage of this URN to signal CVO relative to a media line:
a=extmap:5 urn:3gpp:video-orientation:6
The following media level SDP attribute is defined, in ABNF [53] format, for PSS:
sdp-3GPP-frame-packing-type-line = "a" "=" "3GPP-framepackingtype" ":" frame-packing-type ":" payload-type-number CRLF
frame-packing-type = 1*DIGIT
payload-type-number = 1*DIGIT
The frame-packing-type value specifies the frame packing format of the described frame-packed stereoscopic 3D video. The frame-packing-type value is an integer value that shall be equal to a value in the ‘Value’ column of VideoFramePackingType table specified in [116] and be interpreted according to the ‘Interpretation’ column in the same table. The payload-type-number value indicates to which payload formats the attribute applies to.
If offering frame-packed stereoscopic 3D video as defined in clause 7.4, a PSS server shall include the sdp-3GPP-frame-packing-type-line at the media level. If a PSS client supports frame packed stereoscopic 3D video as defined in clause 7.4, then it shall be able to interpret this SDP attribute when present. The absence of this attribute indicates that the video component is not a frame-packed stereoscopic 3D video.
NOTE: If a PSS client supports frame-packed stereoscopic 3D video, frame packing types as defined in clause 7.4 are supported by the PSS client.
5.3.3.3 The "alt" and "alt-default-id" attributes
The client should interpret the following two media level attributes: "alt" and "alt-default-id". A client from earlier releases will ignore these attributes and can safely do so in a correctly formatted SDP. If the attributes are used by the server they shall be used in a way that makes them backward compatible. When interpreted, they define a number of alternatives from which the client can select the most appropriate one.
A non-extended SDP gives only one alternative for each media part (Annex A.1 Example 1). This is the default alternative for each media. The new SDP attributes defined here are used to modify the default attributes or to add new attributes to the default attributes thus creating new alternatives. Each alternative is numerically identified.
The alternative attribute "alt" is used to replace or add an SDP line to the default configuration. If the alternative attribute contains an SDP line, for which the type and the modifier already exist in the default alternative, the default must be replaced with the given line(s). In case there are multiple lines with the same type and modifier in the default alternative, all of the lines must be replaced. Multiple alternative lines can be used to modify the default alternative. The alternative lines that are used to form a certain alternative shall all carry the same numerical identifier (Annex A.1, Examples 2-4).
The alternative identifier is a unique identifier that points out a single alternative in one media declaration. The identifier must be unique between all media descriptions and their alternatives as it is used for creating combinations between different medias with the grouping attribute (see 5.3.3.4).
The default configuration is in itself a valid alternative. Therefore an attribute (alt-default-id) is defined that assigns an alternative identifier to the default alternative. This identifier can then be used with the grouping attribute (see 5.3.3.4) to create combinations of alternatives from different medias.
The alternative attribute is defined below in ABNF from RFC 4234 [53]. The SDP line is any SDP line allowed at media level except "m=".
alt = "a" "=" "alt" ":" alt-id ":" SDP-line CRLF
SDP-line = <type>=<value> ; See RFC 4566 [6]
alt-id = 1*DIGIT ; unique identifier for the alternative in whole SDP.
To be able to assign an alternative ID to the default alternative, the following identification attribute is defined.
alt-default-id = "a" "=" "alt-default-id" ":" alt-id CRLF
5.3.3.4 The session level grouping attribute, "alt-group"
The client should handle the following attribute: "alt-group". A client from earlier releases will ignore this attribute and can safely do so. When interpreted, it defines a number of grouping alternatives from which the client can select the most appropriate one. The identifiers defined in 5.3.3.3 are used together with the "alt-group" attribute to create combinations consisting of, e.g., one audio and one video alternative.
A grouping attribute is used to recommend certain combinations of media alternatives to the client. There may be more than one grouping attribute at the session level as long as they are for different grouping types and subtypes.
alt-group = "a" "=" "alt-group" ":" alt-group-type ":" alt-group-subtype ":" alt-grouping *(";" alt-grouping) CRLF
alt-group-type = token ; "token" defined in RFC 4566 [6]
alt-group-subtype = token
alt-grouping = grouping-value "=" alt-id *("," alt-id)
grouping-value = token
The alt-group attribute gives one or more combinations of alternatives through their IDs. Each grouping shall be given a grouping value. The grouping value is used to determine if the alternatives within the grouping suit the client. New types and subtypes can be added later.
The following grouping types and subtypes are defined:
– Type: BW, Subtype: All modifiers defined for the SDP "b=" attribute at session and media level. See www.IANA.org for current list of registered attributes.
Grouping value: The bandwidth value defined for that modifier calculated over all the alternatives grouped together in that grouping. For SDP bandwidth modifiers defined at session level the value shall be calculated according to its rule over the alternative part of the grouping. For media-level-only modifiers, the grouping value shall be calculated as a sum of the media-level values in the grouped alternatives. For TIAS [93] the bandwidth value alone is not sufficient to provide a receiver with sufficient information to make a decision. The SDP attribute "maxprate" is also needed. To provide this information in the grouping-value the following syntax shall be used: <bit-rate>_<maxprate>, where <bit-rate> is the bit-rate value for TIAS and <maxprate> is the maxprate value corresponding to the SDP attribute.
Grouping recommendations: Each grouping should only contain one alternative from each media type. There is no need to give groupings for all combinations between the media alternatives, rather it is strongly recommended to only give the most suitable combinations (Annex A.1 Example 5). The client can use the bandwidth values of the grouping to estimate the minimum, guaranteed or maximum bandwidth that will be needed for that session.
– Type: LANG Subtype: RFC3066
Grouping value: A language tag as defined by RFC 3066 [54]. The grouping MUST contain all media alternatives, which support that language tag.
Grouping recommendations: It is recommended that other mechanisms, like user profiles if existing, are primarily used to ensure that the content has language suitable for the user (Annex A.1, Example 6).
Se also Annex A1, Examples 7 through 16. In the examples all three new attributes "alt", "alt-default-id" and "alt-group" are used.
5.3.3.5 The bit-rate adaptation support attribute, "3GPP-Adaptation-Support"
To signal the support of bit-rate adaptation, a media level only SDP attribute is defined in ABNF [53]:
sdp-Adaptation-line = "a" "=" "3GPP-Adaptation-Support" ":" report-frequency CRLF
report-frequency = NonZeroDIGIT [ DIGIT ]
NonZeroDIGIT = %x31-39 ;1-9
A server implementing rate adaptation shall signal the "3GPP-Adaptation-Support" attribute in its SDP.
A client receiving an SDP description where the SDP attribute "3GPP-Adaptation-Support" is present knows that the server provides rate adaptation. The client, if it supports bit-rate adaptation, shall then in its subsequent RTSP signalling use the "3GPP-Adaptation" header as defined in clause 5.3.2.2, as well as the RTCP Next Application Data Unit (NADU) APP packet for reporting the next unit to be decoded, as defined in clause 6.2.3.2.
The SDP attribute shall only be present at the media level. The report frequency value, which shall be larger than zero, indicates to the client that it shall include a NADU APP packet in a compound RTCP packet no less often than the interval specified by report-frequency, except prior to receipt of RTP media packets, when the client is unable to generate a valid NADU APP packet. For example, if this value is 3, the client shall send the NADU APP packet in at least every 3rd RTCP packet.
5.3.3.6 The Quality of Experience support attribute, "3GPP-QoE-Metrics"
PSS servers using QoE-Metrics in a session shall use SDP to initiate the QoE negotiation. The reason why SDP is needed is to support the use cases where SDP is distributed through other methods than RTSP DESCRIBE, e.g. WAP, HTTP or email. A new SDP attribute, which can be used either at session or media level, is defined below in ABNF [53] based on RFC 4566 [6]:
QoE-Metrics-line = "a" "=" "3GPP-QoE-Metrics:" att-measure-spec *("," att-measure-spec)) CRLF
att-measure-spec = Metrics ";" Sending-rate [";" Measure-Range] *([";" Parameter-Ext])
Metrics = as defined in clause 5.3.2.3.1.
Sending-Rate = as defined in clause 5.3.2.3.1.
Measure-Range = as defined in clause 5.3.2.3.1.
Parameter-Ext = as defined in clause 5.3.2.3.1.
PSS servers using QoE-Metrics in a session shall use this attribute to indicate that QoE metrics are supported and will be sent. When present at session level, it shall only contain metrics that apply to the complete session. When present at media level, it shall only contain metrics that are applicable to individual media. The URI that is used in the specification of the RTSP header "3GPP-QoE-Metrics:" is implicit by the RTSP control URI (a=control).
5.3.3.7 The asset information attribute, "3GPP-Asset-Information"
This asset information attribute is defined to transmit asset information in SDP. The attribute is defined ABNF [53]:
3GPP-Assets-Info = "a" "=" "3GPP-Asset-Information:" Asset 0*("," Asset) CRLF
Asset = ("{" "url" "=" <">URL<"> "}") / ("{"AssetName "=" AssetBox "}")
URL = as defined in [60]
AssetName = "Title" / "Description" / "Copyright" / "Performer" / "Author" / "Genre" / "Rating" /
"Classification" / "Keywords" / "Location" / "Album" / "RecordingYear" / "Collection" /
"UserRating" / "Thumbnail" / asset-extension
asset-extension = 1*((0x01..0x09) / 0x0b / 0x0c / (0x0e..0x1f) / (0x21..0x2b) / (0x2d..0x3c) / (0x3e..0x7a) /
0x7c / (0x7d..0xff)) ;any byte except SP, NUL, CR, LF , "=", ",", "{" or "}"
AssetBox = Base64 encoded version [69] of any asset box as defined in Clause 8 of [50].
This SDP attribute can be present at session level, media level or both. Multiple instances of the attribute are allowed.
The resource referenced by the URL can be any pre-formatted data, e.g. an XHTML page or XML file, containing any asset information. It is up to the client’s capability and user’s preference to render the information pointed by the URL.
Example 17 in Clause A.1 shows an SDP file that includes the "3GPP-Asset-Information" attribute.
5.3.3.8 OMA-DM Configuration of QoE Metrics
5.3.3.8.0 General
As an optional alternative to configuring the QoE reporting for each session via SDP/RTSP, OMA-DM can be used to specify the default QoE configuration. If such a default QoE configuration has been specified, it shall be used by the terminal for all subsequent PSS sessions where no session-specific QoE configuration is received. QoE reporting based on the default OMA configuration shall always be done over HTTP with the XML reporting format. If the PSS client does not support HTTP reporting it shall not send default QoE reports.
Any session-specific QoE configuration received shall have higher priority, and in such cases override any default OMA-DM QoE configuration for that session.
For OMA-DM QoE configuration the parameters are specified according to the following Managed Object (MO). Version numbering is included for possible extension of the MO.
The Management Object Identifier shall be: urn:oma:mo:ext-3gpp-pssqoe:1.0.
Protocol compatibility: The MO is compatible with OMA Device Management protocol specifications, version 1.2 and upwards, and is defined using the OMA DM Device Description Framework as described in the Enabler Release Definition OMA-ERELD _DM-V1_2 [100].
5.3.3.8.1 QoE metrics reporting management object
The following nodes and leaf objects shall be contained under the 3GPP_PSSQOE node if a PSS client supports the feature described in this clause (information of DDF for this MO is given in Annex P):
Node: /<X>
This interior node specifies the unique object id of a PSS QoE metrics management object. The purpose of this interior node is to group together the parameters of a single object.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
The following interior nodes shall be contained if the PSS client supports the "PSS QoE metrics Management Object".
/<X>/Servers
This leaf contains a space-separated list of servers to which the QoE reports are transmitted. It is URI addresses, e.g. http://qoeserver.operator.com. In case of multiple servers, the PSS client randomly selects one of the servers from the list, with uniform distribution.
– Occurrence: One
– Format: chr
– Minimum Access Types: Get
– Values: URI of the servers to receive the QoE report.
/<X>/Enabled
This leaf indicates if QoE reporting is requested by the provider.
– Occurrence: One
– Format: bool
– Minimum Access Types: Get
/<X>/APN
This leaf contains the Access Point Name that should be used for establishing the PDP context on which the QoE metric reports will be transmitted. This may be used to ensure that no costs are charged for QoE metrics reporting. If this leaf is not defined then any QoE reporting is done over the default access point.
– Occurrence: ZeroOrOne
– Format: chr
– Minimum Access Types: Get
– Values: the Access Point Name
/<X>/Format
This leaf specifies the format of the report and if compression (Gzip XML) [59] is used.
– Occurrence: ZeroOrOne
– Format: chr
– Minimum Access Types: Get
– Values: "XML", "GZIPXML".
/<X>/Rules
This leaf provides in textual format the rules used to decide whether metrics are to be reported to the QoE metrics report server. The syntax and semantics of this leaf are defined in sub-clause 5.3.3.8.2.
– Occurrence: ZeroOrOne
– Format: chr
– Minimum Access Types: Get
– Values: See clause 5.3.3.8.2.
/<X>/Ext
The Ext node is an interior node where the vendor specific information can be placed (vendor includes application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
/<X>/Session
The Session node is the starting point of the session level QoE metrics definitions.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
/<X>/Session/Metrics
This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting interval and the reporting range. The syntax and semantics of this leaf are identical to the QoE-Header defined in clause 5.3.2.3.
– Occurrence: ZeroOrOne
– Format: chr
– Minimum Access Types: Get
– Values: see clause 5.3.2.3.
/<X>/Session/Ext
The Ext node is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
/<X>/Speech
The Speech node is the starting point of the speech/audio media level QoE metrics definitions.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
/<X>/Speech/Metrics
This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting interval and the reporting range. The syntax and semantics of this leaf are identical to the QoE-Header defined in clause 5.3.2.3.
– Occurrence: ZeroOrOne
– Format: chr
– Minimum Access Types: Get
– Values: see clause 5.3.2.3.
/<X>/Speech/Ext
The Ext node is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
/<X>/Video
The Video node is the starting point of the video media level QoE metrics definitions.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
/<X>/Video/Metrics
This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting interval and the reporting range. The syntax and semantics of this leaf are identical to the QoE-Header defined in clause 5.3.2.3.
– Occurrence: ZeroOrOne
– Format: chr
– Access Types: Get
– Values: see clause 5.3.2.3.
/<X>/Video/Ext
The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the Ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
/<X>/Text
The Text node is the starting point of the timed-text media level QoE metrics definitions.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
– Values: see clause 5.3.2.3.
/<X>/Text/Metrics
This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting interval and the reporting range. The syntax and semantics of this leaf are identical to the QoE-Header defined in clause 5.3.2.3.
– Occurrence: ZeroOrOne
– Format: chr
– Minimum Access Types: Get
– Values: see clause 5.3.2.3.
/<X>/Text/Ext
The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.
– Occurrence: ZeroOrOne
– Format: node
– Minimum Access Types: Get
5.3.3.8.2 QoE reporting rule definition
This clause defines the syntax and semantics of a set of rules which are used to reduce the amount of reporting to the QoE metrics report server. The syntax of the metrics reporting rules is defined below:
– QoE-Rule = "3GPP-QoE-Rule" ":" rule-spec *("," rule-spec)
– rule-spec = rule-name [";" parameters]
– rule-name = "LimitSessionInterval" / "SamplePercentage"
– parameters = parameter *(";" parameter)
– parameter = Param-Name ["=" Param-Value ]
– Param-Name = 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}"
– Param-Value = (1*DIGIT ["." 1*DIGIT]) / (1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e))
The semantics of the rules and the syntax of its parameters are defined below:
The SamplePercentage rule can be used to set a percentage sample of calls which should report reception. This can be useful for statistical data analysis of large populations while increasing scalability due to reduced total uplink signalling. The sample_percentage parameter takes on a value between 0 and 100, including the use of decimals. It is recommended that no more than 3 digits follow a decimal point (e.g. 67.323 is sufficient precision).
When the SamplePercentage rule is not present or its sample_percentage parameter value is 100 each PSS client shall send metric report(s). If the sample_percentage value is less than 100, the UE generates a random number which is uniformly distributed in the range of 0 to 100. The UE sends the reception report when the generated random number is of a lower value than the sample_percentage value.
The LimitSessionInterval rule is used to limit the time interval between consecutive sessions that report metrics. The min_interval parameter for this rule indicates the minimum time distance, in seconds, between the start of two sessions that are allowed to report metrics. When this rule is absent there is no limitation on the minimum time interval.
In case multiple rules are defined in the Management Object, the PSS client should only report metrics when all individual rules evaluate to true (i.e. the rules are logically ANDed). In case no rules are present the PSS client should always report metrics (see also clause xx for metrics reporting procedures).
An example for a QoE metric reporting rule is shown below:
3GPP-QoE-Rule:SamplePercentage;sample_percentage=10.0,LimitSessionInterval;min_interval=300
This example rule defines that only 10% of the sessions shall report, with the minimum time interval between the start times of two consecutive sessions that report metrics to be 5 minutes.
5.4 MIME media types
For continuous media the following MIME media types shall be used:
– AMR narrow-band speech codec (see sub-clause 7.2) MIME media type as defined in [11];
– AMR wideband speech codec (see sub-clause 7.2) MIME media type as defined in [11];
– Extended AMR-WB codec (see sub-clause 7.3) MIME media type as defined in [85];
– Enhanced aacPlus and MPEG-4 AAC audio codecs (see clause 7.3) MIME media type as defined in RFC 6416 [13].
The following applies to servers when this MIME type is used in SDP:
1) Configuration information is exclusively carried out-of-band in the SDP "config" parameter; this shall be signaled by sending "cpresent=0".
2) A PSS server serving implicitly signaled Enhanced aacPlus content shall include "SBR-enabled=1" in the "a=fmtp" line; it shall include "SBR-enabled=0" if it serves plain AAC content.
3) A PSS server serving explicitly signaled content is recommended not to include the "SBR-enabled" parameter in the "a=fmtp" line.
Therefore, the following applies to terminals:
1) The rtpmap rate parameter should not be considered definitive of the sampling rate (though it is, of course, definitive of the timescale of the RTP timestamps).
2) If explicit signaling is in use, the StreamMuxConfig contains both the core AAC sampling rate and the SBR sampling rate. The appropriate output sampling rate may be chosen dependant on Enhanced aacPlus support.
3) If explicit signalling is not in use and no SBR-enabled parameter is present, the StreamMuxConfig contains the AAC sampling rate and the appropriate output sampling rate may be set to this indicated rate.
4) If explicit signalling is not in use and the SBR-enabled parameter is present, terminals supporting Enhanced aacPlus should set the output sampling rate to either the core AAC sampling rate as indicated in the StreamMuxConfig [21] (where "SBR-enabled" is set to "0") or twice the indicated rate (where "SBR-enabled" is set to "1");
– – H.264 (AVC) [90] video codec (see sub-clause 7.4) MIME media type as defined in [92];
– H.265 (HEVC) [117] video codec (see sub-clause 7.4) MIME media type as defined in [118];
– 3GPP timed text format [51] MIME media type as defined in sub-clause 7.1 of [80];
– enc-isoff-generic MIME media type as defined in [102] and used in Annex R;
– RTP retransmission payload format MIME media types as defined in clause 8 of [81].
MIME media types for JPEG, GIF, PNG, SP-MIDI, Mobile DLS, Mobile XMF, SVG, timed text and 3GP can be used in the "Content-type" field in HTTP, "content_type" field in the item information box of 3GP files. The following MIME media types shall be used for these media:
– JPEG (see sub-clause 7.5) MIME media type as defined in [15];
– GIF (see sub-clause 7.6) MIME media type as defined in [15];
– PNG (see sub-clause 7.6) MIME media type as defined in [38];
– SP-MIDI (see sub-clause 7.3A) MIME media type as defined in clause C.2 in Annex C of the present document;
– DLS MIME media type to represent Mobile DLS (see sub-clause 7.3A) as defined in [97];
– Mobile XMF (see sub-clause 7.3A) MIME media type as defined in clause C.3 in Annex C of the present document;
– SVG (see sub-clause 7.7) MIME media type as defined in [42];
– Timed text (see sub-clause 7.9) MIME media type as defined in [79];
– 3GP files (see sub-clause 7.10) MIME media type as defined in [79].
NOTE: The 3GP MIME media type [79] is used for all 3GP files, including 3GP files carrying timed text, images, etc.
5.5 Extension for Fast Content Switching and Start-up
5.5.1 Introduction
Applications which are built on top of packet switched streaming (PSS) services are classified into on-demand and live information delivery applications. This clause defines procedures to allow faster start up and switching of content for both on-demand and live applications by reducing the client/server interactions to a minimum. Additionally, clients are enabled to reuse the existing RTSP control session and RTP resources while switching to new content.
5.5.2 Extensions to RTSP 1.0
5.5.2.1 Introduction
Various general RTSP extensions are required for support of fast content start-up and switching. These extensions must be implemented by PSS clients and servers wishing to support any of these features.
The following new RTSP feature tags are defined:
– "3gpp-pipelined" feature-tag, section 5.5.3
– "3gpp-switch" feature-tag, section 5.5.4.3
– "3gpp-switch-req-sdp" feature-tag, section 5.5.4.4
– "3gpp-switch-stream" feature-tag, section 5.5.4.5
In addition the following new RTSP header fields are defined:
– "Switch-Stream" header, section 5.5.4.2
– "SDP-Requested" header, section 5.5.4.4
– "Pipelined-Requests" header, section 5.5.3
5.5.2.2 Capability Handling
5.5.2.2.1 Introduction
The PSS client shall determine the PSS server’s capabilities and indicate its own capabilities to the server using the "Supported" header field (see clause 5.5.2.2.2) as early as possible (e.g. with the DESCRIBE request).
The "Require" header field is used as defined in RFC 2326 [5] to ensure that a certain feature is supported by the PSS server. An unsupported feature shall cause the containing request to fail with a 551 reply code and "Option not supported" as the reason. The 551 reply shall also include the unsupported features in the "Unsupported" header field. The "Require" header field should not be used for probing support for features but rather to make sure that a specific request is executed correctly with the specified features.
5.5.2.2.2 Definition of the "Supported" RTSP Header Field
PSS clients and servers must support the "Supported" RTSP header field.
The "Supported" header field enumerates all the extensions supported by the client or server using feature tags. The header carries the extensions supported by the message sending entity. The "Supported" header may be included in any request. When present in a request, the server shall respond with its corresponding "Supported" header.
If an RTSP request includes a "Supported" header but the corresponding response does not include this header field, then the PSS client shall assume that the PSS server does not support any of the indicated features
Note, the "Supported" header must be included in error as well as success responses.
The Supported header field contains a list of feature-tags, described in Section 5.5.2.1, that are understood by the client or server.
Example:
C->S: OPTIONS rtsp://3gpp.org/ RTSP/1.0
CSeq: 1
Supported: 3gpp-pipelined
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN
Supported: 3gpp-pipelined, 3gpp-switch, 3gpp-switch-req-sdp, 3gpp-switch-stream
5.5.2.3 SSRC in the "RTP-Info" RTSP Header Field
The "RTP-Info" response header field is used to set RTP-specific parameters in the PLAY response. For streams using RTP as transport protocol the "RTP-Info" header is always part of a 200 response to PLAY (as defined in Annex A.2.1). In addition to the parameters defined in RFC 2326 [5], the "RTP-Info" header may also include a synchronization source (SSRC) parameter.
Note. The SSRC parameter is mandatory for some content switching procedures defined in clause 5.5.4.
The SSRC parameter gives the synchronization source (SSRC) of the RTP flow to which the RTP timestamp and sequence number apply. It is only possible to describe one synchronization source (SSRC) per media resource.
After a fast content switch (FCS) the SSRC source used on a specific RTP session may change. In the event that the SSRC changes, it shall be included in the RTP-Info header. The PSS server shall change the SSRC value for a specific RTP session after a fast content switching operation is performed and
– if the payload type of the old and of the new media stream is the same but the media codec configuration is different, or
– if the mapping of the new media stream is otherwise unknown to the PSS client.
In case the SSRC remains unchanged after a content switch, the RTP sequence number and timestamp should be continuous and shall be monotonically increasing. Otherwise, a random RTP sequence number and timestamp should be used.
Further details on the usage of the SSRC are described in clause 5.5.3 or clause 5.5.4. Note the SSRC may only be included in the "RTP-Info" header, if the client has requested one of the features defined in clause 5.5.3 or clause 5.5.4.The "RTP-Info" header syntax in ABNF [53] is as follows:
RTP-Info = "RTP-Info" ":"rtsp-info-spec *("," rtsp-info-spec) CRLF
rtsp-info-spec = stream-url 1*parameter
stream-url = "url" "=" rtsp-url
parameter = ";" "ssrc" "=" 8HEX
/ ";" "seq" "=" 1*DIGIT
/ ";" "rtptime" "=" 1*DIGIT
5.5.2.4 Semantics of RTSP PLAY method
The queued PLAY functionality described in RFC 2326 [5] is removed. If a PLAY request is received for an RTSP session that is in the Playing State, then the server shall immediately execute the new PLAY request and terminate the old.
5.5.3 Start-up
In order to improve start-up times, a client may pipeline all necessary SETUP requests and the PLAY request. This allows streaming to begin with a single RTSP round trip if the client already has the SDP (or other adequate content description), or two round trips if it needs to first perform a DESCRIBE in order to receive the necessary information.
If the client intends to send upstream packets to ensure correctly open firewalls (also called port punching packets), then the client should not send a PLAY request until all SETUP responses are received. Pipelining of SETUP requests is still possible in this case.
If the client uses RTSP DESCRIBE to fetch the SDP from the server, then the client shall probe the server capabilities as described in clause 5.5.2.2 using the feature-tag value "3gpp-pipelined".
The client shall add the RTSP "Require" header to all but the first pipelined RTSP SETUP request with the value "3gpp-pipelined". Note that the first RTSP SETUP request shall not use a "Require" header. This will allow the PSS client to interoperate with minimal impact with older servers that do not support this feature.
Since the session does not yet exist when these pipelined messages are sent, a request header is defined which allows the client to inform the server that these messages are to be carried on the same session once it is created. Clients wishing to use pipelined start-up must implement the "Pipelined-Requests" header in order to signal the session grouping to the server.
The syntax of the "Pipelined-Requests" header is defined in ABNF [53] as follows:
Pipe-Hdr = "Pipelined-Requests" COLON startup-id
startup-id = 1*8DIGIT
The client should monitor whether the server behaves as declared.
A client unique "startup-id" is required until the client receives the session ID. The "startup-id" is unique for a particular TCP connection. Pipelined requests using this header must be sent on the same TCP connection. The method through which this ID is generated is to be decided by the client.
5.5.4 Fast Content Switching
5.5.4.1 Introduction
In most cases, a content switch can be initiated with a single RTSP request. In order to preserve interoperability with RTSP aware intermediate devices such as application layer gateways, PSS clients should ensure that SETUP requests and responses are sent for each RTP/RTCP port pair to be used. Once a port pair has been negotiated, it may be reused for subsequent content upon a switch.
5.5.4.2 "Switch-Stream" RTSP Header Field
The "Switch-Stream" header field may be used in an RTSP PLAY request or an RTSP PLAY response message. It is used to describe the replacement of media streams after a content switch. The "Switch-Stream" header field may be used with aggregated control and with media control URLs.
The "Switch-Stream" header syntax in ABNF [53] is as follows:
Switch-Stream = "Switch-Stream" COLON switch-spec *(COMMA switch-spec) CRLF
switch-spec = old-stream ";" new-stream
old-stream = "old" "=" (DQ rtsp-url DQ) / (DQ DQ)
new-stream = "new" "=" (DQ rtsp-url DQ) / (DQ DQ)
rtsp-url = as defined in RFC 2326 [5]
DQ = %x22 ; US-ASCII double-quote mark (34)
LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace
COMMA = * ( SP / HT ) "," SWS; comma
COLON = * ( SP / HT ) ":" SWS; colon
If both old media stream and new media stream URLs are indicated in the "Switch-Stream" header field of a PLAY request from a PSS client to a PSS server, then the server shall interpret this as a request to replace the old media stream with the new media stream, hence reusing the transport parameters of the old media stream for the new media stream.
If the "Switch-Stream" header field is included in a PLAY response from a PSS server to a PSS client, then this header informs the client about the media streams that are currently being streamed to the PSS client. The old media stream may be omitted in this case.
If only the new media stream URL is indicated in the "Switch-Stream" header field of a PLAY request from a PSS client to a PSS server, then the PSS server shall interpret this as a request to switch to the new media stream. The PSS server decides the mapping. The PSS server shall indicate the SSRC of the new media stream in the RTP-Info of the reply, in order to enable the PSS client to locate the new stream.
If only the old stream URL is indicated in the "Switch-Stream" header field of a PLAY request from a PSS client to a PSS server, then the PSS server shall interpret this as a request for complete removal of the specified media stream. The client and the server release the resources for this stream without explicit TEARDOWN signalling. The usage of the switch-stream header is defined in clauses 5.5.4.3, 5.5.4.4 and 5.5.4.7.
5.5.4.3 Switching to new content with available SDP
This clause defines all necessary PSS client and PSS server features for fast content switching where the UE already has the SDP for the new content locally available. The UE may have fetched the SDP file using RTSP DESCRIBE or HTTP GET or in any other method. Clients should assume that the herein defined fast content switching procedure is supported for all content items offered by this server. This PSS feature reduces the switching to new content to a single client-server interaction.
The feature-tag indicating this feature is "3gpp-switch". The client should probe the server capabilities as early as possible in the communication using the "3gpp-switch" in the "Supported" header as defined in 5.5.2.2.2. The client shall use the "Require" header with this feature tag value, when requesting this behaviour from the server. The server shall use the PLAY method as defined in 5.5.2.4 with the "3gpp-switch" feature tag in the "Require" header when the client requests this feature. Thus, the server replaces the current RTSP PLAY request by the new request resulting in a switch of streamed content.
When the PSS client wants to change the content of the RTSP session, the PSS client sends a PLAY request with the aggregated control URI of the new content to the PSS server. Note, the aggregated control URI is defined in the SDP file by the session level "a=control:" attribute.
The PSS client shall add the media control URIs of the new streams in the "Switch-Stream" header field to the RTSP PLAY method request. Whenever possible, the PSS client shall map the media control URIs of the same media type (e.g. audio or video) in the old content to the same media type of the new session. Note, this is only applicable for media types, which are present in the old and new content. The server includes always the "Switch-Stream" header in the response. The "Switch-Stream" header field is defined in 5.5.2.4.
If the SSRC have changed, then the server shall indicate the new SSRC values of the new media streams within the "RTP-Info" header in the response. The SSRC entry for the "RTP-Info" is defined in clause 5.5.2.3.
Note, if the new SDP contains more media components than the current session, the client may switch according to this section, describing the desired components in the "Switch-Stream" header, and add the missing components using the method defined in 5.5.4.6.
If less media components are described in the new SDP than currently in use, the client and the server remove the component as defined in 5.5.4.7.
The entity-tag attribute ("a=etag" as specified in [5]) may be used in order to ensure that SDP information is used only if it is valid. When a PSS client requests a switch to content for which an entity-tag is available, it should include the "If-Match" header and the etag value in the PLAY request. A PSS server shall validate the entity-tag in the If-Match headers prior to accepting the request. If the entity-tag is not valid, the server shall return either 412 (Precondition Failed) or if the client has previously communicated support for the "3gpp-switch-req-sdp" feature, the server may respond with a current SDP in an appropriate success response, as defined in Section 5.5.4.4.
5.5.4.4 Switching to new content without SDP
Clients should assume, that the here defined fast content switching procedure is supported for all content items offered by this server. The client uses the URL of the SDP file as content URL to describe the new content item.
Without an SDP or other adequate content description, the client is unable to specify the streams to which it wishes to subscribe. In order to initiate a content switch within a single RTSP round trip, the client may perform a PLAY request to initiate a switch via content URL without specifying individual streams. This allows the client to request that the server return the SDP, initiate a new session, setup all relevant media streams (or make an appropriate stream selection), and begin playback. The content URL used in the PLAY request is the same content URL used in a DESCRIBE. In order to signal that it wishes to receive the description and make a switch, the client shall include the "SDP-Requested" header as defined below. This header is defined as follows:
SDP-Requested-Header = " SDP-Requested" COLON "1"
If a server receives a PLAY request and completes all actions successfully, the server responds with the SDP, Session-ID, RTP-Info, and a "Switch-Stream" descriptor and begins streaming immediately. Whenever possible, the PSS server shall map the media control URIs of the same media type (e.g. audio or video) in the old content to the same media type of the new session. Note, this is only applicable for media types, which are present in the old and new content. The RTP-Info in the PLAY response must contain the SSRC for each stream as defined in 5.5.2.3. The server may issue a new session ID in the response, or it may re-use the existing session ID. The client must be prepared for either case.
If the server is not yet able to begin streaming, it responds with a 202 (Accepted) success code and with the SDP. The client may then perform a switch as described in 5.5.4.3 specifying the streams it would like to receive. This condition can occur if the server requires further client input regarding stream setup prior to beginning playback – for instance if the content requested contains multiple language switch groups and the server does not have the information necessary to choose a language.
If the server is not yet able to begin transmitting all the media streams, it can begin a subset of the streams and respond with a 206 (Partial Data) success code and the SDP. The "Switch-Stream" header and the "RTP-Info" header will indicate which streams have been selected for playback. The client may then add additional media components as described in 5.5.4.6.
If fewer media components are described in the new SDP than currently in use, then the server responds with a 200 (OK). The terminal shall remove the "unused" media components as defined in clause 5.5.4.7.
The client and the server shall release the resources for the unused streams without explicit TEARDOWN signalling.
The feature tag "3gpp-switch-req-sdp" is defined to describe support for this feature. The client should probe the server capabilities as early as possible in the communication using the "Supported" header as defined in 5.5.2.2 and shall use the "Require" header with this feature tag value when requesting this behaviour from the server. The server shall use the PLAY method semantics defined in 5.5.2.4 when the client requests this feature.
5.5.4.5 Switching Media described in one SDP
Some content may be available for streaming in different representations. An example of such a use case is the live streaming of a sport event with multiple camera views. The SDP available at the receiver describes multiple options for one or several media types (e.g. video, audio, or subtitles). Upon initial setup of the session, the player (or the user) selects the preferred combination of the presentation to be consumed and sets up the corresponding media streams. At a later point, the user may trigger a switch to a different media stream carrying an alternative representation of the media.
The PLAY request is sent with the "Switch-Stream" header field as defined in clause 5.5.4.2 indicating the URLs of both the old media stream and the new replacement stream. Upon receiving a PLAY request with a "Switch-Stream" header field for an active session, a PSS server that supports this feature switches to the new media stream using the same transport parameters described in the initial SETUP request for the old media stream. After successfully processing the request, the PSS server shall reply with an "RTP-Info" header indicating all active media streams in the changed session. The "RTP-Info" header may include the SSRCs for each active media stream. The response may also include the "Switch-Stream" header, indicating the stream switches that were successful. If the "Switch-Stream" header field is not present in a successful response and the PSS server was identified to support the media switching functionality, the receiver should assume that all requested switches were successful.
The feature tag "3gpp-switch-stream" is defined to describe support for this feature. This feature tag is different than the feature tag "3gpp-switch" feature described in 5.5.4.3 indicating the support for content (aggregated stream) switch. The client should use the "Require" header with this feature tag value when requesting this behaviour from the server. The server shall use the PLAY method semantics as defined in 5.5.2.4 when the client requests this feature. Note that several media streams of a presentation may be switched at the same time in a single PLAY request.
5.5.4.6 Adding Media Components to an ongoing session
It may happen that the new content stream consists of more media components than the ongoing content stream. In such a case, the client is recommended to switch to the new content with the already established resources and add further components afterwards.
The client should pipeline the setup requests for the new components after the content switching request (see clause 5.5.4). The client shall issue a PLAY request to start all addition media components without interrupting the existing. If the client and server support the "3gpp-pipelined" feature (see clause 5.5.3), then the client shall pipeline the PLAY request with the SETUP requests. The "RTP-Info" header contains the synchronization information for all media components.
The session id value of the already established session shall be part of the SETUP request header to indicate the relation of the media component to the already established components.
5.5.4.7 Removing Media Components from an ongoing session
A PSS client wishing to terminate the streaming of a specific media stream shall send a PLAY request with a "Switch-Stream" header indicating the URL of the media stream to be torn down as the old media stream. No URL for the new media stream should be specified.
Upon receiving a PLAY request with "Switch-Stream" header field indicating that one or more media streams are to be terminated, the server shall stop streaming the indicated media streams and release the used UDP ports for this media component and free the associated resources. However, the other media streams should not be interrupted.
After successfully processing the request, the server shall reply with a success response message and a "Session" header field, even if the session contains no more media streams.
The PSS client shall only use TEARDOWN to completely tear down the whole session.
5.6 Extension for Time-Shifting Support
5.6.1 Introduction
Time shifting functionality is designed to enhance the access to live streaming sessions. For this reason, the PSS server maintains a time-shift buffer for each live feed. The server side timeshift buffer allows the PSS client to pause live sessions and even navigate (rewind, fast forward) in the offered time-shift buffer range. A timeshift supporting PSS client, which is connected to a timeshift supporting PSS server is able to perform some or all of the following operations on timeshifted streaming sessions:
– Pause and resume the playout at a later point in time
– Start playout from (or seek to) a position in the stream that corresponds to a past time instant in the live streaming session
– Perform operations such as Fast and Slow Forward or Rewind (i.e. Trick Mode).
NOTE: the live streaming feed is not necessarily offered by the same PSS server as the time-shifted session. For example, the PSS server may be handling time-shifting services for a live feed accessible as an MBMS streaming service.
5.6.2 General Description
The PSS timeshift functionality requires the availability of one or more timeshift buffers on the server side. The size of the timeshift buffer is determined by the server. This specification does not limit the size of the timeshift buffer.
The timeshift buffer is defined by an upper and a lower range. New live data is added at the upper range to the timeshift buffer. If the timeshift buffer progresses as sliding window, then the server removes and discards data from the lower range of the timeshift buffer. The upper range of the timeshift buffer is also referred to as current recording time.
The PSS server announces the availability of the timeshift feature and describes the current state of the time-shift buffer in the RTSP SETUP response. The PSS server provides the current recording time and the current time-shift buffer ranges with each RTSP PLAY and PAUSE response messages. The server may report updated timeshift buffer ranges throughout the session via SET_PARAMETER messages and the client may request this information via GET_PARAMETER requests.
In the following, two PSS timeshift use-cases are described to clarify the operations of PSS timeshift.
Usecase A: A user starts a live session using "range: npt=now-". The user enters timeshift operation at a later point by pressing "pause". The PSS client stores the value of the "current recording time" header, which is received with the pause response message to resume the session. The PSS client is aware of the server side timeshift buffer ranges.
Usecase B: A user may directly start a live session in a timeshift operation, for instance when changing from broadcast to reception of the same content. The PSS client may use absolute time representation (clock) to continue consuming the content at the same media position.
5.6.2a Extensions to RTSP 1.0
At least one PSS timeshift buffer is provided by the PSS server for at least one live stream. The PSS server may also provide individual timeshift buffers per RTSP session. The PSS server announces the availability of the timeshift feature and describes the current range of the time-shift buffer in the RTSP SETUP response.
The PSS client should always calculate current valid boundaries of the timeshift buffer.
The PSS timeshift feature may be used with either NPT or UTC time ranges. PSS clients that support time shifting shall support also UTC time in addition to NPT.
If the PSS server supports PSS timeshifting as defined in this section, then the new RTSP headers 3GPP-TS-CurrentRecording-Time and 3GPP-TS-Buffer shall be present in all server to client messages.
The Accept-Ranges header field may be used to check for the support of UTC time. The PSS server indicates the preferred media range format for time shifting in the 3GPP-TS-CurrentRecording-Time and 3GPP-TS-Buffer headers in the PLAY response. PLAY requests may contain the "npt=now-" range indication to seek to the upper range of the time shift buffer. Other time shifting operations shall consistently use the same media range format that is indicated by the PSS server.
5.6.3 Accept-Ranges
The Accept-Ranges request and response-header field allows indication of the format supported in the Range header. The PSS client shall include the header in SETUP requests to indicate which formats it supports in PLAY and PAUSE responses and REDIRECT requests. The server shall include the header in the SETUP response and in any error response caused by an unaccepted range format, to indicate the formats supported for the resource indicated by the request URI.
This header has the following ABNF syntax:
– Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges CRLF
– acceptable-ranges = range-unit *(COMMA range-unit)
range-unit = "npt" / "utc"
5.6.4 Signalling Time Shifting Ranges
In order to allow the PSS server to provide the PSS client with the current ranges of the time shift buffer, two new RTSP headers are defined.
The PSS client may start a PSS session already in "timeshift mode".
The PSS server provides the upper bound of the timeshift buffer with the "3GPP-TS-CurrentRecording-Time" header. The PSS client should not request playback beginning beyond the current recording time (i.e. no future playback times). If a PSS server receives a PLAY request outside of the time shift buffer range, the PSS server should handle the request as a request for the appropriate buffer boundary time. In case of a range request exceeding the range end time, this will be the end time; in case of a range request beginning earlier than the buffer start time, this will be the start time. The actual range streamed will then be reported in the 200 OK response message.
The PSS server describes the current available range for PSS time shifting with the "3GPP-TS-Buffer" header. This header may use one of three descriptive formats, depending on the current state of the time-shift buffer. The client is responsible for keeping track of the available timeshift buffer boundaries.
The "buffer-depth" parameter indicates the depth of the timeshift buffer in seconds. When this format is indicated, the timeshift buffer is constantly filled to the specified depth; the timeshift buffer is progressed as a sliding window. The PSS client calculates together with the information from the "3GPP-TS-CurrentRecording-Time" header the lower and upper range of the timeshift buffer. The PSS client shall continuously update the upper and lower boundary of the timeshift buffer.
The "interval" parameter can either indicate a closed range (two value) or an open range (one value) indicating absolute times for the timeshift buffer ranges. No timeshift data is available earlier than the left range value of the 3GPP-TS-Buffer parameter and, if the upper range is present, time shifting is not available beyond that time. If this value indicates an open range (one absolute start time for the timeshift recording), then the PSS server has not given any end-time for timeshift recording.
When both parameters are present, this indicates that the timeshift buffer is still being established. Recording has started at the lower bound of the interval and will progress until the specified depth is reached. Once the buffer depth is reached, then the timeshift buffering continues in a sliding window as described above and the PSS server uses the buffer header parameter for timeshift buffer reporting.
The ABNF syntax for the new headers is as follows:
3GPP-TS-CurrentRecording-Time="3GPP-TS-CurrentRecording-Time" COLON (npt-time-indication / utc-time-indication) CRLF
npt-time-indication = "npt=" (npt-sec / npt-hhmmss)
utc-time-indication = "clock=" utc-time
3GPP-TS-Buffer = "3GPP-TS-Buffer" COLON (depth / interval / interval_depth) [SEMIParameter-Ext] CRLF
depth = "buffer-depth=" 1*DIGIT
interval = utc-range / npt-range
interval_depth = interval SEMI depth
Parameter-Ext = (1*DIGIT ["." 1*DIGIT]) / (1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e))
COLON = < as defined in clause 5.5.4.2 >
SEMI = SWS ";" SWS ; semicolon;
SWS = < as defined in clause 5.5.4.2>
Note: utc-range, npt-range, utc-time, npt-sec, and npt-hhmmss are defined in [5]RFC2326.
5.6.5 Timeshift buffer status updates
The GET_PARAMETER and the SET_PARAMETER methods allow the client and the server to synchronize timeshift buffer information.
The PSS client may query the PSS server at any time for the current timeshift buffer fill states. For this procedure, the PSS Client issues the RTSP GET_PARAMETER request message with the 3GPP-TS-Buffer and/or 3GPP-TS-CurrentRecording-Time tags in the message body. The MIME Type "text/plain" is used for the RTSP message body.
The GET_PARAMETER response shall carry the 3GPP-TS-Buffer and the 3GPP-TS-CurrentRecording headers in the header fields and also in the RTSP response message body.
The server may update the current timshift information using the RTSP SET_PARAMETER method (S->C). The SET_PARAMETER request message shall carry the 3GPP-TS-Buffer and the 3GPP-TS-CurrentRecording headers in the header fields and also in the RTSP request message body. The PSS client shall confirm the reception with a "200 OK" RTSP response message or, if it client does not understand the parameters, it shall return "451 Invalid Parameters" and the PSS server shall not attempt further updates.
5.7 Support for Trick Mode Operations
PSS client and server may support trick mode operations such as fast/slow forward and rewind. The level of scale support may also depend on the selected streaming content.
A PSS Client may use the "play.scale" feature tag to query for support of scaled playout. The "play.scale" feature tag applies only to PSS servers and indicates the support for scale operations for media streaming.
If the server supports the scale value requested, and the content is capable of the scale value requested, the server shall serve the scaled stream to the client. If the server does not support the scale value requested or the content does not support the scale value requested then the server shall decide what level of scaled playout to serve to the client. When trick mode operations are supported, the "Scale" header field of RTSP [5] shall be used for requesting trick mode operations.
Streaming with a scale value other than 1 should not change the streaming bitrate of the corresponding media stream.
The PSS Client is made aware of the scale values supported for the content via the "X-Scale" media level attribute, or by using the "scales" parameter in the GET_PARAMETER and SET_PARAMETER. The "scales" parameter takes precedence in the case of conflicting values. The PSS server may temporarily omit the transmission of media data for one or more media streams on which playout with the selected scale is not possible. For example, this may mean that the video is scaled at a rate of 2, but the audio is omitted for the duration of the scaled playout as it is unable to be scaled.
A PLAY request with a "Scale" indication that is not supported by any of the media streams of the streaming session may be ignored by the PSS server. The PSS server should use the closest supported scale value instead and it shall indicate the chosen value in the response, unless the selected scale value is 1.
The "X-Scale" SDP attribute and the "scales" parameter are defined according to the following ABNF syntax:
Scale="X-Scale:" payload_type SP scale_value *(";" scale_value) CRLF
scales="scales:" scale-spec *("," scale-spec) CRLF
scale-spec= stream-url "=" scale *(";" scale)
scale_value=["-"] 1*DIGIT [ "." *DIGIT]
In the SDP, the payload_type indicates the payload type of the media to which the scale values apply. The stream-url indicates the URL of the media stream to which the indicated scales are applicable. The scale_value is a decimal number that indicates the possible scale value that may be requested for the specified media stream. For a single media stream, multiple scale values are possible.
When timeshifting is used, the following applies:
– in the case that the PSS Client knows that, due to the PSS Server’s buffer, a particular request for scaled playback is impossible to complete, the PSS Client shall not request this scale value.
– in the case that the PSS Server is providing scaled playback and a buffer limit is reached, the PSS Server shall return the scale value of the stream to 1.
– the PSS client should take into account the playout scale when calculating its current position in the time shifting buffer, and take the time shifting buffer into account when requesting a playout scale.
5.8 Session Update
PSS client may support session updates triggered by the PSS server. A new RTSP feature tag "3gpp-session-update" is defined. The PSS client that supports session updates shall include the feature tag in the Supported header field of SETUP or PLAY requests from the client to the server.
The PSS Server shall use the SET_PARAMETER method to trigger session updates with clients that have indicated support for session update. The Range header field shall be included to indicate the time at which the new session description becomes active. The PSS Server shall include the updated session description (SDP) in the body of the message. The new mapping of the media streams to the RTP sessions shall be indicated using the Switch-Stream header as defined in the procedures of content switching.
Example:
S->C SET_PARAMETER rtsp://example.com/content.3gp RTSP/1.0
Cseq: 4072
Session: 332321598
Range: npt=1:21:24.568-
Switch-Stream: old=rtsp://www.nokia.com/content1/trackID=1;
new=rtsp://www.nokia.com/content2/trackID=2
Content-Type: application/sdp
Content-length: 421
v=0
o=33405 135 0 IN IP4 10.42.43.1
s=Live
c=IN IP4 0.0.0.0
t=0 0
m=video 8234 RTP/AVP 96
a=rtpmap:96 H264/90000
a=framerate:25
a=fmtp:96 packetization-mode=1;profile-level-id=42c00b;
m=audio 8236 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/22050
a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-hbr;
C->S RTSP/1.0 200 OK
Cseq: 4072
Session: 332321598
If the client responds with a 451 (Parameter Not Understood) message, the server shall assume that the session update message was not correctly processed and may then terminate the session or redirect the client to the new session.
If RTSP is used over UDP, the server should take precautions to ensure that the session update message has been received by the client, e.g. through redundant transmission of the SET_PARAMETER message.
In case no persistent TCP connection exists between the PSS client and PSS server, the PSS server shall trigger the setup of a TCP connection by sending an RTCP APP packet for an Outstanding Session Notification Message (OSNM).
The fields of the generic RTCP APP packet shall be set as follows:
– name: the OSNM APP data format is detected through the name "PSS0", i.e. 0x50535330
– subtype: the subtype shall be set to 1 for the OSNM format
– application-dependent data: the application-dependent data shall carry an OSNM block as defined in the following figure 2a.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| Message Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- OSNM
The fields of the OSNM block are set as follows:
– Timestamp: the NTP 32-bit timestamp that indicates the recommended time for the client to respond to the notification message
– Message Identifier: the message identifier provides a unique identifier for the OSNM message and enables the client to differentiate between repetitions of the message and new OSNM message.
– Reserved: this field is reserved for future usage and shall be set to 0.
Upon receiving a new RTCP OSNM message and if the PSS client supports session updates, the PSS client shall setup a TCP connection to the RTSP server before the indicated time. The TCP connection may then be terminated after receiving and responding to an RTSP message from the PSS server or at the latest within 5 minutes of the indicated time in the OSNM message.