中國移動(dòng)彩信業(yè)務(wù)管理要求

1、-實(shí)施-發(fā)布中國移動(dòng)通信有限公司 發(fā)布QB-中國移動(dòng)通信企業(yè)標(biāo)準(zhǔn)中國移動(dòng)彩信業(yè)務(wù)終端規(guī)范China Mobile MMS Service Terminal Specification版本號(hào)： V2.2.1前言本規(guī)范規(guī)定了彩信業(yè)務(wù)在終端部分的要求，是開展彩信業(yè)務(wù)的依據(jù)之一。本規(guī)范主要包括以下幾方面內(nèi)容:彩信終端的彩信處理能力、參數(shù)內(nèi)置、發(fā)送接收流程、異常處理、性能要求等等。附錄A、附錄B均為資料性附錄。本規(guī)范由中國移動(dòng)通信有限公司技術(shù)部歸口管理。本規(guī)范由歸口部門負(fù)責(zé)解釋。本規(guī)范起草單位：中國移動(dòng)通信研究院本標(biāo)準(zhǔn)主要起草人：常嘉岳、鄭冬冬目錄1適用范圍12引用標(biāo)準(zhǔn)23相關(guān)術(shù)語34符號(hào)和縮略語解釋4

2、5概述65.1目的65.2業(yè)務(wù)簡介65.3多媒體消息業(yè)務(wù)環(huán)境75.4以MMSC為中心的多媒體消息系統(tǒng)結(jié)構(gòu)86功能要求96.1參數(shù)預(yù)置96.1.1彩信承載參數(shù)96.1.2彩信發(fā)送參數(shù)默認(rèn)值96.1.3彩信接收參數(shù)默認(rèn)值106.2地址106.3彩信的處理能力106.4彩信在移動(dòng)終端上的操作106.4.1編輯116.4.2發(fā)送116.4.3接收126.4.4彩信管理137多媒體格式要求157.1文字157.2音頻157.3圖像157.4視頻157.5對(duì)不支持的內(nèi)容格式處理157.6對(duì)每一頁彩信大小的要求158SMIL的格式要求178.1SMIL的封裝178.1.1MMS header178.1.2M

3、MS Body178.2MMS SMIL188.2.1元素和屬性188.2.2元素和屬性的可選必選性如下表：218.3對(duì)發(fā)送SMIL文件的要求228.4對(duì)接收SMIL文件的要求229接口要求239.1彩信終端發(fā)送彩信到MMSC239.1.1正常操作239.1.2異常操作249.1.3信息單元259.2彩信中心發(fā)送notification消息到彩信終端269.2.1正常操作279.2.2異常操作279.2.3信息單元299.3彩信終端從彩信中心提取彩信309.3.1正常操作319.3.2異常操作329.3.3信息單元339.4發(fā)送報(bào)告359.4.1正常操作359.4.2信息單元3610彩信終端有

4、關(guān)WAP協(xié)議的要求3710.1WAP協(xié)議支持的版本3710.2用戶代理（User Agent)3710.3用戶代理檔案 （UA Profile）3711網(wǎng)絡(luò)的兼容性要求3712硬件要求3712.1處理能力3713編制歷史38附錄A： SMIL的例子39附錄B：彩信終端通信流程圖401 適用范圍本規(guī)范對(duì)彩信業(yè)務(wù)終端提出規(guī)定。本規(guī)范是彩信業(yè)務(wù)的參考依據(jù)，也是終端廠商彩信業(yè)務(wù)終端產(chǎn)品的研發(fā)、生產(chǎn)的參照依據(jù)。適用于GSM網(wǎng)絡(luò)、GPRS網(wǎng)絡(luò)以及3G網(wǎng)絡(luò)環(huán)境。2 引用標(biāo)準(zhǔn)下列規(guī)范包含的條文，通過在本規(guī)范中的引用而構(gòu)成為本要求的條文。在規(guī)范出版時(shí)，所示版本均為有效。所有標(biāo)準(zhǔn)都會(huì)被修訂，使用本規(guī)范的各方應(yīng)探討

5、使用下列標(biāo)準(zhǔn)最新版本的可能性。1 3G TS 22.140 V5.3.0 Multimedia Messaging Service Stage 1， (Release 5)2 3GPP TS 23.140 V6.0.0 Multimedia Messaging Service Stage 2, (Release 5)OMA-MMS-ARCH-V1_2-20030920-C3 OMA-MMS-CONF-V1_2-20030929-C4 OMA-MMS-CTR-V1_2-20030916-C5 OMA-MMS-ENC-V1_2-20030915-C6 中國移動(dòng)多媒體消息業(yè)務(wù)總體技術(shù)要求 v1.0.

6、3，中國移動(dòng)通信有限公司7 中國移動(dòng)多媒體業(yè)務(wù)接口規(guī)范v1.0.3，中國移動(dòng)通信有限公司8 中國移動(dòng)多媒體業(yè)務(wù)規(guī)范 v1.0.3，中國移動(dòng)通信有限公司9 IETF，RFC 2387：“The MIME Multipart/related content type", Levinson E., August 1998.” 10 IETF，RFC 2557：“ Encapsulation of Aggregate Documents, such as HTML (MHTML), Palme J., Hopmann A., Shelness N., March 1999 ”3 相關(guān)術(shù)語在本

7、規(guī)范中使用了“必須”、“推薦”、和“可選”等詞匯來描述對(duì)移動(dòng)終端產(chǎn)品要求的強(qiáng)調(diào)程度。“必須”項(xiàng)是指終端產(chǎn)品所必須提供的功能或性能要求； “推薦”項(xiàng)是指在標(biāo)準(zhǔn)中未作硬性要求，但建議終端產(chǎn)品提供的功能或性能要求； “可選”項(xiàng)指在目前看來是中國移動(dòng)需求的發(fā)展方向，或終端產(chǎn)品在目前階段可不提供的功能或性能要求。規(guī)范中除了明確指明為 “推薦”、“可選”外，均為必須要求。4 符號(hào)和縮略語解釋3GPPThird Generation Partnership ProjectAMRAdaptive Multi-RateAPNAccess Point NameCSDCircuit Switch Data Call

8、GPRSGeneral Packet Radio ServiceGIFGraphical Interchange FormatHTTPHyper Text Transport ProtocolIPInternet ProtocolJPEGJoint Picture Expert GroupMIDIMusical Instrument Digital Interface MIPSMillion Instructions Per SecondMMSMulti-media Message ServicesMMSE Multi-media Message Services EnvironmentMMM

9、ultimedia Message MMIMan Machine Interface.MSMobile StationMOMobile OrientedMTMobile TerminatedMSISDNMobile Station Integrated service Digital Number OTAOver-the-Air PIMPersonal Information ManagementPDP Packet Data ProtocolSARSegmentation Reassembly and ReassemblySMFStandard Midi FileSMILSynchroniz

10、ed Multimedia Integration LanguageSP-MIDIScalable Polyphonic MIDITCP/IPTransmission Control Protocol/Internet ProtocolUCS Universal Character SetURLUniform Resource Locater UTF-8Unicode Trans FormatWAPWireless Application ProtocolWBMPWireless Bit MapWSPWAP Session ProtocolWTPWAP Transport ProtocolWT

11、LSWireless Transportation Layer SecurityWSPWireless Session ProtocolWWWWorld Wide WebMMS Relay/Server：MMS業(yè)務(wù)提供商管理下的MMS特定網(wǎng)絡(luò)實(shí)體和應(yīng)用MMS用戶代理：常駐在UE、MS或外部設(shè)備上的應(yīng)用程序，代表用戶執(zhí)行MMS特定操作發(fā)送報(bào)告：由MMSRelay/Server提供給MM發(fā)方（MMS用戶代理或VASP），關(guān)于MM傳送狀態(tài)的反饋信息閱讀報(bào)告：由收方MMS用戶代理發(fā)送給發(fā)方MMS用戶代理的反饋信息，該信息是反映原MM在收方MMS用戶代理中的處理狀態(tài)5 概述5.1 目的彩信業(yè)務(wù)是基于3G

12、PP標(biāo)準(zhǔn)規(guī)范的新的移動(dòng)數(shù)據(jù)增值業(yè)務(wù)，開放性與標(biāo)準(zhǔn)化是彩信業(yè)務(wù)系統(tǒng)賴以生存發(fā)展的基礎(chǔ)。支持彩信業(yè)務(wù)的終端產(chǎn)品同樣符合這一原則，基于業(yè)界開放式標(biāo)準(zhǔn)，包括各種網(wǎng)絡(luò)協(xié)議、內(nèi)容格式，并且要體現(xiàn)良好的擴(kuò)展性和互操作能力?；诖嗽瓌t本規(guī)范規(guī)定了MMS業(yè)務(wù)的終端產(chǎn)品應(yīng)滿足的要求。5.2 業(yè)務(wù)簡介彩信業(yè)務(wù)是多媒體消息業(yè)務(wù)（Multimedia Message Service）在中國移動(dòng)市場推廣中的名稱，彩信業(yè)務(wù)可以像使用短消息一樣收發(fā)更加個(gè)性化的多媒體消息，如文本、圖形、圖像、音頻、視頻、動(dòng)畫、音樂等信息內(nèi)容，且不影響手機(jī)的正常通話。有人形容，多媒體消息的出現(xiàn)如同電腦多媒體技術(shù)的出現(xiàn)，使PC對(duì)于多數(shù)普通用戶而言

13、從高檔的打字機(jī)變成了娛樂、教育等方面的良好工具，電腦對(duì)于普通用戶的作用發(fā)生了質(zhì)的飛躍一樣，多媒體消息的出現(xiàn)，也使得手機(jī)從最主要通話功能，成為一種集普通話音通信、多媒體信息傳輸(移動(dòng)數(shù)據(jù)業(yè)務(wù))和處理于一身的新型個(gè)人數(shù)字終端，即不僅僅是一個(gè)通話工具，更應(yīng)該是一種電子消費(fèi)產(chǎn)品。 彩信業(yè)務(wù)雖然在給用戶的業(yè)務(wù)表現(xiàn)上類似于SMS業(yè)務(wù)，但在實(shí)際的實(shí)現(xiàn)方法上采用的是WAP事件的處理流程，由接收方主動(dòng)從MMSC取信息，相當(dāng)于WAP的瀏覽或下載方式，因此在網(wǎng)絡(luò)結(jié)構(gòu)和計(jì)費(fèi)模式上與SMS不同。5.3 多媒體消息業(yè)務(wù)環(huán)境圖4-1 多媒體消息業(yè)務(wù)環(huán)境MMSE ：多媒體消息業(yè)務(wù)環(huán)境MMSE 是實(shí)現(xiàn)MMS業(yè)務(wù)的一套獨(dú)立的和完

14、整的網(wǎng)絡(luò)元素的集合。MMS Relay/Server：MMS 中繼/服務(wù)器MMS 中繼/服務(wù)器負(fù)責(zé)存儲(chǔ)和處理輸入和輸出的消息，以及在不同多媒體消息系統(tǒng)之間傳送多媒體消息。MMS User Database：用戶數(shù)據(jù)庫MMS用戶數(shù)據(jù)庫包含所有MMS業(yè)務(wù)中與用戶相關(guān)的信息，例如業(yè)務(wù)定制信息，黑白名單信息等。MMS Useragent： 用戶代理MMS 用戶代理存在于彩信終端，向用戶提供查看、編寫和處理多媒體消息的功能。（例如，提交、接收刪除 MM）。MMS VAS Application：MMS增值應(yīng)用程序MMS VAS 應(yīng)用程序向 MMS 用戶提供增值業(yè)務(wù)。5.4 以MMSC為中心的多媒體消息系

15、統(tǒng)結(jié)構(gòu)多媒體消息系統(tǒng)在GSM/GPRS/3G網(wǎng)絡(luò)中的系統(tǒng)結(jié)構(gòu)如圖42 所示。MM2MM7MM6MM4MM3MM1接入服務(wù)器GSMGGSNGPRS短信中心MMS終端非MMS終端WAP網(wǎng)關(guān)MMS Relay/Server用戶數(shù)據(jù)庫外部服務(wù)器(例如 E-Mail)外部服務(wù)器外部服務(wù)器(例如 Voice Mail)IP 網(wǎng)IP網(wǎng)其它MMSC3GMM8計(jì)費(fèi)系統(tǒng)非MMS終端支撐應(yīng)用MMS增值應(yīng)用系統(tǒng)網(wǎng)管系統(tǒng)RelayServerMMS重定向器ENUM-DNS圖4-2 多媒體消息系統(tǒng)結(jié)構(gòu)圖多媒體消息系統(tǒng)包括以下網(wǎng)元：彩信終端、多媒體消息中心、MMS用戶數(shù)據(jù)庫、外部應(yīng)用服務(wù)器、增值應(yīng)用服務(wù)器以及非彩信終端處理

16、系統(tǒng)。此外，為配合多媒體消息平臺(tái)提供多媒體消息服務(wù)，需要WAP網(wǎng)關(guān)、GSM/GPRS網(wǎng)絡(luò)資源等設(shè)備的支持，還要和現(xiàn)網(wǎng)中的計(jì)費(fèi)系統(tǒng)、網(wǎng)管系統(tǒng)互聯(lián)。多媒體消息中心（MMSC）是整個(gè)多媒體消息系統(tǒng)的核心，它主要負(fù)責(zé)存儲(chǔ)并處理進(jìn)出MMSC的消息，完成在網(wǎng)絡(luò)上發(fā)送由文本、聲音、圖片及其他媒體格式組成的多媒體消息。MMSC 不但能夠完成終端到終端的業(yè)務(wù)需求，還能夠在終端和EMAIL系統(tǒng)以及外部增值應(yīng)用系統(tǒng)之間傳送消息并產(chǎn)生相應(yīng)的計(jì)費(fèi)信息記錄。為了保證滿足系統(tǒng)對(duì)容量和吞吐率的要求，多媒體信息中心應(yīng)當(dāng)能夠支持集群方案，使得進(jìn)入系統(tǒng)的多媒體消息可通過負(fù)載均衡由不同模塊處理，達(dá)到提高系統(tǒng)容量和高效利用資源的目的。

17、6 功能要求 6.1 參數(shù)預(yù)置6.1.1 彩信承載參數(shù)彩信終端必須可以進(jìn)行參數(shù)預(yù)置。設(shè)置包括：l MMS中心網(wǎng)址：;（出廠預(yù)置的網(wǎng)址的開始及結(jié)尾不能包括空格）l CSD方式：接入號(hào)碼17266, 用戶名 wap ; 密碼: wap （GSM和GPRS網(wǎng)絡(luò)終端適用）Wap 1.X的終端的設(shè)置： l GPRS方式： APN: cmwap; 用戶名: 空; 密碼: 空.l WAP網(wǎng)關(guān)地址：72l 端口號(hào)：9201WAP 2.0的終端的設(shè)置： l APN: cmwap; 用戶名: 空; 密碼: 空.l WAP網(wǎng)關(guān)地址：72l 端口號(hào)： 806.1.2 彩信發(fā)送參數(shù)默認(rèn)值

18、彩信終端發(fā)送參數(shù)默認(rèn)值：l 有效期：最長（如果有則設(shè)置）l 要求發(fā)送報(bào)告：否 （如果有則設(shè)置）l 要求閱讀報(bào)告：否（如果有則設(shè)置）6.1.3 彩信接收參數(shù)默認(rèn)值彩信終端接收參數(shù)默認(rèn)值：l 允許接收：是（如果有則設(shè)置）l 立即提?。涸诜锹螤顟B(tài)下不向用戶顯示該選項(xiàng)，該選項(xiàng)默認(rèn)為“是”；在漫游狀態(tài)，提示用戶處于漫游狀態(tài)，向用戶顯示該選項(xiàng)，并允許用戶設(shè)置, 該選項(xiàng)默認(rèn)為“是”。l 允許發(fā)送報(bào)告：否 （如果有則設(shè)置）l 允許發(fā)送閱讀報(bào)告：否（如果有則設(shè)置） 6.2 地址彩信終端必須允許最終用戶發(fā)送彩信到MSISDN（E164，例如8612345678） 和Email地址 （RFC822，例如：name

19、）6.3 彩信的處理能力· 彩信終端必須滿足至少發(fā)送300KB彩信的能力。（這里指彩信封裝后的大小，適用于3G網(wǎng)絡(luò)彩信終端適用）· 彩信終端必須滿足至少接收300KB彩信的能力。（這里指彩信封裝后的大小，適用于3G網(wǎng)絡(luò)彩信終端）· 彩信終端必須滿足至少發(fā)送100KB彩信的能力。（這里指彩信封裝后的大小，適用于GSM和GPRS網(wǎng)絡(luò)彩信終端適用）· 彩信終端必須滿足至少接收100KB彩信的能力。（這里指彩信封裝后的大小，適用于GSM和GPRS網(wǎng)絡(luò)彩信終端）· 用戶必須能查詢每條彩信（包括發(fā)出、收到、未發(fā)送）的相關(guān)信息, 包括主題、彩信大小、收發(fā)方、

20、收發(fā)日期。· 彩信終端必須支持發(fā)送報(bào)告。· 彩信終端可以支持閱讀報(bào)告（可選）。6.4 彩信在移動(dòng)終端上的操作6.4.1 編輯彩信終端必須能創(chuàng)建彩信, 創(chuàng)建的彩信類型必須是application/vnd.wap.multipart.related類型，內(nèi)容包括文字、 圖像、 聲音、視頻（適用于3G網(wǎng)絡(luò)彩信終端）。彩信終端必須能根據(jù)用戶的需求對(duì)創(chuàng)建好的彩信進(jìn)行編輯, 包括對(duì)聲音、圖像和視頻（適用于3G網(wǎng)絡(luò)彩信終端）的選取，刪除和替換, 對(duì)文字的修改。彩信終端必須允許用戶對(duì)存儲(chǔ)在本機(jī)的彩信進(jìn)行編輯。彩信終端必須能夠?qū)pplication/vnd.wap.multipart.re

21、lated類型的彩信進(jìn)行編輯。對(duì)application/vnd.wap.multipart.mixed 類型的彩信，如果不能夠轉(zhuǎn)換成application/vnd.wap.multipart.related類型發(fā)送，則除了文字以外，其他編輯功能必須禁止。每一頁彩信的組成形式只能是下列幾種情形之一：l 包含一張圖片；l 包含一段聲音；l 包含一段文字；l 包含以上三種或其中的任意兩個(gè)；l 包含一段視頻（含聲音）；l 包含一段視頻（含聲音）和一段文字。彩信終端必須支持編輯多頁彩信， 支持的編輯頁數(shù)必須為20頁，必須能在任何位置插入新的頁。彩信終端必須支持對(duì)彩信的預(yù)覽功能。 用戶必須能對(duì)彩信命名標(biāo)題

22、，支持的文字?jǐn)?shù)目必須是40Bytes，即40個(gè)英文字母或者13個(gè)中文。6.4.2 發(fā)送彩信終端必須具有發(fā)送彩信的能力。在用戶選擇發(fā)送彩信以后，在彩信正式發(fā)送以前，終端必須主動(dòng)提示用戶封裝后彩信大?。ㄒ訩B為單位），用戶可以確認(rèn)發(fā)送或者返回。彩信終端必須能將彩信發(fā)送到預(yù)定義的組（推薦）。在彩信發(fā)送后，彩信終端必須向用戶提示發(fā)送結(jié)果，推薦顯示MM1_submit.RES中的Request Status Text字段。彩信終端必須支持自動(dòng)簽名功能，即允許用戶自建簽名并保存在終端上，在發(fā)送彩信時(shí)，可以插入到待發(fā)的彩信中，一并發(fā)出，將簽名檔作為最后一頁插入彩信。如果包含簽名后的彩信總頁數(shù)大于本規(guī)范要求值

23、，則不能發(fā)送并提示用戶彩信頁數(shù)過多。彩信終端必須支持以下形式輸入接收方的地址：l 從電話本列表中選取，必須支持同時(shí)選取多個(gè)接收號(hào)碼；l 直接輸入電話號(hào)碼；l 直接輸入e-Mail地址；l 混合輸入電話號(hào)碼、eMail地址和電話本選取號(hào)碼。l 對(duì)多個(gè)地址自動(dòng)采用分號(hào)或逗號(hào)分割，這些逗號(hào)和分號(hào)均為半角字符。彩信終端必須支持群發(fā)功能，即同時(shí)發(fā)送至多個(gè)收件人，每個(gè)收件人的地址必須合法，并且一次性發(fā)給彩信中心。 6.4.3 接收 用戶不能手動(dòng)拒絕接收彩信。彩信的期限以接收PUSH通知消息時(shí)間為基準(zhǔn)開始計(jì)算，彩信終端不能夠自動(dòng)重復(fù)下載已過期的彩信，對(duì)于手工提取過期彩信時(shí)必須提示用戶該通知消息已過期，并且不

24、與網(wǎng)絡(luò)進(jìn)行任何交互。彩信終端能夠拒絕接收過大彩信，同時(shí)向用戶提示文件過大無法接收。彩信終端在設(shè)置為非自動(dòng)接收情況下，接收到PUSH通知消息后，彩信終端可以不向用戶提示。彩信終端在設(shè)置為自動(dòng)接收情況下，接收到PUSH通知消息后，彩信終端必須向用戶提示，如：顯示一個(gè)圖標(biāo)，或以鈴聲，震動(dòng)方式通知用戶。彩信終端接收到彩信后，彩信終端必須向用戶提示，如：顯示一個(gè)圖標(biāo)，或以鈴聲，震動(dòng)方式通知用戶。彩信終端內(nèi)存在不足以存儲(chǔ)PUSH通知消息時(shí)，必須能提示用戶清理內(nèi)存或者自動(dòng)清理內(nèi)存，終端獲得足夠內(nèi)存后，必須能正確存儲(chǔ)PUSH通知消息并完成相關(guān)操作。彩信終端在收到PUSH通知消息而不能立即提取的情況下，必須能延

25、遲提取彩信。彩信終端接收到PUSH通知消息，發(fā)現(xiàn)內(nèi)存不足以存儲(chǔ)彩信時(shí)必須能提示用戶清理內(nèi)存。如果用戶手動(dòng)提取彩信，則需要提示用戶清理內(nèi)存，并且不向網(wǎng)絡(luò)發(fā)起任何請(qǐng)求，終端獲得足夠內(nèi)存后，必須能正確下載彩信。彩信的接收成功率不應(yīng)受內(nèi)存問題的影響。彩信終端在彩信接受失敗時(shí)，必須向用戶提示相關(guān)信息，并允許用戶手動(dòng)接收彩信。6.4.4 彩信管理 瀏覽彩信終端必須能正常顯示符合終端屏幕規(guī)格的圖像。彩信終端對(duì)于超過屏幕規(guī)格（超長及超寬）的圖像，必須能通過縮小，滾動(dòng)，剪裁或其他方式顯示出來。若不能顯示某個(gè)媒體對(duì)象時(shí)，彩信終端必須保證不影響其他類型媒體對(duì)象的保存和顯示。彩信終端必須能按SMIL的描

26、述正確播放收到的彩信。彩信終端必須能正確播放多頁彩信，必須支持20頁彩信。彩信終端必須支持手動(dòng)播放彩信。彩信終端可以自動(dòng)播放彩信，自動(dòng)播放過程中可以切換為手動(dòng)播放。（可選） 存儲(chǔ)用戶必須能在終端上查尋剩余用戶空間和當(dāng)前存儲(chǔ)空間使用狀況。彩信終端必須能保存已創(chuàng)建、已接收、已發(fā)送的彩信。 回復(fù)彩信終端必須允許用戶在回復(fù)消息（包括彩信和短信）時(shí)選擇回復(fù)消息類型，即彩信或短信。 轉(zhuǎn)發(fā)彩信終端必須能對(duì)接受到的彩信進(jìn)行編輯，并將未更改的部分按照原樣進(jìn)行轉(zhuǎn)發(fā)，發(fā)送部分要求見其他章節(jié)。 刪除彩信終端必須支持用戶逐條刪除存儲(chǔ)在本機(jī)的彩信。彩信終端必須支持

27、對(duì)各個(gè)文件夾的彩信的一次全部刪除。 彩信內(nèi)容的擴(kuò)展應(yīng)用彩信終端在收到彩信后, 用戶可以擴(kuò)展使用已收到的彩信，即分別將該彩信中的元素存在終端中，作為鈴音、屏保、墻紙等。7 多媒體格式要求7.1 文字參見終端多媒體格式規(guī)范 v1.0.0。7.2 音頻 參見終端多媒體格式規(guī)范 v1.0.0。7.3 圖像o 參見終端多媒體格式規(guī)范 v1.0.0；o 至少支持65K色及以上；o 至少支持160x120像素圖片。7.4 視頻o 參見終端多媒體格式規(guī)范 v1.0.0；o 至少支持65K色；o 至少支持160x120像素視頻。7.5 對(duì)不支持的內(nèi)容格式處理彩信終端在遇到不支持格式的多媒體對(duì)象時(shí)，

28、必須不影響其他支持的多媒體對(duì)象的正常顯示，并且可以將不支持的多媒體對(duì)象單獨(dú)保存，在轉(zhuǎn)發(fā)中也不應(yīng)改變?nèi)魏卧胁市诺膬?nèi)容。7.6 對(duì)每一頁彩信大小的要求每一頁彩信可以包含圖像、文本、聲音和視頻，對(duì)每一頁彩信大小的要求如下（適用于GSM和GPRS網(wǎng)絡(luò)彩信終端）：文本：至少支持1KB圖像：至少支持48KB聲音：至少支持48KB總計(jì)：支持100KB。每一頁彩信可以包含圖像、文本、聲音和視頻，對(duì)每一頁彩信大小的要求如下（適用于3G網(wǎng)絡(luò)彩信終端）：文本：至少支持3KB圖像：至少支持250KB聲音：至少支持250KB視頻：至少支持250KB總計(jì)：支持300KB。8 SMIL的格式要求SMIL (Synchro

29、nized multimedia Integration Language)是用于多媒體網(wǎng)站的標(biāo)記語言。在彩信業(yè)務(wù)推廣的初期，移動(dòng)終端有限的顯示能力會(huì)造成無法完全利用SMIL2.0 及SMIL BASIC全部的內(nèi)容，但是終端必須至少支持 SMIL在互操作性方面的要求， 并且所產(chǎn)生的消息必須是有效、完整的SMIL消息，必須可以在非移動(dòng)終端（例如：PC等）上顯示。8.1 SMIL的封裝彩信的結(jié)構(gòu)包括MMS headers和MMS Body兩大部分。MMS headersStart MMS Bodypresentationaudio/wavtext/plainimage/jpeg 8.1.1 MMS

30、 header參見中國移動(dòng)多媒體業(yè)務(wù)接口規(guī)范。8.1.2 MMS BodyMMS Body包含文本、圖像、聲音等媒體類型，除Presentation Part外，各個(gè)媒體類型可以自由規(guī)定安放的位置和順序。發(fā)送時(shí)必須使用Presentation Part來制定消息內(nèi)容的顯示方式，并把Presentation Part放在MMS Body的最前邊。（可選）接收時(shí)如果Presentation Part不在MMS Body的最前面，也要能正常顯示。接收時(shí)如果沒有Presentation Part(Content-Type為application/vnd.wap.multipart.mixed)，最好能

31、按頁播放，至少能存為附件。詳細(xì)內(nèi)容參照國際規(guī)范OMA-MMS-ENC-V1_2-20030915-C.pdf。8.2 MMS SMILMMS SMIL是SMIL2.0的一個(gè)子集，以下將針對(duì)這些元素進(jìn)行規(guī)范和定義。8.2.1 元素和屬性 <smil>元素。該元素是MM文件的根部。屬性：無子元素：<head> <body> <head>元素。該元素描述了表現(xiàn)內(nèi)容，并與時(shí)間無關(guān)。屬性：無子元素：<layout> <meta> <body>元素。該元素描述了內(nèi)容的表現(xiàn)時(shí)間，以及

32、各個(gè)內(nèi)容模塊的連接方式。屬性：無子元素：<par> <layout>元素。該元素決定了各個(gè)內(nèi)容的位置。屬性：無子元素：<region><root-layout> <region>元素。該元素定義媒體對(duì)象的位置，大小以及比例。屬性：width, height, top, left, fit, idl width 用法和定義參考CCS2 specification。元素的值必須是非負(fù)的百分比或整型。如果是后者，則單位是且只能是px?？梢圆粠挝?。默認(rèn)值是autol height 用法和定義參考CCS2 spe

33、cification。規(guī)則和限制參見width。默認(rèn)值是autol top 用法和定義參考CSS2 specificatin。規(guī)則和限制參見width。默認(rèn)值是autol left用法和定義參考CSS2 specificatin。規(guī)則和限制參見width。默認(rèn)值是autol fit 當(dāng)對(duì)象的實(shí)際大小與被指定的大小有所不同時(shí)，該屬性決定調(diào)整方式該屬性可以具有以下的值：Ø fill縮放對(duì)象的高度和寬度到達(dá)被指定的大小。Ø hidden具有兩種效果如果對(duì)象小于被指定的大小，則左上角對(duì)齊，空白部分用背景色填充如果對(duì)象大于被指定的大小，則左上角對(duì)齊，多余部分切除。Ø mee

34、t維持對(duì)象的縱橫比進(jìn)行縮放，直到寬度或者高度與被指定的值相同，且不用切除任何部分?？瞻撞糠忠员尘吧畛?#216; scroll當(dāng)對(duì)象的實(shí)際的大小超出了邊界時(shí)，允許滾動(dòng)。Ø slice維持對(duì)象的縱橫比進(jìn)行縮放，直到寬度或者高度與被指定的值相同，且一部分會(huì)被切除。寬度過大則從右側(cè)切除，高度過大則從底部切除。該屬性只支持二維的對(duì)象，如圖片和視頻。默認(rèn)值是hiddenl id該元素的在此文檔中的唯一標(biāo)識(shí)。 <root-layout> 該元素決定了它的父元素的顯示區(qū)域的大小。屬性：width heightl width區(qū)域的寬度。只允許是長度，單位是且只允許是px。

35、可以不帶單位。l height區(qū)域的高度。只允許是長度，單位是且只允許是px?？梢圆粠挝?。 <meta> 每一個(gè)meta元素指定了一個(gè)name/content鍵值對(duì)，表達(dá)一個(gè)屬性。屬性：name contentl name指定了一個(gè)屬性的名稱。l content指定了一個(gè)屬性的值。 <par> 定義了一個(gè)群組，其中包含若干元素，可以同時(shí)播放。屬性：dur子元素：媒體模塊l dur該群組播放的時(shí)間。建議以毫秒為單位。 媒體模塊，包括 <Text> <Img> <Audio> <Video

36、> <ref>屬性：src region alt begin end dur l src定位對(duì)應(yīng)的媒體信息。由其指定的資源信息必須匹配其父元素的定義。默認(rèn)為空值。即可作為一個(gè)空的資源，起到時(shí)間延遲的作用。l region定義媒體信息顯示的位置（音頻不需要該字段），必須是在layout中定義的region，如果找不到對(duì)應(yīng)的region，則使用默認(rèn)的region進(jìn)行顯示。l alt當(dāng)媒體信息暫時(shí)或被用戶禁止顯示時(shí)，alt信息將予以顯示。默認(rèn)為空值。l begin定義了媒體信息開始顯示的時(shí)間。由于終端的處理能力不同，begin可以被忽略，而改由用戶手動(dòng)控制時(shí)間。默認(rèn)為0。l end

37、定義了媒體信息結(jié)束顯示的時(shí)間。由于終端的處理能力不同，end可以被忽略，而改由用戶手動(dòng)控制時(shí)間。l dur定義了媒體信息顯示的時(shí)間長短。8.2.2 元素和屬性的可選必選性如下表：元素名稱對(duì)發(fā)送方對(duì)接受方smil必選必選head必選必選body必選必選layout必選必選region必選必選root-layout必選必選par必選必選meta可選可選Text必選必選Img必選必選Audio必選必選Video可選可選ref可選可選屬性名稱對(duì)發(fā)送方對(duì)接受方width必選可選height必選可選top必選可選left必選可選fit可選可選id必選可選par必選可選name可選可選content可選可選

38、dur必選可選src必選必選region必選可選alt可選可選begin可選可選end可選可選8.3 對(duì)發(fā)送SMIL文件的要求從終端創(chuàng)建了一條彩信以后，發(fā)送彩信時(shí)，必須以正確的SMIL格式發(fā)送。每一個(gè)多媒體信息必須由一個(gè)SMIL表達(dá)式來描述。表達(dá)式中的每一頁必須有同樣的布局。Content-Type: 為必選項(xiàng)。創(chuàng)建后的彩信必須使用類型application/vnd.wap.multipart.related。8.4 對(duì)接收SMIL文件的要求彩信移動(dòng)終端接收時(shí)必須支持application/vnd.wap.multipart.mixed和application/vnd.wap.multipar

39、t.related類型的彩信，收到不完整的SMIL格式的消息時(shí)終端不 應(yīng)發(fā)生異常。 如果終端匹配SMIL，那么沒有任何調(diào)整的必要。如果不匹配，彩信終端可以調(diào)整各部份的位置，終端可以忽視信息中的布局部分，而用它自身定義的布局取代。 如果終端對(duì)某些SMIL中的Tag或者屬性不支持，終端必須盡量顯示收到的彩信，并且在轉(zhuǎn)發(fā)過程中不應(yīng)改變?cè)瓉淼腟MIL文件。 9 接口要求9.1 彩信終端發(fā)送彩信到MMSC圖9.1提交流程OriginatorMMS UAMMSRelay /ServerMM1_submit.REQMM1_submit.RES表9.1提交消息的類型和方向。摘要消息類型方向MM1_submit

40、.REQ請(qǐng)求MMS用戶代理->MMSRelay/ServerRelay/ServerMM1_submit.RES響應(yīng)MMSRelay/ServerRelay/Server->MMS用戶代理 9.1.1 正常操作始發(fā)方彩信客戶端使用包含彩信控制信息和彩信內(nèi)容的MM1_submit.REQ消息將彩信提交至始發(fā)方MMSRelay/ServerRelay/Server。MMSRelay/ServerRelay/Server將返回一個(gè)MM1_submit.RES消息，該消息中攜帶請(qǐng)求狀態(tài)信息。彩信終端必須支持發(fā)送MM1_submit.REQ和接受MMSRelay/ServerRelay/Se

41、rver所發(fā)送的MM1_submit.RES。9.1.2 異常操作在異常情況下，始發(fā)方MMSRelay/ServerRelay/Server將返回一個(gè)MM1_submit.RES消息，其中包含指示拒絕多媒體消息原因的狀態(tài)信息，例如：未預(yù)約、消息結(jié)構(gòu)破壞、不提供服務(wù)等。如果MMSRelay/ServerRelay/Server不提供MM1_submit.RES消息，彩信終端必須能夠恢復(fù)正常狀態(tài)。異常1: 如果彩信終端不能成功的發(fā)出MM1_Submit.REQ,彩信終端必須提示用戶發(fā)送失敗，并提示用戶會(huì)重新發(fā)送。彩信終端必須支持再自動(dòng)重發(fā) MM1_Submit.REQ.，最多3次。如果還失敗，則存

42、入彩信終端，并向用戶提出明確提示，用戶可以手動(dòng)重發(fā)彩信。異常2: 如果彩信終端成功的發(fā)出MM1_Submit.REQ，但沒有收到MM1_Submit.RES， 彩信終端必須提示用戶彩信發(fā)送超時(shí)同時(shí)必須禁止自動(dòng)重發(fā)，用戶可以手動(dòng)重發(fā)彩信。異常3: 如果彩信終端接收到的MM1_Submit.RES包是”失敗”, 彩信終端必須提示給用戶發(fā)送彩信失敗。推薦彩信終端顯示MM1_Submit.RES里的Request_Status_Text.9.1.3 信息單元表9.2：MM1_submit.REQ中的信息單元信息單元存在情況說明Message Type必選將此消息標(biāo)識(shí)為MM1_submit.REQTra

43、nsaction ID必選MM1_submit.REQ/MM1_submit.RES對(duì)的標(biāo)識(shí)。MMS Version必選標(biāo)識(shí)MMSUA所支持接口的版本。格式參見 OMA-MMS-ENC-V1_2-20030915-C.pdfRecipient address必選MM的接收方地址?？赡艽嬖诙鄠€(gè)地址。地址格式的必須符合WAP-209-MMSEncapsulation-20020105-a中的規(guī)定Content type必選MM內(nèi)容的內(nèi)容類型。必須使用Multipart/Related格式.Sender address可選MM始發(fā)方的地址。Message class可選MM的類別（例如，個(gè)人服務(wù)、廣

44、告服務(wù)和信息服務(wù)）Date and time可選提交彩信的時(shí)間和日期（時(shí)間戳）。Time of Expiry可選彩信或應(yīng)答彩信的指定超時(shí)時(shí)間。Earliest delivery time可選將彩信傳遞給接收方的指定最早時(shí)間。Delivery report可選發(fā)送報(bào)告的請(qǐng)求。Reply-Charging可選應(yīng)答計(jì)費(fèi)的請(qǐng)求。Reply-Deadline可選在應(yīng)答計(jì)費(fèi)的情況下，向接收方提交應(yīng)答的最遲時(shí)間。Reply-Charging-Size可選在應(yīng)答計(jì)費(fèi)的情況下，提供給接收方的應(yīng)答彩信的最大大小。Priority可選消息的優(yōu)先級(jí)（重要性）。Sender visibility可選請(qǐng)求在將消息傳遞給接

45、收方時(shí)，顯示或隱藏發(fā)送方的標(biāo)識(shí)。推薦終端不讓擁護(hù)在界面設(shè)置隱藏發(fā)送方的功能。Store可選除了正常傳遞彩信外，請(qǐng)求將彩信的副本存儲(chǔ)至用戶的MMBox。MM State可選在已存儲(chǔ)彩信的“MM狀態(tài)”信息單元中設(shè)置的值（如果存在“存儲(chǔ)”）。MM Flags可選在已存儲(chǔ)彩信的“MM標(biāo)志”信息單元中設(shè)置的一個(gè)或多個(gè)“MM標(biāo)志”關(guān)鍵字（如果存在“存儲(chǔ)”）。Read reply可選讀取應(yīng)答報(bào)告的請(qǐng)求。Subject可選整個(gè)多媒體消息的標(biāo)題。Reply-Charging-ID可選在應(yīng)答計(jì)費(fèi)的情況下，如果在MM1_submit.REQ中提交應(yīng)答MM，則它指所應(yīng)答原始彩信的標(biāo)識(shí)。Content必選多媒體消息的內(nèi)

46、容表9.3：MM1_submit.RES中的信息單元信息單元存在情況說明Message Type必選將此消息標(biāo)識(shí)為MM1_submit.RES。Transaction ID必選MM1_submit.REQ/MM1_submit.RES對(duì)的標(biāo)識(shí)。MMS Version必選標(biāo)識(shí)MMSRelay/ServerRelay/Server所支持接口的版本。Request Status必選MM提交請(qǐng)求的狀態(tài)。Request Status Text可選限定MM提交請(qǐng)求狀態(tài)的說明。Message ID可選MM的標(biāo)識(shí)（如果MMSRelay/ServerRelay/Server接受MM）。Store Status可

47、選存儲(chǔ)請(qǐng)求的狀態(tài)（如果MM1_submit.REQ中存在“存儲(chǔ)”請(qǐng)求）。Store Status Text可選與存儲(chǔ)狀態(tài)相對(duì)應(yīng)的說明性文本（如果存在）。Stored Message Reference可選最新所存儲(chǔ)MM的狀態(tài)（如果MM1_submit.REQ中存在“存儲(chǔ)”請(qǐng)求）。9.2 彩信中心發(fā)送notification消息到彩信終端MMSRelay /ServerMM1_notification.REQMM1_notification.RESRecipient MMS UA圖9.2 彩信終端接收Notification消息此部分的彩信服務(wù)定義從接收方MMSRelay/ServerRelay

48、/Server到相應(yīng)接收方彩信終端有關(guān)彩信的通知，表9.4從類型和方向方面概括了其中涉及的摘要信息。表9.4：在MMS中通知彩信的摘要消息摘要消息類型方向MM1_notification.REQ請(qǐng)求MMSRelay/ServerRelay/Server->MMS用戶代理MM1_notification.RES響應(yīng)MMS用戶代理->MMSRelay/ServerRelay/Server9.2.1 正常操作MMSRelay/ServerRelay/Server接到MM1_Send.REQ后,會(huì)把 MM1_notification.REQ 發(fā)送到接收方彩信終端. 彩信終端成功接到MM1_

49、notification.REQ后, 必須給MMSRelay / ServerRelay/ Server 發(fā)出MM1_notification.RES信息包.9.2.2 異常操作異常1:如果彩信的大小超過彩信終端可接收的能力, 彩信終端會(huì)在MM1_notification.RES發(fā)“Rejected” <Octet 130> 到MMSRelay/ServerRelay/Server, 表示終端拒絕接收，不再發(fā)出MM1_retrieve.REQ等消息。異常2:如果彩信已經(jīng)過期, 彩信終端會(huì)在MM1_notification.RES發(fā)Expired” <Octet 128>

50、 到MMSRelay/ServerRelay/Server, 表示終端認(rèn)為該消息已經(jīng)過期，不再發(fā)出MM1_retrieve.REQ等消息。9.2.3 信息單元表9.5：MM1_notification.REQ中的信息單元信息元素存在情況說明Message Type必選將此消息標(biāo)識(shí)為MM1_notification.REQTransaction ID必選MM1_notification.REQ/MM1_notification.RES對(duì)的標(biāo)識(shí)。MMS Version必選標(biāo)識(shí)MMSRelay/ServerRelay/Server所支持接口的版本。Message class必選彩信的類別（例如，個(gè)人

51、服務(wù)、廣告服務(wù)、信息服務(wù)；默認(rèn)值=個(gè)人服務(wù)）Message size必選彩信的近似大小Time of expiry必選彩信的超時(shí)時(shí)間。Message Reference必選彩信的引用，例如，URISubject可選整個(gè)彩信的標(biāo)題。Priority可選消息的優(yōu)先級(jí)（重要性）。Sender address可選最近處理過彩信（即提交或轉(zhuǎn)發(fā)彩信）的彩信終端的地址。如果始發(fā)方彩信終端已經(jīng)請(qǐng)求對(duì)接收方隱藏其地址，則它的地址不會(huì)提供給接收方。Stored可選指示將彩信自動(dòng)存儲(chǔ)至MMBox。Delivery report可選發(fā)送報(bào)告的請(qǐng)求。Reply-Charging可選對(duì)此特定原始彩信應(yīng)答不計(jì)費(fèi)的信息。Re

52、ply-Deadline可選在應(yīng)答計(jì)費(fèi)的情況下，將允許的應(yīng)答提交給接收方的最遲時(shí)間。Reply-Charging-Size可選在應(yīng)答計(jì)費(fèi)的情況下，提供給接收方的應(yīng)答彩信的最大大小。Reply-Charging-ID可選如果此通知指示一個(gè)應(yīng)答彩信，則它指應(yīng)答的原始彩信的標(biāo)識(shí)。Element-Descriptor可選彩信單元的參考，它可能包含有關(guān)彩信已參考單元的詳細(xì)信息，例如，消息單元的名稱、大小和（或）類型和格式。Message Distribution Indicator可選如果設(shè)置為“假”，則VASP已指示不能重新分配彩信的內(nèi)容。如果設(shè)置為“真”，則VASP已指示可能重新分配彩信的內(nèi)容。表9

53、.6：MM1_notification.RES中的信息單元信息元素存在情況說明Message Type必選將此消息標(biāo)識(shí)為MM1_notification.RES。Transaction ID必選MM1_notification.REQ/MM1_notification.RES對(duì)的標(biāo)識(shí)。MMS Version必選標(biāo)識(shí)彩信終端所支持接口的版本。MM Status必選MM接收的狀態(tài)。Report allowed可選請(qǐng)求允許或不允許向彩信始發(fā)方發(fā)送報(bào)告。 9.3 彩信終端從彩信中心提取彩信此部分定義彩信終端向彩信中心接收彩信的流程。表9.7從類型和方向方面概括了其中涉及的摘要消息。表9.7：接收彩信要用到的摘要消息摘要消息類型方向MM1_retrieve.REQ請(qǐng)求彩信終端->MMSRelay/ServerRelay/ServerMM1_retrieve.RES響應(yīng)MMSRelay/ServerRelay/Server->彩信終端MM1_acknowledgement.REQ請(qǐng)求彩信終端->MMSRelay/ServerRelay/Server9.3.1 正常操作在彩信終端設(shè)置立即提取消息的方式下，收到MM1_noti