專利名稱：一種發(fā)送多媒體消息的遞送報(bào)告的方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及多媒體移動(dòng)通信技術(shù)，尤其是指 一種發(fā)送多媒體消息的遞送 報(bào)告的方法及裝置。
背景技術(shù)：
多媒體消息服務(wù)(MMS )是短信息服務(wù)(SMS )和增強(qiáng)型消息服務(wù)(EMS ) 的進(jìn)一步發(fā)展，為個(gè)人多媒體移動(dòng)通信服務(wù)提供了完整的端到端解決方案。 從通信內(nèi)容上講，多媒體消息包括圖像、音頻、視頻和數(shù)據(jù)等；從功能上講， 多媒體消息服務(wù)涵蓋了終端到終端、終端到應(yīng)用設(shè)備(例如，增值業(yè)務(wù)提供 商SP、 Email服務(wù)器等)、應(yīng)用設(shè)備到終端的多媒體消息通信。它不僅實(shí)現(xiàn) 了終端之間、終端和應(yīng)用設(shè)備之間的信息傳遞，還實(shí)現(xiàn)了內(nèi)容的多樣性，包 括圖片、語(yǔ)音、圖像、數(shù)據(jù)和文本的各種組合。作為一個(gè)開(kāi)放的媒體接入平 臺(tái)，MMS可以在移動(dòng)用戶和互聯(lián)網(wǎng)內(nèi)容提供商的互動(dòng)下，衍生出更豐富多 彩的內(nèi)容服務(wù)應(yīng)用。由于用戶既可以是MMS的消費(fèi)者，又可以是內(nèi)容開(kāi)發(fā) 者，所以無(wú)疑會(huì)提高用戶對(duì)業(yè)務(wù)的使用興趣。
在運(yùn)營(yíng)商實(shí)際開(kāi)展業(yè)務(wù)時(shí)，經(jīng)常需要使用多個(gè)多媒體消息服務(wù)中心 (MMSC)分別向用戶提供MMS業(yè)務(wù)，各個(gè)MMSC分別管理部分用戶， 提供相應(yīng)用戶的接入功能。圖1所示為現(xiàn)有技術(shù)中MMSC與相關(guān)的各個(gè)網(wǎng) 絡(luò)設(shè)備之間的協(xié)議接口的示意圖。如圖1所示，MMSC與終端之間通過(guò)WAP 網(wǎng)關(guān)進(jìn)4亍交互，所^^用的協(xié)-漢為MM1; MMSC與郵件l良務(wù)器之間采用MM3 協(xié)議進(jìn)行交互，承載協(xié)議為電子郵件傳輸協(xié)議(SMTP) ; MMSC與服務(wù)商 提供商/內(nèi)容提供商(SP/CP)之間采用MM7協(xié)議進(jìn)行交互，承載協(xié)議一般 為超文本傳輸協(xié)議(HTTP ),也可以使用其它的協(xié)議。以增值業(yè)務(wù)提供商(SP)到某個(gè)終端的業(yè)務(wù)為例，在現(xiàn)有技術(shù)中的彩信
業(yè)務(wù)中，現(xiàn)有彩信業(yè)務(wù)的遞送報(bào)告的處理流程為
步驟1, SP將需要發(fā)送給某個(gè)終端的彩信提交給彩信服務(wù)器； 步驟2,彩信服務(wù)器根據(jù)上述終端的號(hào)碼下發(fā)彩信通知給該終端； 步驟3，該終端根據(jù)接收到的彩信通知從彩信服務(wù)器提取彩信； 步驟4，彩信服務(wù)器向SP發(fā)送遞送報(bào)告，告知該終端已經(jīng)接收了彩信。 然而，在彩信業(yè)務(wù)中SP可以一次給多個(gè)用戶發(fā)送彩信，例如，SP—次
給10000個(gè)用戶發(fā)送天氣預(yù)報(bào)彩信。此時(shí)，在上述的處理流程中，步驟1只
需執(zhí)行1次，但步驟2~4則必須執(zhí)行10000次。由于彩信服務(wù)器每次只能
向SP發(fā)送1個(gè)遞送報(bào)告，因此彩信服務(wù)器就需要分10000次將各個(gè)終端提
取彩信的遞送報(bào)告返回給SP。
在日漸繁忙的移動(dòng)通信網(wǎng)絡(luò)中，頻繁的發(fā)送遞送報(bào)告，將會(huì)降低發(fā)送遞送
報(bào)告的成功率，而且由于每次僅能發(fā)送一個(gè)遞送報(bào)告，因此發(fā)送效率較低，對(duì)
系統(tǒng)性能和網(wǎng)絡(luò)資源也造成較大的浪費(fèi)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明實(shí)施例提供了一種發(fā)送多媒體消息的遞送報(bào)告的方法及 裝置，使得MMSC可以一次發(fā)送多個(gè)遞送報(bào)告。 本發(fā)明實(shí)施例中的技術(shù)方案是這樣實(shí)現(xiàn)的 一種發(fā)送多媒體消息的遞送報(bào)告的方法，該方法包括 緩存所需發(fā)送的多媒體消息的遞送報(bào)告；
使用預(yù)先設(shè)置的方式獲取至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告； 生成包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的集合體； 輸出所述集合體。
本發(fā)明的實(shí)施例中還提供了 一種發(fā)送多媒體消息的遞送報(bào)告的裝置，該裝 置包括獲取模塊、生成模塊和輸出模塊；
所述獲取模塊，用于獲取至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告；所述生成模塊，用于根據(jù)獲取模塊所獲取的多媒體消息的遞送報(bào)告，生成
包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的集合體；
所述輸出模塊，用于輸出所述的集合體。 綜上可知，本發(fā)明的實(shí)施例中提供了 一種發(fā)送多媒體消息的遞送報(bào)告的方 法及裝置。通過(guò)上述的方法和裝置，可首先緩存所需發(fā)送的遞送報(bào)告，并將所
緩存的多個(gè)遞送報(bào)告一次輸出，從而可以實(shí)現(xiàn)MMSC —次同時(shí)發(fā)送多個(gè)遞送報(bào) 告，因而提高了發(fā)送遞送報(bào)告的成功率，提高了對(duì)遞送報(bào)告的處理效率，同時(shí) 還減少了對(duì)網(wǎng)絡(luò)資源的浪費(fèi)，提高了系統(tǒng)性能。


圖1所示為現(xiàn)有技術(shù)中MMSC與相關(guān)的各個(gè)網(wǎng)絡(luò)設(shè)備之間的協(xié)議接口 的示意圖。
圖2為本發(fā)明實(shí)施例中發(fā)送多媒體消息的遞送報(bào)告的方法的流程圖。 圖3為本發(fā)明實(shí)施例中發(fā)送多媒體消息的遞送報(bào)告的裝置的結(jié)構(gòu)圖。
具體實(shí)施例方式
為使本發(fā)明的技術(shù)方案和優(yōu)點(diǎn)表達(dá)得更加清楚明白，下面結(jié)合附圖及具 體實(shí)施例對(duì)本發(fā)明再作進(jìn)一步詳細(xì)的i兌明。
圖2為本發(fā)明實(shí)施例中發(fā)送多媒體消息的遞送報(bào)告的方法的流程圖。如 圖2所示，本發(fā)明實(shí)施例中方法的流程包括如下所述的步驟
步驟201,緩存所需發(fā)送的多媒體消息的遞送報(bào)告。
即MMSC在接收到遞送報(bào)告時(shí)，并不馬上將所接收到的遞送報(bào)告發(fā)送 給相應(yīng)的應(yīng)用設(shè)備，而是緩存該所需發(fā)送的遞送報(bào)告，暫不發(fā)送。
步驟202,使用預(yù)先設(shè)置的方式獲取至少兩個(gè)需發(fā)送的多媒體消息的遞 送報(bào)告。
在本步驟中，所述的預(yù)先設(shè)置的方式可以為定時(shí)方式或定長(zhǎng)方式，或是 上述兩種方式的結(jié)合。例如，所述的定長(zhǎng)方式可以為根據(jù)預(yù)先設(shè)定的時(shí)間間隔(例如，5分鐘)從上述緩存的多媒體消息的遞送報(bào)告中獲取至少兩個(gè)
需發(fā)送的多媒體消息的遞送報(bào)告；所述定長(zhǎng)的方式可以為當(dāng)上述緩存的多 媒體消息的遞送報(bào)告的總長(zhǎng)度達(dá)到預(yù)先設(shè)定的閾值(例如，2M)時(shí)，獲取 至少兩個(gè)所述緩存的多媒體消息的遞送報(bào)告。
步驟203,生成包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的集合體。 在上述的步驟203中，可根據(jù)步驟202中所獲取的多媒體消息的遞送報(bào) 告生成一個(gè)包括上述至少兩個(gè)緩存的多媒體消息的遞送報(bào)告的消息或文件。 也就是說(shuō)，可將所緩存的所需發(fā)送的至少兩個(gè)多媒體消息的遞送報(bào)告設(shè)置在 同一個(gè)消息或文件中，形成包括至少兩個(gè)遞送^^告的消息或文件。例如可 以對(duì)現(xiàn)有的遞送報(bào)告請(qǐng)求消息進(jìn)行擴(kuò)展，形成一個(gè)包括至少兩個(gè)遞送報(bào)告的 擴(kuò)展后的遞送報(bào)告請(qǐng)求消息；也可以直接建立一個(gè)包括至少兩個(gè)遞送報(bào)告的 文件。具體的對(duì)現(xiàn)有的遞送報(bào)告請(qǐng)求消息的設(shè)置方式，以及包括至少兩個(gè)遞 送報(bào)告的文件的建立方式將分別在以下的第 一 、第二較佳實(shí)施例中進(jìn)行詳細(xì) 地說(shuō)明。
步驟204,輸出所述集合體。
以下將結(jié)合具體實(shí)施例對(duì)上述的發(fā)送多媒體消息的遞送報(bào)告的方法進(jìn) 行更進(jìn)一步的介紹。為了敘述的方便，在以下的實(shí)施例中，將以所述的MMSC 為彩信服務(wù)器，所述的多媒體消息的遞送報(bào)告為彩信的遞送報(bào)告為例對(duì)本發(fā) 明的技術(shù)方案進(jìn)行詳細(xì)的介紹。由于對(duì)于其他的非彩信服務(wù)器的MMSC以 及其他的多媒體消息的遞送報(bào)告，所使用的方法是相同的，因此將不再贅述。
第一較佳實(shí)施例
現(xiàn)有的遞送報(bào)告支持多種協(xié)議接口 ，例如，超文本傳輸協(xié)議(HTTP) 接口 、簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議(SOAP, Simple Object Access Protocol )接口等，
即所述的遞送報(bào)告可通過(guò)多種協(xié)議接口進(jìn)行傳送。為了實(shí)現(xiàn)一次傳送多個(gè)遞 送報(bào)告，在本實(shí)施例中，需要對(duì)現(xiàn)有的對(duì)傳送遞送報(bào)告的協(xié)議接口進(jìn)行擴(kuò)展。 為了敘述的簡(jiǎn)便，在如下所述的本發(fā)明實(shí)施例中，將以SOAP接口為例進(jìn)行說(shuō)明，對(duì)于其他協(xié)議接口的擴(kuò)展方法與對(duì)SOAP接口的擴(kuò)展方法相同，因此 將不再贅述。
在SOAP協(xié)議接口中，常用的遞送報(bào)告請(qǐng)求消息的格式如表1所示
表1
信息單元位置單元名稱備注
Transaction ID標(biāo)題TransactionID
Message-Type正文MessageType
Version正文Version取值為此規(guī)范的編號(hào)，例如5.2.0。
MMS Relay/Server ID正文MMSRelayServerID
Message ID正文MessageID
Recipient address正文Recipient
Sender address正文Sender
Date and time正文TimeStamp
MM Status正文MMStatus枚^_可能值已超時(shí)、已接收、已拒 絕、不確定、已轉(zhuǎn)發(fā)。
MMS Status Error Code正文MMS Status Error Code具體的錯(cuò)誤代碼請(qǐng)參見(jiàn)設(shè)備規(guī)范
Status text正文StatusText存放多條遞送報(bào)告的必選信息
其中，表1中遞送報(bào)告中的各個(gè)字段的名稱分別為Transaction ID為 事務(wù)標(biāo)識(shí)，Message-Type為消息類型，Version為版本，MMS Relay/Server ID
為月良務(wù)器標(biāo)識(shí)，Message ID為消息標(biāo)識(shí)，Recipient address為4妄收方:l也址， Sender address為發(fā)送方地址，Date and time為曰期和時(shí)間，MM Status為多 媒體消息狀態(tài)，MMS Status Error Code為多媒體消息服務(wù)狀態(tài)錯(cuò)誤碼，Status text為^犬態(tài)文本。
在SOAP協(xié)議接口中，常用的遞送報(bào)告響應(yīng)消息的格式如表2所示
表2
信息單元位置單元名稱備注
Transaction ID標(biāo)題TransactionID
Mcssag6-Typ6正文MessageType
MM7 Version正文MM7Version取值為此規(guī)范的編號(hào)，例如5.2.0。
Request Status正文StatusCode
Request Status text正文StatusText&Details
其中，MM7 Version為MM7協(xié)i義的版本，Request Status為請(qǐng)求信息狀
態(tài)，Request Status text為請(qǐng)求信息狀態(tài)文本，StatusCode為狀態(tài)碼。
對(duì)于遞送報(bào)告請(qǐng)求消息來(lái)說(shuō)，保證業(yè)務(wù)可以正常處理的遞送報(bào)告中的五 個(gè)必選字,殳分另ll為Sender address、 Recipient address、 MessageID、 MMStatus和StatusText。在SOAP協(xié)議接口中， 一個(gè)現(xiàn)有的遞送報(bào)告請(qǐng)求消息中，僅 包括一個(gè)遞送報(bào)告的上述的五個(gè)必選字段，因此一個(gè)遞送報(bào)告請(qǐng)求消息只能 傳送一個(gè)遞送報(bào)告。所以，如果對(duì)上述遞送報(bào)告請(qǐng)求消息進(jìn)行擴(kuò)展，使得在 被擴(kuò)展后的遞送報(bào)告請(qǐng)求消息中，能夠包括多個(gè)遞送報(bào)告的上述五個(gè)必選字 段，就可實(shí)現(xiàn)在一個(gè)遞送報(bào)告請(qǐng)求消息中傳送多個(gè)遞送報(bào)告。
對(duì)遞送報(bào)告請(qǐng)求消息的具體擴(kuò)展方法為將遞送報(bào)告請(qǐng)求消息中記錄遞 送報(bào)告的五個(gè)必選字段信息的部分進(jìn)行擴(kuò)展，在該擴(kuò)展部分中，連續(xù)記錄n (n>l )個(gè)遞送報(bào)告的上述五個(gè)必選字段信息。所記錄的遞送報(bào)告的數(shù)目n 可根據(jù)實(shí)際應(yīng)用情況預(yù)先進(jìn)行設(shè)置。此外，為了進(jìn)行區(qū)別和標(biāo)識(shí)，可為上述 擴(kuò)展部分設(shè)置一個(gè)新標(biāo)簽，該新標(biāo)簽的名稱可設(shè)為"MultiDR"，即在上述 擴(kuò)展部分的首部和尾部分別i殳置"<MultiDR>"和"</MultiDR>"的標(biāo)簽， 接收方根據(jù)上述的新標(biāo)簽即可知該遞送報(bào)告請(qǐng)求消息為擴(kuò)展后的包括多個(gè) 遞送報(bào)告的遞送報(bào)告請(qǐng)求消息。
在具體的實(shí)施方式中，首先在本地內(nèi)存中緩存上述所需發(fā)送的多個(gè)遞送 報(bào)告；然后根據(jù)預(yù)先設(shè)置的定時(shí)和/或定長(zhǎng)的方式從本地內(nèi)存中獲取多個(gè)需 發(fā)送的多媒體消息的遞送報(bào)告；根據(jù)所獲取的多個(gè)遞送報(bào)告以及上述的擴(kuò)展 方法，生成上述擴(kuò)展后的包括多個(gè)遞送報(bào)告的遞送報(bào)告請(qǐng)求消息；接著輸出 上述擴(kuò)展后的遞送報(bào)告請(qǐng)求消息。在上述的實(shí)施方式中，所述定時(shí)的方式為 根據(jù)預(yù)先設(shè)定的時(shí)間間隔(例如，5分鐘)，從上述緩存的多媒體消息的遞 送報(bào)告中獲取多個(gè)需發(fā)送的多媒體消息的遞送報(bào)告；所述定長(zhǎng)的方式為當(dāng) 上述緩存的多媒體消息的遞送報(bào)告的總長(zhǎng)度達(dá)到預(yù)先設(shè)定的閾值(例如， 2M)時(shí)，從上述緩存的多媒體消息的遞送報(bào)告中獲取多個(gè)需發(fā)送的多媒體 消息的遞送報(bào)告。在實(shí)際應(yīng)用時(shí)，可單獨(dú)使用上述的定時(shí)方式或定長(zhǎng)方式獲 取多個(gè)需發(fā)送的多媒體消息的遞送報(bào)告，也可同時(shí)使用上述的定時(shí)方式和定 長(zhǎng)方式獲取多個(gè)需發(fā)送的多媒體消息的遞送報(bào)告。
在對(duì)遞送報(bào)告請(qǐng)求消息進(jìn)行擴(kuò)展后，還需對(duì)與遞送報(bào)告請(qǐng)求消息相對(duì)應(yīng) 的遞送報(bào)告響應(yīng)消息進(jìn)行擴(kuò)展，即根據(jù)擴(kuò)展后的遞送報(bào)告請(qǐng)求消息，在與之相應(yīng)的遞送報(bào)告響應(yīng)消息中記錄StatusCode字段信息的部分，順序記錄n 條StatusCode字段，所記錄的n條StatusCode字段與相應(yīng)的擴(kuò)展后的遞送才艮 告請(qǐng)求消息中的n條遞送報(bào)告——對(duì)應(yīng)，且排列順序也相同。
以SOAP接口為例，上述擴(kuò)展后的遞送報(bào)告請(qǐng)求消息的SOAP接口報(bào)文 如下所示
< xml version="1.0" encoding="UTF-8" >
<env:Envelope xmlns:env="http:〃schemas.xmlsoap.org/soap/envelope/"> <env:Header>
<mm7: TransactionID
xmlns:mm7="http:〃www.3gpp.org/ftp/Specs/archive/23—series/23.140/schema/REL-6-MM7-1-0" env:mustUnderstand=" 1">0110000000006020908131404302</mm7:T腦sactionID〉
</env:Header>
<env:Body>
<DeliveryReportReq
xmlns="http:〃www.3gpp.org/ftp/Specs/archive/23—series/23.140/schema/REL-6-MM7-l-0"〉 <MM7 Version>6.3. 0</MM7 Version> <TimeStamp>2002-09-08T05:14:04-04:00</TimeStamp> <MMSRelayServerID>913000</MMSRelayServerID〉 <Sondor>51512l 1</Sender> -<Recipient>
-<Numb Or>+8613810211231 </Numb cr>
-</Recipient>
-<MossageID>0908131糊913 00001101 </MossagoID>
-<MMStatus>Rotriovod</MMStatus>
-<StatusToxt> 1000</StatusText>
<MultiDR>
<Sender>8888001</Sender>
<MessageID>082715595591300001146</MessageID>
<Recipient><Number>+8613701050001</Number></Recipient>
<MMStatus>Retrieved</MMStatus>
<StatusText> 1000</StatusText>
<Sender>7777123</Sender>
<MessageID>082716035691300001190</MessageID><Recipient><Number>+8613 810240001 </Number></Recipient> <MMStatus>Retrieved</MMStatus> <StatusText> 1000</StatusText> <Sender>6666007</Sender>
<MessageID>0827165900913 0000123 5</MessageID> <Recipient><Number>+8613501051234</Number></Recipient> <MMStatus>Retrieved</MMStatus> <StatusText>l 000</StatusText> </MultiDR> </DeliveryReportReq> </env:Body> </env:Envelope>
在上述報(bào)文中，以橫線為刪除線進(jìn)行標(biāo)識(shí)的部分內(nèi)容，即為擴(kuò)展前的遞 送報(bào)告請(qǐng)求消息中記錄遞送報(bào)告的五個(gè)必選字段信息的部分；而〈MultiDR〉 和々MultiDR〉之間所記錄的內(nèi)容，即為擴(kuò)展后的遞送報(bào)告請(qǐng)求消息中的擴(kuò)展部分。
與上述擴(kuò)展后的遞送報(bào)告請(qǐng)求消息相對(duì)應(yīng)的遞送報(bào)告響應(yīng)消息的SOAP
接口報(bào)文如下所示
< xml version="1.0" encoding="UTF-8" >
<soap-env:Envelope xmlns:soap-env="http:〃schemas.xmlsoap.org/soap/envelope〃'> <soap-env:Pieader> <mm7:TransactionID
xmlns:mm7="http:〃www.3 gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-0"
soap-env:mustUnderstand="r>0110000000006020908131404302</mm7:TransactionID> </soap-env:Header> <soap-env:Body> <DeliveryReportRsp
xmlns="http:〃www.3gpp.org/ftp/Specs/archive/23—series/23.140/schema/REL-6-MM7-l-0"> <MM7Version>6.3.0</MM7Version> <Status>
<StatusCode>1000</StatusCode> <StatusCode> 1000</StatusCode><StatusCode> 1000</StatusCode> </Status> </DeliveryReportRsp> </soap-env:Body> </soap-env:Envelope>
現(xiàn)有的遞送"R告響應(yīng)消息中只有一條StatusCode，而上述擴(kuò)展后的遞送 報(bào)告響應(yīng)消息中具有多條StatusCode,即針對(duì)上述擴(kuò)展后的遞送報(bào)告請(qǐng)求消 息中的每一條遞送報(bào)告，在擴(kuò)展后的遞送報(bào)告響應(yīng)消息中都會(huì)有一條對(duì)應(yīng)的 StatusCode。而且，擴(kuò)展后的遞送報(bào)告響應(yīng)消息中的多條StatusCode的排列 順序與擴(kuò)展后的遞送報(bào)告請(qǐng)求消息中的多條遞送報(bào)告的排列順序是一致的。
此外，如果擴(kuò)展后的遞送報(bào)告響應(yīng)消息中僅有一條StatusCode,且返回 的錯(cuò)誤信息為"消息格式錯(cuò)誤"，則說(shuō)明該應(yīng)用設(shè)備不支持批量傳輸遞送報(bào) 告，此時(shí)，多媒體消息服務(wù)中心(MMSC)仍將以原來(lái)的單條發(fā)送方式發(fā)送 遞送報(bào)告。
第二較佳實(shí)施例
在本實(shí)施例中，彩信服務(wù)器可將要發(fā)送的多條遞送報(bào)告的字段信息按照 預(yù)先設(shè)定的排列順序記錄到同一個(gè)本地文件中，該文件可稱之為記錄文件。 在所述的記錄文件中，每一條記錄均對(duì)應(yīng)一個(gè)遞送報(bào)告并包含該遞送報(bào)告的 所有字段信息。所述的記錄文件可以是文本文件，也可以是二進(jìn)制文件。當(dāng) 所述的記錄文件為文本文件時(shí)，所述記錄文件中的每條記錄的才各式可以為如 下所示的格式
Message-Type | MM7 Version | MMS Relay/Server ID | Date and time | Sender address | Message ID | Recipient address | MM Status | Status text
由上述記錄的格式可知，記錄文件中的每條記錄中都包括了某條遞送報(bào)
告中所有的字段信息。例如， 一個(gè)具有三條記錄的記錄文件的內(nèi)容可為
DRReq|6.3. 234|Retrieved|1000 DRReq|6,3.(001|Retrieved|1000
DRReq|6.3.0|910000|20070527075956|6666007|082716590091300001235|+8613810240 001|Retrieved|1000
上述的文本文件中的記錄格式只是一個(gè)較佳的實(shí)施方式，在實(shí)際應(yīng)用情 況中，可根據(jù)需求設(shè)置文本文件中的記錄格式。
此外，還可將上述所需記錄的多個(gè)遞送報(bào)告的所有字段信息，編譯成二 進(jìn)制格式，并按照預(yù)先設(shè)置的排列順序記錄在一個(gè)二進(jìn)制文件中。
在具體的實(shí)施方式中，首先在彩信服務(wù)器的本地內(nèi)存中緩存上述所需發(fā) 送的多個(gè)遞送報(bào)告；然后根據(jù)預(yù)先設(shè)置的定時(shí)和/或定長(zhǎng)的方式從本地內(nèi)存 中獲取多個(gè)需發(fā)送的多媒體消息的遞送報(bào)告；根據(jù)所獲取的多個(gè)遞送報(bào)告以 及上述的方法，建立上述包括多個(gè)遞送報(bào)告的記錄文件；接著輸出上述記錄 文件。在上述的實(shí)施方式中，所述定時(shí)的方式為根據(jù)預(yù)先設(shè)定的時(shí)間間隔 (例如，5分鐘)，從上述緩存的多媒體消息的遞送報(bào)告中獲取多個(gè)需發(fā)送 的多媒體消息的遞送報(bào)告；所述定長(zhǎng)的方式為當(dāng)上述記錄文件的長(zhǎng)度達(dá)到 預(yù)先設(shè)定的閾值(例如，2M)時(shí)，從上述緩存的多媒體消息的遞送報(bào)告中 獲取多個(gè)需發(fā)送的多媒體消息的遞送報(bào)告。在實(shí)際應(yīng)用時(shí)，可單獨(dú)使用上述 的定時(shí)方式或定長(zhǎng)方式獲取多個(gè)需發(fā)送的多媒體消息的遞送報(bào)告，也可同時(shí) 使用上述的定時(shí)方式和定長(zhǎng)方式獲取多個(gè)需發(fā)送的多媒體消息的遞送報(bào)告。 所述的輸出記錄文件可以是將上述記錄文件輸出到應(yīng)用設(shè)備所提供的存放 目錄中。
除了上述的主動(dòng)輸出的模式外，還可使用多種傳送方式將上述記錄文件 傳送到應(yīng)用設(shè)備上，例如
方式1、發(fā)起方應(yīng)用設(shè)備按照預(yù)先設(shè)定的時(shí)間間隔(例如，5分鐘)， 定期到彩信服務(wù)器的指定位置獲取上述記錄文件，并在成功獲取上述記錄文 件后刪除彩信服務(wù)器中的所述記錄文件。上述獲取文件的方法可以為使用文 件傳輸協(xié)議(FTP)等多種手段。
方式2、當(dāng)輸出上述記錄文件后，可發(fā)送一個(gè)修改后的遞送報(bào)告請(qǐng)求消息給應(yīng)用設(shè)備，在該修改后的遞送報(bào)告請(qǐng)求消息中，Sender address、 Recipient address、 MessageID、 MMStatus等四個(gè)字段的內(nèi)容為空，而字段StatusText 中的內(nèi)容為上述記錄文件在彩信服務(wù)器中的存放路徑；所述應(yīng)用設(shè)備在接收 到上述經(jīng)過(guò)修改的遞送報(bào)告請(qǐng)求消息后，如果直接返回一個(gè)遞送報(bào)告響應(yīng)消 息，且返回的是一個(gè)內(nèi)容為"消息格式錯(cuò)誤"的錯(cuò)誤碼，則說(shuō)明所述應(yīng)用設(shè) 備不支持上述傳輸多條遞送報(bào)告的方法，則仍需以單條的方式發(fā)送遞送報(bào) 告；如果所述應(yīng)用設(shè)備支持上述傳輸多條遞送報(bào)告的方法，則所述應(yīng)用設(shè)備 將根據(jù)上述修改后的遞送報(bào)告請(qǐng)求消息中的存放路徑到彩信服務(wù)器中提取 相應(yīng)的記錄文件；成功提取后，所述應(yīng)用設(shè)備再向彩信服務(wù)器返回遞送報(bào)告 響應(yīng)消息。所述的提取方式可以有多種，例如文件傳輸協(xié)議(FTP)、超 文本傳輸協(xié)議(HTTP)、上傳/下傳(POST/GET)或其他可實(shí)現(xiàn)文件內(nèi)容 傳送的方式。
此外，由于是連續(xù)地產(chǎn)生不同的記錄文件，因此需要通過(guò)文件名稱來(lái)區(qū) 分不同的記錄文件，因此，可根據(jù)如下所示的命名方法來(lái)命名不同的記錄文 件MMSDeviceIDyyyymmddHHMISS.XXXX。例如，某個(gè)記錄文件的名稱 可為91000020070606174500.0019。
圖3為本發(fā)明實(shí)施例中發(fā)送多媒體消息的遞送報(bào)告的裝置的示意圖。如 圖3所示，本發(fā)明實(shí)施例中發(fā)送多媒體消息的遞送報(bào)告的裝置包括獲取模 塊、生成模塊和輸出模塊；
所述獲取模塊，用于獲取至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告；并 將所獲取的多媒體消息的遞送報(bào)告發(fā)送給生成模塊；
所述生成模塊，用于根據(jù)獲取模塊所獲取的多媒體消息的遞送報(bào)告，生 成包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的集合體；并將所生成的集 合體發(fā)送給輸出模塊；
所述輸出模塊，用于輸出所述的集合體。
其中，所述獲取模塊還包括閾值設(shè)定模塊。
所述閾值設(shè)定模塊，用于根據(jù)設(shè)定的時(shí)間間隔向獲取模塊發(fā)送獲取命令；或者，用于當(dāng)所述緩存的所需發(fā)送的多媒體消息的遞送報(bào)告的總長(zhǎng)度達(dá)到設(shè)定
的閾值時(shí)，向獲取模塊發(fā)送獲取命令；或者，用于當(dāng)間隔的時(shí)間達(dá)到設(shè)定的時(shí)
間間隔時(shí)，或當(dāng)所述緩存的所需發(fā)送的多媒體消息的遞送報(bào)告的總長(zhǎng)度達(dá)到設(shè)
定的閾值時(shí)，向獲取模塊發(fā)送獲取命令；
所述獲取模塊，還用于根據(jù)接收到的獲取命令，獲取至少兩個(gè)需發(fā)送的多
媒體消息的遞送報(bào)告。
此外，所述發(fā)送多媒體消息的遞送報(bào)告的裝置還可以包括一個(gè)存儲(chǔ)模塊。
所述存儲(chǔ)模塊，用于緩存多個(gè)所需發(fā)送的多々某體消息的遞送報(bào)告；
而所述獲取模塊，還用于從存儲(chǔ)模塊中獲取至少兩個(gè)需發(fā)送的多媒體消
息的遞送報(bào)告。
綜上可知，通過(guò)上述本發(fā)明實(shí)施例中所提供的方法和裝置，當(dāng)需要發(fā)送 多個(gè)多媒體消息的遞送報(bào)告時(shí)，可首先緩存所需發(fā)送的遞送報(bào)告，并將所緩 存的多個(gè)遞送報(bào)告一次輸出，從而可以實(shí)現(xiàn)一次同時(shí)發(fā)送多個(gè)遞送才艮告，因 而提高了發(fā)送遞送報(bào)告的成功率，提高了對(duì)遞送報(bào)告的處理效率，同時(shí)還減 少了對(duì)網(wǎng)絡(luò)資源的浪費(fèi)，提高了系統(tǒng)性能。
以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù) 范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等， 均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
1權(quán)利要求
1、一種發(fā)送多媒體消息的遞送報(bào)告的方法，其特征在于，該方法包括緩存所需發(fā)送的多媒體消息的遞送報(bào)告；使用預(yù)先設(shè)置的方式獲取至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告；生成包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的集合體；輸出所述集合體。
2、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述生成包括至少兩個(gè)需發(fā) 送的多媒體消息的遞送報(bào)告的集合體包括生成包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的遞送報(bào)告請(qǐng)求消息； 或者，生成包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的記錄文件。
3、 才艮據(jù)權(quán)利要求2所述的方法，其特征在于，所述生成包括至少兩個(gè)需發(fā) 送的多媒體消息的遞送報(bào)告的遞送報(bào)告請(qǐng)求消息包括在遞送^R告請(qǐng)求消息中記錄遞送才艮告的必選字,殳信息的部分，連續(xù)記錄至 少兩個(gè)遞送報(bào)告的必選字段信息；并在所述記錄必選字段信息的部分的首部和 尾部分別設(shè)置一個(gè)用于標(biāo)識(shí)該部分的新標(biāo)簽。
4、 根據(jù)權(quán)利要求3所述的方法，其特征在于，所述輸出所述集合體之后還 包括在與所述包括至少兩個(gè)遞送報(bào)告的遞送報(bào)告請(qǐng)求消息相對(duì)應(yīng)的遞送報(bào)告響 應(yīng)消息中記錄StatusCode字段信息的部分，按所述至少兩個(gè)遞送報(bào)告的順序記
5、 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述生成包括至少兩個(gè)需發(fā) 送的多媒體消息的遞送報(bào)告的記錄文件包括將所述至少兩個(gè)遞送報(bào)告的字段信息按照設(shè)定的排列順序記錄到記錄文件中。
6、 根據(jù)權(quán)利要求2或5所述的方法，其特征在于所述記錄文件為文本文 件或二進(jìn)制文件。
7、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述使用預(yù)先設(shè)置的方式獲取至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告包括根據(jù)設(shè)定的時(shí)間間隔獲取至少兩個(gè)所述緩存的多媒體消息的遞送報(bào)告； 或者，當(dāng)所述緩存的所需發(fā)送的多媒體消息的遞送報(bào)告的總長(zhǎng)度達(dá)到設(shè)定的閾值時(shí)，獲取至少兩個(gè)所述緩存的多媒體消息的遞送報(bào)告；或者，當(dāng)間隔的時(shí)間達(dá)到設(shè)定的時(shí)間間隔時(shí)，或當(dāng)所述緩存的所需發(fā)送的多媒體消息的遞送報(bào)告的總長(zhǎng)度達(dá)到設(shè)定的閾值時(shí)，獲取至少兩個(gè)所述緩存的多媒體消息的遞送報(bào)告。
8、 根據(jù)權(quán)利要求2所述的方法，其特征在于，輸出所述集合體包括 將所述記錄文件輸出到指定位置，所述記錄文件的接收方根據(jù)設(shè)定的時(shí)間間隔到所述指定位置獲取所述記錄文件。
9、 根據(jù)權(quán)利要求2所述的方法，其特征在于，輸出所述集合體包括 將所述記錄文件輸出到指定位置，發(fā)送一個(gè)通知信息給所述記錄文件的接收方，所述記錄文件的接收方根據(jù)所述通知信息到所述指定位置獲取所述記錄 文件。
10、 一種發(fā)送多媒體消息的遞送報(bào)告的裝置，其特征在于，該裝置包括 獲取模塊、生成模塊和輸出模塊；所述獲^^莫塊，用于獲取至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告； 所述生成模塊，用于根據(jù)獲取模塊所獲取的多媒體消息的遞送報(bào)告，生成 包括至少兩個(gè)需發(fā)送的多i某體消息的遞送報(bào)告的集合體； 所述輸出模塊，用于輸出所述的集合體。
11、 根據(jù)權(quán)利要求IO所述的裝置，其特征在于，該裝置還包括閾值設(shè)定 模塊；所述閾值設(shè)定模塊，用于根據(jù)設(shè)定的時(shí)間間隔向獲取模塊發(fā)送獲取命令； 或者，用于當(dāng)所述緩存的所需發(fā)送的多媒體消息的遞送報(bào)告的總長(zhǎng)度達(dá)到設(shè)定 的閾值時(shí)，向獲取模塊發(fā)送獲取命令；或者，用于當(dāng)間隔的時(shí)間達(dá)到設(shè)定的時(shí) 間間隔時(shí)，或當(dāng)所述緩存的所需發(fā)送的多i某體消息的遞送4艮告的總長(zhǎng)度達(dá)到設(shè)定的閾值時(shí)，向獲取模塊發(fā)送獲取命令；所述獲取模塊，還用于根據(jù)接收到的獲取命令，獲取至少兩個(gè)需發(fā)送的多 媒體消息的遞送報(bào)告。
12、根據(jù)權(quán)利要求10或11所述的裝置，其特征在于，該裝置還包括存 儲(chǔ)模塊；所述存儲(chǔ)模塊，用于緩存所需發(fā)送的多媒體消息的遞送報(bào)告； 所述獲^^莫塊，還用于從存儲(chǔ)模塊中獲取至少兩個(gè)需發(fā)送的多媒體消息的 遞送報(bào)告。
全文摘要
本發(fā)明的實(shí)施例中公開(kāi)了一種發(fā)送多媒體消息的遞送報(bào)告的方法，該方法包括緩存所需發(fā)送的多媒體消息的遞送報(bào)告；使用預(yù)先設(shè)置的方式獲取至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告；生成包括至少兩個(gè)需發(fā)送的多媒體消息的遞送報(bào)告的集合體；輸出所述集合體。本發(fā)明的實(shí)施例中還公開(kāi)了一種發(fā)送多媒體消息的遞送報(bào)告的裝置，該裝置包括獲取模塊、生成模塊和輸出模塊。通過(guò)上述的方法和裝置，使得MMSC可以一次發(fā)送多個(gè)遞送報(bào)告，從而提高了發(fā)送遞送報(bào)告的成功率，提高了對(duì)遞送報(bào)告的處理效率，同時(shí)還減少了對(duì)網(wǎng)絡(luò)資源的浪費(fèi)，提高了系統(tǒng)性能。
文檔編號(hào)H04W4/12GK101448207SQ20071016739
公開(kāi)日2009年6月3日 申請(qǐng)日期2007年11月26日 優(yōu)先權(quán)日2007年11月26日
發(fā)明者李小強(qiáng) 申請(qǐng)人:華為技術(shù)有限公司