3g multimedia streaming services

I

1

3GPP2 C.S0046-0 Version 1.0 Date: February 21, 2006

3G Multimedia Streaming Services 2

3

4 COPYRIGHT 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

5 6

http://www.3gpp2.org/

C.S0046-0 v1.0


PREFACE 1

This document defines content types, media formats, codecs, and delivery support for 2 Multimedia Streaming Service (MSS). 3

4

C.S0046-0 v1.0


1 Contents 1

1 Contents ............................................................................................................................................3 2

2 List of Figures ...................................................................................................................................5 3

3 List of Tables ....................................................................................................................................6 4

4 Scope.................................................................................................................................................7 5

5 References.........................................................................................................................................8 6 5.1 Normative References ........................................................................................................8 7 5.2 Informative References.....................................................................................................11 8

6 Definitions and Abbreviations ........................................................................................................12 9 6.1 Definitions ........................................................................................................................12 10 6.2 Abbreviations....................................................................................................................13 11

7 Multimedia Streaming Services Structure.......................................................................................15 12

8 Call procedures for Multimedia Streaming.....................................................................................17 13 8.1 Control Protocol (RTSP) ..................................................................................................17 14

8.1.1 Mobile Link-Char Header 17 15 8.1.2 The 3GPP-Adaptation Header 19 16 8.1.3 The "Avc-rtpinterleaving" Header 19 17

8.2 Session Set-up (SDP)........................................................................................................20 18 8.2.1 Session Capability Exchange (SDP) 20 19 8.2.2 Session Video Buffering (SDP) 20 20 8.2.3 Additional Attributes (SDP) 21 21 8.2.4 Session 3GPP-Adaptation-Support (SDP) 22 22 8.2.5 Session HE AAC Support (SDP) 22 23

8.3 Capability Exchange (CE) ................................................................................................22 24 8.3.1 Overview 22 25 8.3.2 Description 23 26

8.4 Presentation/Layout Description ......................................................................................26 27 8.4.1 SMIL Usage in MSS 26 28

8.5 Data Channel Setup ..........................................................................................................27 29 8.5.1 Header Compression 27 30

8.6 Session Termination .........................................................................................................28 31

9 Transport Protocol ..........................................................................................................................29 32 9.1 RTP/UDP..........................................................................................................................29 33

9.1.1 RTCP extension (NADU APP packet) 30 34 9.2 HTTP/TCP and Container Formats ..................................................................................32 35

9.2.1 Transport of CMF Over HTTP 32 36

C.S0046-0 v1.0


10 Pseudo Streaming............................................................................................................................34 1 10.1 Session Description ..........................................................................................................34 2 10.2 Transport Options .............................................................................................................34 3

10.2.1 Request 34 4 10.2.2 Response 35 5

10.3 FFMS Usage in MSS........................................................................................................37 6

11 Media Types (Codecs) ....................................................................................................................38 7 11.1 General Requirements ......................................................................................................38 8 11.2 "Video" .............................................................................................................................38 9 11.3 "Speech" ...........................................................................................................................38 10

11.3.1 "Narrow Band Speech" 39 11 11.3.2 "Wide Band Speech" 39 12

11.4 "Audio".............................................................................................................................39 13 11.5 "Text in SMIL" .................................................................................................................39 14 11.6 "Timed Text" ....................................................................................................................40 15 11.7 Other media ......................................................................................................................40 16

12 Rate Adaptation of Streaming Media..............................................................................................41 17 12.1 Introduction ......................................................................................................................41 18 12.2 Rate Adaptation ................................................................................................................41 19

12.2.1 Link Characteristics 41 20 12.2.2 Adaptation of Transmission Rate 42 21 12.2.3 Receiver Buffer Level Feedback 42 22

Annex A Call Flow Example (Informative).....................................................................................44 23

Annex B Sample Scenario of a Session (Informative).....................................................................46 24

Annex C Buffering of Video (Normative).......................................................................................49 25 C.1 Introduction ......................................................................................................................49 26 C.2 MSS client buffering requirements...................................................................................52 27

Annex D Pseudo Streaming Session Representation Example (Informative)..................................53 28 D.1 XHTML Presentation Description Format .......................................................................53 29 D.2 <object> Element..............................................................................................................54 30

Annex E Pseudo Streaming Example (Informative) ........................................................................57 31 E.1 Live encoding ...................................................................................................................57 32 E.2 Random positioning..........................................................................................................58 33 E.3 Choosing bitrate................................................................................................................58 34

35

36

C.S0046-0 v1.0


2 List of Figures 1

Figure 7-1 Multimedia Streaming Service ....................................................................................................15 2 Figure 7-2 Multimedia Streaming Services Terminal Function ....................................................................16 3 Figure 8-1 Data Channel Set-up (SO 33/66, 60 and 61) ...............................................................................28 4 Figure 9-1 Protocol Stack for Multimedia Streaming Service ......................................................................29 5 Figure 9-2: Generic Format of an RTCP APP packet. ..................................................................................30 6 Figure 9-3: Data format block for NADU reporting .....................................................................................31 7 Figure 10-1 Basic Sequence of Pseudo-streaming ........................................................................................34 8 Figure E-1 Block diagram for live pseudo-streaming ...................................................................................57 9 Figure E-2 moof -> moov conversion in the server ......................................................................................57 10 Figure E-3 HTTP request for the random positioning ..................................................................................58 11 Figure E-4 Movie file reconstruction for random positioning service ..........................................................58 12 Figure E-5 Protocol enhancement for choosing bitrate.................................................................................59 13 Figure E-6 Generation of movie file for pseudo-streaming from multirate movie file .................................59 14 15

16

C.S0046-0 v1.0


3 List of Tables 1

Table 8-1 Summary of non-UAProf defined Attributes for MSS CE ...........................................................25 2 Table 8-2 Summary of UAProf (HardwarePlatform) defined Attributes for MSS CE .................................25 3 Table 8-3 Summary of UAProf (SoftwarePlatform) defined Attributes for MSS CE ..................................26 4 Table 9-1 CMF parameters for HTTP GET ..................................................................................................33 5 Table 10-1 Pseudo-streaming HTTP GET request parameters .....................................................................35 6 Table 10-2 Pseudo-streaming HTTP response options .................................................................................36 7 Table 10-3 Example of pseudo-streaming message header range parameters ..............................................36 8

9

C.P0046-0 v1.0


4 Scope 1

The objective is to define and standardize the functionality of Multimedia Streaming 2 Services (MSS) that can be incorporated into the operations of wireless 3 telecommunications networks. Audio-only streaming and video-only streaming are 4 special cases of MSS. This document defines the functional characteristics and 5 requirements of the MSS. Features and system requirements are defined in order for 6 MSS to be provided in wireless telecommunications networks. This document addresses 7 unicast services. 8

9

C.P0046-0 v1.0


5 References 1

2

5.1 Normative References 3

This section provides references to other specifications and standards that are 4 necessary to implement this document. 5

1. 3GPP2 S.R0021: "Multimedia Streaming Services – Stage 1". 6

2. 3GPP2 C.S0017-12: "Data Service Options for Spread Spectrum Systems: 7 cdma2000 High Speed Packet Data Service Option 33/66". 8

3. 3GPP2 C.S0017-10: "Data Service Options for Spread Spectrum Systems: Radio 9 Link Protocol Type 3". 10

4. 3GPP2 C.S0047: "Link-Layer Assisted Service Options for Voice-over-IP: Header 11 Removal (SO60) and Robust Header Compression (SO61)". 12

5. 3GPP2 C.S0014: "Enhanced Variable Rate Codec, Speech Service Option 3 for 13 Wideband Spread Spectrum Digital Systems". 14

6. 3GPP2 C.S0020: "High Rate Speech Service Option for Wide Band Spread 15 Spectrum Communication Systems". 16

7. 3GPP2 C.S0050: "File Format(s) for Multimedia Services". 17

8. 3GPP2 C.S0052: "Source-Controlled Variable-Rate Multimode Wideband Speech 18 Codec (VMR-WB) Service Option 62 for Spread Spectrum Systems". 19

9. ITU-T Recommendation H.263: "Video Coding for Low Bitrate Communication". 20

10. ISO/IEC 14496-2:2004: "Information Technology — Generic Coding of Audio-21 Visual Object — Part 2: Visual". 22

11. IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications". 23

12. IETF RFC 768: ""User Datagram Protocol" 24

13. IETF RFC 791: "Internet Protocol DARPA Internet Program Protocol 25 Specification." 26

14. IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal 27 Control". 28

15. IETF RFC 3016: "RTP Payload Format for MPEG-4 Audio/Visual Streams". 29

16. IETF RFC 2429: "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 30 (H.263+)". 31

17. IETF RFC 2658: "RTP Payload Format for PureVoice(tm) Audio". 32

C.P0046-0 v1.0


18. IETF RFC 3558: "RTP Payload and Format for Enhanced Variable Rate Codecs 1 (EVRC) and Selectable Multimode Vocoders (SMV)". 2

19. IETF RFC 3984: "RTP Payload Format for H.264 Video". 3

20. IETF RFC 4348: "RTP Payload formats for Variable-Rate Multimode Wideband 4 (VMR-WB) Audio codec". 5

21. IETF RFC 2326: "Real-Time Streaming Protocol". 6

22. IETF RFC 2327: "Session Description Protocol". 7

23. IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 8

24. IETF STD 0007: "Transmission Control Protocol". 9

25. CompuServe Incorporated: "GIF Graphics Interchange Format: A Standard 10 defining a mechanism for the storage and transmission of raster-based graphics 11 information", Columbus, OH, USA, 1987. 12

26. CompuServe Incorporated: "Graphics Interchange Format: Version 89a", 13 Columbus, OH, USA, 1990. 14

27. ITU-T Recommendation T.81 (1991) | ISO/IEC 10918-1 (1992): "Information 15 technology - Digital compression and coding of continuous-tone still images - 16 Requirements and guidelines. 17

28. W3C Recommendation: "Synchronised Multimedia Integration Language 18 (SMIL 2.0) Specification", http://www.w3.org/TR/2005/REC-SMIL2-20050107/ 19

29. ISO/IEC 10646-1 (2000): "Information technology - Universal Multiple-Octet 20 Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane". 21

30. IETF RFC 2083: "PNG (Portable Networks Graphics) Specification version 1.0 ". 22

31. The Unicode Consortium: "The Unicode Standard", Version 3.0 Reading, MA, 23 Addison-Wesley Developers Press, 2000, ISBN 0-201-61633-5. 24

32. ANSI X3.4, 1986: "Information Systems; Coded Character Set 7 Bit; American 25 National Standard Code for Information Interchange". 26

33. ISO/IEC 8859-1:1998: "Information technology; 8-bit single-byte coded graphic 27 character sets; Part 1: Latin alphabet No. 1". 28

34. IETF; RFC 2279: "UTF-8, A Transformation format of ISO 10646", URL. 29

35. 3GPP TS 23.038: "Alphabets and language-specific information". 30

36. W3C Working Draft Recommendation: "Scalable Vector Graphics (SVG) 1.1 31 Specification", http://www.w3.org/TR/SVG11, February 2002. 32

37. W3C Recommendation: "Mobile SVG Profiles: SVG Tiny and SVG Basic", 33 http://www.w3.org/TR/SVGMobile/. 34

http://www.w3.org/TR/2005/REC-SMIL2-20050107/

http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=28245&ICS1=35&ICS2=40&ICS3=

http://www.w3.org/TR/SVG11

http://www.w3.org/TR/SVGMobile/

C.P0046-0 v1.0


38. 3GPP TS 26.234: "Transparent End-to-End Packet Switched Streaming Service 1 (PSS) Protocols and Codecs". 2

39. Polyphony MIDI Specification Version 1.0, RP-34, MIDI Manufacturers 3 Association, Los Angeles, CA, February 2002. 4

40. Scalable Polyphony MIDI Device 5-to-24 Note Profile for 3GPP Version 1.0, RP-5 35, MIDI Manufacturers Association, Los Angeles, CA, February 2002. 6

41. "Standard MIDI Files 1.0", RP-001, in "The Complete MIDI 1.0 Detailed 7 Specification, Document Version 96.1" The MIDI Manufacturers Association, Los 8 Angeles, CA, USA, February 1996. 9

42. 3GPP2 C.S0045: "Multimedia Messaging Service (MMS): Codecs and File 10 Formats". 11

43. W3C Recommendation: "CC/PP structure and vocabularies", 12 http://www.w3.org/TR/CCPP-struct-vocab/. 13

44. W3C Recommendation: "Resource Description Framework (RDF) Vocabulary 14 Description Language 1.0: RDF Schema", http://www.w3.org/TR/rdf-schema. 15

45. ITU-T Recommendation H.264 (2003): "Advanced video coding for generic 16 audiovisual services" | ISO/IEC 14496-10:2003: "Information technology – 17 Coding of audio-visual objects – Part 10: Advanced Video Coding". 18

46. ITU-T Recommendation, J.127: "Recommendation: Transmission protocol for 19 multimedia Webcasting over TCP/IP networks" 20

47. ISO/IEC 14496-3:2001, Information technology - Coding of audio-visual objects 21 - Part 3: Audio. 22

48. ISO/IEC 14496-3:2001/Amd.1:2003, Bandwidth Extension. 23

49. ISO/IEC 14496-3:2001/Amd.1:2003/COR1:2004. 24

50. 3GPP2 C.S0047: "Link Layer Assisted Service Option for VoIP: Header removal 25 (SO 60) and Robust Header Compression (SO 61). 26

51. 3GPP2 C.S0024: "cdma2000 High Rate Packet Data Specification". 27

52. 3GPP TS 26.245 "3GPP Timed Text". 28

53. IETF RFC 2234: "Augmented BNF for Syntax Specifications: ABNF". 29

54. IETF RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax". 30

55. IETF RFC 2732: "Format for Literal IPv6 Addresses in URL's". 31

56. 3GPP2 C.R1001: "Administration of Parameter Value Assignments for cdma2000 32 Spread Spectrum Standards". 33

57. IETF RFC 3625: "The QCP File Format and Media type for speech data". 34

58. IETF RFC 3555: "MIME Type Registration of RTP Payload Formats". 35

59. W3C Recommendation: "XHTML 1.0: The extensible HyperText Markup 36 Language (Second Edition)", http://www.w3.org/TR/xhtml1.37

http://www.w3.org/TR/CCPP-struct-vocab/

http://www.w3.org/TR/rdf-schema

http://www.w3.org/TR/xhtml1

C.P0046-0 v1.0


1

5.2 Informative References 2

This section provides references to other documents that may be useful for the reader 3 of this document. The following exemplifies two ways to reference TIA [1], 3GPP2 [OSA 4 API] or any other SDO’s documents. Please be consistent in referencing the documents 5 by either using acronyms or numbers. 6

7

C.P0046-0 v1.0


6 Definitions and Abbreviations 1

2

6.1 Definitions 3

For the purposes of the present document, the following terms and definitions apply. 4

codec: a system component that encodes and decodes data (usually audio, video, 5 etc.) from one representation to another, often with the goal of saving memory space 6 or transmission bandwidth (compression). 7

continuous media: media with an inherent notion of time. In the present document 8 speech, audio, synthetic audio, and video are examples of continuous media. 9

dynamic media: same as continuous media 10

discrete media: media that itself does not contain an element of time. In the 11 present document text and still image are examples of discrete media. Note that 12 timed text and bit map graphics can be continuous media also, depending on the 13 presentation aspects. 14

file format: an unambiguous method for storing data on a memory device (usually 15 non-volatile). 16

live content: content that is encoded in real-time and formatted for immediate 17 distribution. 18

media synchronization and media presentation: description of the spatial layout 19 and temporal behavior of a presentation; it can also contain hyperlinks. 20

multimedia: a combination of multiple media elements used in a service to enrich 21 the user experience. 22

natural media: media that occur naturally. In the present document, speech, 23 audio, video and still image are examples of natural media. 24

pre-encoded content: content that is encoded and then stored in a static file. 25

pseudo streaming: a stream of content distributed by progressive download via a 26 reliable delivery protocol (e.g. http) meant for real-time consumption. 27

synthetic media: media that are synthesized from algorithms and/or semantic 28 descriptions. In the present document, bit map graphics, vector graphics and 29 synthetic audio are examples of synthetic media. 30

Real-time streaming: a stream of content meant for real-time consumption. 31

user agent: the module on the terminal that performs MMS specific operations on a 32 user’s behalf. 33

34

C.P0046-0 v1.0


6.2 Abbreviations 1

For the purpose of this document, the following abbreviations apply: 2

3G Third Generation system

3G2 3GPP2 File Format for Multimedia Services

3GPP2 Third Generation Partnership Project 2

3GPP Third Generation Partnership Project

AAC Advanced Audio Coding

ABNF Augmented Backus-Naur Form

AMR Adaptive Multi-Rate

AMR-WB Adaptive Multi-Rate – Wideband

AVC Advanced Video Coding

CC/PP Composite Capabilities/Preferences Profile

CE Capability Exchange

CGI Common Gateway Interface

CMF Compact Multimedia Format

DO Data Only

DV Data and Voice

EVRC Enhanced Variable Rate Codec

FFMS File Formats for Multimedia Services

GIF Graphics Interchange Format

HE AAC High Efficiency Advanced Audio Coding

HRPD High Rate Packet Data

HTTP Hyper Text Transport Protocol

IEC International Electrotechnical Commission

IETF Internet Engineering Task Force

IP Internet Protocol

ISO International Standards Organization

ITU-T International Telecommunication Union - Telecommunication Sector

LLAROHC Link Layer Assisted Robust Header Compression

JPEG Joint Photographic Expert Group

MIDI Musical Instrument Digital Interface

MIME Multipurpose Internet Mail Extensions

MMS Multimedia Messaging Service

C.P0046-0 v1.0


MPEG Motion Picture Expert Group

MS Mobile Station (same as MSS terminal, MSS client)

MSS Multimedia Streaming Service

NADU Next Application Data Unit

PSS Packet Switched Streaming

QoS Quality of Service

RDF Resource Description Framework

RFC Request for Comments

RLP Radio Link Protocol

ROHC Robust Header Compression

RTCP Real-time Transport Control Protocol

RTP Real-time Transport Protocol

RTSP Real-Time Streaming Protocol

SBR Spectral Bandwidth Replication

SDP Session Description Protocol

SMIL Synchronized Media Integration Language

SP-MIDI Scalable Polyphonic MIDI

SO Service Option

SVG Scalable Vector Graphics

TCP Transport Control Protocol

TIA Telecommunications Industry Association

UDP User Datagram Protocol

URI Uniform Resource Identifier

URL Uniform Resource Calculator

VOD Video On Demand

VMR-WB Variable Rate Multimode Wide Band

XML Extensible Markup Language

XHTML Extensible Hypertext Markup Language

1

2

C.P0046-0 v1.0


7 Multimedia Streaming Services Structure 1

This service is defined as a point-to-point service. The streaming service is asymmetric 2 between the sender and the receiver, since the multimedia stream only goes in one 3 direction from a server (MSS server) to a client (MSS client, MS, MSS terminal). On the 4 sender side, the MSS includes content creation, storage, packetization, and 5 transmission. The streaming service supports both retrieval of pre-encoded content and 6 real-time encoded content. The service supports both real-time streaming (yellow) and 7 pseudo-streaming (blue). The requirements are different for real-time streaming and 8 pseudo-streaming. 9

10

Figure 7-1 Multimedia Streaming Service 11

For real-time streaming the encoded information is sent through the packetizer at the 12 MSS server. The receiving MSS terminal Figure 7-2 de-packetizes the data and then 13 decodes it with the corresponding multimedia decoders. The output is then sent to local 14 multimedia devices to be played back. The MSS terminal may also receive a 15 presentation component, which allows additional spatial and temporal attributes to be 16 assigned to the received multimedia components beyond those implicit in the transport 17 and device defaults. 18

The MSS also includes system control protocols for setting up connections between the 19 client(s) and server; negotiating various options, capabilities, and configurations; and 20 communicating with and controlling the various source codecs that the MSS uses. It 21 also includes advanced procedures for monitoring and maintaining QoS under dynamic 22 conditions. The MSS service is intended to be interoperable (to the greatest extent 23 possible) with the 3GPP PSS service defined in [38]. 24

MSS Terminal Air Interface Streaming Server

Control and FeedbackMedia File Control

Media (Video,Speech,Audio,Other)

Full Streaming

Pseudo StreamingRender

Transport

Media File

C.P0046-0 v1.0


1

Figure 7-2 Multimedia Streaming Services Terminal Function 2

3

MSS ControlUser InterfaceMSS Control

User Interface

Visual OutputVisual Output

Audio OutputAudio Output

Video DecoderVideo Decoder

Speech DecoderSpeech Decoder

De-

pack

etiz

eran

d Tr

ansp

ort

Sync

hron

izat

ion

De-

pack

etiz

eran

d Tr

ansp

ort

Sync

hron

izat

ion

Wire

less

Com

mun

icat

ion

Net

wor

k

MSS ControlInterface

Multimedia Streaming Service Terminal Functions

Audio DecoderAudio Decoder

Image DecoderImage Decoder

Text DecoderText Decoder

Vector GraphicsDecoder

Vector GraphicsDecoder

Pres

enta

tion

Layo

utPr

esen

tatio

n La

yout

Pres

enta

tion

Sync

hron

izat

ion

Pres

enta

tion

Sync

hron

izat

ion

PresentationDescriptionPresentationDescription

C.P0046-0 v1.0


8 Call procedures for Multimedia Streaming 1

Streaming of continuous media using RTP/UDP/IP (see 9.1) requires a session control 2 protocol to set-up and control the individual media streams. For the transport of 3 discrete media (images and text), vector graphics, and synthetic audio this specification 4 adopts the use of HTTP/TCP/IP (see 9.2). In this case there is no need for a separate 5 session set-up and control protocol since this is built into HTTP. This section describes 6 session set-up and control of continuous media. 7

8.1 Control Protocol (RTSP) 8

The MSS terminal shall use the Real-Time Streaming Protocol [21] to set-up and control 9 an MSS session. Additionally, MSS clients and servers: 10

• Shall follow the rules for minimal on-demand playback RTSP implementations in 11 appendix D of [21]; 12

• Shall implement the DESCRIBE method (see clause 10.2 in [21]; 13

• Shall implement the Range header field (see clause 12.29 in [21); 14

• Shall include the Range header field in all PLAY responses. 15

TCP should be used to transport RTSP messages reliably. 16

Additional requirements for RTSP usage during Capability Exchange (CE) are described 17 in section 8.2. 18

8.1.1 Mobile Link-Char Header 19

To enable MSS clients to report the link characteristics of the radio interface to the MSS 20 server, the "Mobile-Link-Char" RTSP header is defined. The header takes one or more 21 arguments. The reported information should be taken from a QoS profile as defined in 22 [2]. Note that this information is only valid for the wireless link and does not apply end-23 to-end. However, the parameters do provide constraints that can be used. 24

Three parameters are defined that can be included in the header (future extensions are 25 possible). Any unknown parameter shall be ignored. The three parameters are: 26

- "MNT": the mobile network type. 27

- "GBW": the forward link user data rate in kilobits per second as defined by [2]. 28

- "MTD": the forward link maximum delay, as defined by [2] in milliseconds. 29

The "Mobile-Link-Char" header syntax is defined below using ABNF [53]: 30

mobilelinkheader = "Mobile-Link-Char" ":" link-char-spec *("," 0*1SP link-char-spec) 31 CRLF 32

link-char-spec = char-link-url *(";" 0*1SP link-parameters) 33

char-link-url = "url" "=" <">url<"> 34

link-parameters = Mobile-Type / Guaranteed-BW / Max-Transfer-delay / 35 extension-type 36

C.P0046-0 v1.0


Mobile-Type = "MNT" "=" 1*CHAR 1

Guaranteed-BW = "GBW" "=" 1*DIGIT ; kbps 2

Max-Transfer-delay = "MTD" "=" 1*DIGIT ; ms 3

extension-type = token "=" (token / quoted-string) 4

DIGIT = as defined in [21] 5

CHAR = as defined in [21] 6

token = as defined in [21] 7

quoted-string = as defined in [21] 8

url = as defined in [21] 9

The "Mobile-Link-Char" header can be included in a request using any of the following 10 RTSP methods: SETUP, PLAY, OPTIONS, and SET_PARAMETER. The header shall not 11 be included in any response. The header can contain one or more characteristic 12 specifications. Each specification contains a URI that can either be absolute or relative. 13 Any relative URI uses the RTSP request URI as a base. The URI points to the media 14 component that the given parameters apply to. This can either be an individual media 15 stream or a session aggregate. 16

The "Mobile-Link-Char" header should be included in a SETUP or PLAY request by the 17 client to give the initial values for the link characteristics. A SET_PARAMETER or 18 OPTIONS request can be used to update the Mobile-Link-Char values in a session 19 currently playing. It is strongly recommended that SET_PARAMETER be used as this 20 has the correct semantics for the operation. Additionally, it requires less overhead both 21 in bandwidth and server processing. If the client has initially reported these parameters 22 and they are changed during the session, the client shall update these parameters by 23 including the "Mobile-Link-Char" header in a SET_PARAMETER or OPTIONS request. 24 When performing updates of the parameters, all of the previous signaled values are 25 undefined and only the given ones in the update are defined. This means that even if a 26 parameter has not changed it must be included in the update. 27

The entries of the "MNT" field has the following syntax: 28

3GPP2-<Network Type ID>-<Release information> 29

Network Type ID: 30

1. SSS – Spread Spectrum Systems 31

2. HRPD – High Rate Packet Data 32

Example 1: 33

Mobile-Link-Char: url=" rtsp://server.foo.com/presentation.3g2"; MNT=3GPP2-SSS-34 REL-C; GBW=32; MTD=2000 35

In the above example the header tells the server that its mobile network is cdma2000® 36 Spread Spectrum Systems Release C (1xEV-DV) on an Assured Mode with a bit-rate of 37 32 kbps and a maximum transfer delay of 2.0 seconds. If only mobile network type 38 "MNT" parameter is presented, the server shall assume Non-Assured Mode. 39

cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.

C.P0046-0 v1.0


Example 2: 1

Mobile-Link-Char: url=" rtsp://server.foo.com/presentation.3g2"; MNT=3GPP2-HRPD-2 REL-0; 3

In this example the client tells the server that it is operating on a Non-Assured 1xEV-4 DO Release 0 mobile network. 5

8.1.2 The 3GPP-Adaptation Header 6

To enable MSS clients to request a desired buffer size, a new RTSP request and 7 response header is defined. The header can be used in the methods SETUP, PLAY, 8 OPTIONS, and SET_PARAMETER. The header defined in ABNF [53] has the following 9 syntax: 10

3GPP-adaptation-def = "3GPP-Adaptation" ":" request-spec 0*("," request-spec) 11

request-spec = url-def *buffer-params 12

buffer-params = ";" buffer-size-def 13

/ ";" target-time-def 14

url-def = "url" "=" <"> url <"> 15

buffer-size-def = "size" "=" 1*9DIGIT ; bytes 16

target-time-def = "target-time" "=" 1*9DIGIT; ms 17

url = ( absoluteURI / relativeURI ) 18

absoluteURI and relativeURI are defined in [54] and updated in [55]. The base URI for 19 any relative URI is the RTSP request URI. 20

The "3GPP-Adaptation" header shall be sent in responses to requests containing this 21 header. The MSS server shall not change the values in the response header. The 22 presence of the header in the response indicates to the client that the server 23 acknowledges the request. 24

The buffer size signaled in the "3GPP-Adaptation" header shall correspond to a 25 reception and de-jittering buffer that has this given amount of space for complete RTP 26 packets (including the RTP header). The specified buffer size shall also include any 27 Annex C. pre-decoder buffer space used for this media, as the two buffers cannot be 28 separated. 29

The target time signaled in the value of the "target-time" parameter is the targeted 30 minimum buffer level or, in other words, the client desired amount of playback time in 31 milliseconds to guarantee interrupt-free playback and allow the server to adjust the 32 transmission rate, if needed. 33

Example: 34

3GPP-Adaptation: url="rtsp://server.foo.com/presentation.3g2/streamID=1"; 35 size=35000;target-time=5000 36

8.1.3 The "Avc-rtpinterleaving" Header 37

The MSS client should implement the RTSP "avc-rtpinterleaving" header when 38 H.264/AVC RTP interleaved packetization mode is supported. The header can be used 39

C.P0046-0 v1.0


in the methods SETUP, PLAY, OPTIONS, and SET_PARAMETER. 1

The entry of the "avcrtpinterleaving" field defines how much memory out of the reported 2 client's jitter buffer space can be used for interleaved packets. The value of the 3 "avcrtpinterleaving" field is defined in bytes. If the value of the "avcrtpinterleaving" field 4 equals zero, the interleaved packetization mode is prohibited. This header also indicates 5 that all the AVC RTP packetization types are supported. 6

Example 1: 7

avc-rtpinterleaving: url=" rtsp://server.foo.com/presentation.3g2"; 8 avcrtpinterleaving=3200 9

8.2 Session Set-up (SDP) 10

SDP shall be used for MSS set-up. MSS servers shall provide and MSS clients shall 11 interpret the SDP syntax according to the SDP specification [22] and appendix C of [21]. 12 The SDP delivered to the MSS client shall declare the media types to be used in the 13 session using a codec specific MIME media type for media as described in section [11] 14 of this document. 15

The SDP [22] specification requires certain fields to always be included in an SDP file. 16 Apart from this an MSS server shall include the following fields in the SDP: 17

• "a=control:" according to clauses C.1.1, C.2 and C.3 in [21]; 18

• "a=range:" according to clause C.1.5 in [21]; 19

• "a=rtpmap:" according to clause 6 in [22]; 20

• "a=fmtp:" according to clause 6 in [22]. 21

The bandwidth field in SDP shall be used to indicate to the MSS terminal the amount of 22 bandwidth that is required for the session and the individual media in the presentation. 23 Therefore, an MSS server should include the "b=AS:" field in SDP (both at the session 24 and media level) and an MSS client shall be able to interpret this field. For RTP based 25 applications, AS gives the RTP "session bandwidth'' (including UDP/IP overhead) as 26 defined in section 6.2 of [11]. 27

NOTE: The SDP parsers and/or interpreters should be able to accept NULL values in 28 the 'c=' field (e.g. 0.0.0.0 in IPv4 case). This may happen when the media content does 29 not have a fixed destination address. For more details, see Section C.1.7 of [21] and 30 Section 6 of [22]. 31

8.2.1 Session Capability Exchange (SDP) 32

• An advanced method for Capability Exchange (CE) is defined in section 8.3 of this 33 document. When an MSS client or server supports capability exchange it shall 34 support the transport of profile information over both HTTP and RTSP as defined in 35 section 5.2.5, “Signalling of profile information between client and server,” of [38]. 36 [Note that the 3GPP acronym PSS is equivalent to the 3GPP2 acronym MSS]. 37

8.2.2 Session Video Buffering (SDP) 38

The following Buffering of Video (Normative) related media level SDP fields are defined 39

C.P0046-0 v1.0


for MSS: 1

• "a=X-predecbufsize:<size of the hypothetical pre-decoder buffer>" 2 This gives the suggested size of the Appendix C hypothetical pre-decoder buffer in 3 bytes. 4

• "a=X-initpredecbufperiod:<initial pre-decoder buffering period>" 5 This gives the required initial pre-decoder buffering period specified according to 6 Appendix C. Values are interpreted as clock ticks of a 90-kHz clock. That is, the 7 value is incremented by one for each 1/90 000 seconds. For example, value 180 8 000 corresponds to a two second initial pre-decoder buffering. 9

• "a=X-initpostdecbufperiod:<initial post-decoder buffering period>" 10 This gives the required initial post-decoder buffering period specified according to 11 Appendix C. Values are interpreted as clock ticks of a 90-kHz clock. 12

• "a=X-decbyterate:<peak decoding byte rate>" 13 This gives the peak decoding byte rate that was used to verify the compatibility of 14 the stream with Appendix C. Values are given in bytes per second. 15

If none of the attributes "a=X-predecbufsize:", "a=X-initpredecbufperiod:", "a=X-16 initpostdecbufperiod:", and "a=x-decbyterate:" are present, clients should not expect a 17 packet stream according to Appendix C. If at least one of the listed attributes is present, 18 the transmitted video packet stream shall conform to Appendix C. If at least one of the 19 listed attributes is present, but some of the listed attributes are missing in an SDP 20 description, clients should expect a default value for the missing attributes according to 21 Appendix C. 22

8.2.3 Additional Attributes (SDP) 23

The MSS client should be able to interpret the following attribute: 24

a=X-disallowrandomaccess 25

This indicates that random access is not allowed for this session. This may imply that 26 the stream is live and that any PLAY request will display the stream from its current 27 point. A PLAY request, if used for an on-demand session after the initial one, will be 28 treated by the server to have no Range header regardless of the actual presence of it. 29 That is, the PLAY request indicates a restart from the beginning or resuming from the 30 pause point at the server's discretion (for details, refer to Section 10.5 of [21]). To avoid 31 an unnecessary delay that can be caused in this process, the MSS client should 32 deactivate the random access feature for such a session. E.g., deactivation of rewind 33 and fast forward buttons in the user interface. 34

35

For live sessions indicated by an open ended a=range attribute, a PAUSE will mean that 36 the MSS client does not receive the stream for the paused interval and the MSS client 37 shall issue a PLAY request to resume with Range header with the indicator, 'now', e.g., 38 "Range: npt=now-". 39

40

The MSS client and server should interpret the "alt", "alt-default-id", and "alt-group" 41

C.P0046-0 v1.0


attributes as described in [38]. The "alt" attribute is used to replace or add an SDP line 1 to the default configuration. The "alt-default-id" attribute is used to assign an 2 alternative identifier to the default alternative. The "alt-group" attribute is used to 3 define grouping alternatives from which the client can select the most appropriate. 4 These attributes are used together to create combinations consisting of, e.g., one audio 5 and one video alternative. It is the server’s responsibility to create meaningful grouping 6 alternatives. 7

8.2.4 Session 3GPP-Adaptation-Support (SDP) 8

The MSS server should implement a media level only SDP attribute when "Bit Rate 9 Adaptation" is supported. 10

"a=3GPP-Adaptation-Support:<report frequency>" 11

When a MSS client receives a SDP description where the SDP attribute "3GPP-12 Adaptation-Support" is presented shall then in its subsequent RTSP signaling use the 13 "3GPP-Adaptation" header as defined in section 8.1.2, as well as the RTCP NADU APP 14 packet defined in section 9.1.1. 15

The report frequency value defines the frequency of the buffer level feedback signaling. 16 For example, if the value is 2 then the client shall send the NADU APP packet every two 17 RTCP packets. 18

When the MSS client receives "3GPP-Adaptation-Support" signaling from the server, the 19 Annex C related RTSP signaling "x-predecbufsize" and "x-initpostdecbufperiod" can be 20 ignored. The RTSP "x-initpredecbufperiod" and SDP signaling defined in clause 8.2.2 21 will remain effective. 22

8.2.5 Session HE AAC Support (SDP) 23

The terminal shall support the signaling types "implicit" and "hierarchical explicit" 24 signaling (as defined in [47]). If implicit signaling is used, the AAC object type is 25 signaled to maintain backwards compatibility. If, in such a case, the sampling rate as 26 indicated by the AAC object type descriptor (in the SDP) is 24 kHz or below and "SBR-27 enabled" (see below) is not specified in the SDP, the output shall be configured to twice 28 the AAC sampling rate. In both types of signaling, the MIME type indicated to the 29 terminal for HE AAC shall be the same as for AAC LC. 30

Servers using implicit signaling shall include the "SBR-enabled" parameter in the SDP 31 "a=fmtp" line. "SBR-enabled" shall be set to "1" for streams containing SBR and shall be 32 set to "0" for streams not containing SBR. Terminals may rely on this parameter to set 33 the correct output sampling rate to either the indicated rate (where "SBR-enabled" is set 34 to "0") or twice the indicated rate (where "SBR-enabled" is set to "1"). 35

The above signaling support is not required if only AAC is supported. 36

8.3 Capability Exchange (CE) 37

38

8.3.1 Overview 39

Enhanced capability negotiation provides additional functionality for the MSS by 40

C.P0046-0 v1.0


enabling the MSS servers to provide tailored content suitable for a particular MSS 1 terminal. Another very important task is to provide a smooth transition between 2 different releases of MSS. A Capability Exchange (CE) mechanism for streaming is 3 defined in [38] and should be supported by MSS clients and servers with the additional 4 requirements as described in this document. 5

8.3.2 Description 6

When CE is supported the corresponding device capability profile shall be an RDF 7 document that follows the structure of the CC/PP framework and the CC/PP 8 application UAProf as described in clause 5.2.2 of [38]. 9

The CE vocabulary and its usage is also defined in [38] and summarized in Table 8-1, 10 Table 8-2, and Table 8-3. Some additional cdma2000 values are also defined. When CE 11 is supported, MSS CE vocabulary usage shall be as described in [38]. 12

When support for "media/types" in [38] conflicts with this specification, support as 13 described in this document shall take precedence. 14

The MSS base vocabulary contains one component called "Streaming". A vocabulary 15 extension to UAProf shall be defined as an RDF schema. This schema can be found in 16 Annex F or [38]. The schema together with the description of the attributes in this 17 section, defines the vocabulary. All MSS attributes shall be put in the "Streaming" 18 component. 19

MSS servers should understand the attributes of the "Streaming" component of the 20 MSS base vocabulary. 21

22

MSS Capability Exchange Vocabulary ( component = "Streaming" )

Name 3GPP2 values Applicable 3GPP Values

AdaptationSupport "Yes","No"

AvcRtpInterleaving Integer value greater than or equal to 0

(Bytes)

AudioChannel "Mono","Stereo"

Brands List of supported 3G2 profiles identified by

brand.

List of supported 3GP profiles identified by brand.

MaxPolyphony Integer value between 5 and 24

StreamingAccept List of content types (MIME types) the application

supports

StreamingAccept-Subset List of content types for which the PSS application supports

a subset

"JPEG-PSS","SVG-Tiny","SVG-Basic"

C.P0046-0 v1.0


PssVersion or

MssVersion

"3GPP2-MSS-0" "3GPP-R4","3GPP-R5","3GPP-R6"

RenderingScreenSize Two integer values equal or greater than zero. A value

equal "0x0"means that there exists no possibility to render

visual MSS presentations.

SmilBaseSet "SMIL-3GPP2-FFMS-0", "SMIL-3GPP2-FFMS-A"1

"SMIL-3GPP-R4","SMIL-3GPP-R5","SMIL-3GPP-R6"

SmilModules This attribute defines a list of SMIL 2.0 modules supported

by the client. If the SmilBaseSet is used those modules do not need to be

explicitly listed here. In that case only additional module support needs to be listed.

SmilAccept This attribute defines a list of content types (MIME types) that can be part of a SMIL

presentation.

SmilAccept-Subset This attribute defines a 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.

"JPEG-PSS", "SVG-Tiny", "SVG-Basic"

Three3GPP2LinkChar "Yes","No"

ThreeG2Accept

ThreeG2Accept-Subset

VideoDecodingByteRate Integer value greater than or equal to 8000 (Bytes per

second)

VideoInitialPostDecoderBufferingPeriod

Integer value equal to or greater than zero

1 Version 1.0 and A for 3GPP2 SMIL profiles are defined in [7].

C.P0046-0 v1.0


VideoPreDecoderBufferSize Integer value equal to or greater than zero. Values

greater than one but less than the default buffer size defined

in Annex C are not allowed

1

Table 8-1 Summary of non-UAProf defined Attributes for MSS CE 2

In the UAProf vocabulary [38] there are several attributes that are of interest for the 3 MSS. Table 8-2 and Table 8-3 summarize the UAProf attributes recommended for MSS 4 applications for "HardwarePlatform" and "SoftwarePlatform" respectively. 5

MSS servers should understand the recommended attributes from the UAProf 6 vocabulary [38]. An MSS server may additionally support other UAProf attributes. 7

8

UAProf Capability Exchange Vocabulary (component = "HardwarePlatform" )

Name 3GPP2 values Applicable UAProf Values

BitsPerPixel The number of bits of color or grayscale information per

pixel

ColorCapable Whether the device display supports color or not: "Yes" or

"No"

PixelAspectRatio Ratio of pixel width to pixel height: "1x2"

PointingResolution Type of resolution of the pointing accessory supported

by the device" "Pixel"

Model Model number assigned to the terminal device by the vendor

or manufacturer: "Viper"

Vendor Model number assigned to the terminal device by the vendor

or manufacturer: "Dodge"

9

Table 8-2 Summary of UAProf (HardwarePlatform) defined Attributes for MSS CE 10

11

UAProf Capability Exchange Vocabulary ( component = "SoftwarePlatform" )

Name 3GPP2 values Applicable UAProf Values

CcppAccept-Charset List of character sets the device supports

CcppAccept-Encoding List of transfer encodings the device supports

C.P0046-0 v1.0


CcppAccept-Language List of preferred document languages

1

Table 8-3 Summary of UAProf (SoftwarePlatform) defined Attributes for MSS CE 2

The use of RDF enables an extensibility mechanism for CC/PP-based schemas to 3 address the evolution of new devices and applications. The MSS profile schema 4 specification provides a base vocabulary, which may need to be updated to express new 5 attributes. If the base vocabulary is updated, a new unique namespace will be assigned 6 to the updated schema. The base vocabulary shall only be changed by the TSG 7 responsible for the present document. All extensions to the profile schema shall be 8 governed by the methods defined in section 5.2.4.1 “Vocabulary definitions” of [38] 9 clause 7.7 10

• When an MSS client or server supports CE, it shall support the profile information 11 transport over both HTTP and RTSP between client and server as defined in section 12 5.3.5 “Signalling of profile information between client and server” of [38]. [Note that 13 the 3GPP acronym PSS is equivalent to the 3GPP2 acronym MSS]. 14

When device CE profiles are merged, they shall be merged as described in the clause 15 titled "Merging device capability profiles" in [38]. 16

When device CE profiles are exchanged between a CE profile server and an MSS server, 17 they shall be exchanged as described in clause titled "Profile transfer between PSS 18 server and the device profile server" in [38]. 19

8.4 Presentation/Layout Description 20

The presentation/layout description describes the spatial and temporal relationship 21 between the components of the media stream. The spatial format describes the 22 rendering of the visual media components on the MSS terminal display. The temporal 23 format describes when and how long visual media should be displayed or audio media 24 played. 25

The MSS terminal should support "presentation/layout description". If the MSS 26 terminal supports "presentation/layout description" it 27

• Shall support 3GPP2 SMIL language profile as described in [7]. 28

8.4.1 SMIL Usage in MSS 29

If the terminal has some prior knowledge about the file type it is about to retrieve, e.g. 30 file extensions, then: 31

When retrieving a SMIL file with HTTP the client should include profile information in 32 the GET request. This way the HTTP server can deliver an optimized SMIL presentation 33 to the client. A SMIL presentation can include links to static media. The server should 34 optimize the SMIL file so that links to the referenced static media are adapted to the 35 requesting client. When the "x-wap-profile-warning" indicates that content selection has 36 been applied (201-203) the MSS client should assume that no more capability exchange 37 has to be performed for the static media components. In this case it should not send 38 any profile information when retrieving static media to be included in the SMIL 39 presentation. This will minimize the HTTP header overhead. 40

C.P0046-0 v1.0


8.5 Data Channel Setup 1

The IP bearer for carrying the multimedia streaming traffic shall be set-up according to 2 the procedures described in: 3

• Service option 33 or 66 [2] for cdma2000 1x and cdma2000 1xEV-DV and 4

• Service Option 591 [56] for High Rate Packet Data [51]. 5

Service Option 33/66 uses the Radio Link Protocol Type 3 [3]. The RLP retransmission 6 scheme is negotiated between the MS and base station using the RLP_BLOB procedures 7 [3]. 8

As a general rule RLP allows the bearer to trade bandwidth and delay for reliability. As 9 a rule of thumb the bandwidth will be reduced by a factor of: 10

Effective Bandwidth = 1/(1+SUM(FERn)) n = 1…Num RLP Retransmissions, 11

and delay increased by a factor of n*RLP_RoundTripTime. Typically RLPRoundTripTime 12 is 100 to 200 ms. 13

8.5.1 Header Compression 14

Header compression is a method for greatly compressing redundant information in IP, 15 UDP, and RTP headers. Depending on the media type and the number of media frames 16 in a packet this header information can actually consume more bandwidth than the 17 raw media data. 18

There are several general-purpose and media specific header compression methods 19 which can be used with MSS, namely Robust Header Compression (ROHC) and the 20 cdma2000 specific header reduction methods [50] service option 60 (Header removal) 21 and service option 61 (LLAROHC). Service option 60 and 61 are only applicable to 22 cdma2000 vocoders (EVRC, 13K and VMR-WB), which conform to the RS1 (9.6kbps) or 23 RS2 (14.4kbps) channels. When service option 60 is in use the IP session for service 24 option 60 terminates at the PDSN and not at the MSS client. 25

26

1 This service option assignment made for identification defined in the Radio Access Network is not carried over the air interface.

LLAROHC

IP

MSS Terminal PDSN

IP

MSS Client

Air Interface

SO33

SO61

SO60

ROHC

LLAROHC

ROHC

Speech codec From MSS

Server

LLAROHC

IP

MSS Terminal PDSN

IP

MSS Client

Air Interface

SO33

SO61

SO60

Air Interface

SO33

SO61

SO60

ROHC

LLAROHC

ROHC

Speech codec From MSS

Server

IP traffic (uncompressed, compressed) - Control, Video, etc…

Voice traffic (uncompressed, compressed) IP traffic (uncompressed, compressed) - Control, Video, etc…

Voice traffic (uncompressed, compressed)

C.P0046-0 v1.0


Figure 8-1 Data Channel Set-up (SO 33/66, 60 and 61) 1

8.6 Session Termination 2

RTSP shall be used to terminate the session when the session is completed. The packet 3 data service call is terminated using the procedures defined in Service Option 33/66 4 [2]. If service option 60 or 61 are in use they should be torn down before the service 5 option 33/66 teardown. 6

7

C.P0046-0 v1.0


9 Transport Protocol 1

The MSS client shall support packetization and transport via both RTP [11] /UDP [12] 2 /IP [13] and HTTP [23]/TCP [24] /IP to receive components of the MSS. 3

Support for specific media types are described in the remainder of this section. 4

9.1 RTP/UDP 5

The MSS client shall support transport of continuous media (video, speech, audio and 6 timed text) via RTP/UDP/IP. (Figure 9-1). 7

The MSS client shall provide an IP bearer as described in section 8.5. 8

9

10

Figure 9-1 Protocol Stack for Multimedia Streaming Service 11

The MSS terminal shall support RTP packetization and RTCP feedback as defined in 12 "RTP: A Transport Protocol for Real-Time Applications" [11] and in "RTP Profile for Audio 13 and Video Conferences with Minimal Control" [14] for the following media types when 14 supported: 15

For the MPEG-4 video coder, the payload format shall be as defined in "RTP Payload 16 Format for MPEG-4 Audio/Visual Streams" [15]. 17

For the H.263 video coder, the payload format shall be as defined in "RTP Payload 18 Format for the 1998 Version of ITU-T Rec. H.263 (H.263+)" [16]. 19

For the H.264 video coder, the payload format shall be as defined in "RTP Payload 20 Format for H.264 Video", [19]. 21

For the 13K speech coder, the payload format shall be as defined in "RTP Payload 22 Format for PureVoice(tm) Audio" [17]. 23

Air Link

RLP

PPP

IP

TCP UDP

HTTPRTP/RTCPPAYLOAD

RTSP

Session SetupSession Control

Presentation DescriptionCapability Exchange

OtherMedia

SpeechVideoAudio

Air Link

RLP R-P

Physical

R-P

PPP

IP

Transport

OtherTransport

Application

Physical

MSS Terminal BTS/BSC/PCF PDSN/Server

IP

Physical

Other

C.P0046-0 v1.0


For the EVRC speech coder, the payload format shall be as defined in "RTP Payload and 1 Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Multimode Vocoders 2 (SMV)" [18]. 3

For the VMR-WB speech coder, the payload format shall be as defined in "RTP Payload 4 formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio codec" [20]. 5

For the MPEG4 AAC Audio Coder, the payload format shall be as defined in "RTP 6 Payload Format for MPEG-4 Audio Visual Streams" [15]. 7

For the MPEG-4 HE AAC Audio Coder, the payload format shall be as defined in "RTP 8 Payload Format for MPEG-4 Audio Visual Streams" [15]. 9

NOTE: The number of octets received by an MSS terminal can be closely calculated by 10 multiplying the "sender's octet count" field of the RTCP Sender report by the "fraction 11 lost" field of the corresponding report block in the RTCP Receiver report. 12

9.1.1 RTCP extension (NADU APP packet) 13

A MSS client should implement the RTCP APP packet (Application-Defined RTCP 14 Packet) as defined in section 6.7 of [11] to support the client buffer level feedback 15 function for reporting the Next Application Data Unit (NADU). 16

17 0 1 2 3 18

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 19

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20

|V=2|P| subtype | PT=APP=204 | length | 21

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 22

| SSRC/CSRC | 23

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 24

| name (ASCII) | 25

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 26

| application-dependent data ... 27

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28

Figure 9-2: Generic Format of an RTCP APP packet. 29

30

· name: The NADU APP data format is detected from the name "PSS0". (value: 31 0x50535330) 32

· subtype: This field shall be set to 0 for NADU format. 33

· Length: The number of 32 bit words -1, as defined in RFC 3550 [11]. This means 34 that the field will be 2+3*N, where N is the number of sources reported on. The 35 length field will typically be 5, i.e. 24 bytes packets.· Application-dependent data: 36 One or more of the following data format blocks (as described in Figure 9-3) can be 37 included in the application-dependent data location of the APP packet. The APP 38 packets length field is used to detect how many blocks of data are present. The 39 block shall be sent for the SSRCs for which there are a report block, part of either a 40 Receiver Report or a Sender Report, included in the RTCP compound packet. An 41

C.P0046-0 v1.0


NADU APP packet shall not contain any other data format than the one described in 1 Figure 9-3 below. 2

3 0 1 2 3 4

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 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6

| SSRC | 7

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8

| Playout Delay | NSN | 9

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10

| Reserved | NUN | Free Buffer Space (FBS) | 11

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12

Figure 9-3: Data format block for NADU reporting 13

SSRC: The SSRC of the media stream the buffered packets belong to. 14

Playout delay (16 bits): The difference between the scheduled playout time of the 15 next ADU to be decoded and the time of sending the NADU APP packet, as 16 measured by the media playout clock, expressed in milliseconds. The client may 17 choose not to indicate this value by using the reserved value (Ox FFFF). In case of 18 an empty buffer, the playout delay is not defined and the client should also use the 19 reserved value 0xFFFF for this field. 20

The playout delay allows the server to have a more precise value of the amount of 21 time before the client will underflow. The playout delay shall be computed until the 22 actual media playout (i.e., audio playback or video display). 23

24

NSN (16 bits): The RTP sequence number of the next ADU to be decoded for the 25 SSRC reported on. In the case where the buffer does not contain any packets for 26 this SSRC, the next not yet received sequence number shall be reported, i.e. an 27 NSN value that is one larger than the least significant 16 bits of the RTCP SR or RR 28 report block's "extended highest sequence number received". 29

NUN (5 bits): The unit number (within the RTP packet) of the next ADU to be 30 decoded. The first unit in a packet has a unit number equal to zero. The unit 31 number is incremented by one for each ADU in an RTP packet. In the case of an 32 audio codec, an ADU is defined as an audio frame. In the case of H.264 (AVC), an 33 ADU is defined as a NAL unit. In the case of H.263 and MPEG4 Visual Simple 34 Profile, an ADU is defined as a whole or a part of an H.263 video picture or MPEG4 35 VOP that is included in a RTP packet. In the specific case of H.263, each packet 36 carries a single ADU and the NUN field shall be thus set to zero. Future additions 37 of media encoding or transports capable of having more than one ADU in each RTP 38 payload shall define what shall be counted as an ADU for this format. 39

FBS (16 bit): The amount of free buffer space available in the client at the time of 40 reporting. The reported free buffer space shall all be part of the buffer space that 41 has been reported as available for adaptation by the 3GPP-Adaptation RTSP 42 header, see section 8.1.2. The amount of free buffer space are reported in number 43 of complete 64 byte blocks, thus allowing for up to 4194304 bytes to be reported as 44 free. If more is available, it shall be reported as the maximal amount available, i.e. 45

C.P0046-0 v1.0


4194304 with a field value 0xffff. 1

• Reserved (11 bits): These bits are not used and shall be set to 0 and shall be 2 ignored by the receiver. 3

9.2 HTTP/TCP and Container Formats 4

Some media types, which may be used in an MSS presentation do not currently have a 5 corresponding RTP definition. Therefore, it may be necessary to receive these media 6 types using HTTP/TCP/IP transport (Figure 9-1). Among these media types are: 7 • Audio (Synthetic): SP-MIDI [40], General MIDI [41] and Compact MIDI [7], 8 • Text: Unicode [31] (e.g. US-ASCII [32], ISO-8859-1 [33], UTF-8 [34], GSM 7-bit 9

default alphabet [35], Shift-JIS, etc…), 10 • Timed Text: 3GPP Timed Text [52], 11 • Bitmap Graphics: GIF87 [25], GIF89A [26], PNG [30], 12 • Still Image: JPEG [27], 13 • Vector Graphics: SVG-Tiny [36], [37] and SVG-Basic [36], [37]. 14

When delivering multimedia using HTTP/TCP/IP, media elements should be aggregated 15 into a container file. 16

When multiple media elements are aggregated for combined delivery over HTTP/TCP or 17 other non-streaming approaches they shall be combined using the ".3g2" format as 18 described in [7] when possible to do so. 19

When multiple media elements are aggregated for combined delivery over HTTP/TCP or 20 other non-streaming approaches, and it is not possible to do so using the ".3g2" format, 21 they shall be combined using the ".cmf" format as described in [7] when possible to do 22 so. 23

Media that cannot be aggregated using ".3g2" or CMF may use alternative methods. 24

NOTE: When timed text is present in a “.3g2” file along with audio, speech and/or video 25 components, the audio, speech and/or video components may be parsed at the server 26 and streamed using RTSP/RTP as described in 8.1 / 9.1. 27

9.2.1 Transport of CMF Over HTTP 28

HTTP GET request is used to specify a CMF file by URI. When retrieving a CMF file with 29 HTTP GET request, the client should include optional enhancement parameters such 30 that the HTTP server can deliver an optimized CMF content to the client. Optimizations 31 may include, but are not limited to, CMF version, display size and other content 32 restrictions. 33

The MSS server shall ignore the URI parameters that it does not support. Multiple URI 34 parameters may be listed, and the delimiter "&" shall be used for such cases. Syntax of 35 GET request is shown below. 36

GET URI?uri_parameter_name1=value&uri_parameter_name2=value HTTP/1.1 37

CRLF 38

CRLF 39 40

Item M/O Description

C.P0046-0 v1.0


URI M URI to the 3GPP2 CMF file.

vn O vn represents the CMF version number. CMF Version number is the 4 bytes of data from the 'vers' subchunk. The first two bytes specify major version and the second two bytes specify minor version. The major and minor version numbers are represented in ASCII

URI parameters

sh O sh represents the screen height, with 2 bytes. sh=height

sw O sw represents the screen width, with 2 bytes. sw=width

Table 9-1 CMF parameters for HTTP GET 1

M/O stands for "Mandatory" or "Optional", respectively. 2 3

C.P0046-0 v1.0


10 Pseudo Streaming 1

Transfer of dynamic media content (Video, Speech, Audio, Timed Text) to the MSS 2 terminal may also be accomplished via file download using the TCP protocol as 3 referenced previously in section 9. The ".3g2" file format [7] shall be used for pseudo 4 streaming of timed multimedia (such as video, associated audio and timed text]. 5

The basic sequence of pseudo streaming is depicted in Figure 10-1. MSS client sends 6 HTTP GET request which specifies the file to be downloaded and MSS server transmits 7 the file in the response to the request. MSS client may start multimedia decoding and 8 playback during the download. 9

GET /foo.3g2 http/1.1 <CR><LF> <CR><LF>

Client Server

HTTP/1.1 200 OK

Start of the file receiving

End of the file receiving

Start of playback

10 Figure 10-1 Basic Sequence of Pseudo-streaming 11

10.1 Session Description 12

When deploying pseudo streaming, MSS session set up procedure described in section 13 8.2 is not required. 14

The necessary information for the client is URI of multimedia file and the file size, 15 which are provided by some means such as HTTP, e-mail and etc. The representation of 16 such information is not defined in this specification. 17

10.2 Transport Options 18

19

10.2.1 Request 20

HTTP GET request is used to specify a pseudo streaming file by URI. 21

The request is optionally enhanced using URI parameters and message-headers. The 22 MSS pseudo-streaming server that does not support these options shall ignore the URI 23 parameters that it does not support. Multiple URI parameters may be listed; the 24 delimiter "&" shall be used for such cases. Syntax of GET request is shown below. 25

GET URI?uri_parameter_name1=value&uri_parameter_name2=value HTTP/1.1 26

C.P0046-0 v1.0


message-header 1

CRLF 2

CRLF 3

4

Item M/O Description

URI M URI to the 3GPP2 file.

ac O Access Ticket obtained from the presentation description

br O Bit rate selection in accordance with the presentation description

st O Specifies the start position of the transmission in milliseconds.

Effective only for the initial transmission request, where ts=2.

URI parameters

ts O 2: The beginning of the transmission

3: Continuous transmission

This parameter shall exist if ac is contained.

message-header

Range O bytes=0-XXXXX (The beginning of the transmission)

bytes=YYYYY-ZZZZZ (Subsequent transmission)

Table 10-1 Pseudo-streaming HTTP GET request parameters 5

M/O stands for "Mandatory" or "Optional", respectively. 6

10.2.2 Response 7

Requested data is sent back to the MSS client in the response. The response is 8 optionally enhanced using message-headers. The MSS pseudo-streaming client that 9 does not support these options shall ignore those that it does not support. 10

Response to the data transmission request is defined in the following. 11

HTTP/1.1 Status Code 12

message-header 13

CRLF 14

CRLF 15

requested data 16

17

C.P0046-0 v1.0


Item M/O Value

Status Code M 200 OK (for full length data)

206 Partial Content (for ranged data)

message-header

Content-Range O bytes=xxxx-xxxx/xxxxxx (The size transmitted)

Required for the status "206 Partial Content"

Table 10-2 Pseudo-streaming HTTP response options 1

Regarding the Range parameter, the start bytes shall correspond to the actual bytes 2 received at the previous request. The following table shows an example. Note that the 3 Range parameter doesn’t specify an actual position of the content in the server but 4 specifies the number of bytes expected through the transmission. 5

6

The request number Specified bytes in the request Actual bytes in the response

1 0-96767 48000

2 48000-144767 52000

3 100000-196767 50000

Table 10-3 Example of pseudo-streaming message header range parameters 7

The uses of these options are described in the informative 8 9

C.P0046-0 v1.0


1

Pseudo Streaming Session Representation Example (Informative). 2

10.3 FFMS Usage in MSS 3

The MSS terminal should support pseudo-streaming. If the MSS terminal does support 4 pseudo-streaming, it shall support the ".3g2" MSS file format as specified in [7] and 5 specifically the transmission format for pseudo-streaming as specified in section B.1.2 6 of Annex B of that document. 7

8

C.P0046-0 v1.0


11 Media Types (Codecs) 1

2

11.1 General Requirements 3

Support for all media types is not required. When media support is not mandatory this 4 will be stated. When a media type is supported it shall include the mandatory codecs 5 specified for that media type. 6

11.2 "Video" 7

The MSS terminal should support the media type "Video". If the media type "video" is 8 supported then the MSS terminal: 9

• Shall support decoding of ITU-T Recommendation H.263 Profile 0 Level 45 [9] 10

• Shall support decoding of at least one of the following: 11

• MPEG-4 Visual Simple Profile Level 0b [10], 12

• H.264 Baseline Profile [45] Level 1b with constraint_set1_flag=1. 13

• Should support decoding of ITU-T Recommendation H.263 Profile 3 Level 45 [9] 14

For continuous video media the following MIME media types shall be used: 15

• For H.263 the MIME media type as defined in clause 4.2.7 of [14]; 16

• For MPEG-4 video the MIME media type as defined in [15]. When used in SDP 17 the configuration information shall be carried outband in the "config" SDP 18 parameter and inband (as stated in [15]). As described in [15], the 19 configuration information sent inband and the config information in the SDP 20 shall be the same except that first_half_vbv_occupancy and 21 latter_half_vbv_occupancy which, if exist, may vary in the configuration 22 information sent inband; 23

• For H.264 (AVC) video the MIME media type as defined in [19]. 24

Note that H.263 profile 0 level 10 is contained in MPEG-4 Visual as the short header 25 format. 26

The video decoder should include basic error concealment technologies. These 27 techniques may include re-generating data that is lost in transmission by re-using or 28 interpolating from the temporal adjacent frames or from spatial adjacent regions of the 29 same frame. 30

The video encoder and decoder for the MSS terminal should support square pixel 31 format. The encoder should signal this to avoid un-necessary pixel shape conversion. 32

11.3 "Speech" 33

There are two types of speech defined for MSS – Narrow Band (NB) and Wide Band 34 (WB). 35

C.P0046-0 v1.0


11.3.1 "Narrow Band Speech" 1

The MSS terminal shall support at least one of the following media type "Narrow Band 2 Speech": 3

• EVRC [5], 4

• 13K Vocoder [6]. 5

For continuous narrow band speech media the following MIME media types shall be 6 used: 7

• For EVRC the MIME media type as defined in clause 12.1 of [18]; 8

• For 13K the MIME media type as defined in clause 4.1 of [57] for storage and 9 clause 4.1.20 of [58] for streaming. 10

11.3.2 "Wide Band Speech" 11

The MSS terminal should support the media type "Wide Band Speech". If the media 12 type "Wide Band Speech" is supported the MMS terminal: 13

• Shall support VMR Wide Band [8]; 14

For continuous wide band speech media the following MIME media types shall be used: 15

• For VMR-WB the MIME media type as defined in [20] 16

11.4 "Audio" 17

The MSS terminal should support media type "audio". If the media type "audio" is 18 supported the MSS terminal: 19

• Should support the MPEG-4 AAC Profile Level 2 [47], [48], [49]; 20

• Should support the MPEG-4 HE AAC Profile, Level 2 [47], [48], [49]. 21

For continuous audio media the following MIME media types shall be used: 22

• For MPEG-4 AAC the MIME media type defined in clause 5.4 of [15]; 23

• For MPEG-4 HE AAC the MIME media type defined in clause 5.4 of [15]. 24

11.5 "Text in SMIL" 25

The MSS terminal should support media type "Text in SMIL", which is intended to 26 enable formatted text in a SMIL presentation. If text in SMIL is supported, the MSS 27 terminal: 28

• Shall support a SMIL plus XHTML profile contained in 3GPP2 SMIL language profile 29 [7] presentation and may ignore any unsupported XHTML modules in a SMIL 30 document; 31

• Shall support rendering of a SMIL presentation where text is referenced with the 32 SMIL 2.0 "text" element together with the SMIL 2.0 "src" attribute. 33

C.P0046-0 v1.0


11.6 "Timed Text" 1

The MSS terminal should support the media type "Timed Text". If timed text is 2 supported then the MSS terminal: 3

• Shall support 3GPP Timed Text [52]. 4

11.7 Other media 5

Other media types, as referenced in section 9.2, should be supported as described for 6 MMS [42]. 7

8

C.P0046-0 v1.0


12 Rate Adaptation of Streaming Media 1

2

12.1 Introduction 3

The goal of multimedia streaming rate adaptation is to achieve with the available 4 resources the highest possible quality of experience for the end-user while maintaining 5 interrupt-free playback of the media. This requires that the available network resources 6 are known or estimated and that transmission rates are adapted to the available 7 network link rates. With this information the server can better manage the network 8 buffers and thereby avoid packet losses by overflowing the buffer or underutilization the 9 network resources. The real-time properties of the transmitted media must be 10 considered so that media does not arrive too late to be useful. This will require that 11 media content rate is adapted to the transmission rate. 12

To avoid client buffer violation (underflow or overflow) while still allowing the server to 13 deliver as much data as possible into the client buffer, a functionality for client buffer 14 feedback is defined. This allows the server to closely monitor the buffering status on the 15 client side and thus to optimize the quality of service. The client can specify how much 16 buffer space the server can utilize and the desired target level of protection. When the 17 desired level of protection is achieved, the server may utilize any resources beyond what 18 is needed to maintain that protection level to increase the quality of the media. The 19 server can also utilize the buffer feedback information to decide if the media quality 20 needs to be lowered in order to avoid a buffer underflow and the resulting playback 21 interruption. 22

12.2 Rate Adaptation 23

The bit-rate adaptation for MSS is server centric in the meaning that transmission and 24 content rate are controlled by the server. The server uses RTCP and RTSP as the basic 25 information sources about the state of the client and network. This makes link-rate 26 adaptation for communicating with MSS client possible. 27

12.2.1 Link Characteristics 28

When connected on an assured network channel, a MSS client should inform the server 29 the quality of service parameters for the used wireless link. The known parameters 30 should be included in the RTSP "Mobile-Link-Char" header (section 8.1.1) in either the 31 RTSP SETUP or PLAY request. This enables the server to set some basic assumption 32 about the possible bit-rates and link response. If the client has initially reported these 33 parameters and they are changed during the session the client shall update these 34 parameters by including the "Mobile-Link-Char" header in a SET_PARAMETER or 35 OPTIONS request. 36

A MSS client should inform the server about initial bit-rate available over the link, if 37 known. This reporting shall be done using the RTSP "Bandwidth" header in either the 38 RTSP SETUP or PLAY request. The QoS negotiated guaranteed bit-rate is the best 39 estimate for the bandwidth value. 40

C.P0046-0 v1.0


12.2.2 Adaptation of Transmission Rate 1

The basic information source giving regular reports useful for bit-rate estimations is the 2 RTCP receiver reports as defined by [11]. The RTCP reporting interval is dependent on 3 the RTP profile in use, the bit-rate assigned to RTCP, the average size of RTCP packets, 4 and the number of reporting entities. Most of these parameters can be set or affected 5 by the MSS server through signaling. This allows the server to configure the reporting 6 interval to a desirable working point. 7

In most MSS RTP sessions the server and the client only have one SSRC each, thus 8 providing the highest possible reporting rate. However, some scenarios could result in a 9 large number of SSRCs, thereby possibly lowering the effective reporting interval for 10 client, server or both. 11

The transmission rate adaptation is implementation dependent. The server can use 12 alternate bitstreams for stream switching or use embedded scalable functionalities in 13 the codec. For example, the H.264 extended profile defines two types of switching 14 frames (SP/SI), which can be used for bitstream switching. 15

12.2.3 Receiver Buffer Level Feedback 16

The client buffer feedback signaling functionality should be supported by MSS clients 17 and MSS servers. For MSS clients and servers that support the client buffer feedback 18 signaling functionality, the following parts shall be implemented: 19

• SDP service support, as described in section 8.2.4; 20

• The buffer size (in bytes) provides the MSS server the available buffer space in the 21 client. It is signaled to the server through RTSP, as described in section 8.1.2; 22

• The target buffer protection time (in milliseconds). It is signaled to the server 23 through RTSP, as described in section 8.1.2; 24

The client buffer status feedback information free buffer space, next ADU to be decoded 25 and playout delay. It is signalled to the server via RTCP, as described in section 9.1.1; 26

If a MSS server supports client buffer feedback, it shall include the attribute "3GPP-27 Adaptation-Support" in the SDP, as described in 8.2.4. Upon reception of such an SDP 28 attribute, if a MSS client supports client buffer feedback, it shall send NADU APP 29 packets according to section 9.1.1 after a successful SETUP response. 30

The "3GPP-Adaptation" header may be included in PLAY, OPTIONS and 31 SET_PARAMETER requests in order to update the target buffer protection time value 32 during a session. The buffer size value shall not be modified during a session. 33

With the total buffer size, and the reported amount of free buffer space, the server can 34 avoid overflowing the buffer. A server should assume that any sent RTP packet will 35 consume receiver buffer space equal to the complete RTP packet size. For interleaved or 36 aggregated media, the actual buffer space consumption may be slightly larger if 37 buffering is done in the ADU domain. This is because each ADU may save metadata 38 corresponding to the RTP header and payload fields, like timestamp and decoding 39 sequence numbers individually. This should only be a problem if a server tries to fill 40 exactly to the last free memory block. 41

The server can determine the time to underflow by calculating the amount of media 42 time present in the buffer. This is done using the next ADU sequence number and the 43 highest received sequence number combined with the server's view of the sent ADUs 44

C.P0046-0 v1.0


and their decoding order and playout time. The playout delay signaling in the RTCP APP 1 packet improves the accuracy of the estimated time. For example, in the case of low 2 frame-rate video or missing frames, the playout delay may contribute significantly to 3 the total buffering time at the client. 4

The level of protection needed against transmission rate variations over a wireless 5 network can be substantial (throughput variation because of network load, radio 6 conditions, several seconds of interruption because of handovers, possible extra 7 buffering to perform retransmission). In order to minimize the initial buffering delay, 8 the client may choose an initial buffering that is less than the required buffering it has 9 determined would be satisfactory. For this reason, the target buffer protection time 10 indicates the amount of playable media (in time), which the client would like to have in 11 its buffer. Therefore a server should not perform content adaptation towards higher 12 content rates until the given target time of media units is available in the buffer. 13

14

C.P0046-0 v1.0


Annex A Call Flow Example (Informative) 1

This is an informative annex that contains an example video streaming call flow. 2

The MS establishes an IP bearer, an RLP retransmission scheme, and a corresponding 3 Quality of Service context over Service Option 33/66. The MS and streaming server 4 then communicate over the IP bearer using RTSP as follows: 5

The MS issues a DESCRIBE request to the streaming server to get information about a 6 specific media source. The streaming server responds with an OK followed by an SDP 7 description of the desired sessions. The MS then issues a SETUP to initiate the 8 streaming session. If successful, the streaming server returns an OK. 9

On input from the user to start viewing the content stream, the MS issues a PLAY 10 request to the streaming server. On input from the user to quit the session, the 11 terminal issues a TEARDOWN request to the server, which responds with an OK. This 12 scenario is illustrated in Figure A 13

C.P0046-0 v1.0


1

MS Base Station PDSN MMSServer

Modify SO 33 according torequirements, negotiate RLPretransmission scheme and

QoS context

Establish SO 33 session

Establish PPP and header compression protocols

IP bearer established

IP bearer modified

DESCRIBE

OK, DESCRIBE response (using SDP)

SETUPOK

PLAYOK

TEARDOWNOK

Retrieve Presentation layout from MMS or other methodPresentation Layout Description (SMIL with URLs)

StreamingServer

RTCP SR/RR packets for RTP stream

Audio/Video packets over RTP, graphics/images/timed text

1

Figure A 1 Example Multimedia Streaming Call Flow 2

3

C.P0046-0 v1.0


Annex B Sample Scenario of a Session (Informative) 1

This is an informative annex that describes a sample scenario of a video streaming 2 session. 3

The content URL address is rtsp://server.foo.com:554/presentation.3g2. The 4 server.foo.com is the Internet address of the server, and 554 is the port number (note: 5 The default port number for RTSP is 554). The presentation is the path and filename of 6 the content to be streamed. 7

The RTSP session can be invoked by user clicking the link at the HTTP browser on the 8 mobile terminal or other means, such as entering the URL address by key combinations. 9

When the mobile terminal receives the instruction, it would then first start an IP bearer 10 over Service Option 33/66 as described in this document. 11

The client requests a description of the content and the server responses with the 12 information. 13 C->S: DESCRIBE rtsp://server.foo.com/presentation.3g2 RTSP/1.0 14 CSeq: 312 15 Accept: application/sdp 16 User-Agent: The 3GPP2StreamClient/1.1b3 17 18 S->C: RTSP/1.0 200 OK 19 CSeq: 312 20 Date: 12 February 2001 15:35:06 GMT 21 Content-Type: application/sdp 22 Content-Length: 414 23 v=0 24 o=somebody 2890844526 2890842807 IN IP4 128.97.90.132 25 s=Sample Stream 26 [email protected] 27 c=IN IP4 0.0.0.0 28 b=AS:43 29 t=0 0 30 a=range:npt=0-59.3478 31 a=control:* 32 m=audio 0 RTP/AVP 97 33 b=AS:13 34 a=rtpmap:97 EVRC 35 a=fmtp:97 36 a=maxptime:200 37 a=control:streamed=0 38 m=video 0 RTP/AVP 98 39 b=AS:30 40 a=rtpmap:98 H-263-2000/90000 41 a=fmtp:98 profile=0;level=10 42 a=x-initpredecbufperiod:90000 43 a=control:streamed=1 44

The above response is an RTSP message containing an SDP description of the video 45 (H.263) and audio streams (EVRC). 46

The client can then request to setup the audio and video media components of the 47 session. 48 C->S: SETUP rtsp://server.foo.com/presentation.3g2/streamed=0 RTSP/1.0 49 CSeq: 313 50 Transport: RTP/AVP;unicast;client_port=4588-4589 51 User-Agent: The3GPP2StreamClient/1.1b3 52 53 S->C: RTSP/1.0 200 OK 54 CSeq: 313 55 Date: 12 February 2001 15:35:07 GMT 56 Session: 12345678 57

C.P0046-0 v1.0


Transport: RTP/AVP;unicast;client_port=4588-4589;server_port=6256-6257 1 2 C->S: SETUP rtsp://server.foo.com/presentation.3g2/streamID=1 RTSP/1.0 3 CSeq: 314 4 Session: 12345678 5 Transport: RTP/AVP;unicast;client_port=4588-4589 6 User-Agent: The3GPP2StreamClient/1.1b3 7 8 S->C: RTSP/1.0 200 OK 9 CSeq: 314 10 Date: 12 February 2001 15:35:07 GMT 11 Session: 12345678 12 Transport: RTP/AVP;unicast;client_port=4590-4591;server_port=6258-6259 13

The above messages set up the session between the server and the client for the 14 specific content. The client has chosen to stream both audio and video components in 15 the session. 16

The client can request play starting from any point relative to the beginning of the 17 stream. The server returns the RTP related information to the client in the PLAY 18 response. 19 C->S: PLAY rtsp://server.foo.com/presentation.3g2 RTSP/1.0 20 CSeq: 315 21 Session: 12345678 22 Range: npt=0- 23 User-Agent: The3GPP2StreamClient/1.1b 24 25 S->C: RTSP/1.0 200 OK 26 CSeq: 315 27 Date: 12 February 2001 15:35:07 GMT 28 Session: 12345678 29 Range: npt=0-59.3478 30 RTP-Info: url= rtsp://server.foo.com/presentation.3g2/streamID=0; 31 seq=39900;rtptime=44470648, 32 url= rtsp://server.foo.com/presentation.3g2/streamID=1; 33 seq=31004;rtptime=41090349 34 35 NOTE: Headers can be folded onto multiple lines if the continuation line begins with a 36 space or horizontal tab. For more information, see [21]. 37

The client can also request pause of the stream at any point in the presentation 38 timeline 39

40 C->S: PAUSE rtsp://server.foo.com/presentation.3g2 RTSP/1.0 41 CSeq: 318 42 Session: 12345678 43 User-Agent: The 3GPP2StreamClient/1.1b 44 45 S->C: RTSP/1.0 200 OK 46 CSeq: 318 47 Session: 12345678 48 Date: 12 February 2001 15:35:45 GMT 49

Note that the client can start playing again from any point of the stream (including the 50 point where it paused). 51

Finally, the client can request the tear down of the RTSP session it created. 52 C->S: TEARDOWN rtsp://server.foo.com/presentation RTSP/1.0 53 CSeq: 350 54 Session: 12345678 55 User-Agent: The 3GPP2StreamClient/1.1b 56 57 S->C: RTSP/1.0 200 OK 58 CSeq: 350 59

C.P0046-0 v1.0


Session: 12345678 1

After finishing the RTSP session, the mobile terminal can continue on terminating IP 2 bearer over the Service Option 33/66. 3

4

C.P0046-0 v1.0


1

Annex C Buffering of Video (Normative) 2

C.1 Introduction 3

This annex describes video buffering requirements in the MSS. MSS buffering is 4 optional and may be signaled in SDP 8.2.1 or MSS capability exchange 8.3.2. When this 5 option is in use, the content of this annex is normative. In other words, MSS clients 6 shall be capable of receiving an RTP packet stream that complies with the specified 7 buffering model and MSS servers shall verify that the transmitted RTP packet stream 8 complies with the specified buffering model. 9

MSS Buffering Parameters 10

The behavior of the MSS buffering model is controlled with the following parameters: 11 the initial pre-decoder buffering period, the initial post-decoder buffering period, the 12 size of the hypothetical pre-decoder buffer, the peak decoding byte rate, and the 13 decoding macroblock rate. The default values of the parameters are defined below. 14

• The default initial pre-decoder buffering period is 1 second. 15

• The default initial post-decoder buffering period is zero. 16

• The default size of the hypothetical pre-decoder buffer is defined according to the 17 maximum video bit-rate according to the table below: 18

19

Maximum video bit-rate

Default size of the hypothetical pre-decoder buffer

65536 bits per second

20480 bytes

131072 bits per second

40960 bytes

Undefined 51200 bytes

Table C 1 – Default size of the hypothetical pre-decoder buffer 20

• The maximum video bit-rate can be signaled in the media-level bandwidth attribute 21 of SDP as defined in section 8 of this document. If the video-level bandwidth 22 attribute was not present in the presentation description, the maximum video bit-23 rate is defined according to the video coding profile and level in use. 24

• The size of the hypothetical post-decoder buffer is an implementation-specific issue. 25 The buffer size can be estimated from the maximum output data rate of the 26 decoders in use and from the initial post-decoder buffering period. 27

• The default, the peak decoding byte rate is defined according to the video coding 28 profile and level in use. For example, H.263 Level 10 requires support for bit-rates 29 up to 64000 bits per second. Thus, the peak decoding byte rate equals to 8000 30 bytes per second. 31

• The default decoding macroblock rate is defined according to the video coding 32 profile and level in use. If MPEG-4 Visual is in use, the default macroblock rate 33 equals to VCV decoder rate. If H.263 is in use, the default macroblock rate equals to 34

C.P0046-0 v1.0


(1 / minimum picture interval) multiplied by number of macroblocks in maximum 1 picture format. For example, H.263 Level 10 requires support for picture formats up 2 to QCIF and minimum picture interval down to 2002 / 30000 sec. Thus, the default 3 macroblock rate would be 30000 x 99 / 2002 ≈ 1484 macroblocks per second. 4

MSS clients may signal their capability of providing larger buffers and faster peak 5 decoding byte rates in the capability exchange process described in section 19 of this 6 document. The average coded video bit-rate should be smaller than or equal to the bit-7 rate indicated by the video coding profile and level in use, even if a faster peak decoding 8 byte rate were signaled. 9

Initial parameter values for each stream can be signaled within the SDP description of 10 the stream. Signaled parameter values override the corresponding default parameter 11 values. The values signaled within the SDP description guarantee pauseless playback 12 from the beginning of the stream until the end of the stream (assuming a constant-13 delay reliable transmission channel). 14

MSS servers may update parameter values in the response for an RTSP PLAY request. If 15 an updated parameter value is present, it shall replace the value signaled in the SDP 16 description or the default parameter value in the operation of the MSS buffering model. 17 An updated parameter value is valid only in the indicated playback range, and it has no 18 effect after that. Assuming a constant-delay reliable transmission channel, the updated 19 parameter values guarantee pauseless playback of the actual range indicated in the 20 response for the PLAY request. The indicated pre-decoder buffer size and initial post-21 decoder buffering period shall be smaller than or equal to the corresponding values in 22 the SDP description or the corresponding default values, whichever ones are valid. 23

The following header fields are defined for RTSP: 24

• x-predecbufsize:<size of the hypothetical pre-decoder buffer> 25 This gives the suggested size of the Annex C hypothetical pre-decoder buffer in 26 bytes. 27

• x-initpredecbufperiod:<initial pre-decoder buffering period> 28 This gives the required initial pre-decoder buffering period specified according to 29 Annex C. Values are interpreted as clock ticks of a 90-kHz clock. That is, the value 30 is incremented by one for each 1/90 000 seconds. For example, value 180 000 31 corresponds to a two second initial pre-decoder buffering. 32

• x-initpostdecbufperiod:<initial post-decoder buffering period> 33 This gives the required initial post-decoder buffering period specified according to 34 Annex C. Values are interpreted as clock ticks of a 90-kHz clock. 35

These header fields are defined for the response of an RTSP PLAY request only. Their 36 use is optional. 37

The following example plays the whole presentation starting at SMPTE time code 38 0:10:20 until the end of the clip. The playback is to start at 15:36:00 on 12 Feb 2001. 39 The suggested initial post-decoder buffering period is two seconds. 40 C->S: PLAY rtsp://server.foo.com/presentation.3g2 RTSP/1.0 41 CSeq: 833 42 Session: 12345678 43 Range: smpte=0:10:20-;time=20010212T153600Z 44 45 S->C: RTSP/1.0 200 OK 46 CSeq: 833 47 Date: 12 Feb 2001 15:35:06 GMT 48 Range: smpte=0:10:22-;time=20010212T153600Z 49 RTP-Info : url= rtsp://server.foo.com/presentation.3g2/streamID=0; 50 seq=399000 ;rtptime=44470648, 51

C.P0046-0 v1.0


url= rtsp://server.foo.com/presentation.3g2/streamID=1; 1 seq=31004 ;rtptime=41090349 2 x-initpredecbufperiod: 180000 3 4

MSS server buffering verifier 5

The MSS server buffering verifier is specified according to the MSS buffering model. The 6 model is based on two buffers and two timers. The buffers are called the hypothetical 7 pre-decoder buffer and the hypothetical post-decoder buffer. The timers are named the 8 decoding timer and the playback timer. 9

The MSS buffering model is presented below. 10

1. The buffers are initially empty. 11

2. A MSS Server adds each transmitted RTP packet having video payload to the pre-12 decoder buffer immediately when it is transmitted. All protocol headers at RTP or 13 any lower layer are removed. 14

3. Data is not removed from the pre-decoder buffer during a period called the initial 15 pre-decoder buffering period. The period starts when the first RTP packet is added 16 to the buffer. 17

4. When the initial pre-decoder buffering period has expired, the decoding timer is 18 started from a position indicated in the previous RTSP PLAY request. 19

5. Removal of a video frame is started when both of the following two conditions are 20 met: First, the decoding timer has reached the scheduled playback time of the 21 frame. Second, the previous video frame has been totally removed from the pre-22 decoder buffer. 23

6. The duration of frame removal is the larger one of the two candidates: The first 24 candidate is equal to the number of macroblocks in the frame divided by the 25 decoding macroblock rate. The second candidate is equal to the number of bytes in 26 the frame divided by the peak decoding byte rate. When the coded video frame has 27 been removed from the pre-decoder buffer entirely, the corresponding 28 uncompressed video frame is located into the post-decoder buffer. 29

7. Data is not removed from the post-decoder buffer during a period called the initial 30 post-decoder buffering period. The period starts when the first frame has been 31 placed into the post-decoder buffer. 32

8. When the initial post-decoder buffering period has expired, the playback timer is 33 started from the position indicated in the previous RTSP PLAY request. 34

9. A frame is removed from the post-decoder buffer immediately when the playback 35 timer reaches the scheduled playback time of the frame. 36

10. Each RTSP PLAY request resets the MSS buffering model to its initial state. 37

A MSS server shall verify that a transmitted RTP packet stream complies with the 38 following requirements: 39

• The MSS buffering model shall be used with the default or signaled buffering 40 parameter values. Signaled parameter values override the corresponding default 41 parameter values. 42

• The occupancy of the hypothetical pre-decoder buffer shall not exceed the default or 43 signaled buffer size. 44

• Each frame shall be inserted into the hypothetical post-decoder buffer before or on 45 its scheduled playback time. 46

C.P0046-0 v1.0


C.2 MSS client buffering requirements 1

When annex C is in use, the MSS client shall be capable of receiving an RTP packet 2 stream that complies with the MSS server buffering verifier, when the RTP packet 3 stream is carried over a constant-delay reliable transmission channel. Furthermore, the 4 video decoder of the MSS client, which may include handling of post-decoder buffering, 5 shall output frames at the correct rate defined by the RTP time-stamps of the received 6 packet stream. 7

8

C.P0046-0 v1.0


1

Annex D Pseudo Streaming Session Representation 2 Example (Informative) 3

This Annex shows an example of XHTML [59] session representation, which is defined 4 in ITU-T Recommendation J.127 [46] 5

D.1 XHTML Presentation Description Format 6

The presentation description may be obtained by the receiver using HTTP or other 7 means such as e-mail and may not necessarily be stored on the server. 8

The presentation description contains a description of the media streams making up 9 the program, including their location, title, encoding types, data size, and other 10 parameters that enables the receiver to start retrieving the most appropriate media. 11

The presentation description is written by the <object> element with the <param> 12 elements of XHTML. 13

An example is shown below. Elements defined in this Annex are written with bold 14 letters. 15

<?xml version="1.0" ?> 16

<!DOCTYPE html 17

PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 18

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 19

<head> 20

<title>Webcasting Test Page</title> 21

</head> 22

<body> 23

<object data="http://www.webcasting.org/media.mp4" type="video/MP2T" 24

copyright="no" standby="Click Here"> 25

<param name="disposition" value="devmpzz" valuetype="data" /> 26

<param name="duration" value="30000" valuetype="data" /> 27

<param name="size" value="240000" valuetype="data" /> 28

<param name="title" value="Preview of the movie" valuetype="data" /> 29

<param name="ac" value="Jc5gUxzTqJ9ebM3U18GEWdKgtiTWR6Fe" valuetype="data" /> 30

</object> 31

</body> 32

</html> 33

Elements used in the presentation description are summarized in Table D 1. In Table D 34 1, M/O stands for "Mandatory" or "Optional" respectively. 35

36

Element Attribute M/O Value Description

C.P0046-0 v1.0


object Data M URI String Actual location of the media file.

object Type M MIME Type MIME type of the media.

object Copyright O "yes" | "no" Copyright control.

object Standby M String The displayed text of the link.

param name="ac"

value="…."

valuetype="data"

O String Access Ticket.

param name="bitrate"

value="…."

valuetype="data"

O Numeric String

Bit rate of the content in bps.

param name="disposition"

value="…."

valuetype="data"

M String Types of the content distribution, which stands for downloading, VOD transmission, or live transmission.

param name="duration"

value="…."

valuetype="data"

O Numeric String

Duration of the content in milliseconds.

param name="size"

value="…."

valuetype="data"

O Numeric String

File size of the content in bytes. This field is effective for downloading and VOD streaming.

param name="title"

value="…."

valuetype="data"

M String Title text of the content.

Table D 1 Elements defined in this Annex 1

D.2 <object> Element 2

The following attributes for the <object> element are defined. 3

D.2.1 data 4

This is a mandatory attribute that specifies the URI of the media to be transmitted. In 5 pseudo streaming, since the media is transmitted by HTTP, the scheme of the URI shall 6 be http, or the URI shall start with "http://". 7

D.2.2 type 8

This is a mandatory attribute that specifies the MIME type of the media to be 9 transmitted [7]. 10

D.2.3 copyright 11

This attribute takes "yes" or "no", and this is optional. The default value is "no". The 12 copyright attribute takes effect as follows. 13

C.P0046-0 v1.0


yes: The content is protected from storing. The media data cannot be stored in the 1 device after playing. 2

no: The media data can be stored in the device after playing. 3

If this attribute is not specified, the terminalhandles the file as storage allows. 4

D.2.4 standby 5

This is a mandatory attribute that specifies the displayed text of the link to the media. 6 It will typically be "Click Here" or the name of the content. 7

D.2.5 <param> Element 8

Parameters of the media are specified with the <param> element in the HTML 9 description. The following parameters are defined. Each parameter is identified by the 10 name attribute and the value is specified by the value attribute. For all parameters, 11 ‘valuetype="data"’ is included in each <param> element. 12

The terminal ignores unknown parameters. 13

D.2.6 ac 14

This is an optional parameter and the value attribute specifies the access ticket. The 15 maximum length of the value is 512 Bytes. The terminal that obtained the access ticket 16 from the ac parameter in the presentation description shall use this ticket when the 17 terminal carries out the session control as "ac=" parameter in the HTTP request. 18

This is used for identification of fee collection. 19

D.2.7 bitrate 20

This is an optional parameter. It specifies the total bit rate of the media in bits per 21 second. If the media has video and audio track, the bitrate value will be the sum of the 22 bit rate of each track. 23

If the media has multiple bit rates for adaptive bit rate changing, all the values are 24 specified with ‘:’ separator. For example, 25

<param name="bitrate" value="64000:128000:256000" valuetype="data" /> 26

D.2.8 disposition 27

The disposition parameter defines the content type, its application, distribution scheme, 28 and so on. The existence of the disposition parameter is mandatory. The disposition 29 parameter itself is not defined in this Annex, but what the parameter specifies is 30 defined as follows. 31

• Category of the content: Video (including Video and Audio), Audio, Voice, etc. 32

• Transmission scheme of the content: File downloading, VOD transmission, Live 33 transmission 34

• Purpose of the content: Just viewing, Storing, Particular use (Wallpaper, 35 Screensaver, Alarm, etc.) 36

D.2.9 duration 37

This is an optional parameter. It specifies the duration of the media in milliseconds. If 38 the media has different duration of video and audio track, the value is the longest 39 duration in the tracks. 40

C.P0046-0 v1.0


D.2.10 size 1

This is an optional parameter. It specifies the data size of the media in bytes, which 2 helps the terminal to obtain the content size in advance of transmitting. Regarding the 3 file downloading and the VOD transmission, the file is already created before 4 transmitting. Therefore, the value of the size parameter is the same as the size of the 5 file. 6

In addition, if the media has multiple bit rates for adaptive bit rate changing, each size 7 corresponding to each bit rate is specified with ‘:’ separator. For example, 8

<param name="size" value="240000:480000:960000" valuetype="data" /> 9

If this parameter is not specified in the presentation description, the terminal receives 10 the content size from the server at the beginning of the transmission. This is carried out 11 with the HEAD request of HTTP. 12

For the live transmission, the file size cannot be estimated before transmission. In this 13 case, the size value indicates the maximum size of the stream that is continuously 14 transmitted. For example, if the size is 1572864 for the live transmission, the 15 connection will be closed after receiving 1.5 MB of the content. 16

D.2.11 title 17

This is a mandatory parameter that describes the title of the content. The maximum 18 length of the value is 40 Bytes. The title may be shown on the terminal when the 19 content is playing. 20

21

C.P0046-0 v1.0


Annex E Pseudo Streaming Example (Informative) 1

In this Annex, full features of Pseudo Streaming services are introduced. Some of them 2 require using optional parameters and message-header defined in Section 10.2. 3

E.1 Live encoding 4

Pseudo-streaming is a file based service., Therefore, real-time streaming is not possible 5 using pseudo-streaming. However, pseudo-streaming enables "live" streaming service, if 6 some delay (ex. 30seconds) is acceptable. 7

moov box of the 3GPP2 file format contains an index pointer to each chunk, therefore 8 moov cannot be generated before all the media data in the fragment becomes available. 9

10

11

12

13

14

15

16

17

Figure E-1 Block diagram for live pseudo-streaming 18

The encoder buffer stores a fragment of media data (e. g., 30 seconds), then the file 19 generator creates the moov and mdat atoms. The data from the encoder buffer is sent to 20 the server. Then the next fragment data is stored in the encoder buffer and the file 21 generator creates the moof and mdat boxes. The data from the encoder is sent to the 22 server, and the server appends the data to previously sent data. This is iterated for each 23 fragment, and the file on the server becomes longer. 24

The server provides the client the latest fragment at the requested time using the moof 25 to moov conversion as illustrated below. 26 27 28 29 30 31 32 33 34 35

Figure E-2 moof -> moov conversion in the server 36

The client will receive moov at the beginning of the file, so the decoder operation is the 37 same as with basic pseudo streaming, therefore, the first video frame in the mdat will 38 always be an I-frame. 39

40

ENC

buffer file generator

file converter

Web server Client

Encoder Server

moov mdat moof moof mdat mdat

moov mdat ftyp sent to client

(not yet arrived to server)latest fragment

C.P0046-0 v1.0


E.2 Random positioning 1

The client can choose the beginning position to see the long movie file. 2

3

GET /foo.3g2 http/1.1 Range:bytes=125000-134000 <CR><LF> <CR><LF>

Client Server

HTTP/1.1 206 Partial content Content-Range:bytes=125000-134000/752000<CR><LF> <CR><LF>

4 5

Figure E-3 HTTP request for the random positioning 6

Here, HTTP request includes CGI parameter to specify the beginning time. 7

Case 1) Fragment positioning 8

The server will search for the nearest movie fragment and convert the moof to moov, 9 and then transmits to the client. 10

Case 2) I-frame positioning 11

The server may search for an I-frame within the video media and generate a new moov 12 box. In this way the server can provide a temporal position more closely matching the 13

requested position. Note that media re-encoding is not required even in this case. 14

15

Figure E-4 Movie file reconstruction for random positioning service 16

E.3 Choosing bitrate 17

Considering the difference of the download speed in EV-DO and 1x, it is desirable to 18 choose bitrate of the movie from the client. It is accomplished by transport protocol 19 option and server operation. The transport option is depicted in Figure E-5. It requires 20 CGI parameter to specify the media bitrate. 21

moov mdat moof moof mdat mdat

moov mdat ftyp

0sec 30sec 30sec 60sec 60sec 90sec

I-frame

45 sec is requested

moof mdat

moov mdat ftyp moof mdat

1) moov->moof

2) generate new moof for shortened mdat

nearest I-frame

C.P0046-0 v1.0


GET /foo.3g2?br=128 http/1.1<CR><LF> <CR><LF>

Client Server

HTTP/1.1 200 OK

1 Figure E-5 Protocol enhancement for choosing bitrate 2

3

One of possible implementation of the server is to make a .3g2 file with multiple tracks, 4 in which each track has a different bitrate media for the same contents. Then, the 5 server regenerates a new .3g2 file with single bitrate media from the multiple rate file. 6 So, another enhancement is required. 7

8

Figure E-6 Generation of movie file for pseudo-streaming from multirate movie 9 file 10

Multirate movie fil

foom

foom

foo m

f o o m

Extracted single movie fil

<e.g. A1&V1: 64kb

A2&V2: 128kb

A3&V3: 256kb

V 1 V 2 V 3 A 1 A2 A3V1 V2V3 A1 A2A3 V1V2V3A1 A2A3 V1V2 V3A1 A 2 A 3 V 1 V 2 V 3 A 1 A 2 A 3V1V2V3A1

V1 V1A1 A1V1 A1 V1A1V1A1

3g multimedia streaming services

Documents