中國移動流媒體與音視頻下載業(yè)務(wù)終端技術(shù)規(guī)范--iuggui

《中國移動流媒體與音視頻下載業(yè)務(wù)終端技術(shù)規(guī)范--iuggui》由會員分享，可在線閱讀，更多相關(guān)《中國移動流媒體與音視頻下載業(yè)務(wù)終端技術(shù)規(guī)范--iuggui（39頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 中 國 移 動 通 信 企 業(yè) 標 準 QB-╳╳-╳╳╳-╳╳╳╳ 中國移動流媒體與音視頻下載業(yè)務(wù)終端技術(shù)規(guī)范 China Mobile Streaming and Audio/Video Downloading Service Terminal Specification 版本號：1.1.1（報批稿） 版本號： 1.0.0（報批稿） ╳╳╳╳-╳╳-╳╳實施 ╳╳╳╳-╳╳-╳╳發(fā)布 中國移動通信有限公司 發(fā)布 目 錄 1 范圍 1 2

2、 引用標準 1 3 相關(guān)術(shù)語 1 4 符號和縮略語 1 5 概述 1 5.1 目的 1 5.2 業(yè)務(wù)簡介 1 6 功能要求 1 6.1 基本操作要求 1 6.1.1 業(yè)務(wù)發(fā)起方式的要求 1 6.1.2 業(yè)務(wù)操作的要求 1 6.2 文件格式要求 1 6.3 媒體格式要求 1 6.4 動態(tài)碼率適配功能 1 6.5 參數(shù)配置要求 1 6.5.1 系統(tǒng)默認參數(shù) 1 6.5.1.1 瀏覽器的參數(shù) 1 6.5.1.2 播放器的參數(shù) 1 6.5.2 用戶可配置參數(shù) 1 7 接口要求 1 7.1 協(xié)議要求 1 7.2 終端與服務(wù)器的交互消息要求 1 7.2.1 RTS

3、P協(xié)議消息要求 1 7.2.2 RTSP報頭要求 1 7.2.3 SDP參數(shù)要求 1 7.2.4 MIME參數(shù)要求 1 7.2.5 URL參數(shù)要求 1 7.2.5.1 下載URL及參數(shù)選項定義 1 7.2.5.2 流媒體URL及參數(shù)選項定義 1 7.2.5.3 URL中參數(shù)缺省的情況 1 7.2.6 用戶代理（User Agent）參數(shù)要求 1 7.2.7 RTCP協(xié)議消息要求 1 7.2.8 終端如何區(qū)別直播和點播 1 7.2.9 錯誤代碼的終端提示信息 1 8 硬件要求 1 8.1 本地回放能力要求 1 8.2 處理能力要求 1 8.3 內(nèi)存要求 1 8.4

4、 顯示要求 1 8.5 音頻要求 1 8.6 電源要求 1 9 其他要求 1 9.1 對外部事件響應(yīng)的要求 1 9.1.1 普通電話/可視電話呼入 1 9.1.2 收到SMS/MMS/WAP PUSH 1 9.1.3 本機異常事件 1 9.1.4 其他異常事件 1 9.2 可選功能要求 1 9.2.1 基于HTTP的漸進式下載 1 9.2.2 SMIL參數(shù)要求 1 9.2.3 內(nèi)容自適應(yīng)功能 1 9.2.4 OMA DL斷點續(xù)傳功能 1 10 編制歷史 1 附錄A播放器的界面要求 1 A.1設(shè)計原則 1 A.2觸摸屏用戶 1 A.2.1參考設(shè)計 1 A.3

5、鍵盤用戶 1 A.3.1參考設(shè)計 1 附錄B多碼率媒體流的SDP文件示例 1 附錄C通過SET_PARAMETER發(fā)起速率切換的消息示例 1 附錄D 業(yè)務(wù)操作與RTSP消息的對應(yīng)關(guān)系 1 前 言 本規(guī)范在《中國移動GSM/GPRS終端技術(shù)規(guī)范》和《中國移動WCDMA/GSM雙模終端總體功能及技術(shù)要求》的基礎(chǔ)上，規(guī)定了中國移動通信有限公司流媒體單播和音視頻下載業(yè)務(wù)在終端部分的要求，包括功能要求、接口要求、性能要求等，是有限公司開展流媒體單播與音視頻下載業(yè)務(wù)的依據(jù)之一，不包括多播組播業(yè)務(wù)。該規(guī)范適用于支持流媒體單播和音視頻下載業(yè)務(wù)的2G終端和3G終端。該規(guī)范中除特別說明適用于2G

6、終端或3G終端外，其他要求都是適用于2G終端和3G終端。 本標準的附錄A-D為資料性附錄。 本標準由中國移動通信有限公司技術(shù)部提出并歸口。 本標準由標準歸口部門負責(zé)解釋。 本標準起草單位：中國移動通信研究院。 本標準主要起草人：朱春梅、張炎、唐劍峰。 1 范圍 本標準對流媒體單播和音視頻下載業(yè)務(wù)的終端部分提出規(guī)定。本標準是流媒體單播和音視頻下載業(yè)務(wù)的參考依據(jù)，也是終端廠商流媒體和音視頻下載終端產(chǎn)品的研發(fā)、生產(chǎn)的參照依據(jù)，供中國移動內(nèi)部和廠商共同使用。 本標準適用于支持流媒體單播和音視頻下載業(yè)務(wù)的2G終端和3G終端，及2G和3G網(wǎng)絡(luò)環(huán)境。 2 引用標準 下列標準所包含的條

7、文，通過在本標準中引用而成為本標準的條文。本標準出版時，所示版本均為有效。所有標準都會被修訂，使用本標準的各方應(yīng)探討使用下列標準最新版本的可能性。 [1] 流媒體及音視頻下載業(yè)務(wù)總體技術(shù)要求，中國移動通信有限公司 [2] 流媒體及音視頻下載業(yè)務(wù)規(guī)范，中國移動通信有限公司 [3] 流媒體及音視頻下載業(yè)務(wù)平臺接口規(guī)范，中國移動通信有限公司 [4] 流媒體及音視頻下載業(yè)務(wù)平臺設(shè)備規(guī)范，中國移動通信有限公司 [5] 中國移動WAP業(yè)務(wù)終端技術(shù)規(guī)范，中國移動通信有限公司 [6] 中國移動終端多媒體格式技術(shù)規(guī)范，中國移動通信有限公司 [7] 中國移動GSM/GPRS終端技術(shù)規(guī)范，中

8、國移動通信有限公司 [8] WCDMA/GSM雙模終端總體功能及技術(shù)要求，中國移動通信有限公司 [9] 3GPP TS26.233 Transparent end-to-end packet switched streaming service (PSS); General description [10] 3GPP TS26.234 Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs [11] 3GPP TS26.244 Transparent end-to-en

9、d packet switched streaming service (PSS); 3GPP file format (3GP) [12] IETF RFC 2326: Real Time Streaming Protocol (RTSP) [13] IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications [14] IETF RFC2616: HTTP 1.1: Hypertext Transfer Protocol [15] IETF RFC2327: SDP: Session Descrip

10、tion Protocol 3 相關(guān)術(shù)語 在本規(guī)范中使用了“必須”、“推薦”、和“可選”等詞匯來描述對移動終端產(chǎn)品要求的強調(diào)程度。 “必須”項是指終端產(chǎn)品所必須提供的功能或性能要求； “推薦”項是指在標準中未作硬性要求，但建議終端產(chǎn)品提供的功能或性能要求； “可選”項指在目前看來是中國移動需求的發(fā)展方向，或終端產(chǎn)品在目前階段可不提供的功能或性能要求。 目前階段：從本版本發(fā)布之日截至到下一個版本發(fā)布日期。 規(guī)范中除了明確指明為 “推薦”、“可選”外，均為必須要求。 4 符號和縮略語 3GP 3GPP file format AAC Advanced Au

11、dio Coding FBS Free Buffer Space GBW Guaranteed Bandwidth HTML Hyper Text Markup Language MIME Multipurpose Internet Mail Extensions MMS Multimedia Messaging Service MBW Maximum Bandwidth MTD Maximum transfer delay NSN Next ADU Sequence Number NUN Next ADU decoded Unit Numbe

12、r PSS Packet-switched Streaming Service QCIF Quarter Common Intermediate Format RTCP RTP Control Protocol RTP Real-time Transport Protocol RTSP Real-Time Streaming Protocol SDP Session Description Protocol SMIL Synchronised Multimedia Integration Language UAProf User Age

13、nt Profile 5 概述 5.1 目的 流媒體與音視頻下載業(yè)務(wù)是基于相關(guān)國際標準的移動數(shù)據(jù)增值業(yè)務(wù)，終端應(yīng)基于業(yè)界開放式標準，包括網(wǎng)絡(luò)協(xié)議、媒體格式，體現(xiàn)良好的擴展性和互操作能力?；诖嗽瓌t本規(guī)范規(guī)定了流媒體與音視頻下載業(yè)務(wù)的終端產(chǎn)品應(yīng)滿足的要求。 5.2 業(yè)務(wù)簡介 1、 流媒體 終端播放器實時從流媒體服務(wù)器上獲取流媒體數(shù)據(jù)，邊下載邊播放，流媒體內(nèi)容不在終端設(shè)備上存儲。如果同一內(nèi)容需要多次重復(fù)播放，需要每次播放時從流媒體服務(wù)器上重新下載數(shù)據(jù)。 根據(jù)流媒體內(nèi)容的來源，流媒體業(yè)務(wù)可分為點播和直播兩種： · 流媒體點播 內(nèi)容提供者預(yù)先對一段多媒體內(nèi)容進行編輯、壓縮編碼，形

14、成指定格式的文件，然后上傳到流媒體服務(wù)器上。用戶根據(jù)需要選擇流媒體服務(wù)器上的內(nèi)容文件進行播放。 · 流媒體直播 終端播放器播放流媒體直播內(nèi)容時，內(nèi)容的播放時刻與內(nèi)容源事件的發(fā)生時刻相同，即流媒體編碼服務(wù)器對內(nèi)容源進行實時地壓縮編碼，經(jīng)由流媒體服務(wù)器發(fā)送到用戶終端。 2、 音視頻下載 音視頻片斷下載業(yè)務(wù)的內(nèi)容提供者對內(nèi)容源文件進行編輯編碼形成指定格式的文件，并將文件上傳至服務(wù)器。終端用戶將整個媒體文件全部下載到終端。用戶點擊播放鍵，終端開始播放。 流媒體與音視頻下載系統(tǒng)的體系結(jié)構(gòu)如圖5-1所示。 圖5-1 中國移動流媒體業(yè)務(wù)系統(tǒng)結(jié)構(gòu) 本圖以單點組網(wǎng)為例，其中移動流媒體業(yè)務(wù)平

15、臺由業(yè)務(wù)門戶、內(nèi)容管理系統(tǒng)、業(yè)務(wù)管理平臺、流媒體服務(wù)器、下載服務(wù)器、計費單元、編碼器等模塊組成。CP側(cè)主要設(shè)備包括直播節(jié)目源、編碼器、VOD內(nèi)容，和現(xiàn)網(wǎng)有交互的設(shè)備包括GGSN、WAP GW、數(shù)據(jù)業(yè)務(wù)管理平臺和BOSS系統(tǒng)。 6 功能要求 6.1 基本操作要求 6.1.1 業(yè)務(wù)發(fā)起方式的要求 n 流媒體直播/點播業(yè)務(wù) 終端要求支持通過下列方式發(fā)起流媒體業(yè)務(wù)： · 通過WAP/HTTP瀏覽發(fā)起流媒體業(yè)務(wù)（必選） · 通過SMS信息中的HTTP/RTSP鏈接發(fā)起流媒體業(yè)務(wù)（必選） · 通過WAP PUSH信息中的HTTP/RTSP鏈接發(fā)起流媒體業(yè)務(wù)（必選） · 通過MMS信息

16、中的HTTP/RTSP鏈接發(fā)起流媒體業(yè)務(wù)（可選） · 通過播放器直接進入門戶/頻道瀏覽，再發(fā)起流媒體業(yè)務(wù)（可選） n 音視頻下載業(yè)務(wù) · 通過WAP/HTTP瀏覽發(fā)起音視頻下載業(yè)務(wù)（必選） · 通過瀏覽器能輸入HTTP鏈接直接發(fā)起的視頻下載業(yè)務(wù)（必選） · 通過SMS信息中的HTTP鏈接發(fā)起音視頻下載業(yè)務(wù)（必選） · 通過WAP PUSH信息中的HTTP鏈接發(fā)起音視頻下載業(yè)務(wù)（必選） · 通過MMS信息中的HTTP鏈接發(fā)起音視頻下載業(yè)務(wù)（可選） 6.1.2 業(yè)務(wù)操作的要求 · 對于流媒體點播，終端必須提供播放、暫停、繼續(xù)、停止、退出、定位播放（快進和后退）、音量控制操作。推薦

17、快進、后退的步長為1秒。具體操作與RTSP消息的對應(yīng)關(guān)系參見附錄D。 · 對于流媒體直播，終端必須提供播放、停止、退出、音量控制操作。 · 對于音視頻下載，終端必須提供本地回放功能，本地回放過程中必須包括播放、暫停、繼續(xù)、停止、退出、定位播放、音量控制操作。 · 在流媒體播放過程中，若當前速率不能滿足流媒體播放時，終端必須自動暫停播放并對媒體內(nèi)容進行緩存，在收到足夠信息后繼續(xù)播放。 · 流媒體播放結(jié)束后，終端不能保存任何流媒體文件，并且播放器的緩存必須不允許訪問；音視頻下載的文件必須保存在終端或存儲卡上。 · 如果遇到不支持的音頻格式或視頻格式，終端可以繼續(xù)播放其中可支持的視頻或音頻

18、部分；如果遇到音視頻格式全不支持，終端必須給出相應(yīng)提示。（推薦） · 在流媒體初始緩沖過程中，播放器可以在等到某個預(yù)定緩沖時間之前讓用戶選擇是否提前開始播放。（可選） · 播放器關(guān)閉后，終端必須退回瀏覽器界面。 6.2 文件格式要求 流媒體直播采用.sdp文件，點播和下載都采用.3gp文件，因此終端必須支持.sdp和.3gp文件格式，要求符合3GPP TS 26.244 V6.1.0。 6.3 媒體格式要求 終端必須支持《中國移動終端多媒體格式技術(shù)規(guī)范》中要求的文本、音頻、視頻的編碼格式和所有音視頻組合。 說明：終端必須支持AMR-NB，推薦支持AAC-LC/AAC+/AAC

19、++。終端必須支持H.263 profile0 level10，推薦支持H.264(AVC) Baseline Profile Level 1b，H.263 profile3 level10為可選要求。 6.4 動態(tài)碼率適配功能 對于2G終端，動態(tài)碼率適配是推薦要求。對于3G終端，動態(tài)碼率適配是必選功能。 由于無線傳輸網(wǎng)絡(luò)的不穩(wěn)定性，流媒體服務(wù)器根據(jù)終端定時的反饋信息分配當前可用的數(shù)據(jù)流。要求終端遵循3GPP 26.234 V6.1.0第10節(jié)中動態(tài)碼率適配功能的要求，支持3GPP 26.244 V6.1.0定義的文件格式。動態(tài)碼率適配的消息流程如圖6-1所示。 流媒體服務(wù)器 1

20、0. RTSP: SET_PARAMETER/OPTIONS（攜帶3GPP-Link-Char/Bandwidth/3GPP-Adaptation） 8. RTCP（包括RR、SDES、NADU等） 12. RTSP: 200 OK 4. RTSP: 200 OK（報頭攜帶3GPP-Adaptation） 7. RTP: Audio/Video 3. RTSP: SETUP（報頭攜帶3GPP-Adaptation） 5. RTSP: PLAY 播放器 11. RTSP: TEARDOWN 1. RTSP: DESCRIBE 2. RTSP: 200 OK （SDP中攜帶3G

21、PP-Adaptation-Support） 6. RTSP: 200 OK 9. RTP: Audio/Video 圖6-1 動態(tài)碼率適配的消息流程 1）播放器向服務(wù)器發(fā)起DESCRIBE請求； 2）服務(wù)器響應(yīng)DESCRIBE請求，返回200 OK消息。其中服務(wù)器回復(fù)的DESCRIBE響應(yīng)消息所包含的SDP信息中必須攜帶3GPP-Adaptation-Support字段，并且為非零值； （注：3GPP-Adaptation-Support字段定義了NADU RTCP數(shù)據(jù)包的上報頻率。當該字段為0，表示不支持多碼率；為1，表示每個RR數(shù)據(jù)包中就有一個NADU；為2，表示每2

22、個RR數(shù)據(jù)包有一個NADU。 服務(wù)器在多碼率媒體流的SDP文件中除了包含a=3GPP-Adaptation-Support字段外，必須支持a=alt-group:BW:AS、a=alt-default-id、a=alt等與多碼率文件相對應(yīng)的字段，參見附錄B。） 3）播放器發(fā)起SETUP消息； 播放器必須支持在該消息中上報3GPP-Adaptation報頭信息，具體字段的格式要求為 ? 必須攜帶媒體鏈接（url）、終端緩沖區(qū)大?。╯ize）和緩沖區(qū)的目標保護時間（target-time）屬性參數(shù)，參數(shù)之間用分號分隔，不能加入空格等其他分隔符； ? url鏈接必須加引號； 3GPP

23、-Adaptation報頭格式示例如下： 3GPP-Adaptation:url="rtsp:// 播放器可以在SETUP消息中上報3GPP-Link-Char報頭信息，通知服務(wù)器無線鏈路的初始狀態(tài)，其中包括GBW、MBW、MTD等參數(shù)。（推薦） 3GPP-Link-Char報頭格式示例如下： 3GPP-Link-Char: url="rtsp://192.168.20.31/muti/apH263mnew.3gp"; GBW=0; MBW=0; MTD=300 4）服務(wù)器響應(yīng)SETUP請求，返回200 OK消息，對3GPP-Adaptation字段進行原樣回復(fù)。 播放器必須支

24、持服務(wù)器在響應(yīng)SETUP的200 OK消息中對3GPP-Adaptation字段的原樣回復(fù)。 5）播放器向服務(wù)器發(fā)起PLAY播放請求。 播放器可以在PLAY消息中上報3GPP-Adaptation，通知服務(wù)器動態(tài)碼率適配的初始參數(shù)，格式要求同SETUP消息中該字段要求。（可選） 播放器可以在PALY消息中上報3GPP-Link-Char和Bandwidth，通知服務(wù)器無線鏈路的初始狀態(tài)，格式要求同SETUP消息中該字段要求。（可選） 6）服務(wù)器響應(yīng)PLAY請求，返回200 OK消息。服務(wù)器根據(jù)播放器提供的動態(tài)碼率適配初始參數(shù)和無線鏈路初始狀態(tài)，選擇準備播放的音視頻流，并將str

25、eamid通知播放器。 RTP-Info: url=rtsp://192.168.20.31/muti/apH263mnew.3gp/streamid=0;seq=0;rtptime=0, url=rtsp://192.168.20.31/muti/apH263mnew.3gp/streamid=6;seq=0;rtptime=0 7）服務(wù)器開始向播放器下發(fā)媒體流。 8）播放器必須在媒體流播放過程中周期性向服務(wù)器上報RR/SDES/NADU APP的RTCP數(shù)據(jù)包。 RR和NADU APP必須包括7.2.7節(jié)中要求的字段。 9）服務(wù)器繼續(xù)向播放器下發(fā)媒體流。 10）

26、播放器在流媒體會話過程中根據(jù)應(yīng)用層和無線鏈路的變化向服務(wù)器發(fā)起OPTIONS或SET_PARAMETER消息；（可選） 播放器可以在OPTIONS或SET_PARAMETER消息中上報3GPP-Adaptation，在流媒體會話過程中對終端緩沖區(qū)的目標保護時間（target-time）進行動態(tài)調(diào)整，但是緩沖區(qū)大?。╯ize）是不能改變的。示例參見附錄C。（可選） 播放器可以在OPTIONS或SET_PARAMETER消息中上報3GPP-Link-Char和Bandwidth，通知服務(wù)器無線鏈路的動態(tài)狀態(tài)。（可選） 11）播放器正常播放完成、用戶主動中止播放或主動關(guān)閉播放器時，播放器必

27、須向服務(wù)器發(fā)出TEARDOWN請求； 12）服務(wù)器返回200 OK消息。 6.5 參數(shù)配置要求 要求終端出廠預(yù)置以下參數(shù)，必須支持通過手動方式修改。 6.5.1 系統(tǒng)默認參數(shù) 6.5.1.1 瀏覽器的參數(shù) 終端瀏覽器的參數(shù)設(shè)置參見《中國移動WAP業(yè)務(wù)終端技術(shù)規(guī)范》。 APN：CMWAP 6.5.1.2 播放器的參數(shù) l 緩存設(shè)置 § 初始緩沖大?。ㄍ扑]支持） l 播放設(shè)置 § 循環(huán)播放（只針對本地回放，推薦支持） l 網(wǎng)絡(luò)設(shè)置 § APN：CMWAP § RTP/RTCP最低端口號、最高端口號： § 代理設(shè)置： 是否使用代理：否 代理的IP地址和端口：

28、空 § 超時時間：終端不允許提供連接超時的設(shè)置。 § 帶寬設(shè)置：終端不允許提供帶寬限制的設(shè)置。 6.5.2 用戶可配置參數(shù) § 用戶可以在流媒體播放器中添加、編輯書簽（可選） § 用戶可以改變顯示大小，在全屏和標準屏幕間切換（可選，全屏顯示為可選功能） § 用戶可以選擇單聲道或者立體聲輸出（可選，立體聲輸出為可選功能） § 用戶可以選擇使用揚聲器或者耳機 § 用戶可以在瀏覽器和播放器中輸入HTTP URL。 7 接口要求 7.1 協(xié)議要求 視頻 音頻 語音 鏈路狀態(tài)報告 能力交換 場景描述 靜態(tài)圖像 位圖 矢量圖 文本 同步文本 合成音頻

29、 控制消息 會話描述（SDP） 有效載荷格式 HTTP RTSP RTP/RTCP UDP TCP UDP IP 圖7-1流媒體終端的協(xié)議棧 其中， HTTP/TCP/UDP/IP：傳輸協(xié)議 HTTP主要用于發(fā)現(xiàn)流媒體內(nèi)容，獲取服務(wù)器的RTSP URL和MIME參數(shù)，也可以直接獲得SDP文件。HTTP也可以用于傳輸流媒體中靜態(tài)圖像和文本等內(nèi)容，并用于音視頻下載。 HTTP協(xié)議要求符合RFC2616和3GPP TS 26.234 V6.1.0。MIME是用來標記傳輸?shù)奈募愋停诹髅襟w中主要用于播放器的啟動，具體要求參見7.2.4。 RTSP：實時流媒體協(xié)議

30、RTSP主要通過DESCRIBE，SETUP，PLAY，PAUSE 和TEARDOWN等控制消息來實現(xiàn)流媒體的會話建立、播放、暫停、中止等操作。 RTSP協(xié)議要求符合RFC2326和3GPP TS 26.234 V6.1.0，其中RTSP消息選項、報頭選項、URL參數(shù)選項參見7.2.1, 7.2.2, 7.2.5。 RTP：實時傳輸協(xié)議 RTP主要用于傳輸流媒體中的視頻、音頻和語音等媒體內(nèi)容。RTP協(xié)議要求符合RFC3550和3GPP TS 26.234 V6.1.0。 RTCP：實時傳輸控制協(xié)議 RTCP主要用于服務(wù)器和客戶端之間的流量控制和擁塞控制。在RTP會話期間，各參與者周期

31、性地傳送RTCP包，RTCP包中包含已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計信息，服務(wù)器可以利用這些信息動態(tài)改變傳輸速率。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化。 RTCP協(xié)議要求符合RFC3550和3GPP TS 26.234 V6.1.0，其中RTCP消息選項參見7.2.7。 SDP：會話描述協(xié)議 會話描述協(xié)議是一種用于會話描述的格式（協(xié)議），并不是一個傳輸協(xié)議，也不包含在媒體的編解碼之中，而是用于在不同傳輸協(xié)議之間傳遞消息的通知協(xié)議，其主要目的是解決多媒體會話通知、邀請和會話初始化工作。SDP文件既可以通過對用戶HTTP請求的響應(yīng)傳給播放器，也

32、可以通過對用戶RTSP DESCRIBE請求的響應(yīng)傳給播放器。 SDP協(xié)議要求符合RFC2327和3GPP TS 26.234 V6.1.0，、SDP參數(shù)選項參見7.2.3。 7.2 終端與服務(wù)器的交互消息要求 1、點播、直播類業(yè)務(wù) 終端到服務(wù)器的信息交互存在基于RTSP/RTP和基于HTTP（Progressive download）兩種方式，其中基于HTTP的漸進式下載（Progressive download）屬于可選要求。 采用基于RTSP/RTP的實現(xiàn)方式 要求終端遵循3GPP TS 26.234 V6.1.0的要求。在終端上的操作主要有四個階段：內(nèi)容發(fā)現(xiàn)，連接建立，

33、內(nèi)容播放和連接中止。圖7-2給出了基于RTSP/RTP的流媒體業(yè)務(wù)流程。 2、HTTP: Get SDP HTTP: 200 OK with SDP RTCP RTSP: 200 OK RTSP: 200 OK 6、RTP: Audio/Video 4、RTSP: SETUP 5、RTSP: PLAY HTTP : 200 OK 終端 流媒體門戶 流媒體服務(wù)器 1、HTTP : Get with User Agent 7、RTSP: TEARDOWN 3、RTSP: DESCRIBE RTSP: 200 OK RTSP: 200 OK 圖7-2 基

34、于RTSP/RTP的流媒體業(yè)務(wù)流程 · 內(nèi)容發(fā)現(xiàn) 用戶點擊門戶上某一流媒體內(nèi)容，瀏覽器向門戶發(fā)起HTTP Get命令（含User Agent）。如果瀏覽器通過HTTP 200 OK響應(yīng)消息，從流媒體門戶上獲得流媒體內(nèi)容的RTSP鏈接，用戶點擊該鏈接，終端必須自動激活播放器。（步驟1－>步驟3） 如果瀏覽器通過HTTP 200 OK響應(yīng)消息，從流媒體門戶上獲得SDP文件的HTTP鏈接，用戶點擊該鏈接，向流媒體服務(wù)器請求SDP文件。服務(wù)器返回SDP文件，獲得流媒體內(nèi)容的RTSP鏈接，終端必須自動激活播放器。（步驟1－>步驟2） 對于返回的流媒體內(nèi)容RTSP鏈接，要求終端不能顯示、存儲服

35、務(wù)器返回的流媒體內(nèi)容RTSP鏈接地址。 · 連接建立 ü 獲取會話描述信息 （DESCRIBE） 播放器通過RTSP的DESCRIBE命令請求SDP，服務(wù)器在應(yīng)答中提供流媒體內(nèi)容的描述信息SDP文件，SDP的文本消息告訴播放器多媒體會話的信息，其中主要包括：協(xié)議版本，創(chuàng)作者和會話識別號，會話名稱，會話激活時間，媒體名稱傳輸?shù)刂泛推渌恍┬畔?。（步驟3） 如果服務(wù)器已經(jīng)通過HTTP響應(yīng)返回SDP文件，播放器不再發(fā)送DESCRIBE請求。（步驟2－>步驟4） ü 建立流媒體連接（SETUP） 播放器根據(jù)SDP的信息與媒體服務(wù)器建立RTSP連接，SETUP消息中必須包括會話標識

36、、播放器的傳輸協(xié)議（RTP）端口號。媒體服務(wù)器正確接到此信息后提供響應(yīng)服務(wù)器的RTP端口號，最終完成RTP端口的動態(tài)協(xié)商。（步驟4） · 內(nèi)容播放(PLAY) 播放器向服務(wù)器端發(fā)出RTSP中的播放命令，PLAY消息中必須包含會話標識、時間起始點、媒體服務(wù)器會話標識和媒體播放時間。媒體服務(wù)器通過RTP向播放器傳送媒體內(nèi)容。（步驟5－>步驟6） · 中止(TEARDOWN) 媒體正常播放完成后、用戶主動中止播放或主動關(guān)閉播放器時（不包括用戶暫停播放），播放器都必須向服務(wù)器發(fā)出RTSP中止命令，包括會話標識等信息，服務(wù)器端接到后做出200 OK響應(yīng)。（步驟7） 2、音視頻下載業(yè)

37、務(wù) 目前存在基于WAP方式和基于OMA Download兩種方式。 a） 基于WAP方式 要求終端遵循《中國移動WAP2.0終端規(guī)范》?；赪AP方式的音視頻下載業(yè)務(wù)，由于終端不能向系統(tǒng)返回狀態(tài)報告，因此系統(tǒng)無法獲知文件是否已成功下載到終端。 b） 基于OMA Download方式 對于3G終端，必須支持OMA Download 1.0的要求，終端成功接收到音視頻文件后，必須向下載服務(wù)器發(fā)送狀態(tài)報告。 對于2G終端，OMA Download是推薦功能，二階段是必選功能。 在終端上的操作主要有三個階段：下載請求，文件獲取請求，狀態(tài)報告。圖7-3給出了基于OMA Download

38、方式的音視頻下載業(yè)務(wù)流程圖。 圖 7-3 基于OMA Download方式的音視頻下載業(yè)務(wù)流程圖 · 下載請求 終端向下載服務(wù)器發(fā)起音視頻下載請求，服務(wù)器向終端返回下載描述符。 · 文件獲取請求 終端向下載服務(wù)器發(fā)送文件獲取請求，服務(wù)器向終端返回音視頻文件。 · 狀態(tài)報告 終端成功接收到音視頻文件后，必須向下載服務(wù)器發(fā)送狀態(tài)報告，下載服務(wù)器生成計費話單。 7.2.1 RTSP協(xié)議消息要求 表 7-1 RTSP協(xié)議消息選項 消息 解釋 CMCC要求 備注 OPTIONS 詢問支持的RTSP消息 推薦 SETUP 建立連接 必選 DESCR

39、IBE 媒體文件的描述 必選 PLAY 開始播放，回放 必選 RECORD 錄制功能 可選 不允許終端提供錄制功能的界面 REDIRECT 讓播放器重定向到服務(wù)器 推薦 PAUSE 暫停并保持 必選 GET_PARAMETER 服務(wù)器請求獲取參數(shù) 可選 SET_PARAMETER 播放器設(shè)置參數(shù) 推薦 TEARDOWN 中止 必選 7.2.2 RTSP報頭要求 表 7-2 RTSP報頭選項 消息 報頭 CMCC要求 備注 DESCRIBE Req Cseq 必選 Blocksize

40、可選 Accept 必選 User-Agent 必選 應(yīng)攜帶流媒體播放器軟件以及相關(guān)屬性信息 x-wap-profile 必選 應(yīng)攜帶終端的RDF文件的URI信息 Content-Encoding 必選 Content-Language 必選 DESCRIBE Resp Cseq 必選 Date 必選 Content-Length 必選 Content-Type 必選 Unsupported 條件必選 有不支持的RTSP消息時必須攜帶 SETUP Req Cseq 必選

41、 Blocksize 可選 Transport 必選 （RTP/AVP/UDP,unicast,client_port） User-Agent 必選 3GPP-Adaptation 條件必選 如果終端支持動態(tài)碼率適配；（url;size;target-time ） 3GPP-Link-Char 推薦 SETUP Resp CSeq 必選 Transport 必選 （RTP/AVP/UDP;unicast;client_port; server_port） 3GPP-Adaptation 必選 回復(fù)setup-

42、req中的3GPP-Adaptation Session 必選 Date 必選 Unsupported 條件必選 有不支持的RTSP消息時必須攜帶 PLAY Req Cseq 必選 Bandwidth 推薦 Range 必選 Session 必選 User-Agent 必選 3GPP-Link-Char 推薦 3GPP-Adaptation 可選 PLAY Resp Cseq 必選 Session 必選 Range 必選 RTP-Info

43、 必選 Date 必選 3GPP-Adaptation 條件必選 如果播放器在PLAY中攜帶3gpp-Adaptation字段，服務(wù)器能夠在PLAY resp中回復(fù)該字段。 PAUSE Req Cseq 必選 Session 必選 User-Agent 必選 PAUSE Resp Cseq 必選 Session 必選 Date 必選 TEARDOWN Req Cseq 必選 Session 必選 User-Agent 必選 TEARDOWN Resp Cseq

44、必選 Session 必選 Date 必選 消息 報頭 CMCC要求 備注 SET PARAMETER Req Cseq 必選 Session 條件必選 在SETUP之后的SET PARAMETER Req必須攜帶該參數(shù) User-Agent 必選 3GPP-Adaptation 可選 Content-Encoding 必選 Content-Length 必選 Content-Type 必選 Bandwidth 推薦 終端在SET PARAMETER req消息中攜帶，

45、指明終端當前的可用帶寬。 3GPP-Link-Char 推薦 SET PARAMETER Resp Cseq 必選 Session 必選 Unsupported 條件必選 有不支持的RTSP消息時必須攜帶 3GPP-Adaptation 條件必選 如果播放器在SET PARAMETER中攜帶3gpp-Adaptation字段，服務(wù)器應(yīng)該能夠在resp中回復(fù)該字段。 OPTIONS Req Cseq 必選 Session 條件必選 在SETUP之后的 OPTIONS Req 必須攜帶該參數(shù) Bandwidth 推

46、薦 終端在 OPTIONS req消息中攜帶，指明終端當前的可用帶寬。 3GPP-Adaptation 可選 OPTIONS Resp Cseq 必選 Session 必選 Unsupported 條件必選 有不支持的RTSP消息時必須攜帶 Public 必選 3GPP-Adaptation 條件必選 如果播放器在OPTIONS中攜帶3gpp-Adaptation字段，服務(wù)器應(yīng)該能夠在resp中回復(fù)該字段。 注： 類型“Req”表示應(yīng)用于請求消息中； 類型“Resp”表示應(yīng)用于響應(yīng)消息中； “條件必選”表示在某一條件

47、下該參數(shù)必須支持。 7.2.3 SDP參數(shù)要求 表 7-3 SDP參數(shù)項 參數(shù) 解釋 CMCC要求 具體的參數(shù) V Protocol version 必選 0 O Owner/creator and session identifier 必選 o=- 1084091316 1084091316 IN IP4 10.199.2.103 S Session name 必選 EES I Session information 必選 Author and copyright C Connection Information 必選 HUSm ip

48、address B Bandwidth information 必選 AS:81 T Time the session is active 必選 0 0(starttime,endtime) A sdpplugin 可選 SdpplinVersion:1610641560 A control 必選 control:* A range 必選 range-npt=0-179.263000 A Alt-group 條件必選 如果是多碼率文件，該字段必選BW:AS:28=1,3;56=1,4;60=2,4;120=2,5 注：該字段為session級字

49、段 M Media name and transport address 必選 video 0 RTP/AVP 96 B Bandwidth information 必選 AS:64 B Bandwidth information 必選 RR:2399 B Bandwidth information 必選 RS:799 A control 必選 control:streamid=0 A range 必選 range:npt=0-59.960000 A length 可選 length:npt =59.960000 A rtpmap

50、必選 rtpmap:96 MP4V-ES/90000 A fmtp 必選 fmtp:96 profile-level-id=1;config=000001B0F3000001B50EE040C0CF0000010000000120008440FA282C2090A21F A X-predecbufsize 可選 A X-initpredecbufperiod 可選 A X-initpostdecbufperiod 可選 A X-decbyterate 可選 A alt 條件必選 如果是多碼率文件 A alt-default-id

51、 條件必選 如果是多碼率文件 A 3GPP-Adaptation-Support 條件必選 如果是多碼率文件 M Media name and transport address 必選 audio 0 RTP/AVP 97 B Bandwidth information 必選 AS:17 B Bandwidth information 必選 RR:618 B Bandwidth information 必選 RS:206 A control 必選 control:streamid=1 A range 必選 range:npt=0-59.

52、960000 A length 可選 length:npt=59.960000 A rtpmap 必選 rtpmap:97 mpeg4-generic/16000/1 A fmtp 必選 fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408 A X-predecbufsize 可選 A X-initpredecbufperiod 可選 A X-initpostdecbufperiod 可選 A

53、X-decbyterate 可選 A alt 條件必選 如果是多碼率文件 A alt-default-id 條件必選 如果是多碼率文件 A 3GPP-Adaptation-Support 條件必選 如果是多碼率文件 注： 1. 終端必須可以通過S參數(shù)獲取片源的名稱信息，并提供給用戶訪問。推薦終端播放器支持在播放過程中顯示片源名稱的功能。 2. 終端必須可以通過I參數(shù)獲取片源的作者和版本信息，并提供給用戶訪問。 7.2.4 MIME參數(shù)要求 MIME是用來標記傳輸?shù)奈募愋?，包含在Content-Type 中。 表 7-4 MIME參數(shù)項 主類別 次

54、類別 格式 要求 application SDP .sdp 必選 SMIL .smil 二階段要求 audio AMR .amr 必選 AMR-WB .amr 可選 MP4A-LATM .aac 推薦 3gpp .3gp 必選 video H263-2000 .3gp 必選 H264 .3gp 推薦 3gpp .3gp 必選 7.2.5 URL參數(shù)要求 7.2.5.1 下載URL及參數(shù)選項定義 終端要求支持的下載URL格式： http://://和http

55、://://?字符串 字符串示例：&……&&key=keyvalue 其中“？”之前的各參數(shù)含義如下： 參數(shù) 含義 host 下載服務(wù)器域名或IP地址 port 下載服務(wù)器端口號 path 內(nèi)容路徑 filename 文件名 WAP下載：要求終端必須從WAP頁面中提取完整的HTTP鏈接，并通過HTTP消息發(fā)送給服務(wù)器，要求終端支持URL字符串不少于512位。 OMA DL下載：要求終端必須從DD（Download Descriptor）文件中提取完整的

56、HTTP鏈接，并通過HTTP消息發(fā)送給服務(wù)器，要求終端支持URL字符串不少于512位。 7.2.5.2 流媒體URL及參數(shù)選項定義 終端要求支持的流媒體URL格式： rtsp://://?字符串 字符串示例：&……&&key=keyvalue 其中“？”之前的各參數(shù)含義如下： 參數(shù) 含義 host 流媒體服務(wù)器域名或IP地址 port 流媒體服務(wù)器端口號 path 流媒體內(nèi)容路徑 filename 文件名 要求終端支持URL字符串不少于512位。要

57、求終端必須從WAP頁面中提取完整的RTSP鏈接，并通過RSTP消息發(fā)送給服務(wù)器。 7.2.5.3 URL中參數(shù)缺省的情況 對于下載、直播、點播業(yè)務(wù)，無論從服務(wù)器端傳下來的URL“？”之后的參數(shù)是否缺省，播放器都應(yīng)正常播放，如果某些需要顯示給用戶的參數(shù)無法獲得，則顯示為空。 7.2.6 用戶代理（User Agent）參數(shù)要求 為了使得服務(wù)器端能夠向終端發(fā)送合適的碼流，服務(wù)器需要獲得終端能力，包括終端的屏幕尺寸、CPU處理能力、內(nèi)存大小、屏幕分辨率、播放器類型等信息。 1、終端在訪問流媒體門戶和下載門戶時，要求在HTTP 請求的報頭中將正確的User Agent信息發(fā)給門戶，必須包括終

58、端型號、軟件版本，推薦包括播放器名稱和版本信息，必須符合RFC2616的定義。 User Agent的格式和最大長度限制必須符合中國移動《移動終端WAP2.0技術(shù)規(guī)范》的要求，由若干“參數(shù)條目/參數(shù)條目屬性”組合而成，并以“空格”分開。 舉例如下： User Agent：Nokia7650/1.0 SymbianOS/7.0s Series60/2.0 Release/5.18.2003 Browser/OpenWave7.0 Profile/MIDP-1.0 Configuration/CLDC-1.0 2、在與流媒體服務(wù)器交互過程中，要求播放器在RTSP消息的報頭攜帶User Ag

59、ent，包括播放器的基本信息，必須符合RFC2616的定義，其格式必須符合“播放器名稱/版本” 舉例如下： User-Agent：RealMedia Player/10.0.0.0 7.2.7 RTCP協(xié)議消息要求 RTCP協(xié)議消息有如下幾種類型，詳見RFC 3550 和RFC 3551： SR：發(fā)送端報告，所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報的源端，發(fā)送端同時也可以是接收端。 RR：接收端報告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報的終端。 SDES：源描述，主要功能是作為會話成員有關(guān)標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。

60、 BYE：通知離開，主要功能是通知會話中的其他成員自己將退出會話。 APP：由應(yīng)用程序自己定義，主要解決RTCP的擴展性問題。 發(fā)送媒體流的源端將周期性地產(chǎn)生發(fā)送端報告SR，該RTCP數(shù)據(jù)報含有不同媒體流間的同步信息，以及已經(jīng)發(fā)送的數(shù)據(jù)報和字節(jié)的計數(shù)，接收端根據(jù)這些信息可以估計出實際的數(shù)據(jù)傳輸速率。另一方面，接收端會向所有已知的發(fā)送端發(fā)送接收端報告RR，該RTCP數(shù)據(jù)報含有已接收數(shù)據(jù)報的最大序列號、丟失的數(shù)據(jù)報數(shù)目、延時抖動和時間戳等重要信息，發(fā)送端應(yīng)用根據(jù)這些信息可以估計出往返時延，并且可以根據(jù)數(shù)據(jù)報丟失概率和時延抖動情況動態(tài)調(diào)整發(fā)送速率，以改善網(wǎng)絡(luò)擁塞狀況，或者根據(jù)網(wǎng)絡(luò)狀況平滑地調(diào)整

61、應(yīng)用程序的服務(wù)質(zhì)量。 類似于RTP數(shù)據(jù)包，每個RTCP包以固定部分開始，緊接著的是可變長結(jié)構(gòu)元素，但以一個32位邊界結(jié)束。 (1) SR 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=SR=200

62、 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word

63、 | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-

64、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

65、+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

66、+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d