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

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

1、中 國 移 動 通 信 企 業(yè) 標(biāo) 準(zhǔn)QB-中國移動流媒體與音視頻下載業(yè)務(wù)終端技術(shù)規(guī)范China Mobile Streaming and Audio/Video Downloading Service Terminal Specification 版本號：1.1.1（報批稿） 版本號： 1.0.0（報批稿）-實(shí)施-發(fā)布中國移動通信有限公司 發(fā)布QB-XX-XXX-XXXX目錄1范圍12引用標(biāo)準(zhǔn)13相關(guān)術(shù)語14符號和縮略語25概述15.1目的15.2業(yè)務(wù)簡介16功能要求26.1基本操作要求26.1.1業(yè)務(wù)發(fā)起方式的要求26.1.2業(yè)務(wù)操作的要求36.2文件格式要求36.3媒體格式要求36.4動

2、態(tài)碼率適配功能36.5參數(shù)配置要求56.5.1系統(tǒng)默認(rèn)參數(shù)66.5.1.1瀏覽器的參數(shù)66.5.1.2播放器的參數(shù)66.5.2用戶可配置參數(shù)67接口要求67.1協(xié)議要求67.2終端與服務(wù)器的交互消息要求87.2.1RTSP協(xié)議消息要求107.2.2RTSP報頭要求117.2.3SDP參數(shù)要求137.2.4MIME參數(shù)要求157.2.5URL參數(shù)要求167.2.5.1下載URL及參數(shù)選項(xiàng)定義167.2.5.2流媒體URL及參數(shù)選項(xiàng)定義167.2.5.3URL中參數(shù)缺省的情況177.2.6用戶代理（User Agent）參數(shù)要求177.2.7RTCP協(xié)議消息要求177.2.8終端如何區(qū)別直播和點(diǎn)播

3、237.2.9錯誤代碼的終端提示信息238硬件要求238.1本地回放能力要求238.2處理能力要求238.3內(nèi)存要求248.4顯示要求248.5音頻要求248.6電源要求259其他要求259.1對外部事件響應(yīng)的要求259.1.1普通電話/可視電話呼入259.1.2收到SMS/MMS/WAP PUSH259.1.3本機(jī)異常事件269.1.4其他異常事件269.2可選功能要求269.2.1基于HTTP的漸進(jìn)式下載269.2.2SMIL參數(shù)要求269.2.3內(nèi)容自適應(yīng)功能269.2.4OMA DL斷點(diǎn)續(xù)傳功能2610編制歷史27附錄A播放器的界面要求27A.1設(shè)計原則27A.2觸摸屏用戶27A.2.

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

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

6、本均為有效。所有標(biāo)準(zhǔn)都會被修訂，使用本標(biāo)準(zhǔn)的各方應(yīng)探討使用下列標(biāo)準(zhǔn)最新版本的可能性。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 WCDMA/GSM雙模終端總體功能及技術(shù)要求，中國移動通信有限公司93GPP TS26.233 Transpa

7、rent end-to-end packet switched streaming service (PSS); General description 103GPP TS26.234 Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs113GPP TS26.244 Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)12IETF RFC 2326: Real

8、 Time Streaming Protocol (RTSP) 13IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications14IETF RFC2616: HTTP 1.1: Hypertext Transfer Protocol15IETF RFC2327:SDP: Session Description Protocol3 相關(guān)術(shù)語在本規(guī)范中使用了“必須”、“推薦”、和“可選”等詞匯來描述對移動終端產(chǎn)品要求的強(qiáng)調(diào)程度?！氨仨殹表?xiàng)是指終端產(chǎn)品所必須提供的功能或性能要求； “推薦”項(xiàng)是指在標(biāo)準(zhǔn)中未作硬性要求，但建議終

9、端產(chǎn)品提供的功能或性能要求； “可選”項(xiàng)指在目前看來是中國移動需求的發(fā)展方向，或終端產(chǎn)品在目前階段可不提供的功能或性能要求。目前階段：從本版本發(fā)布之日截至到下一個版本發(fā)布日期。規(guī)范中除了明確指明為 “推薦”、“可選”外，均為必須要求。4 符號和縮略語3GP3GPP file formatAACAdvanced Audio Coding FBS Free Buffer SpaceGBWGuaranteed BandwidthHTMLHyper Text Markup LanguageMIMEMultipurpose Internet Mail ExtensionsMMSMultimedia Me

10、ssaging ServiceMBWMaximum BandwidthMTD Maximum transfer delay NSN Next ADU Sequence NumberNUN Next ADU decoded Unit NumberPSSPacket-switched Streaming ServiceQCIFQuarter Common Intermediate FormatRTCPRTP Control ProtocolRTPReal-time Transport ProtocolRTSPReal-Time Streaming ProtocolSDPSession Descri

11、ption ProtocolSMILSynchronised Multimedia Integration LanguageUAProfUser Agent Profile編號：時間：2021年x月x日書山有路勤為徑，學(xué)海無涯苦作舟頁碼：第34頁 共40頁5 概述5.1 目的流媒體與音視頻下載業(yè)務(wù)是基于相關(guān)國際標(biāo)準(zhǔn)的移動數(shù)據(jù)增值業(yè)務(wù)，終端應(yīng)基于業(yè)界開放式標(biāo)準(zhǔn)，包括網(wǎng)絡(luò)協(xié)議、媒體格式，體現(xiàn)良好的擴(kuò)展性和互操作能力?；诖嗽瓌t本規(guī)范規(guī)定了流媒體與音視頻下載業(yè)務(wù)的終端產(chǎn)品應(yīng)滿足的要求。5.2 業(yè)務(wù)簡介1、 流媒體終端播放器實(shí)時從流媒體服務(wù)器上獲取流媒體數(shù)據(jù)，邊下載邊播放，流媒體內(nèi)容不在終端設(shè)備上存儲

12、。如果同一內(nèi)容需要多次重復(fù)播放，需要每次播放時從流媒體服務(wù)器上重新下載數(shù)據(jù)。根據(jù)流媒體內(nèi)容的來源，流媒體業(yè)務(wù)可分為點(diǎn)播和直播兩種： 流媒體點(diǎn)播內(nèi)容提供者預(yù)先對一段多媒體內(nèi)容進(jìn)行編輯、壓縮編碼，形成指定格式的文件，然后上傳到流媒體服務(wù)器上。用戶根據(jù)需要選擇流媒體服務(wù)器上的內(nèi)容文件進(jìn)行播放。 流媒體直播終端播放器播放流媒體直播內(nèi)容時，內(nèi)容的播放時刻與內(nèi)容源事件的發(fā)生時刻相同，即流媒體編碼服務(wù)器對內(nèi)容源進(jìn)行實(shí)時地壓縮編碼，經(jīng)由流媒體服務(wù)器發(fā)送到用戶終端。2、 音視頻下載音視頻片斷下載業(yè)務(wù)的內(nèi)容提供者對內(nèi)容源文件進(jìn)行編輯編碼形成指定格式的文件，并將文件上傳至服務(wù)器。終端用戶將整個媒體文件全部下載到終端

13、。用戶點(diǎn)擊播放鍵，終端開始播放。流媒體與音視頻下載系統(tǒng)的體系結(jié)構(gòu)如圖5-1所示。圖5-1 中國移動流媒體業(yè)務(wù)系統(tǒng)結(jié)構(gòu)本圖以單點(diǎn)組網(wǎng)為例，其中移動流媒體業(yè)務(wù)平臺由業(yè)務(wù)門戶、內(nèi)容管理系統(tǒng)、業(yè)務(wù)管理平臺、流媒體服務(wù)器、下載服務(wù)器、計費(fèi)單元、編碼器等模塊組成。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 流媒體直播/點(diǎn)播業(yè)務(wù)終端要求支持通過下列方式發(fā)起流媒體業(yè)務(wù)： 通過WAP/HTTP瀏覽發(fā)起流媒體業(yè)務(wù)（必選） 通過SMS信息中的HTTP/RTSP鏈接發(fā)起

14、流媒體業(yè)務(wù)（必選） 通過WAP PUSH信息中的HTTP/RTSP鏈接發(fā)起流媒體業(yè)務(wù)（必選） 通過MMS信息中的HTTP/RTSP鏈接發(fā)起流媒體業(yè)務(wù)（可選） 通過播放器直接進(jìn)入門戶/頻道瀏覽，再發(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ù)操作的要求 對于流媒體點(diǎn)播，終端必須提供播放、暫停、繼

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

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

17、支持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ù)終端定時的反饋信息分配當(dāng)前可用的數(shù)據(jù)流。要求終端遵循3GPP 26.234 V6.1.0第10節(jié)中動態(tài)碼率適配功能的要求，支持3GPP 26.244 V6.1.0定義的文件格式。動態(tài)碼率適配的消息流程如圖6-1所示。流媒體服務(wù)器10. RTSP: SET_PARAME

18、TER/OPTIONS（攜帶3GPP-Link-Char/Bandwidth/3GPP-Adaptation）8. RTCP（包括RR、SDES、NADU等）12. RTSP: 200 OK4. RTSP: 200 OK（報頭攜帶3GPP-Adaptation）7. RTP: Audio/Video3. RTSP: SETUP（報頭攜帶3GPP-Adaptation）5. RTSP: PLAY播放器11. RTSP: TEARDOWN1. RTSP: DESCRIBE2. RTSP: 200 OK （SDP中攜帶3GPP-Adaptation-Support）6. RTSP: 200 OK9.

19、 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ù)包的上報頻率。當(dāng)該字段為0，表示不支持多碼率；為1，表示每個RR數(shù)據(jù)包中就有一個NADU；為2，表示每2個RR數(shù)據(jù)包有一個NADU。服務(wù)器在多碼率媒體流的SDP文件中除了包含a=3GPP-Adaptation-Sup

20、port字段外，必須支持a=alt-group:BW:AS、a=alt-default-id、a=alt等與多碼率文件相對應(yīng)的字段，參見附錄B。）3）播放器發(fā)起SETUP消息；播放器必須支持在該消息中上報3GPP-Adaptation報頭信息，具體字段的格式要求為 必須攜帶媒體鏈接（url）、終端緩沖區(qū)大?。╯ize）和緩沖區(qū)的目標(biāo)保護(hù)時間（target-time）屬性參數(shù)，參數(shù)之間用分號分隔，不能加入空格等其他分隔符； url鏈接必須加引號；3GPP-Adaptation報頭格式示例如下：3GPP-Adaptation:url=rtsp:/播放器可以在SETUP消息中上報3GPP-Link-

21、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=3004）服務(wù)器響應(yīng)SETUP請求，返回200 OK消息，對3GPP-Adaptation字段進(jìn)行原樣回復(fù)。播放器必須支持服務(wù)器在響應(yīng)SETUP的200 OK消息中對3GPP-Adaptation字段的原樣回復(fù)。5）播放器向服務(wù)器發(fā)起PLAY播放請求。播放器可以在PLAY消息中上報3GPP-Adapt

22、ation，通知服務(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)，選擇準(zhǔn)備播放的音視頻流，并將streamid通知播放器。RTP-Info: url=rtsp:/192.168.20.31/muti/apH263mnew.3gp/streamid=0;seq=0;rtptime=0, url=rtsp:/

23、192.168.20.31/muti/apH263mnew.3gp/streamid=6;seq=0;rtptime=07）服務(wù)器開始向播放器下發(fā)媒體流。8）播放器必須在媒體流播放過程中周期性向服務(wù)器上報RR/SDES/NADU APP的RTCP數(shù)據(jù)包。RR和NADU APP必須包括7.2.7節(jié)中要求的字段。9）服務(wù)器繼續(xù)向播放器下發(fā)媒體流。10）播放器在流媒體會話過程中根據(jù)應(yīng)用層和無線鏈路的變化向服務(wù)器發(fā)起OPTIONS或SET_PARAMETER消息；（可選）播放器可以在OPTIONS或SET_PARAMETER消息中上報3GPP-Adaptation，在流媒體會話過程中對終端緩沖區(qū)的目標(biāo)

24、保護(hù)時間（target-time）進(jìn)行動態(tài)調(diào)整，但是緩沖區(qū)大?。╯ize）是不能改變的。示例參見附錄C。（可選）播放器可以在OPTIONS或SET_PARAMETER消息中上報3GPP-Link-Char和Bandwidth，通知服務(wù)器無線鏈路的動態(tài)狀態(tài)。（可選）11）播放器正常播放完成、用戶主動中止播放或主動關(guān)閉播放器時，播放器必須向服務(wù)器發(fā)出TEARDOWN請求；12）服務(wù)器返回200 OK消息。6.5 參數(shù)配置要求要求終端出廠預(yù)置以下參數(shù)，必須支持通過手動方式修改。6.5.1 系統(tǒng)默認(rèn)參數(shù)6.5.1.1 瀏覽器的參數(shù)終端瀏覽器的參數(shù)設(shè)置參見中國移動WAP業(yè)務(wù)終端技術(shù)規(guī)范。APN：CMWA

25、P6.5.1.2 播放器的參數(shù)l 緩存設(shè)置 初始緩沖大?。ㄍ扑]支持）l 播放設(shè)置 循環(huán)播放（只針對本地回放，推薦支持）l 網(wǎng)絡(luò)設(shè)置 APN：CMWAP RTP/RTCP最低端口號、最高端口號： 代理設(shè)置：是否使用代理：否代理的IP地址和端口：空 超時時間：終端不允許提供連接超時的設(shè)置。 帶寬設(shè)置：終端不允許提供帶寬限制的設(shè)置。6.5.2 用戶可配置參數(shù) 用戶可以在流媒體播放器中添加、編輯書簽（可選） 用戶可以改變顯示大小，在全屏和標(biāo)準(zhǔn)屏幕間切換（可選，全屏顯示為可選功能） 用戶可以選擇單聲道或者立體聲輸出（可選，立體聲輸出為可選功能） 用戶可以選擇使用揚(yáng)聲器或者耳機(jī) 用戶可以在瀏覽器和播放器中

26、輸入HTTP URL。7 接口要求7.1 協(xié)議要求視頻音頻語音鏈路狀態(tài)報告能力交換場景描述靜態(tài)圖像位圖矢量圖文本同步文本合成音頻控制消息會話描述（SDP）有效載荷格式HTTPRTSPRTP/RTCPUDPTCPUDPIP圖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是用來標(biāo)記傳輸?shù)奈募愋?，在流媒體中主要用于播放

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

28、塞控制。在RTP會話期間，各參與者周期性地傳送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消息選項(xiàng)參見7.2.7。SDP：會話描述協(xié)議會話描述協(xié)議是一種用于會話描述的格式（協(xié)議），并不是一個傳輸協(xié)議，也不包含在媒體的編解碼之中，而是用于在不同傳輸協(xié)議之間傳遞消息的通知協(xié)議，其主要目的是解決多媒體會話通知、邀請和會話初始化工作。SDP文件既可以通過對用戶HTT

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

30、容播放和連接中止。圖7-2給出了基于RTSP/RTP的流媒體業(yè)務(wù)流程。2、HTTP: Get SDPHTTP: 200 OK with SDPRTCPRTSP: 200 OKRTSP: 200 OK6、RTP: Audio/Video4、RTSP: SETUP5、RTSP: PLAYHTTP : 200 OK終端流媒體門戶流媒體服務(wù)器1、HTTP : Get with User Agent7、RTSP: TEARDOWN3、RTSP: DESCRIBERTSP: 200 OK RTSP: 200 OK圖7-2 基于RTSP/RTP的流媒體業(yè)務(wù)流程 內(nèi)容發(fā)現(xiàn)用戶點(diǎn)擊門戶上某一流媒體內(nèi)容，瀏覽器向

31、門戶發(fā)起HTTP Get命令（含User Agent）。如果瀏覽器通過HTTP 200 OK響應(yīng)消息，從流媒體門戶上獲得流媒體內(nèi)容的RTSP鏈接，用戶點(diǎn)擊該鏈接，終端必須自動激活播放器。（步驟1步驟3）如果瀏覽器通過HTTP 200 OK響應(yīng)消息，從流媒體門戶上獲得SDP文件的HTTP鏈接，用戶點(diǎn)擊該鏈接，向流媒體服務(wù)器請求SDP文件。服務(wù)器返回SDP文件，獲得流媒體內(nèi)容的RTSP鏈接，終端必須自動激活播放器。（步驟1步驟2）對于返回的流媒體內(nèi)容RTSP鏈接，要求終端不能顯示、存儲服務(wù)器返回的流媒體內(nèi)容RTSP鏈接地址。 連接建立 獲取會話描述信息 （DESCRIBE）播放器通過RTSP的DE

32、SCRIBE命令請求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消息中必須包括會話標(biāo)識、播放器的傳輸協(xié)議（RTP）端口號。媒體服務(wù)器正確接到此信息后提供響應(yīng)服務(wù)器的RTP端口號，最終完成RTP端口的動態(tài)協(xié)商。（步驟4） 內(nèi)容播放(PLAY)播

33、放器向服務(wù)器端發(fā)出RTSP中的播放命令，PLAY消息中必須包含會話標(biāo)識、時間起始點(diǎn)、媒體服務(wù)器會話標(biāo)識和媒體播放時間。媒體服務(wù)器通過RTP向播放器傳送媒體內(nèi)容。（步驟5步驟6） 中止(TEARDOWN)媒體正常播放完成后、用戶主動中止播放或主動關(guān)閉播放器時（不包括用戶暫停播放），播放器都必須向服務(wù)器發(fā)出RTSP中止命令，包括會話標(biāo)識等信息，服務(wù)器端接到后做出200 OK響應(yīng)。（步驟7）2、音視頻下載業(yè)務(wù)目前存在基于WAP方式和基于OMA Download兩種方式。a） 基于WAP方式要求終端遵循中國移動WAP2.0終端規(guī)范?；赪AP方式的音視頻下載業(yè)務(wù)，由于終端不能向系統(tǒng)返回狀態(tài)報告，因此系

34、統(tǒng)無法獲知文件是否已成功下載到終端。b） 基于OMA Download方式對于3G終端，必須支持OMA Download 1.0的要求，終端成功接收到音視頻文件后，必須向下載服務(wù)器發(fā)送狀態(tài)報告。對于2G終端，OMA Download是推薦功能，二階段是必選功能。在終端上的操作主要有三個階段：下載請求，文件獲取請求，狀態(tài)報告。圖7-3給出了基于OMA Download方式的音視頻下載業(yè)務(wù)流程圖。圖 7-3 基于OMA Download方式的音視頻下載業(yè)務(wù)流程圖 下載請求終端向下載服務(wù)器發(fā)起音視頻下載請求，服務(wù)器向終端返回下載描述符。 文件獲取請求終端向下載服務(wù)器發(fā)送文件獲取請求，服務(wù)器向終端返回

35、音視頻文件。 狀態(tài)報告終端成功接收到音視頻文件后，必須向下載服務(wù)器發(fā)送狀態(tài)報告，下載服務(wù)器生成計費(fèi)話單。7.2.1 RTSP協(xié)議消息要求表 7-1 RTSP協(xié)議消息選項(xiàng)消息解釋CMCC要求備注OPTIONS詢問支持的RTSP消息推薦SETUP建立連接必選DESCRIBE媒體文件的描述必選PLAY開始播放，回放必選RECORD錄制功能可選不允許終端提供錄制功能的界面REDIRECT讓播放器重定向到服務(wù)器推薦PAUSE暫停并保持必選GET_PARAMETER服務(wù)器請求獲取參數(shù)可選SET_PARAMETER播放器設(shè)置參數(shù)推薦TEARDOWN中止必選7.2.2 RTSP報頭要求表 7-2 RTSP報頭

36、選項(xiàng)消息報頭CMCC要求備注DESCRIBE ReqCseq必選Blocksize可選Accept必選User-Agent必選應(yīng)攜帶流媒體播放器軟件以及相關(guān)屬性信息x-wap-profile必選應(yīng)攜帶終端的RDF文件的URI信息Content-Encoding必選Content-Language必選DESCRIBE RespCseq必選Date必選Content-Length必選Content-Type必選Unsupported條件必選有不支持的RTSP消息時必須攜帶SETUP ReqCseq必選Blocksize可選Transport必選（RTP/AVP/UDP,unicast,client

37、_port）User-Agent必選3GPP-Adaptation條件必選如果終端支持動態(tài)碼率適配；（url;size;target-time ）3GPP-Link-Char推薦SETUP RespCSeq必選Transport必選（RTP/AVP/UDP;unicast;client_port; server_port）3GPP-Adaptation必選回復(fù)setup-req中的3GPP-AdaptationSession必選Date必選Unsupported條件必選有不支持的RTSP消息時必須攜帶PLAY ReqCseq必選Bandwidth推薦Range必選Session必選User-A

38、gent必選3GPP-Link-Char推薦3GPP-Adaptation可選PLAY RespCseq必選Session必選Range必選RTP-Info必選Date必選3GPP-Adaptation條件必選如果播放器在PLAY中攜帶3gpp-Adaptation字段，服務(wù)器能夠在PLAY resp中回復(fù)該字段。PAUSE ReqCseq必選Session必選User-Agent必選PAUSE RespCseq必選Session必選Date必選TEARDOWN ReqCseq必選Session必選User-Agent必選TEARDOWN RespCseq必選Session必選Date必選消息

39、報頭CMCC要求備注SET PARAMETER ReqCseq必選Session條件必選在SETUP之后的SET PARAMETER Req必須攜帶該參數(shù)User-Agent必選3GPP-Adaptation可選Content-Encoding必選Content-Length必選Content-Type必選Bandwidth推薦終端在SET PARAMETER req消息中攜帶，指明終端當(dāng)前的可用帶寬。3GPP-Link-Char推薦SET PARAMETER RespCseq 必選Session必選Unsupported條件必選有不支持的RTSP消息時必須攜帶3GPP-Adaptation條

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

41、務(wù)器應(yīng)該能夠在resp中回復(fù)該字段。注： 類型“Req”表示應(yīng)用于請求消息中；類型“Resp”表示應(yīng)用于響應(yīng)消息中；“條件必選”表示在某一條件下該參數(shù)必須支持。7.2.3 SDP參數(shù)要求表 7-3 SDP參數(shù)項(xiàng)參數(shù)解釋CMCC要求具體的參數(shù)VProtocol version必選0OOwner/creator and session identifier必選o=- 1084091316 1084091316 IN IP4 10.199.2.103SSession name必選EESISession information必選Author and copyrightCConnection Info

42、rmation必選HUSm ip addressBBandwidth information必選AS:81TTime the session is active必選0 0(starttime,endtime)Asdpplugin可選SdpplinVersion:1610641560Acontrol必選control:*Arange必選range-npt=0-179.263000AAlt-group條件必選如果是多碼率文件，該字段必選BW:AS:28=1,3;56=1,4;60=2,4;120=2,5注：該字段為session級字段MMedia name and transport addres

43、s必選video 0 RTP/AVP 96BBandwidth information必選AS:64BBandwidth information必選RR:2399BBandwidth information必選RS:799Acontrol必選control:streamid=0Arange必選range:npt=0-59.960000Alength可選length:npt =59.960000Artpmap必選rtpmap:96 MP4V-ES/90000Afmtp必選fmtp:96 profile-level-id=1;config=000001B0F3000001B50EE040C0CF0

44、000010000000120008440FA282C2090A21FAX-predecbufsize可選AX-initpredecbufperiod可選AX-initpostdecbufperiod可選AX-decbyterate可選Aalt條件必選如果是多碼率文件Aalt-default-id條件必選如果是多碼率文件A3GPP-Adaptation-Support條件必選如果是多碼率文件MMedia name and transport address必選audio 0 RTP/AVP 97BBandwidth information必選AS:17BBandwidth informatio

45、n必選RR:618BBandwidth information必選RS:206Acontrol必選control:streamid=1Arange必選range:npt=0-59.960000Alength可選length:npt=59.960000Artpmap必選rtpmap:97 mpeg4-generic/16000/1Afmtp必選fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1408AX-predecbufsize可選AX-initprede

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

47、applicationSDP.sdp必選SMIL.smil二階段要求audioAMR.amr必選AMR-WB.amr可選MP4A-LATM.aac推薦3gpp.3gp必選videoH263-2000.3gp必選H264.3gp推薦3gpp.3gp必選7.2.5 URL參數(shù)要求7.2.5.1 下載URL及參數(shù)選項(xiàng)定義終端要求支持的下載URL格式：http:/:/和http:/:/?字符串字符串示例：&key=keyvalue其中“？”之前的各參數(shù)含義如下：參數(shù)含義host下載服務(wù)器域名或IP地址port下載服務(wù)器端口號path內(nèi)容路徑filename文件名WAP下載：要求終端必須從WAP頁面中提

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

49、端必須從WAP頁面中提取完整的RTSP鏈接，并通過RSTP消息發(fā)送給服務(wù)器。7.2.5.3 URL中參數(shù)缺省的情況對于下載、直播、點(diǎn)播業(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ā)給門戶，必須包括終端型號、軟件版本，推薦包

50、括播放器名稱和版本信息，必須符合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.02、在與流媒體服務(wù)器交互過程中，要求播放器在RTSP消息的報頭攜帶User Agent，包括播放器的基本信息，必須符合RFC

51、2616的定義，其格式必須符合“播放器名稱/版本”舉例如下：User-Agent：RealMedia Player/10.0.0.07.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)標(biāo)識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達(dá)會話控制信息的功能。 BYE：通知離開，主要功能是通知會話中的其他成員自己將退出會話。 APP：

52、由應(yīng)用程序自己定義，主要解決RTCP的擴(kuò)展性問題。發(fā)送媒體流的源端將周期性地產(chǎn)生發(fā)送端報告SR，該RTCP數(shù)據(jù)報含有不同媒體流間的同步信息，以及已經(jīng)發(fā)送的數(shù)據(jù)報和字節(jié)的計數(shù)，接收端根據(jù)這些信息可以估計出實(shí)際的數(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)整應(yīng)用程序的服務(wù)質(zhì)量。類似于RTP數(shù)據(jù)包，每個RTCP包以固定部分開始，緊接著的是可變

53、長結(jié)構(gòu)元素，但以一個32位邊界結(jié)束。(1) SR0 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 | length | header+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SSRC of sender |+=+=+=+=+=+=+=+=+

54、=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| NTP timestamp, most significant word | sender+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info| NTP timestamp, least significant word |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RTP timestamp |+-+-+-+-+-+-

55、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| senders packet count |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| senders octet count |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC_1 (SSRC of first source) | report+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

56、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block| fraction lost | cumulative number of packets lost | 1-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| extended highest sequence number received |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| interarrival jitter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| last SR (LSR)