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

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

1、 中 國 移 動 通 信 企 業(yè) 標 準 QB-╳╳-╳╳╳-╳╳╳╳ 中國移動流媒體與音視頻下載業(yè)務終端技術規(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 相關術語 1 4 符號和縮略語 1 5 概述 1 5.1 目的 1 5.2 業(yè)務簡介 1 6 功能要求 1 6.1 基本操作要求 1 6.1.1 業(yè)務發(fā)起方式的要求 1 6.1.2 業(yè)務操作的要求 1 6.2 文件格式要求 1 6.3 媒體格式要求 1 6.4 動態(tài)碼率適配功能 1 6.5 參數配置要求 1 6.5.1 系統(tǒng)默認參數 1 6.5.1.1 瀏覽器的參數 1 6.5.1.2 播放器的參數 1 6.5.2 用戶可配置參數 1 7 接口要求 1 7.1 協(xié)議要求 1 7.2 終端與服務器的交互消息要求 1 7.2.1 RTS

3、P協(xié)議消息要求 1 7.2.2 RTSP報頭要求 1 7.2.3 SDP參數要求 1 7.2.4 MIME參數要求 1 7.2.5 URL參數要求 1 7.2.5.1 下載URL及參數選項定義 1 7.2.5.2 流媒體URL及參數選項定義 1 7.2.5.3 URL中參數缺省的情況 1 7.2.6 用戶代理（User Agent）參數要求 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 內存要求 1 8.4

4、 顯示要求 1 8.5 音頻要求 1 8.6 電源要求 1 9 其他要求 1 9.1 對外部事件響應的要求 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參數要求 1 9.2.3 內容自適應功能 1 9.2.4 OMA DL斷點續(xù)傳功能 1 10 編制歷史 1 附錄A播放器的界面要求 1 A.1設計原則 1 A.2觸摸屏用戶 1 A.2.1參考設計 1 A.3

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

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

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

8、國移動通信有限公司 [8] WCDMA/GSM雙模終端總體功能及技術要求，中國移動通信有限公司 [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ī)范中使用了“必須”、“推薦”、和“可選”等詞匯來描述對移動終端產品要求的強調程度。 “必須”項是指終端產品所必須提供的功能或性能要求； “推薦”項是指在標準中未作硬性要求，但建議終端產品提供的功能或性能要求； “可選”項指在目前看來是中國移動需求的發(fā)展方向，或終端產品在目前階段可不提供的功能或性能要求。 目前階段：從本版本發(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è)務是基于相關國際標準的移動數據增值業(yè)務，終端應基于業(yè)界開放式標準，包括網絡協(xié)議、媒體格式，體現(xiàn)良好的擴展性和互操作能力?；诖嗽瓌t本規(guī)范規(guī)定了流媒體與音視頻下載業(yè)務的終端產品應滿足的要求。 5.2 業(yè)務簡介 1、 流媒體 終端播放器實時從流媒體服務器上獲取流媒體數據，邊下載邊播放，流媒體內容不在終端設備上存儲。如果同一內容需要多次重復播放，需要每次播放時從流媒體服務器上重新下載數據。 根據流媒體內容的來源，流媒體業(yè)務可分為點播和直播兩種： · 流媒體點播 內容提供者預先對一段多媒體內容進行編輯、壓縮編碼，形

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

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

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

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

18、部分；如果遇到音視頻格式全不支持，終端必須給出相應提示。（推薦） · 在流媒體初始緩沖過程中，播放器可以在等到某個預定緩沖時間之前讓用戶選擇是否提前開始播放。（可選） · 播放器關閉后，終端必須退回瀏覽器界面。 6.2 文件格式要求 流媒體直播采用.sdp文件，點播和下載都采用.3gp文件，因此終端必須支持.sdp和.3gp文件格式，要求符合3GPP TS 26.244 V6.1.0。 6.3 媒體格式要求 終端必須支持《中國移動終端多媒體格式技術規(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ěn)定性，流媒體服務器根據終端定時的反饋信息分配當前可用的數據流。要求終端遵循3GPP 26.234 V6.1.0第10節(jié)中動態(tài)碼率適配功能的要求，支持3GPP 26.244 V6.1.0定義的文件格式。動態(tài)碼率適配的消息流程如圖6-1所示。 流媒體服務器 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）播放器向服務器發(fā)起DESCRIBE請求； 2）服務器響應DESCRIBE請求，返回200 OK消息。其中服務器回復的DESCRIBE響應消息所包含的SDP信息中必須攜帶3GPP-Adaptation-Support字段，并且為非零值； （注：3GPP-Adaptation-Support字段定義了NADU RTCP數據包的上報頻率。當該字段為0，表示不支持多碼率；為1，表示每個RR數據包中就有一個NADU；為2，表示每2

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

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

24、持服務器在響應SETUP的200 OK消息中對3GPP-Adaptation字段的原樣回復。 5）播放器向服務器發(fā)起PLAY播放請求。 播放器可以在PLAY消息中上報3GPP-Adaptation，通知服務器動態(tài)碼率適配的初始參數，格式要求同SETUP消息中該字段要求。（可選） 播放器可以在PALY消息中上報3GPP-Link-Char和Bandwidth，通知服務器無線鏈路的初始狀態(tài)，格式要求同SETUP消息中該字段要求。（可選） 6）服務器響應PLAY請求，返回200 OK消息。服務器根據播放器提供的動態(tài)碼率適配初始參數和無線鏈路初始狀態(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）服務器開始向播放器下發(fā)媒體流。 8）播放器必須在媒體流播放過程中周期性向服務器上報RR/SDES/NADU APP的RTCP數據包。 RR和NADU APP必須包括7.2.7節(jié)中要求的字段。 9）服務器繼續(xù)向播放器下發(fā)媒體流。 10）

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

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

28、空 § 超時時間：終端不允許提供連接超時的設置。 § 帶寬設置：終端不允許提供帶寬限制的設置。 6.5.2 用戶可配置參數 § 用戶可以在流媒體播放器中添加、編輯書簽（可選） § 用戶可以改變顯示大小，在全屏和標準屏幕間切換（可選，全屏顯示為可選功能） § 用戶可以選擇單聲道或者立體聲輸出（可選，立體聲輸出為可選功能） § 用戶可以選擇使用揚聲器或者耳機 § 用戶可以在瀏覽器和播放器中輸入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)流媒體內容，獲取服務器的RTSP URL和MIME參數，也可以直接獲得SDP文件。HTTP也可以用于傳輸流媒體中靜態(tài)圖像和文本等內容，并用于音視頻下載。 HTTP協(xié)議要求符合RFC2616和3GPP TS 26.234 V6.1.0。MIME是用來標記傳輸的文件類型，在流媒體中主要用于播放器的啟動，具體要求參見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參數選項參見7.2.1, 7.2.2, 7.2.5。 RTP：實時傳輸協(xié)議 RTP主要用于傳輸流媒體中的視頻、音頻和語音等媒體內容。RTP協(xié)議要求符合RFC3550和3GPP TS 26.234 V6.1.0。 RTCP：實時傳輸控制協(xié)議 RTCP主要用于服務器和客戶端之間的流量控制和擁塞控制。在RTP會話期間，各參與者周期

31、性地傳送RTCP包，RTCP包中包含已發(fā)送的數據包的數量、丟失的數據包的數量等統(tǒng)計信息，服務器可以利用這些信息動態(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請求的響應傳給播放器，也

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

33、內容播放和連接中止。圖7-2給出了基于RTSP/RTP的流媒體業(yè)務流程。 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 終端 流媒體門戶 流媒體服務器 1、HTTP : Get with User Agent 7、RTSP: TEARDOWN 3、RTSP: DESCRIBE RTSP: 200 OK RTSP: 200 OK 圖7-2 基

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

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

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

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

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

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

40、可選 Accept 必選 User-Agent 必選 應攜帶流媒體播放器軟件以及相關屬性信息 x-wap-profile 必選 應攜帶終端的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 必選 回復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字段，服務器能夠在PLAY resp中回復該字段。 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必須攜帶該參數 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字段，服務器應該能夠在resp中回復該字段。 OPTIONS Req Cseq 必選 Session 條件必選 在SETUP之后的 OPTIONS Req 必須攜帶該參數 Bandwidth 推

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

47、下該參數必須支持。 7.2.3 SDP參數要求 表 7-3 SDP參數項 參數 解釋 CMCC要求 具體的參數 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參數獲取片源的名稱信息，并提供給用戶訪問。推薦終端播放器支持在播放過程中顯示片源名稱的功能。 2. 終端必須可以通過I參數獲取片源的作者和版本信息，并提供給用戶訪問。 7.2.4 MIME參數要求 MIME是用來標記傳輸的文件類型，包含在Content-Type 中。 表 7-4 MIME參數項 主類別 次

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參數要求 7.2.5.1 下載URL及參數選項定義 終端要求支持的下載URL格式： http://://和http

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

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

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

58、端型號、軟件版本，推薦包括播放器名稱和版本信息，必須符合RFC2616的定義。 User Agent的格式和最大長度限制必須符合中國移動《移動終端WAP2.0技術規(guī)范》的要求，由若干“參數條目/參數條目屬性”組合而成，并以“空格”分開。 舉例如下： 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、在與流媒體服務器交互過程中，要求播放器在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數據報的源端，發(fā)送端同時也可以是接收端。 RR：接收端報告，所謂接收端是指僅接收但不發(fā)送RTP數據報的終端。 SDES：源描述，主要功能是作為會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。

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

61、應用程序的服務質量。 類似于RTP數據包，每個RTCP包以固定部分開始，緊接著的是可變長結構元素，但以一個32位邊界結束。 (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