專利名稱：一種接受文件傳輸邀請和拒絕文件傳輸邀請的方法及系統(tǒng)的制作方法
技術(shù)領域：
本發(fā)明涉及文件傳輸，尤其涉及一種接受文件傳輸邀請和拒絕文件傳輸邀請的方法及系統(tǒng)。
背景技術(shù)：
面對信息通信產(chǎn)業(yè)周期的演進以及消費者模式的變遷大潮，面對互聯(lián)網(wǎng)的骨灰級創(chuàng)新模式以及新媒體的廣泛傳播、甚至是IT廠商、內(nèi)容整合者與消費電子廠商向運營領域的滲透，電信運營商正在采取一種積極的融合、開放的態(tài)度，努力嘗試開放其電信能力，集思廣益，發(fā)揮第三方企業(yè)與個人的創(chuàng)新能力，打造豐富的增值應用；另一方面，借用這種電信服務的二次分發(fā)渠道，促進基本電信服務的銷售。尤其是終端與軟件廠商在在線應用商店市場烽煙四起之時，運營商必須要利用電信能力(可靠的通信服務；用戶數(shù)據(jù)；情境；認證；計費等)打造一條新的差異化的道路。1998年P(guān)arlay組織成立致力于為電話網(wǎng)絡開發(fā)API (應用編程接口)。借助這些 API，第三方機構(gòu)可以創(chuàng)建自己的應用。Parlay組織在這方面做了統(tǒng)一的標準化工作，制定了基于CORBA (公共對象資源代理架構(gòu))的Parlay/OSA (開放服務架構(gòu))API，對各種電信能力的使用進行編程方面的統(tǒng)一工作。另外Parlay/OSA API也獲得了 ETSI (歐洲電信標準協(xié)會)與3GPP (第三代移動通信合作伙伴計劃標準組織)共同協(xié)助。在3GPP中，Parlay被當成開放服務架構(gòu)(OSA)的一部分。Parlay X是Parlay、3GPP和OMA(開放移動聯(lián)盟)頒發(fā)的基于SOAP (簡單對象訪問協(xié)議)Web服務的API標準規(guī)范。Parlay REST (面向Parlay X的RESTful約束)，是OMA最新頒發(fā)的一套API標準規(guī)范，旨在為OMA中的Parlay X Web 服務規(guī)范(子)集指定REST Web服務約束。在^feb 2. 0領域，支持Ajax (異步Javakript腳本和XML可擴展標簽語言)技術(shù)的API相對應用比較廣泛，風格為REST (REpresentational State Transfer,表象化狀態(tài)轉(zhuǎn)變)。REST不是一種新技術(shù)，也不是一種標準，而是一組設計原則；與基于SOAP的Web服務 (如Parlay X)相比，REST API更加輕量級，具有更優(yōu)良的開發(fā)者友好性，便于Web應用的開發(fā)和Mashup。因此越來越多的Web服務開始采用REST風格設計和實現(xiàn)。例如，Amazon, com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的 (維基百科)。GSMA (全球移動系統(tǒng)協(xié)會)RCS (富通信套件)是基于現(xiàn)有IMS (IP多媒體子系統(tǒng)) 網(wǎng)絡設施和開發(fā)協(xié)議搭建出來的提供可互操作的豐富通信功能的業(yè)務包，主要包括增強型地址簿、增強型呼叫、增強型融合消息等業(yè)務，使用戶可以對自己的呈現(xiàn)(如個人圖片、留言、推薦鏈接以及狀態(tài))進行更新，也可以在手機的通訊錄中實時看到好友的呈現(xiàn)情況，并實現(xiàn)短信、彩信、聊天(即時消息)、文件傳輸?shù)榷喾N通信需求。RCS是包括運營商、設備商和手機終端廠商共同支持的統(tǒng)一的技術(shù)及實現(xiàn)標準，因此它不但容易培養(yǎng)消費者較為一致的使用習慣，而且可以實現(xiàn)不同國家、不同運營商的互聯(lián)互通。后續(xù)階段，RCS將進一步引入社交網(wǎng)絡、開放式REST API應用編程接口、與互聯(lián)網(wǎng)集成應用商店等內(nèi)容。RCS REST風
5格API的目標用戶是典型的Web開發(fā)商、第三方開發(fā)者、業(yè)務提供商，通過API可以將電信運營商的RCS業(yè)務能力和IMS網(wǎng)絡能力開放，更適合Wfeb 2. Offidget輕量級應用與Mashup 的開發(fā)，迎合Web應用的發(fā)展趨勢。目前，電信運營商短信、彩信的業(yè)務能力已經(jīng)可以通過OMA (開放移動聯(lián)盟)制定的ParlayREST2. 0協(xié)議標準開放，而文件傳輸業(yè)務能力還沒有制定相應的協(xié)議標準開放， 用戶還不能夠調(diào)用電信能力實現(xiàn)接受文件傳輸邀請和拒絕文件傳輸邀請的相關(guān)控制。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的一個目的在于提供一種接受文件傳輸邀請的方法及系統(tǒng)，以解決用戶不能調(diào)用電信能力，實現(xiàn)接受文件傳輸邀請的相關(guān)控制的問題。為了解決上述問題，本發(fā)明提供了一種接受文件傳輸邀請的方法，該方法基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變(REST)應用編程接口(API)實現(xiàn)，包括客戶端向服務器發(fā)送接受文件傳輸邀請消息，攜帶使用的動作和資源的信息，及表示接受邀請的信息，所述資源用統(tǒng)一資源位置符(URL)標示；所述服務器收到所述接受文件傳輸邀請消息后，向所述客戶端返回接受文件傳輸邀請響應消息。較佳地使用的所述動作為HTTP的布置(POST)動作或設定(PUT)動作，所述資源的資源 URL包含終端參與者的用戶標示符和文件傳輸邀請的標示符中的至少一種。較佳地所述接受文件傳輸邀請消息還包括被邀請的終端參與者的參與者地址、參與者姓名、參與者狀態(tài)和參與者的消息會話轉(zhuǎn)播協(xié)議(MSRP)客戶端路徑信息中的至少一種。較佳地客戶端發(fā)送接受文件傳輸邀請消息之前，按以下方式生成所述接受文件傳輸邀請消息以HTTP的布置(POST)動作或設定(PUT)動作為使用的動作，以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包含被邀請的終端參與者的用戶標示符和/或文件傳輸邀請的標示符；根據(jù)表示“接受邀請”的參數(shù)值生成邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體；根據(jù)所述消息頭和消息體生成所述接受文件傳輸邀請消息。較佳地生成所述邀請反饋的數(shù)據(jù)結(jié)構(gòu)之前，先根據(jù)被邀請的終端參與者的參與者地址、 參與者姓名、參與者狀態(tài)和參與者的消息會話轉(zhuǎn)播協(xié)議(MSRP)客戶端路徑信息中的至少一種，生成文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)；生成所述邀請反饋的數(shù)據(jù)結(jié)構(gòu)時，還將所述文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)和相應的文件傳輸會話的標示符寫入所述邀請反饋的數(shù)據(jù)結(jié)構(gòu)。較佳地終端參與者接受文件傳輸邀請成功時，所述服務器返回接受文件傳輸邀請響應消息之前，通過以下方式來生成接受文件傳輸邀請響應消息
根據(jù)HTTP表示“無內(nèi)容(No Content)，，的響應符，生成消息頭；根據(jù)所述消息頭生成接受文件傳輸邀請響應消息。相應地，本發(fā)明還提供了一種接受文件傳輸邀請的系統(tǒng)，客戶端和服務器基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變(REST)應用編程接口(API)交互，該系統(tǒng)包括客戶端中的消息生成裝置，用于生成接受文件傳輸邀請消息；客戶端中的消息發(fā)送裝置，用于向服務器發(fā)送接受文件傳輸邀請消息；服務器中的消息接收和處理裝置，用于在收到接受文件傳輸邀請消息后進行解析和處理；服務器中的消息生成裝置，用于生成接受文件傳輸邀請響應消息；服務器中的消息發(fā)送裝置，用于向所述客戶端返回所述接受文件傳輸邀請響應消肩、ο較佳地所述客戶端中的消息生成裝置又包括消息頭生成子裝置，用于以HTTP的布置(POST)動作或設定(PUT)動作為使用的動作，以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包含被邀請的終端參與者的用戶標示符和/或文件傳輸邀請的標示符；消息體生成子裝置，用于根據(jù)被邀請的終端參與者的參與者地址、參與者姓名、參與者狀態(tài)和參與者的消息會話轉(zhuǎn)播協(xié)議(MSRP)客戶端路徑信息中的至少一種，生成文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)；并根據(jù)所述文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)、表示 “接受邀請”的參數(shù)值和相應的文件傳輸會話的標示符，生成一個邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體；根據(jù)所述消息頭和消息體生成所述接受文件傳輸邀請消息；所述服務器中的消息生成裝置又包括消息頭生成子裝置，用于根據(jù)HTTP表示“無內(nèi)容(No Content) ”的響應符，生成消息頭；消息生成子裝置，用于根據(jù)所述消息頭生成接受文件傳輸邀請響應消息?；谏鲜龇桨?，Web開發(fā)商、第三方開發(fā)者或業(yè)務提供商等用戶可以通過客戶端， 使用REST API訪問調(diào)用電信運營商網(wǎng)絡域中的電信能力，進行接受文件傳輸邀請的相關(guān)控制。有鑒于此，本發(fā)明的另一個目的在于提供一種拒絕文件傳輸邀請的方法及系統(tǒng)， 以解決用戶不能調(diào)用電信能力，實現(xiàn)拒絕文件傳輸邀請的相關(guān)控制的問題。為了解決上述問題，本發(fā)明提供了一種拒絕文件傳輸邀請的方法，該方法基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變(REST)應用編程接口(API)實現(xiàn)，包括客戶端向服務器發(fā)送拒絕文件傳輸邀請消息，攜帶使用的動作和資源的信息，及表示拒絕邀請的信息，所述資源用統(tǒng)一資源位置符(URL)標示；所述服務器收到所述拒絕文件傳輸邀請消息后，向所述客戶端返回拒絕文件傳輸邀請響應消息。較佳地使用的所述動作為HTTP的布置(POST)動作或設定(PUT)動作或刪除(DELETE)動作，所述資源的資源URL包含終端參與者的用戶標示符和文件傳輸邀請的標示符中的至少一種。較佳地客戶端發(fā)送拒絕文件傳輸邀請消息之前，按以下方式生成所述拒絕文件傳輸邀請消息以HTTP的布置(POST)動作或設定(PUT)動作或刪除(DELETE)動作為使用的動作，以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包括被邀請的終端參與者的用戶標示符和/或文件傳輸邀請的標示符；根據(jù)表示“拒絕邀請”的參數(shù)值和相應的文件傳輸會話的標示符生成一個邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體；根據(jù)所述消息頭和消息體生成所述拒絕文件傳輸邀請消息。較佳地終端參與者拒絕文件傳輸邀請成功時，所述服務器返回拒絕文件傳輸邀請響應消息之前，通過以下方式來生成拒絕文件傳輸邀請響應消息根據(jù)HTTP表示“無內(nèi)容(No Content) ”的響應符，生成消息頭；根據(jù)所述消息頭生成拒絕文件傳輸邀請響應消息。相應地，本發(fā)明還提供了一種拒絕文件傳輸邀請的系統(tǒng)，客戶端和服務器基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變(REST)應用編程接口(API)交互，包括客戶端中的消息生成裝置，用于生成拒絕文件傳輸邀請消息；客戶端中的消息發(fā)送裝置，用于向服務器發(fā)送拒絕文件傳輸邀請消息；服務器中的消息接收和處理裝置，用于在收到拒絕文件傳輸邀請消息后進行解析和處理；服務器中的消息生成裝置，用于生成拒絕文件傳輸邀請響應消息；服務器中的消息發(fā)送裝置，用于向所述客戶端返回拒絕文件傳輸邀請響應消息。較佳地所述客戶端中的消息生成裝置又包括消息頭生成子裝置，用于以HTTP的布置(POST)動作或設定(PUT)動作或刪除 (DELETE)動作為使用的動作，以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包括被邀請的終端參與者的用戶標示符和/或文件傳輸邀請的標示符；消息體生成子裝置，用于根據(jù)表示“拒絕邀請”的參數(shù)值和相應的文件傳輸會話的標示符生成一個邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體；消息生成子裝置，用于根據(jù)所述消息頭和消息體生成所述拒絕文件傳輸邀請消息；所述服務器中的消息生成裝置又包括消息頭生成子裝置，用于根據(jù)HTTP表示“無內(nèi)容(No Content) ”的響應符，生成消息頭；消息生成子裝置，用于根據(jù)所述消息頭生成拒絕文件傳輸邀請響應消息?；谏鲜龇桨福琖eb開發(fā)商、第三方開發(fā)者或業(yè)務提供商等用戶可以通過客戶端， 使用REST API訪問調(diào)用電信網(wǎng)絡域中的電信能力，進行拒絕文件傳輸邀請的相關(guān)控制。


圖1為本發(fā)明實施例開放電信能力接口的系統(tǒng)結(jié)構(gòu)的示意圖；圖2為本發(fā)明實施例一接受文件傳輸邀請的方法的流程圖；圖3為本發(fā)明實施例二拒絕文件傳輸邀請的方法的流程圖；圖4為本發(fā)明實施例被邀請的客戶端和服務器之間進行接受文件傳輸邀請、拒絕文件傳輸邀請相關(guān)操作的示意圖。
具體實施例方式為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下文中將結(jié)合附圖對本發(fā)明的實施例進行詳細說明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互任意組合。實施例一圖1示出了本實施例開放文件傳輸業(yè)務電信能力接口的系統(tǒng)結(jié)構(gòu)。如圖所示，電信網(wǎng)絡域包含IMS核心網(wǎng)和業(yè)務層，業(yè)務層包含短信業(yè)務服務器、彩信業(yè)務服務器、文件傳輸業(yè)務服務器(如RCS文件傳輸業(yè)務引擎)以及其他業(yè)務服務器等各種業(yè)務網(wǎng)絡設備，但是，本發(fā)明用于文件傳輸業(yè)務的服務器也可以同時用于其他多種業(yè)務，并不局限于專用的服務器。這些服務器向Web開發(fā)商、第三方開發(fā)者、業(yè)務提供商等提供開放的REST APLffeb 開發(fā)商、第三方開發(fā)者、業(yè)務提供商等用戶的客戶端可以使用REST API訪問電信網(wǎng)絡域，調(diào)用電信網(wǎng)絡域的RCS業(yè)務能力和IMS網(wǎng)絡能力，實現(xiàn)電信業(yè)務的Wfeb 2. Offidget輕量級應用與Mashup的開發(fā)。本實施例中，Web開發(fā)商、第三方開發(fā)者、業(yè)務提供商等用戶開發(fā)的應用程序可以通過客戶端，使用本實施例提供的REST API對服務器進行接受文件傳輸邀請的相關(guān)控制。 客戶端可以位于業(yè)務提供商的網(wǎng)絡設備中，也可以位于終端用戶設備如移動終端、固定終端等中。本發(fā)明適用的用戶也不限于上述類型，可以是基于互聯(lián)網(wǎng)服務、WEB服務的任何有控制權(quán)限的文件傳輸參與者。文中，接受文件傳輸邀請(Accept FileTransfer Request)也可以稱為接受文件傳輸請求，拒絕文件傳輸邀請(Decline FileTransfer Request)也可以稱為拒絕文件傳輸請求。本實施例中REST API使用的資源、動作和數(shù)據(jù)結(jié)構(gòu)的相關(guān)定義如下
權(quán)利要求
1.一種接受文件傳輸邀請的方法，該方法基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變 (REST)應用編程接口(API)實現(xiàn)，包括客戶端向服務器發(fā)送接受文件傳輸邀請消息，攜帶使用的動作和資源的信息，所述資源用統(tǒng)一資源位置符(URL)標示；所述服務器收到所述接受文件傳輸邀請消息后，向所述客戶端返回接受文件傳輸邀請響應消息。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于使用的所述動作為HTTP的布置(POST)動作或設定(PUT)動作，所述資源的資源URL 包含終端參與者的用戶標示符和文件傳輸邀請的標示符中的至少一種。
3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于所述接受文件傳輸邀請消息還包括被邀請的終端參與者的參與者地址、參與者姓名、 參與者狀態(tài)和參與者的消息會話轉(zhuǎn)播協(xié)議(MSRP)客戶端路徑信息中的至少一種。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，客戶端發(fā)送接受文件傳輸邀請消息之前， 按以下方式生成所述接受文件傳輸邀請消息以HTTP的布置(POST)動作或設定(PUT)動作為使用的動作，以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包含被邀請的終端參與者的用戶標示符和/ 或文件傳輸邀請的標示符；根據(jù)表示“接受邀請”的參數(shù)值生成邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體； 根據(jù)所述消息頭和消息體生成所述接受文件傳輸邀請消息。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于生成所述邀請反饋的數(shù)據(jù)結(jié)構(gòu)之前，先根據(jù)被邀請的終端參與者的參與者地址、參與者姓名、參與者狀態(tài)和參與者的消息會話轉(zhuǎn)播協(xié)議(MSRP)客戶端路徑信息中的至少一種， 生成文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)；生成所述邀請反饋的數(shù)據(jù)結(jié)構(gòu)時，還將所述文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)和相應的文件傳輸會話的標示符寫入所述邀請反饋的數(shù)據(jù)結(jié)構(gòu)。
6.根據(jù)權(quán)利要求1或4或5所述的方法，其特征在于終端參與者接受文件傳輸邀請成功時，所述服務器返回接受文件傳輸邀請響應消息之前，通過以下方式來生成接受文件傳輸邀請響應消息根據(jù)HTTP表示“無內(nèi)容(No Content)，，的響應符，生成消息頭； 根據(jù)所述消息頭生成接受文件傳輸邀請響應消息。
7.一種拒絕文件傳輸邀請的方法，該方法基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變 (REST)應用編程接口(API)實現(xiàn)，包括客戶端向服務器發(fā)送拒絕文件傳輸邀請消息，攜帶使用的動作和資源的信息，所述資源用統(tǒng)一資源位置符(URL)標示；所述服務器收到所述拒絕文件傳輸邀請消息后，向所述客戶端返回拒絕文件傳輸邀請響應消息。
8.根據(jù)權(quán)利要求7所述的方法，其特征在于使用的所述動作為HTTP的布置(POST)動作或設定(PUT)動作或刪除(DELETE)動作， 所述資源的資源URL包含終端參與者的用戶標示符和文件傳輸邀請的標示符中的至少一種。
9.根據(jù)權(quán)利要求7所述的方法，其特征在于，客戶端發(fā)送拒絕文件傳輸邀請消息之前， 按以下方式生成所述拒絕文件傳輸邀請消息以HTTP的布置(POST)動作或設定(PUT)動作或刪除(DELETE)動作為使用的動作，以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包括被邀請的終端參與者的用戶標示符和/或文件傳輸邀請的標示符；根據(jù)表示“拒絕邀請”的參數(shù)值和相應的文件傳輸會話的標示符生成一個邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體；根據(jù)所述消息頭和消息體生成所述拒絕文件傳輸邀請消息。
10.根據(jù)權(quán)利要求7或9所述的方法，其特征在于終端參與者拒絕文件傳輸邀請成功時，所述服務器返回拒絕文件傳輸邀請響應消息之前，通過以下方式來生成拒絕文件傳輸邀請響應消息根據(jù)HTTP表示“無內(nèi)容(No Content)，，的響應符，生成消息頭； 根據(jù)所述消息頭生成拒絕文件傳輸邀請響應消息。
11.一種接受文件傳輸邀請的系統(tǒng)，客戶端和服務器基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變(REST)應用編程接口(API)交互，該系統(tǒng)包括客戶端中的消息生成裝置，用于生成接受文件傳輸邀請消息；客戶端中的消息發(fā)送裝置，用于向服務器發(fā)送接受文件傳輸邀請消息；服務器中的消息接收和處理裝置，用于在收到接受文件傳輸邀請消息后進行解析和處理；服務器中的消息生成裝置，用于生成接受文件傳輸邀請響應消息； 服務器中的消息發(fā)送裝置，用于向所述客戶端返回所述接受文件傳輸邀請響應消息。
12.如權(quán)利要求11所述的系統(tǒng)，其特征在于 所述客戶端中的消息生成裝置又包括消息頭生成子裝置，用于以HTTP的布置(POST)動作或設定(PUT)動作為使用的動作， 以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包含被邀請的終端參與者的用戶標示符和/或文件傳輸邀請的標示符；消息體生成子裝置，用于根據(jù)被邀請的終端參與者的參與者地址、參與者姓名、參與者狀態(tài)和參與者的消息會話轉(zhuǎn)播協(xié)議(MSRP)客戶端路徑信息中的至少一種，生成文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)；并根據(jù)所述文件傳輸會話參與者信息的數(shù)據(jù)結(jié)構(gòu)、表示“接受邀請”的參數(shù)值和相應的文件傳輸會話的標示符，生成一個邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體；根據(jù)所述消息頭和消息體生成所述接受文件傳輸邀請消息； 所述服務器中的消息生成裝置又包括消息頭生成子裝置，用于根據(jù)HTTP表示“無內(nèi)容(No Content)”的響應符，生成消息頭；消息生成子裝置，用于根據(jù)所述消息頭生成接受文件傳輸邀請響應消息。
13.一種拒絕文件傳輸邀請的系統(tǒng)，客戶端和服務器基于電信網(wǎng)絡域提供的表象化狀態(tài)轉(zhuǎn)變(REST)應用編程接口(API)交互，包括客戶端中的消息生成裝置，用于生成拒絕文件傳輸邀請消息；客戶端中的消息發(fā)送裝置，用于向服務器發(fā)送拒絕文件傳輸邀請消息；服務器中的消息接收和處理裝置，用于在收到拒絕文件傳輸邀請消息后進行解析和處理；服務器中的消息生成裝置，用于生成拒絕文件傳輸邀請響應消息； 服務器中的消息發(fā)送裝置，用于向所述客戶端返回拒絕文件傳輸邀請響應消息。 14.如權(quán)利要求13所述的系統(tǒng)，其特征在于 所述客戶端中的消息生成裝置又包括消息頭生成子裝置，用于以HTTP的布置(POST)動作或設定(PUT)動作或刪除 (DELETE)動作為使用的動作，以文件傳輸邀請反饋為使用的資源，生成消息頭，所述資源的資源URL包括被邀請的終端參與者的用戶標示符和/或文件傳輸邀請的標示符；消息體生成子裝置，用于根據(jù)表示“拒絕邀請”的參數(shù)值和相應的文件傳輸會話的標示符生成一個邀請反饋的數(shù)據(jù)結(jié)構(gòu)，作為消息體；消息生成子裝置，用于根據(jù)所述消息頭和消息體生成所述拒絕文件傳輸邀請消息； 所述服務器中的消息生成裝置又包括消息頭生成子裝置，用于根據(jù)HTTP表示“無內(nèi)容(No Content)”的響應符，生成消息頭；消息生成子裝置，用于根據(jù)所述消息頭生成拒絕文件傳輸邀請響應消息。
全文摘要
一種接受文件傳輸邀請和拒絕文件傳輸邀請的方法及系統(tǒng)，基于電信網(wǎng)絡域提供的REST API實現(xiàn)，拒絕文件傳輸邀請時，客戶端向服務器發(fā)送拒絕文件傳輸邀請消息，攜帶使用的動作和資源的信息，及表示拒絕邀請的信息；服務器收到所述拒絕文件傳輸邀請消息后，向所述客戶端返回拒絕文件傳輸邀請響應消息。接受文件傳輸邀請時，客戶端向服務器發(fā)送接受文件傳輸邀請消息，攜帶使用的動作和資源的信息，及表示接受邀請的信息；所述服務器收到所述接受文件傳輸邀請消息后，向所述客戶端返回接受文件傳輸邀請響應消息。本發(fā)明可以解決用戶不能調(diào)用電信能力實現(xiàn)接受和拒絕文件傳輸邀請的相關(guān)控制的問題。
文檔編號H04L29/08GK102469137SQ20101054826
公開日2012年5月23日 申請日期2010年11月17日 優(yōu)先權(quán)日2010年11月17日
發(fā)明者邵偉翔 申請人:中興通訊股份有限公司