[go: up one dir, main page]

CN101325585B - 文件传输方法、互连网关和客户端 - Google Patents

文件传输方法、互连网关和客户端 Download PDF

Info

Publication number
CN101325585B
CN101325585B CN2007101084790A CN200710108479A CN101325585B CN 101325585 B CN101325585 B CN 101325585B CN 2007101084790 A CN2007101084790 A CN 2007101084790A CN 200710108479 A CN200710108479 A CN 200710108479A CN 101325585 B CN101325585 B CN 101325585B
Authority
CN
China
Prior art keywords
domain
file
sip
imps
negotiation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN2007101084790A
Other languages
English (en)
Other versions
CN101325585A (zh
Inventor
牟伦建
卞永刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Zhitong World Technology Service Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN2007101084790A priority Critical patent/CN101325585B/zh
Priority to EP08757682A priority patent/EP2159982A4/en
Priority to PCT/CN2008/071271 priority patent/WO2008151572A1/zh
Publication of CN101325585A publication Critical patent/CN101325585A/zh
Application granted granted Critical
Publication of CN101325585B publication Critical patent/CN101325585B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明公开了一种文件传输方法，互连网关和客户端。其中，其能够获取第一域发送的第一协议类型的文件传输协商请求；获取第二域的反馈信息；根据第二域的反馈信息确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行第一域与第二域之间的文件传输。因此本发明能够实现SIP域与IMPS域之间相互传输文件给对方域前的协商，从而能够根据协商结果，避免不同域之间传输不必要的文件。

Description

文件传输方法、互连网关和客户端
技术领域
本发明涉及通信领域，尤其涉及文件传输技术。
背景技术
目前，对于移动通信的用户而言，其开展的消息业务可能有两种类型：一种是IMPS(Instant Messaging and Presence Service，即时消息和存在业务)域中的消息业务，其基于CSP(Client Server Protocol，客户端服务协议)/SSP(ServerServer Protocol，服务器服务协议)实现；另外一种是基于SIP(Session InitiatedProtocol，初始会话协议)域中的消息业务，例如SIMPLE(SIP Instant Messageand Presence Leveraging Extensions，SIP即时消息和呈现支持扩展)、CPM(Converged IP Message，融合IP消息)等等，其基于SIP协议实现。
上述两种类型的消息业务可以在IMPS域和SIP域之间交互，其基于如图1所示的IMPS域和SIP域互连组网示意图实现：
SIP域可以通过SIP MES SAGE(SIP消息)和MSRP(Message Session RelayProtocol，消息会话中继协议)，向IMPS域发送消息，或从IMPS域接收消息，GW(互连网关)完成IMPS消息和SIP MESSAGE/MSRP之间的转换。
由上述可以看出，基于图1所示的组网，可以在不同域之间，进行即时消息的交互、呈现信息的交互、开展会议等等。
文件传输作为一种特殊的业务消息交互形式，其具有独特的性质：例如，发送方在发送文件之前，可能会与接收方协商，如询问接收方是否接收该文件等；实际传输的时候文件会有文件名称，文件大小等属性；一个文件的传输都是单向的等等。下面以SIP域内的用户之间，以及IMPS域内的用户之间相互传输文件为例，说明文件传输所具有的特性：
目前SIP域内的用户之间传输文件的情况如下：
在实际传输文件之前，可以在控制层面通过SDP(Session DescriptionProtocol，会话描述协议)协商过程，协商MSRP会话用于文件传送，在SDP协商过程中会交换文件的元数据信息，协商可以由文件发送者发起，也可以由文件接收者发起。
目前IMPS域内的设备之间传输文件的情况如下：
IMPS域内，没有控制层面的文件发送协商过程，发送方根据自己的客户端能力发送文件，接收方的服务器可以根据接收方客户端能力选择接收，发送方也可以在发送文件之前通过邀请事务询问对方是否接收文件。IMPS域内的服务器可以通过发送消息事务传送IMPS域设备之间交互的文件，其将文件内容放入消息的内容元素中，文件名称、类型、大小在消息的信息结构中描述。
由现有技术可以看出，无论是SIP域内的不同设备之间相互传输文件，还是IMPS域内的不同设备之间相互传输文件，都需要在传输文件之前进行协商，以避免不需要的文件传输。然而如果SIP域和IMPS域之间互相传输文件，目前还没有相应的协商方法支持，从而无法避免SIP域和IMPS域之间可能相互传输对方域不能接收，或对方域不愿意接收的不必要文件。
发明内容
本发明的实施例提供一种用于文件传输的协商方法、互连网关和客户端，其能够实现SIP域与IMPS域之间相互传输文件给对方域前的协商。
本发明的实施例通过如下技术方案实现：
本发明的实施例提供一种文件传输方法，其包括：
获取第一域发送的第一协议类型的文件传输协商请求；
获取第二域反馈的第二协议类型的第二域客户端文件传输能力信息；
根据第二域的反馈信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行第一域与第二域之间的文件传输；
所述根据第二域的反馈信息确定协商结果的过程，包括：
根据所述文件传输能力信息，确定第二域不能够进行文件传输，则认为文件传输协商结果为失败；
或，根据所述文件传输能力信息，确定第二域能够进行文件传输，并将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的文件传输协商请求，并将所述第二协议类型传输协商请求传输给第二域；根据第二域针对到达的文件传输协商请求反馈的文件传输协商应答，确定与第二域协商的文件传输协商结果。
本发明的实施例还提供一种互连网关，其包括：
第一传输单元，用于获取第一域发送的第一协议类型的文件传输协商请求；
第二传输单元，用于获取第二域反馈的第二协议类型的第二域客户端文件传输能力信息；
第一协商结果确定单元，用于根据第二域的反馈信息，确定与所述文件传输协商请求相应的协商结果；
第一文件传输单元，用于根据所述协商结果进行第一域与第二域之间的文件传输；
所述根据第二域的反馈信息确定协商结果的过程，包括：
根据所述文件传输能力信息，确定第二域不能够进行文件传输，则认为文件传输协商结果为失败；
或，根据所述文件传输能力信息，确定第二域能够进行文件传输，并将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的文件传输协商请求，并将所述第二协议类型传输协商请求传输给第二域；根据第二域针对到达的文件传输协商请求反馈的文件传输协商应答，确定与第二域协商的文件传输协商结果。
本发明的实施例还提供一种客户端，其包括：
协商请求获取单元，用于接收基于增加文件元数据描述的IMPS协议类型的文件传输协商请求，所述基于增加文件元数据描述的IMPS协议类型的文件传输协商请求由互连网关提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息，将所述SDP描述信息中的元数据信息，添加到基于增加文件元数据描述的IMPS协议类型的协商请求中的文件元数据描述中；
应答单元，用于根据所述客户端的能力，判断是否能够进行文件传输，若不能，则作出文件传输协商失败应答；若能，则根据用户的响应或用户配置作出相应的文件传输协商应答。
本发明的实施例还提供另一种文件传输方法，其包括：
接收IMPS域发送的携带文件的IMPS协议类型消息后，针对所述文件的传输，发送基于SIP协议类型的文件传输协商请求给SIP域；
获取SIP域针对所述文件传输协商请求反馈的相应应答中携带的信息；
根据所述应答中携带的信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行IMPS域与SIP域之间的文件传输。
本发明的实施例还提供另一种互连网关，其包括：
协商请求传输单元，用于接收IMPS域发送的携带文件的IMPS协议类型消息后，针对所述文件的传输，发送基于SIP协议类型的文件传输协商请求给SIP域内设备；
第二协商结果确定单元，用于获取SIP域针对所述文件传输协商请求反馈的相应应答中携带的信息；
第二文件传输单元，用于根据所述应答中携带的信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行IMPS域与SIP域之间的文件传输。
依据本发明的实施例，能够获取第一域发送的第一协议类型的文件传输协商请求；获取第二域的反馈信息；根据第二域的反馈信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行第一域与第二域之间的文件传输。因此本发明实施例能够实现SIP域与IMPS域之间相互传输文件给对方域前的协商，从而能够根据协商结果，避免不同域之间传输不必要的文件。
附图说明
图1为背景技术提供的IMPS侧和SIP侧互连的组网图；
图2为本发明第一实施例的流程图；
图3为基于本发明第一实施例，SIP域向IMPS域发送文件的流程图；
图4为本发明第二实施例的流程图；
图5为基于本发明第二实施例，SIP域向IMPS域发送文件的流程图；
图6为本发明第二实施例的流程图；
图7为基于本发明第三实施例，IMPS域向SIP域发送文件的流程图；
图8为本发明第四实施例的流程图；
图9为IMPS客户端对增加文件元数据描述的文件传输协商请求的处理流程。
具体实施方式
本发明第一实施例提供了一种文件传输方法，其仍然基于如图1所示的组网而实现。本实施例中，第一域为SIP域，第一协议类型为SIP协议和/或SDP协议；第二域为IMPS域，第二协议类型为IMPS协议；其给出SIP域发送文件给IMPS域的实施过程，获取SIP域发送的SIP协议类型的文件发送协商请求；根据IMPS域反馈的信息，向SIP域返回所述文件发送协商请求对应的基于SIP协议类型的文件传输协商应答。根据IMPS域反馈的信息确定协商结果，根据协商结果进行不同域之间的文件传输。实现流程如图2所示，包括：
步骤S101，互连网关接收SIP域发送的SIP协议文件传输协商请求；该协商请求中携带SDP描述信息，用以描述发送文件请求的信息。
如果之前SIP域与该IMPS域之间没有会话，则该文件传输协商请求是一个新的SIP INVITE(SIP邀请)请求，如果之前SIP域与该IMPS域之间有会话，则该文件传输协商请求可以是SIP re-INVITE(SIP再邀请)请求，如果之前SIP域与该IMPS域之间有早期会话，则该文件传输协商请求可以SIPUPDATE(SIP更新)请求。
步骤S102，读取该SIP协议文件传输协商请求中的SDP，提取SDP中描述的所要传输文件的信息；
步骤S103，判断IMPS用户是否接收文件；如果IMPS用户接收文件，则转到步骤S104；否则，转到步骤S109；
判断IMPS用户是否接收文件可以分为两种情况：
1、判断用户是否能够接收文件
互连网关可以获取IMPS用户的Profile(特征)信息或者网络信息，根据其判断用户是否能够接收文件；
2、判断用户是否愿意接收文件
通过向IMPS服务器发送询问，IMPS服务器接收到该询问后，向用户发送询问，并将IMPS用户的应答返回给互连网关，或者根据用户配置确定用户是否愿意，然后返回相应的应答给互连网关；互连网关根据IMPS服务器返回的应答，判断用户是否愿意接收文件，可以通过Invite(邀请)消息或SystemMessage(系统消息)来实现该询问应答，Invite的类型可以是即时消息，也可以是端到端的应用程序。
步骤S104，回复文件传输协商请求成功响应给SIP域；
步骤S105，根据协商内容，建立用于文件传输的MSRP会话；
步骤S106，接收SIP域通过新建的MSRP会话发送的文件；
步骤S107，将接收到的文件，映射到IMPS域能够接收的IMPS协议的消息中，然后转发给IMPS域；
步骤S108，结束文件传输，根据情况重新协商新的会话或结束会话，结束流程；
步骤S109，将文件传输协商请求失败响应回复给SIP域，回到SIP域发送文件传输协商请求之前的状态。请求之前可能网关与SIP域之间存在会话，也可能不存在会话，结束流程。
本发明第一实施例中，如果SIP域发出的文件传输协商请求中包含多个文件发送请求，则IMPS侧针对每个文件发送请求，单独检查用户是否接收文件，将检查结果合成到一个SDP描述信息中，然后通过携带该SDP描述信息的SIP应答，回复给SIP域。
下面举例对本发明第一实施例进行详细说明。该实例中，第一域为SIP域，第一协议类型为SIP协议和/或SDP协议；第二域为IMPS域，第二协议类型为IMPS协议；该实例的具体实施过程如图3所示，包括：
步骤S201，SIP域想向IMPS域发送一个文件，其通过SIP Client(SIP客户端，包括一些基于SIP的业务客户端)发送SIP INVITE请求，请求中包含用于文件传输的SDP描述信息，该SDP描述信息中包含：表示该请求是一个文件发送请求的信息，文件的名称、类型、大小、散列值等等，可以描述如下：
Figure GSB00000799396600071
步骤S202，SIP INVITE请求首先被路由到SIP Server(SIP服务器，包括SIP/IP核心和一些基于SIP的业务服务器)，SIP Server经过一定的处理，例如确定下一步的路由，将SIP INVITE转发到GW。
步骤S203，GW收到该SIP INVITE，根据其中携带的SDP描述信息，判断是一个文件发送请求，因此首先向IMPS Server(IMPS服务器)请求获取IMPS域用户的profile信息，其可以通过GetUserProfileRequest(获取用户特征请求)请求获取接收者的profile信息。
步骤S204，GW接收IMPS Server返回的UserProfile(用户特征)响应，根据响应中用户的profile信息，判断IMPS域用户是否能够接收该文件。
步骤S205，GW判断出IMPS域用户能够接收该文件后，进一步向IMPSServer发出InviteRequest(邀请请求)，询问IMPS域用户是否愿意接收文件，该请求中的Invite-Type元素可以设置成“IM”(代表即时消息)或“AP”(代表端到端的应用)，如果是“IM”，协商成功后就以即时消息承载文件，如果是“AP”，协商成功后就用协商中商定的应用程序发送文件，本实施例中假设Invite-Type元素设置成“IM”，请求的Invite-Reason(邀请原因)元素可以描述该邀请用于文件传送，并包括SDP中获取的所要发送文件的属性，请求的Validity(有效期)元素可以根据GW设置设定，该值与SIP域的SIP INVITE能够维持的时间相等，如果在该时间内GW没有收到IMPS侧的应答，则返回SIP侧的失败响应；如果判断IMPS域不能接收文件，则可以向SIP域发送者返回SIP响应，响应的SDP中将该文件传送媒体流端口设成0，表示协商不成功。
步骤S206，IMPS Server向GW返回InviteRequest请求对应的Status(状态响应)。
步骤S207，IMPS Server将InviteRequest请求转换成InviteUserRequest(邀请用户请求)，向IMPS Client发送。
步骤S208，IMPS Client接收InviteUserRequest请求，呈现给IMPS用户，同时向IMPS Server返回Status响应。
步骤S209，在步骤S204之后，GW可以向SIP侧返回对应SIP INVITE的SIP 183(SIP临时响应)，临时响应首先被发送到SIP Server。
步骤S210，SIP Server转发SIP 183响应到SIP Client。
步骤S211，IMPS侧，步骤S208之后，IMPS域用户同意接收文件，通过IMPS Client(IMPS客户端)向IMPS Server发送InviteUserResponse响应，将响应的Invite-Acceptance(邀请接受)属性设置为“Yes”，表明IMPS域用户同意接收即时消息，如果IMPS域用户不同意接收文件，可以将响应的Invite-Acceptance属性设置为“No”。
步骤S212，IMPS Server接收InviteUserResponse(邀请用户响应)，返回对应的Status响应。
步骤S213，IMPS Server将InviteUserResponse响应转换成InviteResponse(邀请响应)，发送给GW。
步骤S214，GW返回Status响应。
步骤S215，GW根据InviteResponse中Invite-Acceptance属性值，确认IMPS域用户同意接收文件，因此返回SIP 200 OK响应，响应中携带的SDP描述信息包括：表示该请求是一个文件接收请求，文件的名称、类型、大小、散列值等等，例如：
Figure GSB00000799396600101
步骤S216，SIP Server向SIP Client转发SIP 200OK(SIP成功响应)。
步骤S217，SIP Client返回SIPACK(SIP确认)。
步骤S218，SIP Server向GW转发SIPACK。
步骤S219，SIP Client和GW之间建立用于文件传输的MSRP会话。
步骤S220，SIP Client利用MSRP SEND向GW发送文件，根据文件大小，可能包含多个MSRP SEND(MSRP发送请求)。
步骤S221，GW向SIP Client返回MSRP OK(MSRP成功响应)。
步骤S222，文件传输完毕后，SIP Client发出SIP BYE(SIP结束)请求，请求结束MSRP会话，同时释放MSRP会话资源。
如果步骤S201是SIP re-INVITE请求，则该步骤也是SIP re-INVITE请求。
步骤S223，SIP Server转发SIP BYE请求到GW。
步骤S224，GW返回SIP 200OK响应，中断SIP域的MSRP会话，释放会话资源。
步骤S225，IMPS Server转发SIP 200OK响应给SIP Client。
步骤S226，步骤S220之后，GW完成接收文件，将文件以适合IMPS消息的格式通过SendMessageRequest(发送消息请求)发送给IMPS Server，SendMessageRequest的Message-Info(消息信息)结构中，ContentType为“image/jpeg”，ContentSize为4092，ContentName为″My cool picture.jpg″。
步骤S227，IMPS Server返回SendMessageResponse(发送消息响应)。
步骤S228，步骤S226之后，IMPS Server根据IMPS域设置的接收消息方式，向IMPS Client发送消息，本实施例中IMPS域设置了Push方式，因此IMPSServer向IMPS Client发送NewMessage(新消息)请求。
步骤S229，IMPS Client返回MessageDelivered(消息递送响应)，整个流程结束。
本发明第二实施例提供了第二种文件传输方法，其仍然基于如图1所示的组网而实现。本实施例中，第一域为SIP域，第一协议类型为SIP协议；第二域为IMPS域，第二协议类型为IMPS协议；其给出SIP域用户主动要求接收文件(例如SIP域用户从网络论坛上知道IMPS域用户有某个文件，因此主动向IMPS域用户要求接收文件)时，互连网关获取SIP域发送的SIP协议类型的文件接收协商请求；根据IMPS域反馈的信息，向SIP域返回所述文件接收协商请求对应的基于SIP协议类型的文件传输协商应答。根据IMPS域反馈的信息确定协商结果，根据协商结果进行不同域之间的文件传输。实现流程如图4所示，包括：
步骤S301，接收SIP域的文件传输协商请求。该请求中携带SDP描述信息，该描述信息中记录了文件接收协商请求。
如果之前SIP域与该IMPS域之间没有会话，则该请求是一个新的SIPINVITE请求；如果之前SIP域与该IMPS域之间有会话，则该请求可以是SIPre-INVITE请求；如果之前SIP域与该IMPS域之间有早期会话，则该请求可以SIP UPDATE请求。
步骤S302，读取文件传输协商请求中的SDP，提取SDP中描述的所要传输文件的信息。
步骤S303，判断IMPS域用户是否同意发送文件，如果IMPS域用户同意发送文件则到步骤S304，否则至步骤S309；
可以通过向IMPS域发送询问，接收IMPS域应答判断用户是否愿意发送文件，可以通过Invite或SystemMessage来实现该询问应答，Invite类型可以是即时消息，也可以是Application-Application(应用程序)。
步骤S304，回复SIP域协商请求成功响应。
步骤S305，根据协商内容，建立用于传输文件的MSRP会话。
步骤S306，接收IMPS域通过即时消息发送的文件。
步骤S307，互连网关通过比较所接收的IMPS域发送文件的参数和初始文件传输协商请求中SDP所描述的文件信息，例如文件名称，大小、类型等，将接收到的文件通过步骤S305建立的MSRP会话转发给SIP域。
步骤S308，结束文件传输，根据情况重新协商新的会话或结束会话，结束流程。
步骤S309，回复SIP域协商请求失败响应，回到SIP域发送文件传输协商请求之前的状态，请求之前可能网关与SIP域之间存在会话，也可能不存在会话，结束流程。
本发明第二实施例中，如果SIP域发出的文件接收协商请求中包含多个文件接收请求，则IMPS侧针对每个文件接收请求，单独检查IMPS域用户是否同意发送文件，将检查结果合成一个SDP描述信息中，然后通过携带该SDP描述信息的SIP应答，回复给SIP域。
本发明第二实施例中，如果SIP域发出的一个请求的SDP中同时包含文件发送请求和文件接收请求，则针对每个请求按类型分别处理，检查IMPS侧用户是否接收文件，或是否同意发送文件，将检查结果合成一个SDP描述信息中，然后通过携带该SDP描述信息的SIP应答，回复给SIP域。
下面举例对本发明第二实施例进行详细说明。该实例中，第一域为SIP域，第一协议类型为SIP协议；第二域为IMPS域，第二协议类型为IMPS协议；该实例的具体实施过程如图5所示，包括：
步骤S401，SIP域用户想向IMPS域用户请求一个文件，因此通过SIP Client发送SIP INVITE请求，请求中包含用于文件传输的SDP，其包括：表示该请求是一个文件接收请求的信息，文件的名称、类型、大小、散列值等等，可以描述如下：
Figure GSB00000799396600121
Figure GSB00000799396600131
步骤S402，SIP INVITE请求首先被路由到SIP Server，SIP Server经过一定的处理，例如确定下一步的路由，将SIP INVITE转发到GW。
步骤S403，GW返回SIP临时响应，向SIP Server发送SIP 183。
步骤S404，SIP Server转发SIP 183响应到SIP Client。
步骤S405，GW收到该SIP INVITE，判断是一个文件接收请求，因此需要询问IMPS域用户是否愿意发送文件，GW向IMPS发出InviteRequest请求，请求中的Invite-Type元素可以设置成“IM”(代表即时消息)或“AP”(代表端到端的应用)，如果是“IM”，协商成功后就以即时消息承载文件，如果是“AP”，协商成功后就用协商中商定的应用程序传输文件，本实施例中假设Invite-Type元素设置成“IM”，请求的Invite-Reason元素可以描述该SIP域用户需要获取文件，并包括SDP中获取的所要接收文件的属性，请求的Validity元素可以根据GW设置设定，该值与SIP域SIP INVITE能够维持的时间相等，如果在该时间内GW没有收到IMPS域的应答，则返回SIP域失败响应。
步骤S406，IMPS Server向GW返回InviteRequest请求对应的Status响应。
步骤S407，IMPS Server将InviteRequest请求转换成InviteUserRequest请求，向IMPS Client发送。
步骤S408，IMPS Client接收InviteUserRequest请求，呈现给IMPS域用户，同时向IMPS Server返回Status响应。
步骤S409，IMPS域用户同意发送文件，通过IMPS Client向IMPS Server发送InviteUserResponse响应，将响应的Invite-Acceptance属性设置为“Yes”，表明域用户同意进行即时消息发送文件，如果IMPS域用户不同意发送文件，可以将响应的Invite-Acceptance属性设置为“No”。
步骤S410，IMPS Server接收InviteUserResponse响应，返回对应的Status响应。
步骤S411，IMPS Server将InviteUserResponse响应映射为InviteResponse响应，发送给GW。
步骤S412，GW返回Status响应。
步骤S413，GW根据InviteResponse中Invite-Acceptance属性值，确认IMPS域用户同意发送文件，因此返回SIP 200OK响应，响应的SDP包括：表示该请求是一个文件接收请求的信息，文件的名称、类型、大小、散列值等等，可以描述如下：
Figure GSB00000799396600141
步骤S414，SIP Server向SIP Client转发SIP 200OK响应。
步骤S415，SIP Client返回SIPACK请求。
步骤S416，SIP Server向GW转发SIPACK请求。
步骤S417，SIP Client和GW之间建立用于文件传输的MSRP会话。
步骤S418，步骤S410之后，SIP Client通过SendMessageRequest发送文件，将消息的Message-Info结构中的ContentName设成要发送的文件名称“Mycool picture.jpg”，消息的内容部分为文件本身。
步骤S419，IMPS Server返回SendMessageResponse。
步骤S420，步骤S418之后，IMPS Server向GW发送SendMessageRequest。
步骤S421，GW返回SendMessageResponse。
步骤S422，步骤S420之后，GW判断SendMessageRequest为一个文件发送请求，并且已经在SIP域协商好相应的MSRP会话用于该文件传输，因此通过该MSRP会话发送MSRP SEND请求，将接收到的文件以适当格式放入MSRP SEND请求，根据文件大小可能有多个MSRP SEND请求。
步骤S423，SIP Client向GW返回MSRP OK响应。
步骤S424，文件传输完毕后，SIP Client发出SIP BYE请求，请求结束MSRP会话，同时释放MSRP会话资源。
步骤S425，SIP Server转发SIP BYE请求到GW。
步骤S426，GW返回SIP 200 OK响应，中断SIP域MSRP会话，释放会话资源。
步骤S427，IMPS Server转发SIP 200OK响应给SIP Client，流程结束。
对应本发明第一实施例和第二实施例的处理流程，本发明实施例还提供一种互连网关，其包括：第一传输单元、第二传输单元、第一协商结果确定单元和第一文件传输单元。其中所述所述第一协商结果确定单元包括进一步包括：判断子单元、请求处理子单元和第一协商结果确定子单元。其中所述请求处理子单元进一步包括：第一映射子单元和第一传输子单元。所述互连网关还进一步包括第一文件传输单元，所述第一文件传输单元进一步包括第一文件传输子单元或第二文件传输子单元。所述互连网关还可以进一步包括应答单元。
第一传输单元，用于获取第一域发送的第一协议类型的文件传输协商请求。
第二传输单元，用于获取第二域的反馈信息。具体处理情况如下：
第一获取子单元，用于获取第二域反馈的第二域客户端的文件传输能力信息。
第一协商结果确定单元，用于根据第二域的反馈信息确定协商结果。具体处理情况如下：
判断子单元，用于根据所述文件传输能力信息，判断是否能够进行文件传输，如果判断能够进行文件传输，进一步激活请求处理子单元处理。
请求处理子单元，用于将第一域发送的第一协议类型的文件传输协商请求，映射为用于与第二域进行文件传输协商的第二协议类型的文件协商请求，并将完成映射后得到的文件协商请求，传输给第二域；具体处理情况如下：
第一映射子单元，用于当所述判断子单元的判断结果为能够进行文件传输时，提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的元数据信息，添加到IMPS协议类型的协商请求中的邀请原因元素中；
第一传输子单元，用于将所述第一映射子单元完成添加过程后得到的IMPS协议类型的协商请求，传输给作为第二域的IMPS域内设备；
第一协商结果确定子单元，用于根据第二域服务器针对所述请求处理子单元发送的文件传输协商请求反馈的文件传输协商应答，确定与第二域协商的文件传输协商结果；或者，当所述判断子单元的判断结果为不能进行文件传输时，认为与第二域协商后得到的文件传输协商结果为失败。
第一文件传输单元，用于根据所述协商结果进行第一域与第二域之间的文件传输。具体处理情况如下：
第一文件传输子单元，用于根据第二域反馈的信息确定协商结果为成功后，完成第一域与第二域交互的用于承载文件消息的映射，并将映射后的用于承载文件的消息传输给对方域；或者，
第二文件传输子单元，用于当协商结果为失败后，拒绝传输第一域与第二域交互的用于承载文件的消息。
应答单元，用于将所述协商结果确定单元所确定的与第二域协商的文件传输协商结果，映射到基于第一协议类型的文件传输协商应答中，向第一域返回。
对应本发明第一实施例和第二实施例的处理流程，本发明实施例还提供另一种互连网关，其与上述互连网关的区别在于：
第二传输单元不再包括第一获取子单元，而包括：映射子单元和第二获取子单元。其中所述映射子单元包括：第四映射子单元和第四传输子单元。第一协商结果确定单元不再包括判断子单元、请求处理子单元和第一协商结果确定子单元，而包括：第四协商结果确定子单元。其余元件与上述相关元件雷同。
第一传输单元，用于获取第一域发送的第一协议类型的文件传输协商请求。
第二传输单元，用于获取第二域的反馈信息；具体处理情况如下：
映射子单元，用于将第一域发送的第一协议类型的文件传输协商请求，映射为用于与第二域进行文件传输协商的第二协议类型的文件传输协商请求，并将其传输给第二域；具体处理情况如下：
第四映射子单元，用于提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的元数据信息，添加到IMPS协议类型的协商请求中的邀请原因元素中；第四传输子单元，用于将所述第四映射子单元完成添加过程后得到的IMPS协议类型的协商请求，传输给作为第二域的IMPS域内设备。
第二获取子单元，用于获取第二域针对到达的文件传输协商请求反馈的应答。
第一协商结果确定单元，用于根据第二域的反馈信息确定协商结果。具体处理情况如下：
第四协商结果确定子单元，用于根据作为第二域的IMPS服务器反馈的文件传输协商应答，确定与作为第二域的IMPS域协商的文件传输协商结果。
第一文件传输单元，用于根据所述协商结果进行第一域与第二域之间的文件传输。具体处理情况如下：
第一文件传输子单元，根据第二域反馈的信息确定协商结果为成功后，完成第一域与第二域交互的用于承载文件消息的映射，并将映射后的用于承载文件的消息传输给对方域；具体处理情况如下：
将SIP域发送的携带文件的SIP协议类型消息，映射为携带文件的IMPS协议类型消息；将所述IMPS协议类型消息，发送给IMPS域；或者，
将IMPS域发送的携带文件的IMPS协议类型消息，映射为携带文件的SIP协议类型消息；将所述SIP协议类型消息，发送给SIP域。
第二文件传输子单元，当协商结果为失败后，拒绝传输第一域与第二域交互的用于承载文件的消息。
应答单元，用于将所述协商结果确定单元所确定的与第二域协商的文件传输协商结果，映射到基于第一协议类型的文件传输协商应答中，向第一域返回。
本发明第三实施例提供了第三种文件传输方法，其仍然基于如图1所示的组网而实现。本实施例中给出IMPS域向SIP域主动发送文件的实施过程。
由于IMPS域传输文件之前没有控制层面的协商过程，但SIP域可以进行文件协商，因此在IMPS域向SIP域主动发送文件的情况下，在传输文件给SIP域之前，通过互连网关与SIP域进行文件传输协商，让SIP域用户在接收文件之前就可以了解该文件的一些信息，从而可以决定是否接收文件。该情况下，互连网关接收IMPS域发送的携带文件的IMPS协议类型消息后，针对所述文件的传输，发送基于SIP协议类型的文件传输协商请求给SIP域内设备；接收SIP域内设备反馈的相应文件传输协商请求应答，根据所述应答确定协商结果。具体实现流程如图6所示，包括：
步骤S501，接收IMPS域发送的发送消息请求。
步骤S502，获取该发送消息请求中的消息信息描述信息，包括消息类型、大小等等。
步骤S503，判断消息传输的内容是否为文件，如果是，则到步骤S504；如果不是，则到步骤S510。
判断依据是：判断IMPS消息的Message-Info结构中是否有ContentName信息，如果有ContentName信息，则消息传输的内容为文件；如果没有，则消息传输的内容不是文件。
步骤S504，生成用于文件传输的SDP描述，SDP描述中的文件名称为步骤S503中ContentName的值，文件大小为IMPS侧发送消息请求中消息内容的大小，计算消息内容的hash值后放入SDP描述，文件类型为Message-Info结构中的ContentType的值，如果该ContenType为Message/CPIM，则为消息Content部分的Content-type的值。
步骤S505，用步骤S504生成的SDP描述信息，与SIP域协商新的MSRP会话，如果原先已经与SIP域有相应的MSRP会话存在，将可以新生成的SDP和原先MSRP会话的SDP组合协商新的MSRP会话。
步骤S506，根据SIP域针对该SDP的回答，判断SIP域是否同意接收文件，如果同意，则至步骤S507；否则，至步骤S509。
步骤S507，利用新建的MSRP会话，将接收到的IMPS域发送的文件，发送给SIP域。
步骤S508，等文件传输完毕，根据情况重新协商新的会话或结束会话，结束流程。
步骤S509，消息发送失败，SIP域回到文件传输协商之前的状态，结束流程。
步骤S510，判断消息大小是否适合用SIP MESSAGE发送，如果适合，则到步骤S511；否则，至步骤S512。
判断依据是：IMPS域发送的消息大小是否小于1300或SIP域传输路径的最小MTU-200字节，如果小于，则适合用SIP MESSAGE发送；否则，不适合用SIP MESSAGE发送。
步骤S511，利用SIP MESSAGE方式将消息发送给SIP域，流程结束。
步骤S512，SIP域按照普通大消息的发送处理方式，对消息进行发送处理。
如果SIP侧已经有相应MSRP会话，则利用该会话发送IMPS域发送的消息内容；如果SIP侧不存在相应的MSRP会话，则协商建立新的MSRP会话，协商成功则发送消息，协商不成功则发送消息失败。
本发明第三实施例中，如果文件较小，可以利用SIP MESSAGE发送，则GW也可以直接利用SIP MESSAGE发送文件，因此GW可以先检查IMPS域发送的消息大小是否适合利用SIP MESSAGE发送给SIP域，如果适合，则直接用SIP MESSAGE发送给SIP域，如果不适合，再检查该消息发送的是否是文件，如果是文件，则按步骤S504-S509执行，如果不是文件，则按普通消息的发送处理方式，将消息发送给SIP域。
对应本发明第三实施例的处理流程，本发明第三实施例还提供一种互连网关，其包括：协商请求传输单元、第二协商结果确定单元和第二文件传输单元。
协商请求传输单元，用于接收IMPS域发送的携带文件的IMPS协议类型消息后，针对所述文件的传输，发送基于SIP协议类型的文件传输协商请求给SIP域内设备。
第二协商结果确定单元，用于获取SIP域内设备针对到达的文件传输协商请求反馈的相应应答，根据所述应答确定协商结果。
第二文件传输单元，根据协商结果确定单元所确定的协商结果，进行IMPS域与SIP域之间的文件传输。具体处理情况如下：
当所述协商结果确定单元确认协商结果为成功时，将所述携带文件的IMPS协议类型消息，映射成携带文件的SIP协议类型消息，传输给SIP域；或者，当确认协商结果为失败时，丢弃所述携带文件的IMPS协议类型消息。
下面举例对本发明第三实施例进行详细说明。该实例的具体实施过程如图7所示，包括：
步骤S701，IMPS Client通过SendMessageRequest发送文件，将消息的Message-Info结构中的ContentName设成要发送的文件名称“My coolpicture.jpg”，消息的内容部分为文件本身。
步骤S702，IMPS Server返回SendMessageResponse。
步骤S703，步骤S701之后，IMPS Server向GW发送SendMessageRequest。
步骤S704，GW返回SendMessageResponse。
步骤S705，步骤S703之后，GW判断该IMPS消息是用于发送一个文件，且因为文件超过一定大小需要用MSRP来发送，因此向SIP域发送SIP INVITE消息，将所接收的IMPS消息中的文件大小、名称、类型以及计算后的hash值放入SDP描述信息中，该SDP可以描述如下：
Figure GSB00000799396600211
步骤S706，SIP Server向SIP Client转发SIP INVITE请求。
步骤S707，如果SIP域用户同意接收文件，SIP Client返回SIP 200 OK响应，响应中包含SDP应答，所述SDP应答中包括：表示该请求是一个文件接收请求的信息，文件的名称、类型、大小、散列值等等，可以描述如下：
Figure GSB00000799396600212
Figure GSB00000799396600221
步骤S708，SIP Server转发SIP 200OK响应到GW。
步骤S709，GW发送SIPACK请求。
步骤S710，SIP Server向SIP Client转发SIP ACK请求。
步骤S711，SIP Client和GW之间建立起MSRP会话，用于文件传输。
步骤S712，GW通过建立的MSRP会话发送MSRP SEND请求，将IMPS域接收到的文件以适当格式放入MSRP SEND请求，根据文件大小可能有多个MSRP SEND请求。
步骤S713，SIP Client返回MSRP OK响应。
步骤S714，文件传输完毕后，SIP Client发出SIP BYE请求，请求结束MSRP会话，同时释放MSRP会话资源。
步骤S715，SIP Server转发SIP BYE请求到GW。
步骤S716，GW返回SIP 200OK响应，中断SIP域MSRP会话，释放会话资源。
步骤S717，IMPS Server转发SIP 200OK响应给SIP Client，流程结束。
本发明第四实施例提供了第四种文件传输方法，其给出了IMPS域向SIP域发送文件时的处理流程。本实施例中，在IMPS邀请事务的邀请请求(InviteRequest和InviteUserRequest)中增加了文件元数据描述，记为Invite-File，用于描述文件元数据，以对文件传输协商进行控制。所述新增加的文件元数据描述的结构如表1所示：
  名称   类型   描述
  Direction   String   文件传输方向，R代表接收文件，S代表发送文件
  Name   String   文件名称
  Type   String   文件MIME类型
  Size   Integer   文件大小
  Hash   Structure   文件的Hash值
  -Algorithm   String   Hash算法名称
  -Value   Hex   十六进制的Hash值
表1
当SIP域和IMPS域之间传输文件而进行协商时，表1中定义的Name、Type、Size和Hash分别对应SDP中的文件描述4元组：名称、类型、大小和Hash值。举例如下：
SDP中的一个文件描述：
Figure GSB00000799396600231
本实施例中，互连网关接收IMPS域发送的文件传输协商请求，该请求中携带新增加的文件元数据描述，根据该文件元数据描述，将该请求映射为SDP描述信息，然后通过SIP协商请求消息，将该SDP描述信息发送给SIP域。本实施例的处理流程如图8所示，包括：
步骤S801，接收IMPS域的文件传输协商请求，请求中包括用于文件元数据描述的Invite-File元素。
步骤S802，互连网关提取IMPS域发送的基于增加文件元数据描述的IMPS协议类型的文件传输协商请求中的文件元数据描述；将所述文件元数据描述中的元数据信息，添加到SDP描述信息中，通过SIP协商请求消息，将该SDP描述信息发送给SIP域，与SIP域协商文件传输；
步骤S803，互连网关根据与SIP域的协商结果判断是否协商成功，如果成功则进行下面步骤，否则至步骤S808。
步骤S804，互连网关回复IMPS协商请求成功响应。
步骤S805，互连网关建立与SIP域之间用于文件传输的MSRP会话；本步骤和步骤S804没有先后顺序之分。
步骤S806，互连网关进行实际文件传输报文的映射并发送，如果是IMPS域发送文件，则将携带文件的IMPS消息转换为携带文件的SIP消息，并将所述SIP消息发送给SIP域；如果是SIP域发送文件，则将携带文件的SIP消息转换为携带文件的IMPS消息，并将所述IMPS消息发送给IMPS域。
步骤S807，文件传输结束，结束与SIP域之间用于文件传输的MSRP会话。
步骤S808，回复IMPS协商请求失败响应。
可以看出，通过本实施例，IMPS域与SIP域之间可以有效进行文件传输协商，并且能够较好根据互相协商的结果传输文件。
对应本发明第四实施例的处理流程，本发明实施例还提供一种互连网关，其包括：第一传输单元、第二传输单元、第一协商结果确定单元和第一文件传输单元。所述第二传输单元进一步包括：映射子单元和第二获取子单元。其中所述映射子单元包括第三映射子单元和第三传输子单元。所述第一协商结果确定单元进一步包括：第三协商结果确定子单元。所述第一文件传输单元进一步包括第一文件传输子单元和第二文件传输子单元，所述互连网关还可以进一步包括应答单元。
第一传输单元，用于获取第一域发送的第一协议类型的文件传输协商请求；
第二传输单元，用于获取第二域的反馈信息；具体处理情况如下：
映射子单元，用于将第一域发送的第一协议类型的文件传输协商请求，映射为用于与第二域进行文件传输协商的第二协议类型的文件传输协商请求，并将其传输给第二域；具体处理情况如下：
第三映射子单元，提取作为第一域的IMPS域发送的基于增加文件元数据描述的IMPS协议类型的文件传输协商请求中的文件元数据描述；将所述文件元数据描述中的元数据信息，添加到所述SIP协议类型的协商请求中的SDP描述信息中；
第三传输子单元，将所述第三映射子单元完成添加过程后得到的SIP协议类型的协商请求，传输给作为第二域的SIP域的设备；
第二获取子单元，获取第二域针对到达的文件传输协商请求反馈的应答。
第一协商结果确定单元，根据第二域的反馈信息确定协商结果。具体处理情况如下：
第三协商结果确定子单元，根据作为第二域的SIP域的客户端返回的文件传输协商应答，确定相应的文件传输协商结果；所述应答是SIP客户端接收到基于SIP协议类型的文件传输协商请求后，根据其自己的能力是否能够满足文件传输所反馈的，或者是根据其自己的能力是否能够满足文件传输以及其获取到的用户响应或用户配置所反馈的。
第一文件传输单元，根据所述协商结果进行第一域与第二域之间的文件传输。具体处理情况如下：
第一文件传输子单元，用于根据第二域反馈的信息确定协商结果为成功后，完成第一域与第二域交互的用于承载文件消息的映射，并将映射后的用于承载文件的消息传输给对方域；具体处理情况如下：
将SIP域发送的携带文件的SIP协议类型消息，映射为携带文件的IMPS协议类型消息；将所述IMPS协议类型消息，发送给IMPS域；或者，将IMPS域发送的携带文件的IMPS协议类型消息，映射为携带文件的SIP协议类型消息；将所述SIP协议类型消息，发送给SIP域。
第二文件传输子单元，当协商结果为失败后，拒绝传输第一域与第二域交互的用于承载文件的消息。
应答单元，将所述协商结果确定单元所确定的与第二域协商的文件传输协商结果，映射到基于第一协议类型的文件传输协商应答中，向第一域返回。
另外，基于本发明第四实施例的思想，通过在IMPS域的文件传输协商请求，如IMPS域的邀请事务的邀请请求(InviteRequest和InviteUserRequest)中增加了文件元数据描述，对于第一实施例中，互连网关在处理SIP域的文件传输协商请求(即文件发送协商请求)，以及第二实施例中，互连网关在处理SIP域的文件传输协商请求(即文件接收协商请求)时，还可以按照如下处理方式实现：
将SIP域的文件传输协商请求中携带的SDP描述信息提取出；将所述SDP描述信息中的元数据信息，添加到基于增加文件元数据描述的IMPS协议类型的协商请求中的文件元数据描述中。
将所述基于增加文件元数据描述的IMPS协议类型的协商请求发送给IMPS客户端。
接收IMPS客户端返回的文件传输协商应答，所述应答是IMPS客户端接收到基于增加文件元数据描述的IMPS协议类型的文件传输协商请求后，根据其自己的能力是否能够满足文件传输所反馈的，或者是根据其自己的能力是否能够满足文件传输以及其获取到的用户响应或用户配置所反馈的；根据所述IMPS客户端返回的文件传输协商应答，确定文件传输协商结果；
将所确定的文件传输协商结果，映射到SIP协议类型的文件传输协商应答中，并返回给SIP域。
之后，根据第二域反馈的信息确定协商结果为成功后，SIP域与IMPS域交互的用于承载文件的消息，通过所述互连网关进行消息格式的转换，发送给接收文件的一方；或者，根据第二域反馈的信息确定协商结果为失败后，拒绝传输第一域与第二域交互的用于承载文件的消息。
通过该方案，互连网关在处理文件传输协商请求时，不再需要判断IMPS域用户能否接收文件，可以由IMPS客户端判断，其它处理情况与第一实施例和第二实施例中的相关描述类似，这里仅仅对IMPS客户端的处理流程进行描述，如图9所示，包括：
步骤S901，IMPS客户端接收互连网关发送的文件传输协商请求。该文件传输协商请求中携带新增加的文件元数据描述。
步骤S902，IMPS客户端获取文件传输协商请求中携带的文件元数据描述中所描述的文件信息。
步骤S903，IMPS客户端判断能否进行该文件传输，如果所述文件传输协商请求是发送文件的协商请求，IMPS客户端利用步骤S902获取的文件大小类型等信息，判断能否接收该文件，若能够接收，则至步骤S904；否则，至步骤S906；如果所述文件传输协商请求是接收文件的协商请求，IMPS客户端首先根据文件大小类型，判断是否能够发送该文件，还可以根据名称、Hash值等进一步判断是否存在符合请求中文件信息的文件，如果不存在符合条件的文件，则不能发送，综合判断后如果能够发送，则至步骤S904；否则，至步骤S906。
步骤S904，显示文件信息，询问用户是否同意文件传输。
可以将步骤S903中选出的符合条件的文件列表给用户选择。
步骤S905，根据用户输入判断用户是否同意文件传输，如果用户不同意，则至步骤S906；否则，至步骤S907。
步骤S906，回复IMPS文件传输协商失败响应，流程结束。
步骤S907，回复IMPS文件传输协商成功响应，流程结束；如果请求是接收文件，则将用户选择的文件发送给请求方。
对应上述客户端的处理流程，本发明实施例还提供一种客户端，其包括：协商请求获取单元和应答单元。
协商请求获取单元，用于接收基于增加文件元数据描述的IMPS协议类型的文件传输协商请求；
应答单元，用于根据所述客户端的能力，判断是否能够进行文件传输，若不能，则作出文件传输协商失败应答；若能，则根据用户的响应或用户配置作出相应的文件传输协商应答。
对应上述在IMPS邀请事务的邀请请求(InviteRequest和InviteUserRequest)中增加了文件元数据描述后，第一实施例和第二实施例的处理情况，本发明实施例还提供一种互连网关，其包括：第一传输单元、第二传输单元、第一协商结果确定单元和第一文件传输单元。所述第二传输单元进一步包括：映射子单元和第二获取子单元。其中所述映射子单元进一步包括第二映射子单元和第二传输子单元。所述第一协商结果确定单元进一步包括：第二协商结果确定子单元。所述第一文件传输单元还进一步包括：第一文件传输子单元和第二文件传输子单元。所述互连网关还进一步包括应答单元。
第一传输单元，用于获取第一域发送的第一协议类型的文件传输协商请求；
第二传输单元，用于获取第二域的反馈信息；具体处理情况如下：
映射子单元，用于将第一域发送的第一协议类型的文件传输协商请求，映射为用于与第二域进行文件传输协商的第二协议类型的文件传输协商请求，并将其传输给第二域；具体处理情况如下：
第二映射子单元，提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的元数据信息，添加到基于增加文件元数据描述的IMPS协议类型的协商请求中的文件元数据描述中；
第二传输子单元，用于将所述第二映射子单元完成添加过程后得到的IMPS协议类型的协商请求，传输给作为第二域的IMPS域的设备。
第二获取子单元，用于获取第二域针对到达的文件传输协商请求反馈的应答。
第一协商结果确定单元，用于根据第二域的反馈信息确定协商结果；具体处理情况如下：
所述第一协商结果确定单元中的第二协商结果确定子单元，根据作为第二域的IMPS域的客户端返回的文件传输协商应答，确定相应的文件传输协商结果；所述应答是IMPS客户端接收到基于增加文件元数据描述的IMPS协议类型的文件传输协商请求后，根据其自己的能力是否能够满足文件传输所反馈的，或者是根据其自己的能力是否能够满足文件传输以及其获取到的用户响应或用户配置所反馈的。
第一文件传输单元，用于根据所述协商结果进行第一域与第二域之间的文件传输。具体处理情况如下：
第一文件传输子单元，用于根据第二域反馈的信息确定协商结果为成功后，完成第一域与第二域交互的用于承载文件消息的映射，并将映射后的用于承载文件的消息传输给对方域；具体处理情况如下：
将SIP域发送的携带文件的SIP协议类型消息，映射为携带文件的IMPS协议类型消息；将所述IMPS协议类型消息，发送给IMPS域；或者，
将IMPS域发送的携带文件的IMPS协议类型消息，映射为携带文件的SIP协议类型消息；将所述SIP协议类型消息，发送给SIP域。
第二文件传输子单元，用于当协商结果为失败后，拒绝传输第一域与第二域交互的用于承载文件的消息。
应答单元，用于将所述协商结果确定单元所确定的与第二域协商的文件传输协商结果，映射到基于第一协议类型的文件传输协商应答中，向第一域返回。
由本发明的实施例的具体实施方案可以看出，其能够获取第一域发送的第一协议类型的文件传输协商请求；获取第二域的反馈信息；根据第二域的反馈信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行第一域与第二域之间的文件传输。因此能够实现SIP域与IMPS域之间相互传输文件的协商，从而能够根据协商结果，避免了不同域之间传输不必要的文件，使系统资源得到充分的利用。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (30)

1.一种文件传输方法，其特征在于，包括：
获取第一域发送的第一协议类型的文件传输协商请求；
获取第二域反馈的第二协议类型的第二域客户端文件传输能力信息；
根据第二域的反馈信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行第一域与第二域之间的文件传输；
所述根据第二域的反馈信息确定协商结果的过程，包括：
根据所述第二域客户端的文件传输能力信息，确定第二域能够进行文件传输，并将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的文件传输协商请求，并将所述第二协议类型传输协商请求传输给第二域；根据第二域针对到达的文件传输协商请求反馈的文件传输协商应答，确定与第二域协商的文件传输协商结果。
2.如权利要求1所述的方法，其特征在于，
所述第一域包括SIP域，所述第一协议类型包括：SIP和/或SDP；
所述第二域包括IMPS域，所述第二协议类型包括IMPS。
3.如权利要求1所述的方法，其特征在于，所述根据第二域的反馈信息确定协商结果的过程，还包括：
根据所述第二域客户端文件传输能力信息，确定第二域不能够进行文件传输，则认为文件传输协商结果为失败。
4.如权利要求1所述的方法，其特征在于，所述将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的协商请求，包括：
提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的与所要传输文件相关的元数据信息，添加到IMPS协议类型的协商请求中的邀请原因元素中。
5.如权利要求1所述的方法，其特征在于，
所述第一域包括SIP域，所述第一协议类型包括：SIP和/或SDP；所述第二域包括IMPS域，所述第二协议类型包括基于增加文件元数据描述的IMPS；
或者，
所述第一域包括IMPS域，所述第一协议类型包括：基于增加文件元数据描述的IMPS；所述第二域包括SIP域，所述第二协议类型包括SIP和/或SDP。
6.如权利要求5所述的方法，其特征在于，所述获取第二域的反馈信息，包括：
将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的文件传输协商请求，并将所述第二协议类型的文件传输协商请求传输给第二域；获取第二域针对到达的文件传输协商请求反馈的相应文件传输协商应答。
7.如权利要求6所述的方法，其特征在于，所述将第一域发送的第一协议类型的文件传输协商请求，映射第二协议类型的文件传输协商请求的过程，包括：
提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的与所要传输文件相关的元数据信息，添加到IMPS协议类型的协商请求中的邀请原因元素中；
或者，
提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的与所要传输文件相关的元数据信息，添加到基于增加文件元数据描述的IMPS协议类型的协商请求中的文件元数据描述中；
或者，
提取作为第一域的IMPS域发送的基于增加文件元数据描述的IMPS协议类型的文件传输协商请求中的文件元数据描述；将所述文件元数据描述中的元数据信息，添加到所述SIP协议类型的协商请求中的SDP描述信息中。
8.如权利要求6所述的方法，其特征在于，所述根据第二域的反馈信息确定协商结果，包括：
根据作为第二域的IMPS服务器反馈的文件传输协商应答，确定与作为第二域的IMPS域协商的文件传输协商结果；
或者，
根据作为第二域的IMPS客户端反馈的针对到达的文件传输协商请求反馈的应答，确定与第二域协商的文件传输协商结果；所述应答是IMPS客户端接收到基于增加文件元数据描述的IMPS协议类型的文件传输协商请求后，根据所述IMPS客户端的能力是否能够满足文件传输所反馈的，或者是根据所述IMPS客户端的的能力是否能够满足文件传输以及其获取到的用户响应或用户配置所反馈的；
或者，
根据作为第二域的SIP客户端返回的文件传输协商应答，确定与作为第二域的SIP域协商的文件传输协商结果，所述应答是SIP客户端接收到基于SIP协议类型的文件传输协商请求后，根据所述SIP客户端的能力是否能够满足文件传输所反馈的，或者是根据其自己的能力是否能够满足文件传输以及其获取到的用户响应或用户配置所反馈的。
9.如权利要求4、7或8所述的方法，其特征在于，所述IMPS协议类型的文件协商请求包括：基于IMPS协议类型的邀请事务或系统消息事务。
10.如权利要求1所述的方法，其特征在于，所述根据第二域反馈的信息确定协商结果，根据所述协商结果进行第一域与第二域之间的文件传输的过程，包括：
确定协商结果为成功后，完成第一域与第二域交互的用于承载文件的消息的映射，并传输映射后的用于承载文件的消息给对方域；或者，确定协商结果为失败后，拒绝传输第一域与第二域交互的用于承载文件的消息。
11.如权利要求10所述的方法，其特征在于，
当所述用于承载文件的消息为SIP协议类型消息时，通过MSRP会话发送。
12.如权利要求10所述的方法，其特征在于，当所述用于承载文件的消息为IMPS协议类型消息时，包括：IMPS即时消息。
13.如权利要求1所述的方法，其特征在于，还包括：
将所确定的与第二域协商的文件传输协商结果映射到基于第一协议类型的文件传输协商应答中，向第一域返回。
14.一种互连网关，其特征在于，包括：
第一传输单元，用于获取第一域发送的第一协议类型的文件传输协商请求；
第二传输单元，用于获取第二域反馈的第二协议类型的第二域客户端文件传输能力信息；
第一协商结果确定单元，用于根据第二域的反馈信息，确定与所述文件传输协商请求相应的协商结果；
第一文件传输单元，用于根据所述协商结果进行第一域与第二域之间的文件传输；
所述根据第二域的反馈信息确定协商结果的过程，包括：
根据所述第二域客户端的文件传输能力信息，确定第二域能够进行文件传输，并将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的文件传输协商请求，并将所述第二协议类型传输协商请求传输给第二域；根据第二域针对到达的文件传输协商请求反馈的文件传输协商应答，确定与第二域协商的文件传输协商结果。
15.如权利要求14所述的互连网关，其特征在于，所述根据第二域的反馈信息确定协商结果的过程，还包括：
根据所述第二域客户端文件传输能力信息，确定第二域不能够进行文件传输，则认为文件传输协商结果为失败。
16.如权利要求14所述的互连网关，其特征在于，所述第二传输单元包括：
第一获取子单元，用于获取第二域反馈的第二域客户端的文件传输能力信息。
17.如权利要求16所述的互连网关，其特征在于，所述第一协商结果确定单元包括：
判断子单元，用于根据所述文件传输能力信息，判断是否能够进行文件传输，如果判断能够进行文件传输，进一步激活请求处理子单元处理；
请求处理子单元，用于将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的文件协商请求，并将完成映射后得到的文件协商请求，传输给第二域；
第一协商结果确定子单元，用于将第二域服务器针对所述请求处理子单元发送的文件传输协商请求反馈的文件传输协商应答，确定与第二域协商的文件传输协商结果；或者，当所述判断子单元的判断结果为不能进行文件传输时，认为与第二域协商后得到的文件传输协商结果为失败。
18.如权利要求17所述的互连网关，其特征在于，所述请求处理子单元包括：
第一映射子单元，用于当所述判断子单元的判断结果为能够进行文件传输时，提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的元数据信息，添加到IMPS协议类型的协商请求中的邀请原因元素中；
第一传输子单元，用于将所述第一映射子单元完成添加过程后得到的IMPS协议类型的协商请求，传输给作为第二域的IMPS域内设备。
19.如权利要求14所述的互连网关，其特征在于，所述第二传输单元包括：
映射子单元，用于将第一域发送的第一协议类型的文件传输协商请求，映射为第二协议类型的文件传输协商请求，并将所述第二协议类型的文件传输协商请求传输给第二域；
第二获取子单元，用于获取第二域针对到达的文件传输协商请求反馈的应答。
20.如权利要求19所述的互连网关，其特征在于，所述映射子单元包括：
第二映射子单元，用于提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的元数据信息，添加到基于增加文件元数据描述的IMPS协议类型的协商请求中的文件元数据描述中；第二传输子单元，用于将所述第二映射子单元完成添加过程后得到的IMPS协议类型的协商请求，传输给作为第二域的IMPS域的设备；
或者，
第三映射子单元，用于提取作为第一域的IMPS域发送的基于增加文件元数据描述的IMPS协议类型的文件传输协商请求中的文件元数据描述；将所述文件元数据描述中的元数据信息，添加到所述SIP协议类型的协商请求中的SDP描述信息中；第三传输子单元，用于将所述第三映射子单元完成添加过程后得到的SIP协议类型的协商请求，传输给作为第二域的SIP域的设备；
或者，
第四映射子单元，用于提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息；将所述SDP描述信息中的元数据信息，添加到IMPS协议类型的协商请求中的邀请原因元素中；第四传输子单元，用于将所述第四映射子单元完成添加过程后得到的IMPS协议类型的协商请求，传输给作为第二域的IMPS域内设备。
21.如权利要求19或20所述的互连网关，其特征在于，所述第一协商结果确定单元包括：
第二协商结果确定子单元，用于根据作为第二域的IMPS域的客户端返回的文件传输协商应答，确定相应的文件传输协商结果；所述应答是IMPS客户端接收到基于增加文件元数据描述的IMPS协议类型的文件传输协商请求后，根据所述IMPS客户端的能力是否能够满足文件传输所反馈的，或者是根据所述IMPS客户端的能力是否能够满足文件传输以及其获取到的用户响应或用户配置所反馈的；
或者，
第三协商结果确定子单元，用于根据作为第二域的SIP域的客户端返回的文件传输协商应答，确定相应的文件传输协商结果；所述应答是SIP客户端接收到基于SIP协议类型的文件传输协商请求后，根据所述SIP客户端的能力是否能够满足文件传输所反馈的，或者是根据所述SIP客户端的能力是否能够满足文件传输以及其获取到的用户响应或用户配置所反馈的；
或者，
第四协商结果确定子单元，用于根据作为第二域的IMPS服务器反馈的文件传输协商应答，确定与作为第二域的IMPS域协商的文件传输协商结果。
22.如权利要求14所述的互连网关，其特征在于，所述第一文件传输单元包括：
第一文件传输子单元，用于根据第二域反馈的信息确定协商结果为成功后，完成第一域与第二域交互的用于承载文件消息的映射，并将映射后的用于承载文件的消息传输给对方域；或者，
第二文件传输子单元，用于当协商结果为失败后，拒绝传输第一域与第二域交互的用于承载文件的消息。
23.如权利要求14所述的互连网关，其特征在于，还包括：
应答单元，用于将所述协商结果确定单元所确定的与第二域协商的文件传输协商结果，映射到基于第一协议类型的文件传输协商应答中，向第一域返回。
24.一种客户端，其特征在于，包括：
协商请求获取单元，用于接收基于增加文件元数据描述的IMPS协议类型的文件传输协商请求，所述基于增加文件元数据描述的IMPS协议类型的文件传输协商请求由互连网关提取作为第一域的SIP域发送的SIP协议类型的文件传输协商请求中的SDP描述信息，将所述SDP描述信息中的元数据信息，添加到基于增加文件元数据描述的IMPS协议类型的协商请求中的文件元数据描述中；
应答单元，用于根据所述客户端的能力，判断是否能够进行文件传输，若不能，则作出文件传输协商失败应答；若能，则根据用户的响应或用户配置作出相应的文件传输协商应答。
25.一种文件传输方法，其特征在于，包括：
接收IMPS域发送的携带文件的IMPS协议类型消息后，针对所述文件的传输，发送基于SIP协议类型的文件传输协商请求给SIP域；
获取SIP域针对所述文件传输协商请求反馈的相应应答中携带的信息；
根据所述应答携带的信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行IMPS域与SIP域之间的文件传输。
26.如权利要求25所述的方法，其特征在于，所述基于SIP协议类型的文件传输协商请求携带SDP描述信息；所述SDP描述信息中包括请求应答的信息。
27.如权利要求25或26所述的方法，其特征在于，所述根据所述协商结果进行IMPS域与SIP域之间的文件传输的过程，包括：
当确认协商结果为成功时，将所述携带文件的IMPS协议类型消息，映射成携带文件的SIP协议类型消息，将经映射得到的SIP协议类型消息传输给SIP域；或者，
当确认协商结果为失败时，丢弃所述携带文件的IMPS协议类型消息。
28.如权利要求27所述的方法，其特征在于，通过MSRP会话，将经映射得到的SIP协议类型消息传输给SIP域。
29.一种互连网关，其特征在于，包括：
协商请求传输单元，用于接收IMPS域发送的携带文件的IMPS协议类型消息后，针对所述文件的传输，发送基于SIP协议类型的文件传输协商请求给SIP域内设备；
第二协商结果确定单元，用于获取SIP域针对所述文件传输协商请求反馈的相应应答中携带的信息；
第二文件传输单元，用于根据所述应答中携带的信息，确定与所述文件传输协商请求相应的协商结果，根据所述协商结果进行IMPS域与SIP域之间的文件传输。
30.如权利要求29所述的互连网关，其特征在于，所述第二文件传输单元包括：
第三文件传输子单元，用于当确认协商结果为成功时，将所述携带文件的IMPS协议类型消息映射成携带文件的SIP协议类型消息，传输给SIP域；或者，
第四文件传输子单元，用于当确认协商结果为失败时，丢弃所述携带文件的IMPS协议类型消息。
CN2007101084790A 2007-06-14 2007-06-14 文件传输方法、互连网关和客户端 Expired - Fee Related CN101325585B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2007101084790A CN101325585B (zh) 2007-06-14 2007-06-14 文件传输方法、互连网关和客户端
EP08757682A EP2159982A4 (en) 2007-06-14 2008-06-11 METHOD, INTERCONNECT GATEWAY, AND FILE TRANSFER CLIENT
PCT/CN2008/071271 WO2008151572A1 (en) 2007-06-14 2008-06-11 Method, interconnection gateway and client of file transfer

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2007101084790A CN101325585B (zh) 2007-06-14 2007-06-14 文件传输方法、互连网关和客户端

Publications (2)

Publication Number Publication Date
CN101325585A CN101325585A (zh) 2008-12-17
CN101325585B true CN101325585B (zh) 2012-08-22

Family

ID=40129263

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007101084790A Expired - Fee Related CN101325585B (zh) 2007-06-14 2007-06-14 文件传输方法、互连网关和客户端

Country Status (3)

Country Link
EP (1) EP2159982A4 (zh)
CN (1) CN101325585B (zh)
WO (1) WO2008151572A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2916511B1 (en) * 2014-03-07 2020-02-12 Airbus Opérations SAS High assurance security gateway interconnecting different domains
EP3736061B1 (en) 2019-05-06 2024-08-07 Lapmaster Wolters GmbH Fine blanking system and method for operating the same

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1449620A (zh) * 2000-07-25 2003-10-15 美国在线服务公司 视频消息传送
CN1599398A (zh) * 2004-09-28 2005-03-23 钟志军 实现电话向计算机网络即时通信终端发信息的装置和方法
CN1794707A (zh) * 2005-08-09 2006-06-28 华为技术有限公司 即时消息系统间的搜索方法和互连服务器

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2637749T3 (es) * 2003-08-29 2017-10-16 Siemens Aktiengesellschaft Método para gestionar servicios de presencia en un sistema de comunicación con protocolos de presencia heterogéneos
US7526563B2 (en) * 2004-02-27 2009-04-28 Nokia Corporation Interworking gateway and method
CN1829219A (zh) * 2005-03-02 2006-09-06 华为技术有限公司 一种文件传输方法
NO323214B1 (no) 2005-03-21 2007-01-29 Telenor Asa webtjeneste for aksess til hjemmenettverk
US7395344B2 (en) 2005-12-02 2008-07-01 The Boeing Company Method for ACARS application communication over an IP network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1449620A (zh) * 2000-07-25 2003-10-15 美国在线服务公司 视频消息传送
CN1599398A (zh) * 2004-09-28 2005-03-23 钟志军 实现电话向计算机网络即时通信终端发信息的装置和方法
CN1794707A (zh) * 2005-08-09 2006-06-28 华为技术有限公司 即时消息系统间的搜索方法和互连服务器

Also Published As

Publication number Publication date
EP2159982A1 (en) 2010-03-03
CN101325585A (zh) 2008-12-17
EP2159982A4 (en) 2010-11-17
WO2008151572A1 (en) 2008-12-18

Similar Documents

Publication Publication Date Title
US7904521B2 (en) Method for transferring chat messages by establishing chat room data transfer channel
EP2342883B1 (en) File transfer in conference services
JP5735495B2 (ja) ソーシャルネットワーク内で認証要求メッセージを送信するための方法および装置
KR101120656B1 (ko) 그룹 통신
JP2009512931A (ja) オフラインインスタントメッセージのリトリーブ
WO2007041937A1 (fr) Methode d'envoi et de reception de message hors ligne, appareil client, serveur et systeme
US9049165B2 (en) Method for delivering message based on CPM service and server thereof
CN101682616A (zh) 使用多个设备的网络多媒体通信
WO2007009369A1 (en) Method and system by which instant message user can use instant message system chat room to which user unbelongs
CN110875914B (zh) 一种基于共享会话链路传输消息的方法及装置
WO2013063886A1 (zh) 一种网关、跨社区群组信息处理系统及方法
US20080091781A1 (en) Group communication
CN102223293B (zh) 消息请求的路由方法及处理系统
CN102130845A (zh) 回执报告的发送方法及处理系统
IL187751A (en) Page-mode messaging
CN102340456B (zh) 互通网关系统的通信方法及互通网关系统
KR101038736B1 (ko) 세션 기반 통신
US20120042083A1 (en) Method and system for transmitting a large message mode cpm message to group
CN101325585B (zh) 文件传输方法、互连网关和客户端
US20120131114A1 (en) Method and system for transmitting large message mode CPM messages
CN102026112B (zh) 一种融合ip消息的发送方法及系统
CN109120578B (zh) 一种实现链路连接处理的方法及装置
KR101524311B1 (ko) 통신 시스템에서 그룹 메시징 세션 생성 방법 및 그 시스템
CN101453429A (zh) 多方通讯系统及方法
WO2011127799A1 (zh) 路由方法、装置及系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20170818

Address after: 201, room 1, building A, No. 518053, front Bay Road, Qianhai, Shenzhen Shenzhen cooperation zone, Guangdong, China

Patentee after: Shenzhen Zhitong World Technology Service Co. Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: Huawei Technologies Co., Ltd.

Effective date of registration: 20170818

Address after: 201, room 1, building A, No. 518053, front Bay Road, Qianhai, Shenzhen Shenzhen cooperation zone, Guangdong, China

Patentee after: Shenzhen Zhitong World Technology Service Co. Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: Huawei Technologies Co., Ltd.

EE01 Entry into force of recordation of patent licensing contract
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20081217

Assignee: Shannan City ran Technology Co., Ltd.

Assignor: Shenzhen Zhitong World Technology Service Co. Ltd.

Contract record no.: 2017440020096

Denomination of invention: File transmission method, interconnection gateway and client terminal

Granted publication date: 20120822

License type: Common License

Record date: 20171208

Application publication date: 20081217

Assignee: Shenzhen Vimicro Tech Co. Ltd.

Assignor: Shenzhen Zhitong World Technology Service Co. Ltd.

Contract record no.: 2017440020097

Denomination of invention: File transmission method, interconnection gateway and client terminal

Granted publication date: 20120822

License type: Common License

Record date: 20171211

Application publication date: 20081217

Assignee: Shannan City ran Technology Co., Ltd.

Assignor: Shenzhen Zhitong World Technology Service Co. Ltd.

Contract record no.: 2017440020096

Denomination of invention: File transmission method, interconnection gateway and client terminal

Granted publication date: 20120822

License type: Common License

Record date: 20171208

Application publication date: 20081217

Assignee: Shenzhen Vimicro Tech Co. Ltd.

Assignor: Shenzhen Zhitong World Technology Service Co. Ltd.

Contract record no.: 2017440020097

Denomination of invention: File transmission method, interconnection gateway and client terminal

Granted publication date: 20120822

License type: Common License

Record date: 20171211

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20120822

Termination date: 20190614