CN101355533A - 一种通信互连方法和设备 - Google Patents
一种通信互连方法和设备 Download PDFInfo
- Publication number
- CN101355533A CN101355533A CN200710137522.6A CN200710137522A CN101355533A CN 101355533 A CN101355533 A CN 101355533A CN 200710137522 A CN200710137522 A CN 200710137522A CN 101355533 A CN101355533 A CN 101355533A
- Authority
- CN
- China
- Prior art keywords
- sip
- user
- imps
- request
- incidence relation
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
-
- 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]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明公开了一种通信互连方法，互连功能实体与支持第一通信协议的第一通信系统和支持第二通信协议的第二通信系统分别相连，所述互连功能实体建立所述第一通信系统的会话标识和第二通信系统的会话标识之间的关联关系；所述互连功能实体根据所述关联关系，在所述两个通信系统间转发会话消息。本发明还公开了用于实现通信互连的设备。本发明方案可以使支持不同协议的多客户端用户之间进行消息业务时，多个客户端之间不互相干扰。
Description
技术领域
本发明涉及通信技术领域，特别涉及一种通信互连方法和设备。
背景技术
目前的移动通信网络或互联网络中的消息业务主要包括两种类型，一种是基于客户端-服务器协议(Client Server Protocol，CSP)/服务器-服务器协议(Server Server Protocol，SSP)协议的即时消息和存在业务(InstantMessaging and Presence Service，IMPS)中的消息业务，另外一种是基于会话初始协议(Session Initiated Protocol，SIP)的消息业务，例如SIP即时消息和存在效用扩展(SIP Instant Message and Presence Leveraging Extensions，SIMPLE)即时消息(Instant Message，IM)、融合IP消息(Converged IPMessage，CPM)等等。
在IMPS或SIP中，一个用户可以有多个客户端，这多个客户端可以位于不同的终端，也可以位于同一个终端，用户可以同时使用多个客户端而不互相干扰。在IMPS中，可以对一个用户发送消息，消息将按照用户在网络中的设置被发送到某个客户端，或多个客户端，也可以直接对某个客户端发送消息；订阅呈现信息时，如果是使用多个客户端之一订阅，也需要将呈现信息发送给订阅的终端而不影响其他终端。以基于SIP的消息业务为例，在SIP中有三种类型的消息：寻呼模式、大消息模式和会话模式，寻呼模式利用SIP消息(SIP MESSAGE)发送，发送端和接收端之间不建立会话，不同消息之间没有联系，每个消息独立路由；大消息模式需要发送端和接收端之间建立会话，会话的媒体流为单向，单个消息发送完毕就结束会话，不同消息之间也没有联系，每个消息独立路由；会话模式则建立一个长期的会话，在会话内发送消息，消息之间有联系，且消息都按会话协商过程协商的路径路由。SIMPLE呈现业务中，SIP订阅同样需要建立会话，在会话内发送SIP通知，这样SIP通知的路由路径是确定的。
在IMPS用户与SIP用户之间进行消息收发的情况下，需要实现IMPS和SIP之间的互连。图1是现有的IMPS用户和SIP用户互连的示意图，左边是IMPS系统，右边是SIP系统，这两个系统之间通过互连网关(GW)连接，进行即时消息、呈现信息、会议等等的互连。SIP用户可以通过SIP消息(SIP MESSAGE)或消息会话中继协议(Message Session Relay Protocol，MSRP)向IMPS用户发送消息或从IMPS用户接收消息，互连网关完成IMPS消息和SIP MESSAGE/MSRP之间的转换。图2是现有技术中SIP用户和IMPS用户建立消息会话的流程，由SIP用户主动发起请求。其中，SIP系统表示SIP系统中的实体，可以是SIP客户端或SIP服务器；IMPS系统表示IMPS系统中的实体，可以是IMPS客户端或IMPS服务器。该流程包括如下步骤：
步骤201：SIP系统向互连网关发送SIP邀请(SIP INVITE)请求；
步骤202：互连网关将SIP INVITE请求转换成IMPS的邀请事务的邀请请求(Invite Request)，发送给IMPS系统；
步骤203：IMPS系统向互连网关返回状态响应；
步骤204：互连网关向SIP系统返回SIP 100Trying临时响应；
步骤205：在步骤203之后，IMPS系统根据所收到的邀请请求进行处理，向互连网关返回邀请事务的邀请响应(InviteResponse)，表明IMPS用户接受邀请；
步骤206：互连网关向IMPS系统返回状态响应；
步骤207：互连网关向SIP系统返回SIP 200OK成功响应；
步骤208：SIP系统向互连网关发出SIP ACK响应。
这样SIP系统和互连网关之间建立了消息会话，SIP用户通过该会话可以向IMPS用户发送消息，互连网关接收到消息之后，将所述消息转换格式后发送给IMPS系统，IMPS用户可以向SIP用户发送消息，互连网关接收到消息之后，将所述消息转换格式，利用和SIP系统之间建立的消息会话将消息发送到SIP系统。
现有技术中，互连网关根据IMPS用户的用户标识(UserID)来向IMPS用户发送消息，根据SIP用户的SIP统一资源标志符(SIP URI)向SIP用户发送消息，如果IMPS用户有多个客户端，就可能会造成参与会话协商的是某个客户端，但是实际的消息却发送到多个客户端；如果SIP用户通过多个会话同时与同一个IMPS用户交互，则互连网关接收到IMPS用户发送的消息时，不能判断通过SIP系统的哪个会话发送给SIP用户。例如SIP用户A有两个终端A1和A2，IMPS用户B有多个客户端B1和B2，A1通过会话方式和B1交互，A2通过会话方式和B2交互，现有技术就无法实现。因此，对于多客户端的IMPS用户和多客户端的SIP用户之间的消息业务，现有技术没有能够满足实际需要的解决方案。
发明内容
有鉴于此，本发明实施例提出一种通信互连的方法，可以使支持不同协议的多客户端用户之间进行会话。
该方法中，将互连功能实体与支持第一通信协议的第一通信系统和支持第二通信协议的第二通信系统分别相连，所述互连功能实体建立所述第一通信系统的会话标识和第二通信系统的会话标识之间的关联关系；
所述互连功能实体根据所述关联关系，在所述两个通信系统间转发会话消息。
本发明实施例还提出了一种互连功能实体，包括：
收发模块，用于接收来自所述第一通信系统的消息，根据关联关系查询模块的通知将来自格式转换模块的消息发送至所述第二通信系统；或者
用于接收来自所述第二通信系统的消息，根据关联关系查询模块的通知将来自格式转换模块的消息发送至所述第一通信系统；
关联关系建立模块，用于确定对应于第一通信系统和第二通信系统的会话标识，建立并存储所述会话标识之间的关联关系；
关联关系查询模块，用于根据所述收发模块所接收的来自第一通信系统的消息所属会话标识，查询所述关联关系建立模块中存储的关联关系，得到所述第二通信系统的会话标识，并将所得到的第二通信系统的会话标识通知所述收发模块；或者
用于根据所述收发模块所接收的来自第二通信系统的消息所属会话标识，查询所述关联关系建立模块中存储的关联关系，得到所述第一通信系统的会话标识，并将所得到的第一通信系统的会话标识通知所述收发模块；
格式转换模块，用于将所述收发模块所接收的第一通信协议支持的消息转换为第二通信协议支持的格式，并将所述转换后的消息发送给所述收发模块；或者
用于将所述收发模块所接收的第二通信协议支持的消息转换为第一通信协议支持的格式，并将所述转换后的消息发送给所述收发模块。
从以上技术方案可以看出，通过建立不同通信协议的会话标识的关联关系，根据该关联关系可以实现将来自第一通信协议系统的消息准确发送到第二通信协议系统中的目的客户端中。本发明方案可以使支持不同协议的多客户端用户之间进行消息业务时，多个客户端之间不互相干扰。
附图说明
图1为现有技术中IMPS用户和SIP用户互连的示意图；
图2为现有技术中SIP用户和IMPS用户建立消息会话的流程图；
图3为本发明实施例通过SIP INVITE请求建立对话用于会话模式即时消息的过程中，互连网关的处理流程图；
图4为本发明实施例IMPS用户向SIP用户发送邀请请求进行即时消息的过程中，互连网关的处理流程图；
图5为本发明实施例SIP用户发起订阅请求并接收来自IMPS服务器发送的呈现通知过程中，互连网关的处理流程图；
图6为本发明实施例IMPS用户发起订阅请求并接收来自SIMPLE呈现服务器发送的呈现通知的过程中，互连网关的处理流程图；
图7为本发明第一实施例的SIP用户请求进行即时消息的信令交互流程图；
图8为本发明第一实施例中IMPS客户端1正在与SIP客户端通话的过程中，IMPS用户通过IMPS客户端2主动请求进行即时消息的信令交互流程图；
图9为本发明第二实施例为SIP用户订阅IMPS用户呈现信息的信令交互流程图；
图10为本发明第三实施例的互连网关的结构框图。
具体实施方式
本发明实施例通过在SIP系统会话和IMPS系统会话之间建立起关联关系，互连网关在会话期间存储所述关联关系，并根据该关联关系来关联两个系统的会话，这样就可以实现多客户端(终端)情况下，SIP用户用和IMPS用户之间用会话模式进行即时消息通讯，通过建立的会话发送消息，可以实现SIP用户多客户端和IMPS用户多客户端之间同时进行多个消息交互而不互相干扰；还可以实现SIP用户或IMPS用户多客户端对另一系统用户呈现信息的订阅。
其中，互连网关在会话建立过程中所建立SIP系统的会话标识与IMPS系统的会话标识之间的关联关系如表1所示，其中SIP用户在IMPS系统的UserID是SIP用户的地址记录(Address Of Record，AOR)，即为SIP URI，ClientID是由GW生成的，其作用在下面描述。
表1
目前在SIP系统实现消息业务，主要包括以下两种方式：第一种，通过SIP邀请(SIP INVITE)请求建立对话用于会话模式的即时消息；第二种，通过SIP订阅(SIP SUBSCRIBE)请求建立对话用于呈现信息的订阅和通知。以下对这两种情况分别加以叙述。
通过SIP INVITE请求建立对话用于会话模式即时消息
通过SIP INVITE请求建立SIP系统对话用于会话模式即时消息可以分为两种情况，一种是SIP用户主动发起SIP INVITE请求，一种是IMPS用户主动发起邀请请求(InviteRequest)，在该过程中，互连网关完成SIPINVITE请求和IMPS邀请请求之间的转换。
SIP用户向IMPS用户发送SIP INVITE请求，进行会话模式的即时消息，GW在此过程中的处理流程如图3所示，包括如下步骤：
步骤301：接收来自SIP用户的SIP INVITE请求，新生成一条关联关系记录，将所述SIP INVITE请求中的SIP系统的对话标识写入关联关系记录，对话标识由来源标签(From tag)、目的标签(To tag)和呼叫标识(Call-ID)组成；
步骤302：将SIP INVITE请求中的发送方的AOR作为SIP用户在IMPS系统的UserID写入关联关系记录；
步骤303：将SIP INVITE请求中的接收方AOR作为IMPS用户的UserID写入关联关系记录；
步骤304：生成一个SIP用户的ClientID，该ClientID对同一对进行消息业务的SIP用户和IMPS用户保持唯一，也就是说，该SIP用户的不同客户端所对应的ClientID彼此不同，将生成的ClientID写入关联关系记录。生成ClientID的具体方式可以是根据该SIP用户的用户标识来生成，例如，若SIP用户的用户标识为：alice@atlanta.com，则该SIP用户的各个客户端的ClientID可以是：alice01、alice02、alice03等等；实际上也可以采用其它生成方式，只要这些ClientID彼此不同并且与所述IMPS用户的ClientID也不相同即可。
步骤305：将SIP INVITE请求映射成相应的IMPS邀请请求，IMPS请求的发送方为以UserID和/或ClientID标识的SIP用户，请求的接收方为以UserID标识的IMPS用户；
步骤306：接收来自IMPS系统的应答，如果应答表示IMPS用户不接收邀请，则转至步骤309；如果IMPS用户接收邀请，则执行步骤307；
步骤307：若IMPS邀请应答中包含IMPS用户的ClientID或ApplicationID，则将该ClientID或ApplicationID放入关联关系记录；返回对应SIP INVITE请求的成功响应，开始即时消息通讯；
步骤308：根据已设置的关联关系，在SIP系统和IMPS系统之间进行会话消息的转换与转发。具体包括：
接收SIP用户在对话内通过MSRP发送的SIP消息，根据所述SIP消息所属的对话标识，查找所述关联关系记录得到IMPS用户的用户标识、客户端标识和/或应用标识，将所述消息转换为IMPS协议支持的格式，并将所述转换格式后的消息发送到所述IMPS用户标识、客户端标识和/或应用标识对应的IMPS客户端。其中，所述将SIP消息转换为IMPS消息包括：将IMPS消息的发送方设成以UserID和ClientID标识的SIP用户，将IMPS消息的接收方设置为以UserID、UserID和ClientID或UserID和ApplicationID标识的IMPS用户的客户端。
和/或，来自IMPS用户的消息，根据所述消息中的IMPS用户的用户标识、SIP用户的用户标识和/或客户端标识，查找所述关联关系得到对应的SIP系统会话标识，将所述消息转换为SIP支持的格式，并将所述转换格式后的消息通过所述SIP系统会话标识对应的SIP会话发送到SIP系统。
如果接收到SIP用户的SIP BYE请求，或者在某个时间期内没有收到IMPS用户的消息，则结束SIP系统的对话，删除关联关系记录，结束流程。
步骤309：直接返回给SIP用户失败响应，删除步骤301生成的关联关系记录，并结束本流程。
IMPS用户向SIP用户发送邀请请求进行即时消息通讯，GW在此过程中的处理流程如图4所示，包括如下步骤：
步骤401：接收IMPS用户的邀请请求，新生成一条关联关系记录，将邀请请求中的发送方UserID作为IMPS用户的UserID放入关联关系记录，如果请求中包含发送方ClientID或ApplicationID，则将该IMPS用户的ClientID或ApplicationID放入关联关系记录；
步骤402：将IMPS邀请请求中的接收方UserID作为SIP用户的UserID放入关联关系记录；
步骤403：将IMPS邀请请求转换成SIP INVITE请求，请求的接收方AOR为步骤402确定的SIP用户UserID，请求的发送方AOR为IMPS用户的UserID，请求的From tag和Call-ID由GW生成；
步骤404：发送SIP INVITE请求，接收响应，如果为失败响应，则转至步骤409；如果为成功响应，则执行步骤405至408；
步骤405：将SIP对话标识放入关联关系记录；
步骤406：生成一个SIP用户的ClientID，该ClientID对同一对SIP用户和IMPS用户保持唯一，将生成的ClientID放入关联关系记录；具体生成方式可类比前面的步骤304。
步骤407：将成功响应转换成邀请响应，表示SIP用户接收邀请，在邀请响应中以SIP用户的UserID和ClientID来标识SIP用户，开始即时消息；
步骤408：根据已设置的关联关系，在SIP系统和IMPS系统之间进行会话消息的转换与转发。具体包括：
接收SIP用户在对话内通过MSRP发送的SIP消息，根据所述SIP消息所属的对话标识，查找所述关联关系记录得到IMPS用户的用户标识、客户端标识和/或应用标识，将所述消息转换为IMPS协议支持的格式，并将所述转换格式后的消息发送到所述IMPS用户标识、客户端标识和/或应用标识对应的IMPS客户端。其中，所述将SIP消息转换为IMPS消息包括：将IMPS消息的发送方设成以UserID和ClientID标识的SIP用户，将IMPS消息的接收方设置为以UserID、UserID和ClientID或UserID和ApplicationID标识的IMPS用户的客户端。
和/或，来自IMPS用户的消息，根据所述消息中的IMPS用户的用户标识、SIP用户的用户标识和/或客户端标识，查找所述关联关系得到对应的SIP系统会话标识，将所述消息转换为SIP支持的格式，并将所述转换格式后的消息通过所述SIP系统会话标识对应的SIP会话发送到SIP系统。
如果接收到SIP用户的SIP BYE请求，或者在某个时间期内没有收到IMPS用户的消息或收到IMPS用户发出的取消邀请请求，则结束SIP系统的对话，删除关联关系记录。
步骤409：回复IMPS用户邀请响应，表示SIP用户不接收邀请，删除步骤401生成的关联关系记录，流程结束。
通过SIP SUBSCRIBE请求建立对话用于呈现信息订阅和通知
通过SIP SUBSCRIBE请求建立对话同样可以分为SIP用户发起订阅请求和IMPS用户发起订阅请求两种情况。
SIP用户发起订阅请求，接收来自IMPS服务器发送的呈现通知，GW在此过程中的处理流程如图5所示，包括如下步骤：
步骤501：接收SIP用户发送的SIP SUBSCRIBE请求，新生成一条关联关系记录，将所述SIP SUBSCRIBE请求中的SIP的对话标识放入关联关系记录，对话标识由From tag、To tag和Call-ID组成；
步骤502：将SIP SUBSCRIBE请求中的发送方AOR作为SIP用户在IMPS系统的UserID，放入关联关系记录；
步骤503：将SIP SUBSCRIBE请求中的接收方AOR作为IMPS用户的UserID，放入关联关系记录；
步骤504：生成一个SIP用户的ClientID，该ClientID对同一对SIP用户和IMPS用户保持唯一，将生成的ClientID放入关联关系记录；具体生成方式可类比前面的步骤304；
步骤505：将SIP SUBSCRIBE请求映射成相应的IMPS呈现订阅请求或获取呈现信息请求，IMPS请求的发送方为以UserID和ClientID标识的SIP用户，请求的接收方为以UserID标识的IMPS用户，发送IMPS呈现订阅请求；
步骤506：接收IMPS系统的应答，如果应答表示订阅失败，则至步骤509；如果应答表示订阅成功，则执行步骤507至步骤508；
步骤507：返回对应SIP SUBSCRIBE请求的成功响应；
步骤508：接收IMPS系统发送的呈现信息通知，根据其中接受方SIP用户的UserID和ClientID，发送方IMPS用户的UserID查找关联关系记录，确定SIP系统的对话，在SIP系统对话内用SIP NOTIFY请求发送呈现信息。如果接收到SIP用户的去订阅请求，或者SIP系统订阅有效期满而SIP用户没有继续订阅，则结束SIP系统的对话，删除关联关系记录，过程结束；
步骤509：删除步骤501生成的关联关系记录，直接返回给SIP用户失败响应，整个过程结束。
IMPS用户发起订阅请求，接收来自SIMPLE呈现服务器发送的呈现通知，GW在此过程中的处理流程如图6所示，包括如下步骤：
步骤601：接收IMPS用户发起的订阅请求，生成一条关联关系记录，将请求中的发送方UserID作为IMPS用户的UserID放入关联关系记录，如果请求中包含发送方ClientID或ApplicationID，则将该IMPS用户的ClientID或ApplicationID放入关联关系记录；；
步骤602：将IMPS呈现订阅请求中的被订阅者UserID作为SIP用户在IMPS系统的UserID，放入关联关系记录；
步骤603：将IMPS呈现订阅请求转换成SIP SUBSCRIBE请求，请求的接收方AOR为步骤602确定的SIP用户UserID，请求的发送方AOR为IMPS用户的UserID，请求的From tag和Call-ID由GW生成，发送SIPSUBSCRIBE请求；
步骤604：接收SIP响应，如果为失败响应，则至步骤608；如果为成功响应，则执行步骤605至步骤607；
步骤605：将对话标识放入关联关系记录；
步骤606：将SIP成功响应转换成IMPS成功状态响应，表示订阅成功，状态响应被送往IMPS用户；
步骤607：接收SIMPLE呈现服务器在对话内发送的被订阅者SIP用户的呈现信息通知，转换成IMPS格式的呈现通知，呈现通知的接收者根据关联关系记录设成以UserID、UserID和ClientID或UserID和ApplicationID标识的IMPS用户，呈现通知中的呈现者为以UserID为标识的SIP用户；如果接收到IMPS用户的去订阅请求，或者SIP系统的订阅终止(包括终止不能再订阅或终止再订阅失败)，则结束SIP系统的对话，删除关联关系记录，流程结束。
步骤608：回复IMPS用户失败响应，表示订阅失败，删除步骤1生成的关联关系记录，流程结束。
为使本发明的目的、技术方案和优点更加清楚，下面结合具体实施例对本发明作进一步的详细阐述。
图7示出了本发明第一实施例的SIP用户请求进行即时消息的信令交互流程。图中的SIP客户端包括属于同一个SIP用户的多个客户端，本实施例中一个SIP用户有两个SIP客户端；SIP服务器包括SIP/IP核心网和至少一个基于SIP的业务服务器。本实施例的流程具体如下：
步骤701：SIP用户要和IMPS用户进行即时消息，因此通过属于该SIP用户的SIP客户端发送SIP INVITE请求，本实施例中，假设是通过SIP客户端1发送该SIP INVITE请求，如下：
INVITE wv:bob@biloxi.com SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bK776asdhds
Max-Forwards:70
To:Bob<wv:bob@biloxi.com> //被邀请用户的UserID
From:Alice<sip:alice@atlanta.com>；tag＝1928301774 //发起邀请的用户的UserID以及来
源标签
Call-ID:a84b4c76e66710@pc33.atlanta.com //呼叫标识
CSeq:314159INVITE
Contact:<sip:alice@atlanta.com；gr＝urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
Content-Type:application/sdp
Content-Length:142
...
该SIP INVITE请求被路由到SIP服务器。
步骤702：SIP服务器对所述SIP INVITE请求进行处理，例如确定下一步的路由，将SIP INVITE 转发到互连网关。
步骤703：互连网关根据上述SIP INVITE请求中的“INVITEwv:bob@biloxi.com SIP/2.0”判断该请求是即时消息请求，因此将SIPINVITE请求映射为IMPS的InviteRequest，所述InviteRequest的内容如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-SSP1.3″>
<Session sessionID＝″123456@someone.za″>
<Transaction mode＝″Request″transactionID＝″113″>
<InviteRequest inviteID＝“12345”inviteType＝“IM”validity＝“60”>
<MetaInfo clientOriginated＝″Yes″>
<Requestor>
<User userID＝″sip:alice@atlanta.com″>
<ClientID url＝″alice01″/>
</User>
</Requestor>
</MetaInfo>
<Inviting>
<User userID＝“sip:alice@atlanta.com”> //发起邀请用户的UserID
<ClientID url＝“alice01”/> //发起邀请用户的ClientID
</User>
</Inviting>
<Invited>
<User userID＝“wv:bob@biloxi.com”/> //被邀请用户的UserID
</Invited>
</InviteRequest>
</Transaction>
</Session>
</WV-SSP-Message>
其中邀请者的UserID“sip:alice@atlanta.com”和被邀请者的UserID“wv:bob@biloxi.com”分别来自于SIP INVITE请求的来源(From)头域和目的(To)头域，邀请者的ClientID“alice01”为互连网关在该步骤中即时生成，该请求被发送到相应的IMPS服务器。
步骤704：IMPS服务器向互连网关返回状态(Status)响应。
步骤705：步骤703之后，IMPS服务器将SSP的InviteRequest转换成CSP的邀请用户请求(InviteUserRequest)发给IMPS Client。步骤705可以在步骤704之前或之后，步骤704和步骤705之间没有先后次序关系。
步骤706：IMPS客户端向IMPS服务器返回状态响应；
步骤707：IMPS用户接收邀请，通过IMPS客户端相IMPS服务器返回邀请用户响应(InviteUserResponse)，具体如下：
<WV-CSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-CSP1.3″>
<Session sessionID＝″478923@bob.biloxi.com″>
<Transaction mode＝″Response″transactionID＝″113″>
<InviteUserResponse inviteID＝“12345”acceptance＝“Yes”>
<Status code＝″200″/>
<Inviting>
<User userID＝“sip:alice@atlanta.com”> //发起邀请用户的UserID
<ClientID url＝“alice01”/> //发起邀请用户的ClientID
</User>
</Inviting>
<Responding>
<User userID＝“wv:bob@biloxi.com”> //被邀请用户的UserID
<ClientID url＝″http://www.wireless-village.org/applications/MudServer″/>//被邀请
用户的ClientID
</User>
</Responding>
</InviteUserResponse>
</Transaction>
</Session>
</WV-CSP-Message>
该信令中包含了IMPS Client的ClientID“http://www.wireless-village.org/applications/MudServer”。
步骤708：IMPS服务器向IMPS客户端返回状态响应。
步骤709：在步骤707之后，IMPS服务器将CSP的InviteUserResponse转换成SSP的InviteResponse，发送给互连网关。
步骤710：互连网关向IMPS服务器返回状态响应。
步骤711：步骤709之后，互连网关判断IMPS用户接收邀请，因此返回对应步骤702中SIP INVITE的成功响应SIP 200OK，响应首先发送到SIP服务器，具体如下：
SIP/2.0 200 OK
To:Bob<wv:bob@biloxi.com>；tag＝a6c85cf //被邀请用户的UserID以及目的标
签
From:Alice<sip:alice@atlanta.com>；tag＝1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq:314159 INVITE
Contact:<sip:gateway@example.com>
Content-Type:application/sdp
Content-Length:131
同时互连网关新建一条关联关系记录，如表2所示：
| 关联关系 | 内容 |
| 对话标识 | From-tag＝1928301774；To-tag＝a6c85cf；Call-ID＝a84b4c76e66710@pc33.atlanta.com |
| SIP用户的UserID | sip:alice@atlanta.com |
| SIP用户的ClientID | alice01 |
| IMPS用户的UserID | wv:bob@biloxi.com |
| IMPS用户的ClientID或ApplicationID | ClientID＝http://www.wireless-village.org/applications/MudServer |
表2
步骤712：SIP服务器向SIP客户端1返回SIP 200OK响应；
步骤713：SIP客户端1向SIP服务器发送SIP ACK请求；
步骤714：SIP服务器向互连网关发送SIP ACK请求，SIP客户端1和互连网关之间建立用于即时消息的MSRP会话；
步骤715：SIP客户端1利用MSRP发送指令(MSRP SEND)发送即时消息，消息被发送到互连网关，具体内容如下：
MSRP d93kswow SEND
To-Path:msrp://gateway.example.com:8888/9di4eae923wzd；tcp //源地址
From-Path:msrp://alicemphone.example.com:7777/iau39soe2843z；tcp //目的地址
Message-ID:12339sdqwer //消息标识
Byte-Range:1-148/148
Content-Type:message/cpim
To:Bob<wv:bob@example.com> //IMPS用户的UserID
From:Alice<sip:alice@example.com>
Content-Type:text/plain
Hi，I’m Alice！ //消息内容
-------d93kswow$
步骤716：互连网关向SIP客户端1返回MSRP OK响应；
步骤717：步骤715之后，互连网关收到来自SIP客户端1的MSRP SEND消息，判断该消息属于已建立的对话，根据该MSRP SEND消息中携带的对话标识查找自身已经保存的关联关系记录，确定接收方IMPS用户的UserID和ClientID；并且，互连网关进行消息格式转换，将所述MSRP SEND消息转换成IMPS格式的发送消息请求(SendMessageRequest)，具体如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-SSP1.3″>
<Session sessionID＝″123456@someone.za″>
<Transaction mode＝″Request″transactionID＝″114″>
<SendMessageRequest deliveryReport＝“No”>
<MetaInfo clientOriginated＝″Yes″>
<Requestor>
<User userID＝″sip:alice@atlanta.com″>
<ClientID url＝″alice01″/>
</User>
</Requestor>
</MetaInfo>
<MessageInfo contentSize＝“14”>
<Recipient> //消息接收者
<User userID＝“wv:bob@biloxi.com”>
<ClientID url＝″http://www.wireless-village.org/applications/MudServer″/>
</User>
</Recipient>
<Sender> //消息发送者
<User userID＝“sip:alice@atlanta.com”>
<ClientID url＝“alice01”/>
</User>
</Sender>
</MessageInfo>
<ContentData contentType＝“text/plain”encoding＝“base64”> //消息内容
Hi，I′m Alice！
</ContentData>
</SendMessageRequest>
</Transaction>
</Session>
</WV-SSP-Message>
可以看到，在MessageInfo元素中的接收方UserID和ClientID为查找到的IMPS用户的UserID和ClientID，发送方UserID和ClientID为SIP用户的UserID和ClientID，该SendMessageRequest被发送到IMPS服务器。
步骤718：IMPS服务器向互连网关返回发送消息响应(SendMessageResponse)。
步骤719：步骤717之后，IMPS服务器将SSP的SendMessageRequest转换成CSP的新消息(NewMessage)，发送给IMPS客户端。由于在此之间已经确认了接收方的UserID和ClientID，所以保证消息能够发送给正确的IMPS客户端。
步骤720：IMPS客户端向IMP服务器返回消息已传递(MessageDelivered)响应；
步骤721：在SIP用户用SIP客户端1与IMPS用户进行即时消息的过程中，可能该用户想利用另一个终端SIP客户端2与相同的IMPS用户进行即时消息，而原来SIP客户端1与IMPS用户进行的会话不能中断，例如正在传送文件，因此需要同时进行两个会话，SIP用户利用SIP客户端2发出SIP INVITE请求，具体如下：
INVITE wv:bob@biloxi.com SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bK776asdhds
Max-Forwards:70
To:Bob<wv:bob@biloxi.com>
From:Alice<sip:alice@atlanta.com>；tag＝7723
Call-ID:12345@pc33.atlanta.com
CSeq:212 INVITE
Contact:<sip:alice@atlanta.com；gr＝kjh29x97us97d>
Content-Type:application/sdp
Content-Length:142
...
该SIP INVITE请求同步骤701中一样，被路由到SIP服务器；
步骤722：SIP服务器对来自SIP客户端2的SIP INVITE请求进行处理，例如确定下一步的路由，将SIP INVITE转发到互连网关。
步骤723：互连网关判断该请求是即时消息请求，因此将SIP INVITE请求映射为IMPS的InviteRequest，如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD WV-SSP1.3″>
<Session sessionID＝″223456@someone.za″>
<Transaction mode＝″Request″transactionID＝″113″>
<InviteRequest inviteID＝“22345”inviteType＝“IM”validity＝“60”>
<MetaInfo clientOriginated＝″Yes″>
<Requestor>
<User userID＝″sip:alice@atlanta.com″>
<ClientID url＝″alice02″/>
</User>
</Requestor>
</MetaInfo>
<Inviting> //邀请者
<User userID＝“sip:alice@atlanta.com”>
<ClientID url＝“alice02”/>
</User>
</Inviting>
<Invited> //被邀请者
<User userID＝“wv:bob@biloxi.com”/>
</Invited>
</InviteRequest>
</Transaction>
</Session>
</WV-SSP-Message>
其中邀请者的UserID和被邀请者的UserID分别来自于SIP INVITE请求的From头域和To头域，邀请者的ClientID为互连网关生成，该请求被发送到相应的IMPS服务器。步骤723中的InviteRequest与步骤703中的InviteRequest相比，差别仅仅在于发起请求的客户端标识不同。
步骤724：IMPS服务器向互连网关返回状态响应。
步骤725：步骤723之后，IMPS服务器将SSP的InviteRequest转换成CSP的InviteUserRequest发给IMPS客户端。
步骤726：IMPS客户端向IMPS服务器返回状态响应；
步骤727：IMPS用户接收邀请，通过IMPS客户端返回InviteUserResponse，发送给IMPS Server，如下：
<WV-CSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-CSP1.3″>
<Session sessionID＝″478923@bob.biloxi.com″>
<Transaction mode＝″Response″transactionID＝″113″>
<InviteUserResponse inviteID＝“22345”acceptance＝“Yes”>
<Status code＝″200″/>
<Inviting> //邀请者
<User userID＝“sip:alice@atlanta.com”>
<ClientID url＝“alice02”/>
</User>
</Inviting>
<Responding> //被邀请者
<User userID＝“wv:bob@biloxi.com”>
<ClientID url＝″http://www.wireless-village.org/applications/MudServer″/>
</User>
</Responding>
</InviteUserResponse>
</Transaction>
</Session>
</WV-CSP-Message>
该信令中包含了IMPS Client的ClientID。
步骤728：IMPS服务器向IMPS客户端返回状态响应。
步骤729：在步骤727之后，IMPS服务器将CSP的InviteUserResponse转换成SSP的InviteResponse，并发送给互连网关。
步骤730：互连网关向IMPS服务器返回状态响应。
步骤731：步骤729之后，互连网关判断IMPS用户接收邀请，因此返回对应步骤722中SIP INVITE的成功响应SIP 200 OK，响应首先发送到SIP服务器，如下：
SIP/2.0 200 OK
To:Bob<wv:bob@biloxi.com>；tag＝1234
From:Alice<sip:alice@atlanta.com>；tag＝7723
Call-ID:12345@pc33.atlanta.com
CSeq:212 INVITE
Contact:<sip:gateway@example.com>
Content-Type:application/sdp
Content-Length:131
同时互连网关新建一条关联关系记录，如表3所示：
| 关联关系 | 内容 |
| 对话标识 | From-tag＝7723；To-tag＝1234；Call-ID＝12345@pc33.atlanta.com |
| SIP用户UserID | sip:alice@atlanta.com |
| SIP用户ClientID | alice02 |
| IMPS用户UserID | wv:bob@biloxi.com |
| IMPS用户ClientID或ApplicationID | ClientID＝http://www.wireless-village.org/applications/MudServer |
表3
步骤732：SIP服务器向SIP客户端2返回SIP 200 OK响应。
步骤733：SIP客户端2向SIP服务器发送SIP ACK请求。
步骤734：SIP服务器向互连网关发送SIP ACK请求，SIP客户端2和互连网关之间建立用于即时消息的MSRP会话。
步骤735：对IMPS用户来说，此时可以与UserID为sip:alice@example.com的用户的两个客户端进行即时消息，这两个客户端的ClientID分别为alice01和alice02，IMPS用户利用IMPS客户端向新发出邀请的alice02发送即时消息，消息被发送到IMPS服务器，如下：
<WV-CSP-Message xmlns＝”http://www.openmobilealliance.org/DTD/WV-CSP1.3”>
<Session sessionID＝″478923@bob.biloxi.com″>
<Transaction mode＝”Request″transactionID＝”114”>
<SendMessageRequest deliveryReport＝“No”>
<MessageInfo contentSize＝“18”>
<Recipient> //消息接收者
<User userID＝“sip:alice@atlanta.com”>
<ClientID url＝”alice02”/>
</User>
</Recipient>
<Sender> //消息发送者
<User userID＝“wv:bob@biloxi.com”>
<ClientID url＝“http://www.wireless-village.org/applications/MudServer”/>
</User>
</Sender>
</MessageInfo>
<ContentData contentType＝“text/plain”encoding＝“base64”> //消息内容
Why change client？
</ContentData>
</SendMessageRequest>
</Transaction>
</Session>
</WV-CSP-Message>
步骤736：IMPS服务器向IMPS客户端返回SendMessageResponse响应；
步骤737：步骤735之后，IMPS服务器将CSP的SendMessageRequest转换成SSP的SendMessageRequest，发给互连网关。
步骤738：互连网关返回给IMPS服务器SendMessageResponse响应。
步骤739：步骤737之后，互连网关收到SendMessageRequest发送的消息，根据消息的发送方UserID，接收方UserID和ClientID，查找关联关系记录，确定SIP系统的对话标识，GW进行消息格式转换，转换成MSRP格式的MSRP SEND消息，并在所查找到的对话内发送该消息，所述MSRPSEND内容如下：
MSRP d93kswow SEND
To-Path:msrp://alicepc.example.com:3020/iau39soe2844z；tcp
From-Path:msrp://gateway.example.com:8888/0di4eae923wzd；tcp
Message-ID:12340sdqwer
Byte-Range:1-152/152
Content-Type:message/cpim
To:Bob<sip:alice@example.com>
From:Alice<wv:bob@example.com>
Content-Type:text/plain
Why change client？ //消息内容
-------d93kswow$
该消息被发往SIP客户端2；
步骤740：SIP客户端2接收MSRP SEND消息，向互连网关返回MSRPOK响应。
在上述会话过程中，有可能IMPS用户会用另一个客户端与同一SIP用户再建立一个会话，图8示出了IMPS客户端1正在与SIP客户端通话的过程中，IMPS用户通过IMPS客户端2主动请求进行即时消息的信令流程，包括如下步骤：
步骤801至步骤814：IMPS用户通过IMPS客户端2向同一SIP用户发出即时消息邀请，互连网关进行信令转换，向SIP用户发出SIP INVITE请求，SIP用户接收邀请，回复成功响应，网关转换成IMPS邀请响应，表示SIP用户接收即时消息邀请，在互连网关新建一条关联关系记录如表4所示：
| 对话标识 | From-tag＝7745；To-tag＝4456；Call-ID＝23456@pc33.atlanta.com |
| SIP用户UserID | sip:alice@atlanta.com |
| SIP用户ClientID | alice03 |
| IMPS用户UserID | wv:bob@biloxi.com |
| IMPS用户ClientID或ApplicationID | ClientID＝bobIM |
表4
步骤815至步骤820：SIP用户利用新建的会话向新IMPS用户客户端发送消息，GW接收消息，查找关联表后，将消息正确的发往IMPS用户的客户端，该客户端ClientID为“bobIM”。
以上的第一实施例中说明了客户端到客户端的消息流程，也同样适用于SIP用户或IMPS用户利用多终端加入另外系统聊天室的场景。
图9示出了本发明第二实施例为SIP用户订阅IMPS用户呈现信息的信令交互流程，具体包括如下步骤：
步骤901：SIP用户想订阅IMPS用户的呈现信息，因此通过SIP客户端1发送SIP订阅(SIP SUBSCRIBE)请求，该请求具体内容如下：
SUBSCRIBE wv:bob@biloxi.com SIP/2.0
To:<wv:bob@biloxi.com> //被订阅的呈现者
From:<sip:alice@atlanta.com>；tag＝xfg9 //订阅者
Call-ID:2010@biloxi.com
CSeq:17766 SUBSCRIBE
Max-Forwards:70
Event:presence
Accept:application/pidf+xml
Contact:<sip:alice@atlanta.com；gr＝urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
Expires:600
Content-Length:...
请求首先被发送到呈现服务器(Presence Server)。
步骤902：呈现服务器判断被订阅者为IMPS用户，将SIP SUBSCRIBE请求发送给互连网关。
步骤903：互连网关将SIP SUBSCRIBE请求转换成IMPS的SubscribeRequest，发送给IMPS服务器，如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-SSP1.3″>
<Session sessionID＝″123456@someone.za″>
<Transaction mode＝″Request″transactionID＝″113″>
<SubscribeRequest>
<MetaInfo clientOriginated＝″Yes″>
<Requestor> //订阅者
<User userID＝″sip:alice@atlanta.com″>
<ClientID url＝″alice01″/>
</User>
</Requestor>
</MetaInfo>
<UserID userID＝“wv:bob@biloxi.com”/> //被订阅的呈现者
...
</SubscribeRequest>
</Transaction>
</Session>
</WV-SSP-Message>
步骤904：IMPS服务器检查授权状况，判断允许该SIP用户订阅IMPS用户的呈现信息，返回状态响应，表示订阅成功；
步骤905：互连网关接收状态响应，转换成SIP 200OK响应，返回给呈现服务器，所述SIP 200OK响应的内容具体如下：
SIP/2.0 200 OK
To:<wv:bob@biloxi.com>；tag＝ffd2
From:<sip:alice@atlanta.com>；tag＝xfg9
Call-ID:2010@biloxi.com
CSeq:17766 SUBSCRIBE
Expires:600
Contact:<sip:gateway@example.com>
Content-Length:0
同时互连网关新建一条关联关系记录如表5所示：
| 对话标识 | From-tag＝xfg9；To-tag＝ffd2；2010@biloxi.com |
| SIP用户UserID | sip:alice@atlanta.com |
| SIP用户ClientID | alice01 |
| IMPS用户UserID | wv:bob@biloxi.com |
| IMPS用户ClientID或ApplicationID | NULL |
表5
步骤906：呈现服务器向SIP客户端1返回SIP 200 OK响应；
步骤907：步骤904之后，IMPS服务器向订阅者发送被订阅者的呈现信息，如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-SSP1.3″>
<Session sessionID＝″123456@biloxi.com″>
<Transaction mode＝″Request″transactionID＝″113″>
<PresenceNotification>
<MetaInfo clientOriginated＝″No″/>
<User userID＝“sip:alice@atlanta.com”> //订阅者
<ClientID url＝″alice01″/>
</User>
<PresenceValue userID＝”wv:bob@biloxi.com”> //呈现者的呈现信息
...
</Presence Value>
</PresenceNotification>
</Transaction>
</Session>
</WV-SSP-Message>
该消息首先被发送到互连网关；
步骤908：互连网关向IMPS服务器返回Status应答；
步骤909：步骤907之后，互连网关根据收到的PresenceNotification中订阅者UserID、ClientID和被订阅者UserID，查找关联关系记录，找到对应的SIP系统订阅对话，在该对话内通过SIP NOTIFY请求将收到的呈现信息发给SIP客户端1，如下：
NOTIFY sip:alice@atlanta.com；gr＝urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
From:<wv:bob@biloxi.com>；tag＝ffd2
To:<sip:alice@atlanta.com>；tag＝xfg9
Call-ID:2010@biloxi.com
Event:presence
Subscription-State:active；expires＝598
Max-Forwards:70
CSeq:8775NOTIFY
Contact:<sip:gateway@example.com>
Content-Type:application/pidf+xml
Content-Length:...
步骤910：SIP客户端1向互连网关返回SIP 200 OK响应；
步骤911：该SIP用户打开另一个终端SIP客户端2，通过该终端订阅同一IMPS用户的另外一些呈现信息，首先通过SIP客户端2发送SIPSUBSCRIBE请求，如下：
SUBSCRIBE wv:bob@biloxi.com SIP/2.0
To:<wv:bob@biloxi.com>
From:<sip:alice@atlanta.com>；tag＝xfg8
Call-ID:2011@biloxi.com
CSeq:177 SUBSCRIBE
Max-Forwards:70
Event:presence
Accept:application/pidf+xml
Contact:<sip:alice@atlanta.com；gr＝kjh29x97us97d>
Expires:600
Content-Length:0
请求首先被发送到呈现服务器。
步骤912：呈现服务器判断被订阅者为IMPS用户，将SIP SUBSCRIBE请求发送给互连网关；
步骤913：互连网关将SIP SUBSCRIBE请求转换成IMPS的SubscribeRequest，发送给IMPS服务器，如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-SSP1.3″>
<Session sessionID＝″223456@someone.za″>
<Transaction mode＝″Request″transactionID＝″113″>
<SubscribeRequest>
<MetaInfo clientOriginated＝″Yes″>
<Requestor>
<User userID＝″sip:alice@atlanta.com″>
<ClientID url＝″alice02″/>
</User>
</Requestor>
</MetaInfo>
<UserID userID＝“wv:bob@biloxi.com”/>
...
</SubscribeRequest>
</Transaction>
</Session>
</WV-SSP-Message>
步骤914：IMPS服务器检查授权状况，判断允许该SIP用户订阅IMPS用户的呈现信息，返回Status响应，表示订阅成功；
步骤915：互连网关接收Status响应，转换成SIP 200OK响应，返回给呈现服务器，如下：
SIP/2.0 200 OK
To:<wv:bob@biloxi.com>；tag＝ffd3
From:<sip:alice@atlanta.com>；tag＝xfg8
Call-ID:2011@biloxi.com
CSeq:177 SUBSCRIBE
Expires:600
Contact:<sip:gateway@example.com>
Content-Length:0
同时互连网关新建一条关联关系记录如表6所示：
| 对话标识 | From-tag＝xfg8；To-tag＝ffd3；2011@biloxi.com |
| SIP用户UserID | sip:alice@atlanta.com |
| SIP用户ClientID | alice02 |
| IMPS用户UserID | wv:bob@biloxi.com |
| IMPS用户ClientID或ApplicationID | NULL |
表6
步骤916：呈现服务器向SIP客户端2返回SIP 200 OK响应；
步骤917：步骤904之后，IMPS服务器向订阅者发送被订阅者的呈现信息，如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-SSP1.3″>
<Session sessionID＝″123456@biloxi.com″>
<Transaction mode＝″Request″transactionID＝″114″>
<PresenceNotification>
<MetaInfo clientOriginated＝″No″/>
<User userID＝“sip:alice@atlanta.com”>
<ClientID url＝″alice02″/>
</User>
<PresenceValue userID＝”wv:bob@biloxi.com”>
...
</PresenceValue>
</PresenceNotification>
</Transaction>
</Session>
</WV-SSP-Message>
该消息首先被发送到互连网关；
步骤918：互连网关向IMPS服务器返回Status应答；
步骤919：步骤907之后，互连网关根据收到的PresenceNotification中订阅者UserID、ClientID和被订阅者UserID，查找关联关系记录，找到对应的SIP系统订阅对话，在该对话内通过SIP NOTIFY请求将收到的呈现信息发给SIP客户端1，如下：
NOTIFY sip:alice@atlanta.com；gr＝kjh29x97us97d SIP/2.0
From:<wv:bob@biloxi.com>；tag＝ffd3
To:<sip:alice@atlanta.com>；tag＝xfg8
Call-ID:2011@biloxi.com
Event:presence
Subscription-State:active；expires＝598
Max-Forwards:70
CSeq:8775 NOTIFY
Contact:<sip:gateway@example.com>
Content-Type:application/pidf+xml
Content-Length:...
步骤920：SIP客户端1向互连网关返回SIP 200 OK响应；
步骤921：一段时间之后，SIP客户端1订阅的IMPS用户的呈现信息发生变化，IMPS服务器发出PresenceNotification，如下：
<WV-SSP-Message xmlns＝″http://www.openmobilealliance.org/DTD/WV-SSP1.3″>
<Session sessionID＝″123456@biloxi.com″>
<Transaction mode＝″Request″transactionID＝″115″>
<PresenceNotification>
<MetaInfo clientOriginated＝″No″/>
<User userID＝“sip:alice@atlanta.com”>
<ClientID url＝″alice01″/>
</User>
<PresenceValue userID＝”wv:bob@biloxi.com”>
...
</PresenceValue>
</PresenceNotification>
</Transaction>
</Session>
</WV-SSP-Message>
该消息首先被发送到互连网关；
步骤922：互连网关向IMPS服务器返回Status应答；
步骤923：步骤907之后，互连网关根据收到的PresenceNotification中订阅者UserID、ClientID和被订阅者UserID，查找关联关系记录，找到对应的SIP系统订阅对话，在该对话内通过SIP NOTIFY请求将收到的呈现信息发给SIP客户端1，如下：
NOTIFY sip:alice@atlanta.com；gr＝urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
From:<wv:bob@biloxi.com>；tag＝ffd2
To:<sip:alice@atlanta.com>；tag＝xfg9
Call-ID:2010@biloxi.com
Event:presence
Subscription-State:active；expires＝580
Max-Forwards:70
CSeq:8776 NOTIFY
Contact:<sip:gateway@example.com>
Content-Type:application/pidf+xml
Content-Length:...
步骤924：SIP客户端1向互连网关返回SIP 200 OK响应；
同一IMPS用户的多个IMPS客户端订阅同一SIP用户的呈现信息流程为上述流程反向，不同之处在于互连网关不分配ClientID给每个SIP对话，但是将SIP对话关联到IMPS用户的UserID和ClientID，具体流程不再详述。
本发明第三实施例提出了一种互连网关，其结构框图如图11所示，包括：
收发模块1001，用于接收来自SIP系统(或IMPS系统)的消息，根据关联关系查询模块1003的通知，将来自格式转换模块1004的消息发送至IMPS系统(或SIP系统)；
关联关系建立模块1002，用于确定对应于SIP系统和IMPS系统的消息业务的会话标识，建立并存储所述会话标识之间的关联关系；所述SIP系统会话标识包括SIP系统的对话标识；所述IMPS系统的会话标识包括参与该会话的SIP用户的用户标识和客户端标识，参与该会话的IMPS用户的用户标识和客户端标识，其中，IMPS用户的客户端标识可以是ClientID或ApplicationID；
关联关系查询模块1003，用于根据所述收发模块1001所接收的来自SIP系统(或IMPS系统)的消息的内容，查询所述关联关系建立模块1002中存储的关联关系，得到所述消息将要发送的IMPS系统(或SIP系统)会话标识，并将所得到的会话标识通知所述收发模块1001；
格式转换模块1004，用于将所述收发模块1001所接收的SIP(或IMPS协议)支持的消息转换为IMPS协议(或SIP)支持的格式，并将所述转换后的消息发送给所述收发模块1001。
其中，关联关系建立模块1002进一步包括：
获取单元，用于从所述收发模块1001所接收的SIP请求/应答或IMPS请求/应答中，获取SIP用户的用户标识、SIP系统的对话标识、IMPS用户的用户标识和IMPS用户的客户端标识，并将所获取的所述各项标识作为关联关系记录中的内容；
生成单元，用于生成关联关系记录中的SIP用户的客户端标识。
以上所述实施例都是IMPS用户和SIP用户之间的消息业务，实际上本发明方案并不限于此，凡是支持不同通信协议的多客户端用户之间的消息业务都可以应用本发明方案。另外，以上实施例中用于连接SIP系统和IMPS系统并且进行上述系统之间消息转换的网元为互连网关，实际上也可以由能够实现上述互连功能的其它网元来实现，因此将所述网元可以统称为互连功能实体。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
Claims (13)
1、一种通信互连方法，互连功能实体与支持第一通信协议的第一通信系统和支持第二通信协议的第二通信系统分别相连，其特征在于：
所述互连功能实体建立所述第一通信系统的会话标识和第二通信系统的会话标识之间的关联关系；
所述互连功能实体根据所述关联关系，在所述两个通信系统间转发会话消息。
2、根据权利要求1所述的方法，其特征在于，所述第一通信协议为会话初始协议SIP，所述第一通信系统为SIP系统，所述第二通信协议为即时消息和存在业务IMPS协议，所述第二通信系统为IMPS系统；
或者，所述第一通信协议为IMPS协议，所述第一通信系统为IMPS系统，所述第二通信协议为SIP，所述第二通信系统为SIP系统。
3、根据权利要求2所述的方法，其特征在于，所述SIP系统的会话标识为SIP对话标识，所述IMPS的会话标识为SIP用户的用户标识、SIP用户的客户端标识、IMPS用户的用户标识和/或IMPS用户的客户端标识。
4、根据权利要求3所述的方法，其特征在于，所述互连功能实体建立所述第一通信系统的会话标识和第二通信系统的会话标识之间的关联关系包括：
互连功能实体接收来自SIP系统中的SIP用户的SIP请求，新建一条SIP系统的会话标识和IMPS系统的会话标识的关联关系记录；
将所述SIP请求中的内容写入所述关联关系记录中；
将所述SIP请求转换为IMPS请求，并将所述IMPS请求发送到IMPS系统中；
接收来自IMPS系统的应答，并将所述应答中内容写入所述关联关系记录中。
5、根据权利要求4所述的方法，其特征在于，所述将所述SIP请求中的内容写入所述关联关系记录中包括：
将所述SIP请求中的对话标识作为所述关联关系记录中的SIP系统的会话标识；将所述SIP请求中的发送方地址记录作为所述关联关系记录中的所述SIP用户的用户标识，将所述SIP请求中的接收方地址记录作为所述关联关系记录中IMPS用户的用户标识；互连功能实体生成所述关联关系记录中的SIP用户的客户端标识，所述SIP用户的客户端标识对于所述SIP用户和IMPS用户保持唯一；
所述将SIP请求转换为IMPS请求包括：
将所述SIP用户的用户标识和/或所述SIP用户的客户端标识作为所述IMPS请求的发送方，将所述IMPS用户的用户标识作为所述IMPS请求的接收方。
6、根据权利要求4所述方法，其特征在于，所述将应答中内容写入所述关联关系记录中包括：
将所述应答中的IMPS用户的客户端标识或应用标识作为所述关联关系记录中的IMPS用户的客户端标识。
7、根据权利要求3所述的方法，其特征在于，所述互连功能实体建立所述第一通信系统的会话标识和第二通信系统的会话标识之间的关联关系包括：
互连功能实体接收来自IMPS用户的IMPS请求，新建一条SIP系统的会话标识和IMPS系统的会话标识的关联关系记录；
将所述IMPS请求中的内容写入所述关联关系记录中；
将所述IMPS请求转换为SIP请求，并将所述SIP请求发送到SIP系统中；
接收来自SIP系统的成功响应，将SIP成功响应的对话标识作为所述关联关系记录中的SIP系统的会话标识，生成所述关联关系记录中的SIP用户的客户端标识，所述SIP用户的客户端标识对于所述SIP用户和IMPS用户保持唯一。
8、根据权利要求7所述的方法，其特征在于，所述将所述IMPS请求中的内容写入所述关联关系记录中包括：
将所述IMPS请求中的发送方用户标识作为所述关联关系记录中的IMPS用户的用户标识，将所述IMPS请求中的发送方客户端标识或应用标识作为所述关联关系记录中的IMPS用户的客户端标识，将所述IMPS请求中的接收方用户标识作为所述关联关系记录中的SIP用户的用户标识；
所述将所述IMPS请求转换为SIP请求包括：
将所述SIP用户的用户标识作为所述SIP请求中的接收方地址记录，将所述IMPS用户的用户标识作为发送方的地址记录。
9、根据权利要求4至8任一项所述的方法，其特征在于，所述SIP请求为SIP邀请请求，所述IMPS请求为IMPS邀请请求；或者，所述SIP请求为SIP订阅请求，所述IMPS请求为IMPS订阅请求。
10、根据权利要求4至8任一项所述的方法，其特征在于，所述互连功能实体根据所述关联关系，在所述两个通信系统间转发会话消息包括：
互连功能实体接收到来自SIP用户的消息，根据所述消息所属的对话标识，查找所述关联关系得到IMPS用户的用户标识、客户端标识和/或应用标识，将所述消息转换为IMPS协议支持的格式，并将所述转换格式后的消息发送到所述IMPS用户标识、客户端标识和/或应用标识对应的IMPS客户端；
或者，互连功能实体接收来自IMPS用户的消息，根据所述消息中的IMPS用户的用户标识、SIP用户的用户标识和/或客户端标识，查找所述关联关系得到对应的SIP系统会话标识，将所述消息转换为SIP支持的格式，并将所述转换格式后的消息通过所述SIP系统会话标识对应的SIP会话发送到SIP系统。
11、一种互连功能实体，与支持第一通信协议的第一通信系统和支持第二通信协议的第二通信系统分别相连，其特征在于，包括：
收发模块，用于接收来自所述第一通信系统的消息，根据关联关系查询模块的通知将来自格式转换模块的消息发送至所述第二通信系统；或者
用于接收来自所述第二通信系统的消息，根据关联关系查询模块的通知将来自格式转换模块的消息发送至所述第一通信系统；
关联关系建立模块，用于确定对应于第一通信系统和第二通信系统的会话标识，建立并存储所述会话标识之间的关联关系；
关联关系查询模块，用于根据所述收发模块所接收的来自第一通信系统的消息所属会话标识，查询所述关联关系建立模块中存储的关联关系，得到所述第二通信系统的会话标识，并将所得到的第二通信系统的会话标识通知所述收发模块；或者
用于根据所述收发模块所接收的来自第二通信系统的消息所属会话标识，查询所述关联关系建立模块中存储的关联关系，得到所述第一通信系统的会话标识，并将所得到的第一通信系统的会话标识通知所述收发模块；
格式转换模块，用于将所述收发模块所接收的第一通信协议支持的消息转换为第二通信协议支持的格式，并将所述转换后的消息发送给所述收发模块；或者
用于将所述收发模块所接收的第二通信协议支持的消息转换为第一通信协议支持的格式，并将所述转换后的消息发送给所述收发模块。
12、根据权利要求10所述互连功能实体，其特征在于，所述第一通信协议为SIP，第二通信协议为IMPS；或者，所述第一通信协议为IMPS，第二通信协议为SIP。
13、根据权利要求12所述的互连功能实体，其特征在于，所述收发模块进一步用于接收来自SIP系统的SIP请求或来自IMPS系统的IMPS请求；
所述关联关系建立模块进一步包括：
获取单元，用于从所述收发模块所接收的SIP请求/应答或IMPS请求/应答中，获取SIP用户的用户标识、SIP系统的对话标识、IMPS用户的用户标识和/或IMPS用户的客户端标识，并将所获取的所述各项标识作为关联关系记录中的内容；
生成单元，用于生成关联关系记录中的SIP用户的客户端标识。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710137522.6A CN101355533B (zh) | 2007-07-26 | 2007-07-26 | 一种通信互连方法和设备 |
| PCT/CN2008/071762 WO2009012724A1 (fr) | 2007-07-26 | 2008-07-25 | Procédé et dispositif permettant une interconnexion de communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710137522.6A CN101355533B (zh) | 2007-07-26 | 2007-07-26 | 一种通信互连方法和设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101355533A true CN101355533A (zh) | 2009-01-28 |
| CN101355533B CN101355533B (zh) | 2011-09-14 |
Family
ID=40281021
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200710137522.6A Active CN101355533B (zh) | 2007-07-26 | 2007-07-26 | 一种通信互连方法和设备 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101355533B (zh) |
| WO (1) | WO2009012724A1 (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102298518A (zh) * | 2010-05-26 | 2011-12-28 | 微软公司 | 从技术未知的管理命令到多个管理协议的转换 |
| CN108965108A (zh) * | 2018-06-27 | 2018-12-07 | 腾讯科技（深圳）有限公司 | 一种消息推送方法及相关设备 |
| CN109246385A (zh) * | 2018-11-01 | 2019-01-18 | 苏州科达科技股份有限公司 | 用于多方会议的通信方法及会议系统 |
| CN109831377A (zh) * | 2019-03-26 | 2019-05-31 | 安康鸿天科技股份有限公司 | 一种不同即时通讯协议与sip协议之间互通的技术 |
| CN110178354A (zh) * | 2016-12-08 | 2019-08-27 | T移动美国公司 | 消息会话中继协议／超文本传输协议文件传输 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11533345B2 (en) | 2020-03-27 | 2022-12-20 | Samsung Electronics Co., Ltd. | Method and apparatus for providing generic framework to manage custom subscription over sip |
| CN112291207B (zh) * | 2020-10-16 | 2022-11-25 | 武汉中科通达高新技术股份有限公司 | 一种前端设备目录获取方法及装置 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005022863A1 (en) * | 2003-08-29 | 2005-03-10 | SIEMENS MOBILE COMMUNICATIONS S.p.A. .A. | Method for managing presence services in a communication system with heterogeneous presence protocols |
| US7526563B2 (en) * | 2004-02-27 | 2009-04-28 | Nokia Corporation | Interworking gateway and method |
| CN100544356C (zh) * | 2005-06-07 | 2009-09-23 | 中兴通讯股份有限公司 | 一种协议互通实体对重叠收发码信令的映射方法 |
| CN100488176C (zh) * | 2005-08-09 | 2009-05-13 | 华为技术有限公司 | 即时消息系统间的搜索方法 |
| CN100596124C (zh) * | 2006-03-03 | 2010-03-24 | 华为技术有限公司 | 实现业务互通的方法及系统 |
-
2007
- 2007-07-26 CN CN200710137522.6A patent/CN101355533B/zh active Active
-
2008
- 2008-07-25 WO PCT/CN2008/071762 patent/WO2009012724A1/zh active Application Filing
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102298518A (zh) * | 2010-05-26 | 2011-12-28 | 微软公司 | 从技术未知的管理命令到多个管理协议的转换 |
| CN102298518B (zh) * | 2010-05-26 | 2016-03-30 | 微软技术许可有限责任公司 | 从技术未知的管理命令到多个管理协议的转换 |
| CN110178354A (zh) * | 2016-12-08 | 2019-08-27 | T移动美国公司 | 消息会话中继协议／超文本传输协议文件传输 |
| CN108965108A (zh) * | 2018-06-27 | 2018-12-07 | 腾讯科技（深圳）有限公司 | 一种消息推送方法及相关设备 |
| CN108965108B (zh) * | 2018-06-27 | 2021-03-26 | 腾讯科技（深圳）有限公司 | 一种消息推送方法及相关设备 |
| CN109246385A (zh) * | 2018-11-01 | 2019-01-18 | 苏州科达科技股份有限公司 | 用于多方会议的通信方法及会议系统 |
| CN109246385B (zh) * | 2018-11-01 | 2020-08-28 | 苏州科达科技股份有限公司 | 用于多方会议的通信方法及会议系统 |
| CN109831377A (zh) * | 2019-03-26 | 2019-05-31 | 安康鸿天科技股份有限公司 | 一种不同即时通讯协议与sip协议之间互通的技术 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101355533B (zh) | 2011-09-14 |
| WO2009012724A1 (fr) | 2009-01-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7526563B2 (en) | Interworking gateway and method | |
| EP1929730B1 (en) | Method and apparatus for instant messaging | |
| CN101299785B (zh) | 一种会话处理的方法、系统以及业务服务器 | |
| CN101212719B (zh) | 一种无线通信网络中实现融合消息业务的方法及系统 | |
| KR100966959B1 (ko) | 단말기 디바이스, 네트워크 디바이스, 메시지 검색 방법 및 컴퓨터 프로그램 저장 제품 | |
| CN101355533B (zh) | 一种通信互连方法和设备 | |
| CN100499598C (zh) | 即时消息用户使用其它即时消息系统聊天室的方法及系统 | |
| US20090157816A1 (en) | System and method for instant message transmission in mobile communication terminal | |
| US9426108B2 (en) | Method for storing conversation upon user's request in CPM system, and system thereof | |
| US20080270553A1 (en) | Method and System for Instant Notification of Communication Block Information | |
| CN101374118A (zh) | 一种消息互连的方法、系统及装置 | |
| WO2008060085A1 (en) | Method and system for managing message threads in converged ip messaging service | |
| EP2560329B1 (en) | Method and processing system for routing a message request | |
| CN101207577B (zh) | 消息系统间的互连方法及消息互连网关 | |
| CN102130845A (zh) | 回执报告的发送方法及处理系统 | |
| CN100411394C (zh) | 一种在消息会话中继协议中消息的封装传输系统及方法 | |
| CN102123133A (zh) | 不同消息业务平台互通时传送消息回执的方法和消息系统 | |
| CN101834730A (zh) | 一种多媒体会议控制方法和系统 | |
| CN102340456A (zh) | 互通网关系统的通信方法及互通网关系统 | |
| CN101557352B (zh) | 一种实现群组消息业务的方法和系统 | |
| KR101455196B1 (ko) | 아이엠에스 기반의 프레즌스 서비스 연동 시스템 및 방법 | |
| CN102026112B (zh) | 一种融合ip消息的发送方法及系统 | |
| KR20100060355A (ko) | 통신 시스템에서 그룹 메시징 세션 생성 방법 및 그 시스템 | |
| CN101292480A (zh) | 脱机即时消息的取回 | |
| KR101445390B1 (ko) | 통합 메시징 서비스에서 수신 메시지의 처리 상태 정보공유 방법 및 시스템 |
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 | ||
| ASS | Succession or assignment of patent right |
Owner name: BEIJING WEIBEN INTELLECTUAL PROPERTY MANAGEMENT CO Free format text: FORMER OWNER: HUAWEI TECHNOLOGY CO., LTD. Effective date: 20150413 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 518129 SHENZHEN, GUANGDONG PROVINCE TO: 100080 HAIDIAN, BEIJING |
|
| TR01 | Transfer of patent right |
Effective date of registration: 20150413 Address after: 100080 room 401A, building 27, 1 Xin Lu, Haidian District, Beijing Patentee after: Beijing Weiben Intellectual Property Management Co. Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: Huawei Technologies Co., Ltd. |
|
| ASS | Succession or assignment of patent right |
Owner name: BEIJING Z-GOOD TECHNOLOGY SERVICE CO., LTD. Free format text: FORMER OWNER: BEIJING WEIBEN INTELLECTUAL PROPERTY MANAGEMENT CO., LTD. Effective date: 20150520 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 100080 HAIDIAN, BEIJING TO: 100085 HAIDIAN, BEIJING |
|
| TR01 | Transfer of patent right |
Effective date of registration: 20150520 Address after: 100085 Beijing city Haidian District No. 33 Xiaoying Road 1 1F06 room Patentee after: BEIJING ZHIGU TECHNOLOGY SERVICES CO., LTD. Address before: 100080 room 401A, building 27, 1 Xin Lu, Haidian District, Beijing Patentee before: Beijing Weiben Intellectual Property Management Co. Ltd. |