【正文】 口要求、性能要求等，是有限公司開(kāi)展流媒體單播與音視頻下載業(yè)務(wù)的依據(jù)之一，不包括多播組播業(yè)務(wù)。本標(biāo)準(zhǔn)的附錄 AD 為資料性附錄。本標(biāo)準(zhǔn)主要起草人：朱春梅、張炎、唐劍峰。2 引用標(biāo)準(zhǔn)下列標(biāo)準(zhǔn)所包含的條文，通過(guò)在本標(biāo)準(zhǔn)中引用而成為本標(biāo)準(zhǔn)的條文。 General description [10] 3GPP Transparent endtoend Packetswitched Streaming Service (PSS)。目前階段：從本版本發(fā)布之日截至到下一個(gè)版本發(fā)布日期。 業(yè)務(wù)簡(jiǎn)介 流媒體終端播放器實(shí)時(shí)從流媒體服務(wù)器上獲取流媒體數(shù)據(jù)，邊下載邊播放，流媒體內(nèi)容不在終端設(shè)備上存儲(chǔ)。? 流媒體直播終端播放器播放流媒體直播內(nèi)容時(shí)，內(nèi)容的播放時(shí)刻與內(nèi)容源事件的發(fā)生時(shí)刻相同，即流媒體編碼服務(wù)器對(duì)內(nèi)容源進(jìn)行實(shí)時(shí)地壓縮編碼，經(jīng)由流媒體服務(wù)器發(fā)送到用戶終端。流媒體與音視頻下載系統(tǒng)的體系結(jié)構(gòu)如圖51所示。推薦快進(jìn)、后退的步長(zhǎng)為 1 秒。? 在流媒體播放過(guò)程中，若當(dāng)前速率不能滿足流媒體播放時(shí)，終端必須自動(dòng)暫停播放并對(duì)媒體內(nèi)容進(jìn)行緩存，在收到足夠信息后繼續(xù)播放。 （可選）? 播放器關(guān)閉后，終端必須退回瀏覽器界面。終端必須支持 profile0 level10，推薦支持 (AVC) Baseline Profile Level 1b， profile3 level10 為可選要求。要求終端遵循3GPP ，支持3GPP 的文件格式。當(dāng)該字段為0，表示不支持多碼率；為1，表示每個(gè)RR數(shù)據(jù)包中就有一個(gè)NADU；為2，表示每2個(gè)RR數(shù)據(jù)包有一個(gè)NADU。 MBW=0。播放器可以在PLAY消息中上報(bào)3GPPAdaptation，通知服務(wù)器動(dòng)態(tài)碼率適配的初始參數(shù)，格式要求同SETUP消息中該字段要求。RTPInfo: url= url=7）服務(wù)器開(kāi)始向播放器下發(fā)媒體流。10）播放器在流媒體會(huì)話過(guò)程中根據(jù)應(yīng)用層和無(wú)線鏈路的變化向服務(wù)器發(fā)起OPTIONS或SET_PARAMETER消息；（可選）播放器可以在OPTIONS或SET_PARAMETER消息中上報(bào)3GPPAdaptation，在流媒體會(huì)話過(guò)程中對(duì)終端緩沖區(qū)的目標(biāo)保護(hù)時(shí)間（targettime）進(jìn)行動(dòng)態(tài)調(diào)整，但是緩沖區(qū)大?。╯ize）是不能改變的。 參數(shù)配置要求要求終端出廠預(yù)置以下參數(shù)，必須支持通過(guò)手動(dòng)方式修改。 用戶可配置參數(shù)? 用戶可以在流媒體播放器中添加、編輯書(shū)簽（可選） ? 用戶可以改變顯示大小，在全屏和標(biāo)準(zhǔn)屏幕間切換（可選，全屏顯示為可選功能）? 用戶可以選擇單聲道或者立體聲輸出（可選，立體聲輸出為可選功能）? 用戶可以選擇使用揚(yáng)聲器或者耳機(jī)? 用戶可以在瀏覽器和播放器中輸入 HTTP URL。MIME是用來(lái)標(biāo)記傳輸?shù)奈募愋?，在流媒體中主要用于播放器的啟動(dòng)。RTP 協(xié)議要求符合RFC3550 和3GPP TS 。 RTCP協(xié)議要求符合RFC3550和3GPP TS ，其中 。 終端與服務(wù)器的交互消息要求點(diǎn)播、直播類業(yè)務(wù)終端到服務(wù)器的信息交互存在基于 RTSP/RTP 和基于 HTTP（Progressive download）兩種方式，其中基于 HTTP 的漸進(jìn)式下載（Progressive download）屬于可選要求。RTCPRTSP: 200 OKRTSP: 200 OKRTP: Audio/VideoRTSP: SETUPRTSP: PLAYHTTP : 200 OK終端 流媒體門(mén)戶 流媒體服務(wù)器HTTP : Get with User AgentRTSP: TEARDOWNRTSP: DESCRIBERTSP: 200 OK RTSP: 200 OK圖 72 基于 RTSP/RTP的流媒體業(yè)務(wù)流程? 內(nèi)容發(fā)現(xiàn)用戶點(diǎn)擊門(mén)戶上某一流媒體內(nèi)容，瀏覽器向門(mén)戶發(fā)起 HTTP Get 命令（含 User Agent）。（ 步驟 1－步驟 2）對(duì)于返回的流媒體內(nèi)容 RTSP 鏈接，要求終端不能顯示、存儲(chǔ)服務(wù)器返回的流媒體內(nèi)容RTSP 鏈接地址。媒體服務(wù)器正確接到此信息后提供響應(yīng)服務(wù)器的 RTP 端口號(hào)，最終完成 RTP 端口的動(dòng)態(tài)協(xié)商。 （步驟 7）音視頻下載業(yè)務(wù)目前存在基于WAP方式和基于 OMA Download兩種方式。對(duì)于 2G 終端，OMA Download 是推薦功能，二階段是必選功能。? 文件獲取請(qǐng)求終端向下載服務(wù)器發(fā)送文件獲取請(qǐng)求，服務(wù)器向終端返回音視頻文件。targettime ）3GPPLinkChar 推薦SETUP Resp CSeq 必選Transport 必選 （RTP/AVP/UDP。PAUSE Req Cseq 必選Session 必選UserAgent 必選PAUSE Resp Cseq 必選Session 必選Date 必選TEARDOWN Req Cseq 必選Session 必選UserAgent 必選TEARDOWN Resp Cseq 必選Session 必選Date 必選13 / 39注： 類型“Req”表示應(yīng)用于請(qǐng)求消息中；類型“Resp”表示應(yīng)用于響應(yīng)消息中；“條件必選”表示在某一條件下該參數(shù)必須支持。3GPPAdaptation 可選OPTIONS Resp Cseq 必選Session 必選Unsupported 條件必選 有不支持的 RTSP 消息時(shí)必須攜帶Public 必選3GPPAdaptation 條件必選 如果播放器在 OPTIONS 中攜帶 3gppAdaptation 字段， 服務(wù)器應(yīng)該能夠在 resp中回復(fù)該字段。120=2,5注：該字段為 session 級(jí)字段M Media name and transport address 必選 video 0 RTP/AVP 96B Bandwidth information 必選 AS:64B Bandwidth information 必選 RR:2399B Bandwidth information 必選 RS:799A control 必選 control:streamid=0A range 必選 range:npt=A length 可選 length:npt =A rtpmap 必選 rtpmap:96 MP4VES/90000A fmtp 必選fmtp:96 profilelevelid=1。indexlength=3。2. 終端必須可以通過(guò) I 參數(shù)獲取片源的作者和版本信息，并提供給用戶訪問(wèn)。paramN=valueNamp?！璦mp。 URL中參數(shù)缺省的情況對(duì)于下載、直播、點(diǎn)播業(yè)務(wù)，無(wú)論從服務(wù)器端傳下來(lái)的 URL“？”之后的參數(shù)是否缺省，播放器都應(yīng)正常播放，如果某些需要顯示給用戶的參數(shù)無(wú)法獲得，則顯示為空。舉例如下：User Agent：Nokia7650/ SymbianOS/ Series60/ Release/ Browser/ Profile/ Configuration/在與流媒體服務(wù)器交互過(guò)程中，要求播放器在 RTSP 消息的報(bào)頭攜帶 User Agent，包括播放器的基本信息，必須符合 RFC2616 的定義，其格式必須符合“播放器名稱/版本”舉例如下：UserAgent：RealMedia Player/ RTCP協(xié)議消息要求RTCP 協(xié)議消息有如下幾種類型，詳見(jiàn) RFC 3550 和 RFC 3551：SR：發(fā)送端報(bào)告，所謂發(fā)送端是指發(fā)出 RTP 數(shù)據(jù)報(bào)的源端，發(fā)送端同時(shí)也可以是接收端。 APP：由應(yīng)用程序自己定義，主要解決 RTCP 的擴(kuò)展性問(wèn)題。(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 |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| NTP timestamp, most significant word | sender+++++++++++++++++++++++++++++++++ info| NTP timestamp, least significant word |+++++++++++++++++++++++++++++++++| RTP timestamp |+++++++++++++++++++++++++++++++++| sender39。s packet count 必選 必選sender39。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=RR=201 | length | header+++++++++++++++++++++++++++++++++| SSRC of packet sender |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC_1 (SSRC of first source) | report+++++++++++++++++++++++++++++++++ block| fraction lost | cumulative number of packets lost | 1+++++++++++++++++++++++++++++++++| extended highest sequence number received |+++++++++++++++++++++++++++++++++| interarrival jitter |+++++++++++++++++++++++++++++++++20 / 39| last SR (LSR) |+++++++++++++++++++++++++++++++++| delay since last SR (DLSR) |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| SSRC_2 (SSRC of second source) | report+++++++++++++++++++++++++++++++++ block: ... : 2+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| profilespecific extensions