CN102469137B - 一种接受文件传输邀请和拒绝文件传输邀请的方法及*** - Google Patents

Abstract

一种接受文件传输邀请和拒绝文件传输邀请的方法及***，基于电信网络域提供的REST API实现，拒绝文件传输邀请时，客户端向服务器发送拒绝文件传输邀请消息，携带使用的动作和资源的信息，及表示拒绝邀请的信息；服务器收到所述拒绝文件传输邀请消息后，向所述客户端返回拒绝文件传输邀请响应消息。接受文件传输邀请时，客户端向服务器发送接受文件传输邀请消息，携带使用的动作和资源的信息，及表示接受邀请的信息；所述服务器收到所述接受文件传输邀请消息后，向所述客户端返回接受文件传输邀请响应消息。本发明可以解决用户不能调用电信能力实现接受和拒绝文件传输邀请的相关控制的问题。

Description

一种接受文件传输邀请和拒绝文件传输邀请的方法及***

技术领域

本发明涉及文件传输，尤其涉及一种接受文件传输邀请和拒绝文件传输邀请的方法及***。

背景技术

面对信息通信产业周期的演进以及消费者模式的变迁大潮，面对互联网的骨灰级创新模式以及新媒体的广泛传播、甚至是IT厂商、内容整合者与消费电子厂商向运营领域的渗透，电信运营商正在采取一种积极的融合、开放的态度，努力尝试开放其电信能力，集思广益，发挥第三方企业与个人的创新能力，打造丰富的增值应用；另一方面，借用这种电信服务的二次分发渠道，促进基本电信服务的销售。尤其是终端与软件厂商在在线应用商店市场烽烟四起之时，运营商必须要利用电信能力(可靠的通信服务；用户数据；情境；认证；计费等)打造一条新的差异化的道路。

1998年Parlay组织成立致力于为电话网络开发API(应用编程接口)。借助这些API，第三方机构可以创建自己的应用。Parlay组织在这方面做了统一的标准化工作，制定了基于CORBA(公共对象资源代理架构)的Parlay/OSA(开放服务架构)API，对各种电信能力的使用进行编程方面的统一工作。另外Parlay/OSA API也获得了ETSI(欧洲电信标准协会)与3GPP(第三代移动通信合作伙伴计划标准组织)共同协助。在3GPP中，Parlay被当成开放服务架构(OSA)的一部分。Parlay X是Parlay、3GPP和OMA(开放移动联盟)颁发的基于SOAP(简单对象访问协议)Web服务的API标准规范。Parlay REST(面向Parlay X的RESTful约束)，是OMA最新颁发的一套API标准规范，旨在为OMA中的Parlay X Web服务规范(子)集指定REST Web服务约束。

在Web 2.0领域，支持Ajax(异步JavaScript脚本和XML可扩展标签语言)技术的API相对应用比较广泛，风格为REST(REpresentational StateTransfer，表象化状态转变)。REST不是一种新技术，也不是一种标准，而是一组设计原则；与基于SOAP的Web服务(如Parlay X)相比，REST API更加轻量级，具有更优良的开发者友好性，便于Web应用的开发和Mashup。因此越来越多的Web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的(***)。

GSMA(全球移动***协会)RCS(富通信套件)是基于现有IMS(IP多媒体子***)网络设施和开发协议搭建出来的提供可互操作的丰富通信功能的业务包，主要包括增强型地址簿、增强型呼叫、增强型融合消息等业务，使用户可以对自己的呈现(如个人图片、留言、推荐链接以及状态)进行更新，也可以在手机的通讯录中实时看到好友的呈现情况，并实现短信、彩信、聊天(即时消息)、文件传输等多种通信需求。RCS是包括运营商、设备商和手机终端厂商共同支持的统一的技术及实现标准，因此它不但容易培养消费者较为一致的使用习惯，而且可以实现不同国家、不同运营商的互联互通。后续阶段，RCS将进一步引入社交网络、开放式REST API应用编程接口、与互联网集成应用商店等内容。RCS REST风格API的目标用户是典型的Web开发商、第三方开发者、业务提供商，通过API可以将电信运营商的RCS业务能力和IMS网络能力开放，更适合Web 2.0Widget轻量级应用与Mashup的开发，迎合Web应用的发展趋势。

目前，电信运营商短信、彩信的业务能力已经可以通过OMA(开放移动联盟)制定的ParlayREST2.0协议标准开放，而文件传输业务能力还没有制定相应的协议标准开放，用户还不能够调用电信能力实现接受文件传输邀请和拒绝文件传输邀请的相关控制。

发明内容

有鉴于此，本发明的一个目的在于提供一种接受文件传输邀请的方法及***，以解决用户不能调用电信能力，实现接受文件传输邀请的相关控制的问题。

为了解决上述问题，本发明提供了一种接受文件传输邀请的方法，该方法基于电信网络域提供的表象化状态转变(REST)应用编程接口(API)实现，包括：

客户端向服务器发送接受文件传输邀请消息，携带使用的动作和资源的信息，及表示接受邀请的信息，所述资源用统一资源位置符(URL)标示；

所述服务器收到所述接受文件传输邀请消息后，向所述客户端返回接受文件传输邀请响应消息。

较佳地

使用的所述动作为HTTP的布置(POST)动作或设定(PUT)动作，所述资源的资源URL包含终端参与者的用户标示符和文件传输邀请的标示符中的至少一种。

较佳地

所述接受文件传输邀请消息还包括被邀请的终端参与者的参与者地址、参与者姓名、参与者状态和参与者的消息会话转播协议(MSRP)客户端路径信息中的至少一种。

较佳地

客户端发送接受文件传输邀请消息之前，按以下方式生成所述接受文件传输邀请消息：

以HTTP的布置(POST)动作或设定(PUT)动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包含被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

根据表示“接受邀请”的参数值生成邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成所述接受文件传输邀请消息。

较佳地

生成所述邀请反馈的数据结构之前，先根据被邀请的终端参与者的参与者地址、参与者姓名、参与者状态和参与者的消息会话转播协议(MSRP)客户端路径信息中的至少一种，生成文件传输会话参与者信息的数据结构；

生成所述邀请反馈的数据结构时，还将所述文件传输会话参与者信息的数据结构和相应的文件传输会话的标示符写入所述邀请反馈的数据结构。

较佳地

终端参与者接受文件传输邀请成功时，所述服务器返回接受文件传输邀请响应消息之前，通过以下方式来生成接受文件传输邀请响应消息：

根据HTTP表示“无内容(No Content)”的响应符，生成消息头；

根据所述消息头生成接受文件传输邀请响应消息。

相应地，本发明还提供了一种接受文件传输邀请的***，客户端和服务器基于电信网络域提供的表象化状态转变(REST)应用编程接口(API)交互，该***包括：

客户端中的消息生成装置，用于生成接受文件传输邀请消息；

客户端中的消息发送装置，用于向服务器发送接受文件传输邀请消息；

服务器中的消息接收和处理装置，用于在收到接受文件传输邀请消息后进行解析和处理；

服务器中的消息生成装置，用于生成接受文件传输邀请响应消息；

服务器中的消息发送装置，用于向所述客户端返回所述接受文件传输邀请响应消息。

较佳地

所述客户端中的消息生成装置又包括：

消息头生成子装置，用于以HTTP的布置(POST)动作或设定(PUT)动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包含被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

消息体生成子装置，用于根据被邀请的终端参与者的参与者地址、参与者姓名、参与者状态和参与者的消息会话转播协议(MSRP)客户端路径信息中的至少一种，生成文件传输会话参与者信息的数据结构；并根据所述文件传输会话参与者信息的数据结构、表示“接受邀请”的参数值和相应的文件传输会话的标示符，生成一个邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成所述接受文件传输邀请消息；

所述服务器中的消息生成装置又包括：

消息头生成子装置，用于根据HTTP表示“无内容(No Content)”的响应符，生成消息头；

消息生成子装置，用于根据所述消息头生成接受文件传输邀请响应消息。

基于上述方案，Web开发商、第三方开发者或业务提供商等用户可以通过客户端，使用REST API访问调用电信运营商网络域中的电信能力，进行接受文件传输邀请的相关控制。

有鉴于此，本发明的另一个目的在于提供一种拒绝文件传输邀请的方法及***，以解决用户不能调用电信能力，实现拒绝文件传输邀请的相关控制的问题。

为了解决上述问题，本发明提供了一种拒绝文件传输邀请的方法，该方法基于电信网络域提供的表象化状态转变(REST)应用编程接口(API)实现，包括：

客户端向服务器发送拒绝文件传输邀请消息，携带使用的动作和资源的信息，及表示拒绝邀请的信息，所述资源用统一资源位置符(URL)标示；

所述服务器收到所述拒绝文件传输邀请消息后，向所述客户端返回拒绝文件传输邀请响应消息。

较佳地

使用的所述动作为HTTP的布置(POST)动作或设定(PUT)动作或删除(DELETE)动作，所述资源的资源URL包含终端参与者的用户标示符和文件传输邀请的标示符中的至少一种。

较佳地

客户端发送拒绝文件传输邀请消息之前，按以下方式生成所述拒绝文件传输邀请消息：

以HTTP的布置(POST)动作或设定(PUT)动作或删除(DELETE)动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包括被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

根据表示“拒绝邀请”的参数值和相应的文件传输会话的标示符生成一个邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成所述拒绝文件传输邀请消息。

较佳地

终端参与者拒绝文件传输邀请成功时，所述服务器返回拒绝文件传输邀请响应消息之前，通过以下方式来生成拒绝文件传输邀请响应消息：

根据HTTP表示“无内容(No Content)”的响应符，生成消息头；

根据所述消息头生成拒绝文件传输邀请响应消息。

相应地，本发明还提供了一种拒绝文件传输邀请的***，客户端和服务器基于电信网络域提供的表象化状态转变(REST)应用编程接口(API)交互，包括：

客户端中的消息生成装置，用于生成拒绝文件传输邀请消息；

客户端中的消息发送装置，用于向服务器发送拒绝文件传输邀请消息；

服务器中的消息接收和处理装置，用于在收到拒绝文件传输邀请消息后进行解析和处理；

服务器中的消息生成装置，用于生成拒绝文件传输邀请响应消息；

服务器中的消息发送装置，用于向所述客户端返回拒绝文件传输邀请响应消息。

较佳地

所述客户端中的消息生成装置又包括：

消息头生成子装置，用于以HTTP的布置(POST)动作或设定(PUT)动作或删除(DELETE)动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包括被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

消息体生成子装置，用于根据表示“拒绝邀请”的参数值和相应的文件传输会话的标示符生成一个邀请反馈的数据结构，作为消息体；

消息生成子装置，用于根据所述消息头和消息体生成所述拒绝文件传输邀请消息；

所述服务器中的消息生成装置又包括：

消息头生成子装置，用于根据HTTP表示“无内容(No Content)”的响应符，生成消息头；

消息生成子装置，用于根据所述消息头生成拒绝文件传输邀请响应消息。

基于上述方案，Web开发商、第三方开发者或业务提供商等用户可以通过客户端，使用REST API访问调用电信网络域中的电信能力，进行拒绝文件传输邀请的相关控制。

附图说明

图1为本发明实施例开放电信能力接口的***结构的示意图；

图2为本发明实施例一接受文件传输邀请的方法的流程图；

图3为本发明实施例二拒绝文件传输邀请的方法的流程图；

图4为本发明实施例被邀请的客户端和服务器之间进行接受文件传输邀请、拒绝文件传输邀请相关操作的示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

实施例一

图1示出了本实施例开放文件传输业务电信能力接口的***结构。如图所示，电信网络域包含IMS核心网和业务层，业务层包含短信业务服务器、彩信业务服务器、文件传输业务服务器(如RCS文件传输业务引擎)以及其他业务服务器等各种业务网络设备，但是，本发明用于文件传输业务的服务器也可以同时用于其他多种业务，并不局限于专用的服务器。这些服务器向Web开发商、第三方开发者、业务提供商等提供开放的REST API，Web开发商、第三方开发者、业务提供商等用户的客户端可以使用REST API访问电信网络域，调用电信网络域的RCS业务能力和IMS网络能力，实现电信业务的Web 2.0Widget轻量级应用与Mashup的开发。

本实施例中，Web开发商、第三方开发者、业务提供商等用户开发的应用程序可以通过客户端，使用本实施例提供的REST API对服务器进行接受文件传输邀请的相关控制。客户端可以位于业务提供商的网络设备中，也可以位于终端用户设备如移动终端、固定终端等中。本发明适用的用户也不限于上述类型，可以是基于互联网服务、WEB服务的任何有控制权限的文件传输参与者。

文中，接受文件传输邀请(Accept FileTransfer Request)也可以称为接受文件传输请求，拒绝文件传输邀请(Decline FileTransfer Request)也可以称为拒绝文件传输请求。

本实施例中REST API使用的资源、动作和数据结构的相关定义如下：

资源统一资源位置符链接中，serverRoot表示服务器路径，apiVersion表示API版本，FileTransfer表示文件传输，Terminating表示终端(被邀请方)，TerminatingID表示终端参与者的用户标示符，如可以采用终端参与者地址。{FileTransferRequest Id}表示文件传输邀请标示符。

上述REST API使用的数据结构类型定义如下：

数据结构类型Type：Requestfeedback邀请反馈

数据结构类型Type：FileTransferParticipantInformation文件传输会话参与者信息

其中，文件传输会话参与者(包括源端、终端)的资源URL可以包含文件传输会话的资源URL和参与者标示符(participantId)表示，文件传输会话的资源URL可以包含参与者用户标示符和文件传输会话标示符。

枚举Enumeration：FileTransferParticipantStatus文件传输会话参与者状态

图2为本实施例基于REST API接受文件传输邀请的流程图，包括以下步骤：

步骤S201：客户端向服务器发送接受文件传输邀请消息，携带使用的动作和资源的信息，及表示接受邀请的信息，所述资源用资源统一资源位置符(URL)标示；

本实施例的接受文件传输邀请消息中，消息头中包括使用的动作和资源，消息体中包括邀请反馈的数据结构。

客户端可以通过以下方式生成该消息：

以HTTP的布置(POST)动作或设定(PUT)动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包含被邀请的终端参与者的用户标示符和文件传输邀请的标示符中的至少一个；

按照XML格式，根据表示“接受邀请”的参数值生成邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成接受文件传输邀请消息。

可选地，在生成消息体时，先按照XML格式，根据被邀请的文件传输会话终端参与者的参与者地址、参与者姓名、参与者状态、参与者的MSRP(消息会话转播协议)客户端路径信息中的至少一种，生成文件传输会话参与者信息的数据结构，生成邀请反馈的数据结构时写入该文件传输会话参与者信息的数据结构。邀请反馈的数据结构还可以写入邀请加入的文件传输的文件传输会话标示符。

各实施例涉及的消息体，也可以采用XML外的其他专用格式如Java脚本对象符号(JSON)。

下面用一个示例来说明一下生成的接受文件传输邀请消息。

假定终端参与者为用户Peter E.Xample(SIP:user2example.com)，该用户接受文件传输邀请。

以下为接受文件传输邀请消息内容的示例及说明：

    POST

    http://{serverRoot}/{apiVersion}/FileTransfer/Terminating/SIP:user2example.com/FileTransferRequests/{Fi

    leTransferRequestIdl}/feedback HTTP/1.1\\动作+资源的HTTP URL

    Content-Type：application/xml

    Accept：application/xml

    Host：example.com:80

    <？xml version＝″1.0″encoding＝″UTF-8″？>

    <FileTransfer：Requestfeedback xmlns:FileTransfer＝″urn:oma:xml:rest:FileTransfer:1″>\\邀请反馈数据结构

    的开始

    <AcceptRequest>true</AcceptRequest>\\表示是否接受邀请的参数值

    <FileTransferSessionID>{FileTransferSessionId1}</FileTransferSessionID>\\文件传输会话标示符

    <Invitee>\\被邀请者的文件传输会话参与者信息数据结构的开始

    <participantAddress>SIP:user2example.com</participantAddress>

    <participantName>Peter E.Xample</participantName>

    <participantStatus>FileTransferParticipantAcceptRequest</participantStatus>

    <MSRPClientPath>msrp://Peter E.Xample.example.com:7575/u3978ae283wzd；tcp

</MSRPClientPath>

</Invitee>\\被邀请者的文件传输会话参与者信息数据结构的开始</FileTransfer:Requestfeedback>\\邀请反馈数据结构的结束

在本申请给出的若干消息内容的示例中，对REST API中定义的动作、资源、数据结构和部分信息作了说明，其他内容如数据结构中定义的信息，消息头中的其他内容等，请参照上文和Web中的规定。

步骤S202：所述服务器收到所述接受文件传输邀请消息后，向所述客户端返回接受文件传输邀请响应消息。

接受文件传输邀请响应消息中，消息头包括HTTP的响应符，可以不携带消息体。

终端参与者接受文件传输邀请成功时，服务器可以通过以下方式来生成该消息：

根据HTTP表示“无内容(No Content)”的响应符，生成消息头；

根据所述消息头生成接受文件传输邀请响应消息。

以下为接受文件传输邀请成功时，接受文件传输邀请响应消息内容的示例和说明：

HTTP/1.1204 No Content

Date：Mon，28Jun 2010 17:51:59 GMT

实施例二

本实施例涉及基于电信网络域提供的REST API拒绝文件传输邀请的相关控制。所基于的***与实施例一相同，资源、动作和数据结构的相关定义请参照实施例一中的说明。

图3为本实施例基于REST API拒绝文件传输邀请的流程图，包括以下步骤：

步骤S301：客户端向服务器发送拒绝文件传输邀请消息，携带使用的动作和资源的信息，及表示拒绝邀请的信息，所述资源用资源统一资源位置符(URL)标示；

拒绝文件传输邀请消息的消息头包括使用的动作和资源，消息体中包括邀请反馈的数据结构。

客户端可以通过以下方式来生成该消息：

以HTTP的布置(POST)动作或设定(PUT)动作或删除(DELETE)动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包括被邀请的终端参与者的用户标示符和文件传输邀请的标示符中的至少一个；

根据表示“拒绝邀请”的参数值和相应的文件传输会话的标示符中的至少一种，生成一个邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成所述拒绝文件传输邀请消息。

下面用一个示例来说明一下生成的拒绝文件传输邀请消息。

假定终端参与者为用户Peter E.Xample(SIP:user2example.com)，该用户请求拒绝邀请。

以下为拒绝文件传输邀请消息内容的示例及说明：

POST

http://{serverRoot}/{apiVersion}/FileTransfer/Terminating/SIP:user2example.com/FileTransferRequests/{Fi

leTransferRequestId1}/feedback HTTP/1.1\\动作+资源的资源URL

Content-Type：application/xml

Accept：application/xml

Host：example.com:80

<？xml version＝″1.0″encoding＝″UTF-8″？>

<FileTransfer：Requestfeedback xmlns:FileTransfer＝″urn:oma:xml:rest:FileTransfer:1″>\\邀请反馈数据结构

的开始

<AcceptRequest>false</AcceptRequest>\\表示是否接受邀请的参数值

<FileTransferSessionID>{FileTransferSessionId1}</FileTransferSessionID>\\文件传输会话标示符

 </FileTransfer:Requestfeedback>\\邀请反馈数据结构的结束

步骤S302：所述服务器收到所述拒绝文件传输邀请消息后，向所述客户端返回拒绝文件传输邀请响应消息。

终端参与者拒绝文件传输邀请成功时，拒绝文件传输邀请响应消息的消息头包括HTTP的响应符，可以不携带消息体。

该消息可以通过以下方式来生成：

根据HTTP表示“无内容(No Content)”的响应符生成消息头；

根据所述消息头生成拒绝文件传输邀请响应消息。

图4为综合上述实施例的，客户端和服务器之间接受文件传输邀请、拒绝文件传输邀请的操作示意图。

文件传输启动，文件传输邀请中(源端参与者已发出邀请)；

之后，客户端接受文件传输邀请，包括以下步骤：

客户端生成接受文件传输邀请消息；

客户端向服务器发送接受文件传输邀请消息；

服务器收到接受文件传输邀请消息后进行解析和处理，如，启动建立文件传输；

服务器生成接受文件传输邀请响应消息；

服务器向客户端返回接受文件传输邀请响应消息。

或者，客户端拒绝文件传输邀请，包括以下步骤：

客户端生成拒绝文件传输邀请消息；

客户端向服务器发送拒绝文件传输邀请消息；

服务器收到拒绝文件传输邀请消息后进行解析和处理，如，通知源端参与者；

服务器生成拒绝文件传输邀请响应消息；

服务器向客户端返回拒绝文件传输邀请响应消息。

上述各个消息的内容和生成方法请参见上文中的描述，不再重复。

上述方案中，具体说明了接受文件传输邀请和拒绝文件传输邀请的开放电信能力接口，各个消息的内容即可以满足文件传输业务的需要，又可以适用于现有的开放电信能力的相关规范如OMA中的相关规范、IEFT文件传输协议等。大大方便了Web开发商、第三方开发者或业务提供商等以REST风格的API灵活地对服务器进行接受文件传输邀请和拒绝文件传输邀请的相关控制。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现，相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种接受文件传输邀请的方法，该方法基于电信网络域提供的表象化状态转变REST应用编程接口API实现，包括：

客户端按以下方式生成接受文件传输邀请消息：

以HTTP的布置POST动作或设定PUT动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包含被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

根据表示“接受邀请”的参数值生成邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成所述接受文件传输邀请消息；

客户端向服务器发送接受文件传输邀请消息，携带使用的动作和资源的信息，所述资源用统一资源位置符URL标示；所述接受文件传输邀请消息还包括被邀请的终端参与者的参与者地址、参与者姓名、参与者状态、参与者的消息会话转播协议MSRP客户端路径信息、其他资源链接和客户端相关标签中的至少一种；

所述服务器收到所述接受文件传输邀请消息后，向所述客户端返回接受文件传输邀请响应消息。

2.根据权利要求1所述的方法，其特征在于：

生成所述邀请反馈的数据结构之前，先根据被邀请的终端参与者的参与者地址、参与者姓名、参与者状态、参与者的消息会话转播协议MSRP客户端路径信息、其他资源链接和客户端相关标签中的至少一种，生成文件传输会话参与者信息的数据结构；

生成所述邀请反馈的数据结构时，还将所述文件传输会话参与者信息的数据结构和相应的文件传输会话的标示符写入所述邀请反馈的数据结构。

3.根据权利要求1或2所述的方法，其特征在于：

终端参与者接受文件传输邀请成功时，所述服务器返回接受文件传输邀请响应消息之前，通过以下方式来生成接受文件传输邀请响应消息：

根据HTTP表示“无内容No Content”的响应符，生成消息头；

根据所述消息头生成接受文件传输邀请响应消息。

4.一种拒绝文件传输邀请的方法，该方法基于电信网络域提供的表象化状态转变REST应用编程接口API实现，包括：

客户端按以下方式生成拒绝文件传输邀请消息：

以HTTP的布置POST动作或设定PUT动作或删除DELETE动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包括被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

根据表示“拒绝邀请”的参数值和相应的文件传输会话的标示符生成一个邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成所述拒绝文件传输邀请消息；

客户端向服务器发送拒绝文件传输邀请消息，携带使用的动作和资源的信息，所述资源用统一资源位置符URL标示；

所述服务器收到所述拒绝文件传输邀请消息后，向所述客户端返回拒绝文件传输邀请响应消息；

所述邀请反馈的数据结构包括文件传输会话参与者信息，所述文件传输会话参与者信息包括参与者地址、参与者姓名、参与者状态、参与者的消息会话转播协议MSRP客户端路径信息、其他资源链接和客户端相关标签中的至少一种。

5.根据权利要求4所述的方法，其特征在于：

终端参与者拒绝文件传输邀请成功时，所述服务器返回拒绝文件传输邀请响应消息之前，通过以下方式来生成拒绝文件传输邀请响应消息：

根据HTTP表示“无内容No Content”的响应符，生成消息头；

根据所述消息头生成拒绝文件传输邀请响应消息。

6.一种接受文件传输邀请的***，客户端和服务器基于电信网络域提供的表象化状态转变REST应用编程接口API交互，该***包括：

客户端中的消息生成装置，用于生成接受文件传输邀请消息；

客户端中的消息发送装置，用于向服务器发送接受文件传输邀请消息；

服务器中的消息接收和处理装置，用于在收到接受文件传输邀请消息后进行解析和处理；

服务器中的消息生成装置，用于生成接受文件传输邀请响应消息；

服务器中的消息发送装置，用于向所述客户端返回所述接受文件传输邀请响应消息；

所述客户端中的消息生成装置又包括：

消息头生成子装置，用于以HTTP的布置POST动作或设定PUT动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包含被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

消息体生成子装置，用于根据被邀请的终端参与者的参与者地址、参与者姓名、参与者状态、参与者的消息会话转播协议MSRP客户端路径信息、其他资源链接和客户端相关标签中的至少一种，生成文件传输会话参与者信息的数据结构；并根据所述文件传输会话参与者信息的数据结构、表示“接受邀请”的参数值和相应的文件传输会话的标示符，生成一个邀请反馈的数据结构，作为消息体；

根据所述消息头和消息体生成所述接受文件传输邀请消息。

7.如权利要求6所述的***，其特征在于：

所述服务器中的消息生成装置又包括：

消息头生成子装置，用于根据HTTP表示“无内容No Content”的响应符，生成消息头；

消息生成子装置，用于根据所述消息头生成接受文件传输邀请响应消息。

8.一种拒绝文件传输邀请的***，客户端和服务器基于电信网络域提供的表象化状态转变REST应用编程接口API交互，包括：

客户端中的消息生成装置，用于生成拒绝文件传输邀请消息；

客户端中的消息发送装置，用于向服务器发送拒绝文件传输邀请消息；

服务器中的消息接收和处理装置，用于在收到拒绝文件传输邀请消息后进行解析和处理；

服务器中的消息生成装置，用于生成拒绝文件传输邀请响应消息；

服务器中的消息发送装置，用于向所述客户端返回拒绝文件传输邀请响应消息；

所述客户端中的消息生成装置又包括：

消息头生成子装置，用于以HTTP的布置POST动作或设定PUT动作或删除DELETE动作为使用的动作，以文件传输邀请反馈为使用的资源，生成消息头，所述资源的资源URL包括被邀请的终端参与者的用户标示符和/或文件传输邀请的标示符；

消息体生成子装置，用于根据表示“拒绝邀请”的参数值和相应的文件传输会话的标示符生成一个邀请反馈的数据结构，作为消息体；

消息生成子装置，用于根据所述消息头和消息体生成所述拒绝文件传输邀请消息；

所述邀请反馈的数据结构包括文件传输会话参与者信息，所述文件传输会话参与者信息包括参与者地址、参与者姓名、参与者状态、参与者的消息会话转播协议MSRP客户端路径信息、其他资源链接和客户端相关标签中的至少一种。

9.如权利要求8所述的***，其特征在于：

所述服务器中的消息生成装置又包括：

消息头生成子装置，用于根据HTTP表示“无内容No Content”的响应符，生成消息头；

消息生成子装置，用于根据所述消息头生成拒绝文件传输邀请响应消息。