WO2009012724A1

WO2009012724A1 - A method and device for communication interconnection

Info

Publication number: WO2009012724A1
Application number: PCT/CN2008/071762
Authority: WO
Inventors: Yonggang Bian; Lunjian Mu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-07-26
Filing date: 2008-07-25
Publication date: 2009-01-29
Also published as: CN101355533A; CN101355533B

Abstract

A method for communication interconnection is provided, an interconnection function entity respectively interconnects the first communication system supporting the first communication protocol and the second communication system supporting the second communication protocol, the interconnection function entity establishes the associated relation between the session id of the first communication system and the session id of the second communication system; based on the associated relation, the interconnection function entity forwards the session message between two communication systems. A device for communication interconnection is also provided. The scheme of this invention makes no interference between multi-clients, when the message service is processed between the users of multi-clients supporting different protocols.

Description

Communication interconnection method and device

Technical field

The present invention relates to the field of communications technologies, and in particular, to a communication interconnection method and device. Background technique

The current messaging services in the mobile communication network or the Internet mainly include two types, one is instant messaging based on the Client Server Protocol (CSP)/Server-Server Protocol (SSP) protocol. And the message service in the Instant Messaging and Presence Service (IMS), and the other is the Session Initiated Protocol (SIP)-based message service, such as SIP instant messaging and presence extension (SIP Instant Message and Presence). Leveraging Extensions, SIMPLE) Instant Message (IM), Converged IP Message (CPM) and more.

In IMPS or SIP, a user can have multiple clients. These multiple clients can be located in different terminals or on the same terminal. Users can use multiple clients at the same time without interfering with each other. In the IMPS, a message can be sent to a user, and the message will be sent to a client, or multiple clients according to the settings of the user in the network, or directly sent to a client; when subscribing to the presence information, If you are using one of the multiple clients to subscribe, you also need to send the presence information to the subscribed terminal without affecting other terminals. Taking the SIP-based message service as an example, there are three types of messages in SIP: paging mode, large message mode, and session mode. The paging mode is sent by SIP message (SIP MESSAGE), and is not established between the sender and the receiver. Session, there is no connection between different messages, each message is independently routed; the big message mode needs to establish a session between the sender and the receiver, the media stream of the session is one-way, the session ends when a single message is sent, and different messages are also No contact, each message is independently routed; the session mode establishes a long-term session, sends a message within the session, and there is a connection between the messages, and the messages are routed according to the path negotiated by the session negotiation process. In the SIMPLE presentation service, the SIP subscription also needs to establish a session and send a SIP notification within the session, so that the routing path of the SIP notification is determined.

In the case of messaging between an IMPS user and a SIP user, an interconnection between IMPS and SIP needs to be implemented. Figure 1 is a schematic diagram of the existing IMPS user and SIP user interconnection, the IMPS system on the left and the SIP system on the right. The two systems are connected through the interconnection gateway (GW) for instant messaging, presence information, conferences, etc. Interconnection. SIP users can pass SIP messages (SIP MESSAGE) Or the Message Session Relay Protocol (MSRP) sends a message to the IMPS user or receives a message from the IMPS user, and the interconnection gateway completes the conversion between the IMPS message and the SIP MESSAGE/MSRP. FIG. 2 is a flow chart of establishing a message session between a SIP user and an IMPS user in the prior art, and the SIP user actively initiates a request. The SIP system represents an entity in the SIP system, which may be a SIP client or a SIP server; the IMPS system represents an entity in the IMPS system, which may be an IMPS client or an IMPS server. The process includes the following steps:

Step 201: The SIP system sends a SIP INVITE request to the interconnection gateway. Step 202: The interconnection gateway converts the SIP INVITE request into an invitation request of the IMPS invitation transaction (Invite Request), and sends the request to the IMPS system.

Step 203: The IMPS system returns a status response to the interconnection gateway.

Step 204: The interconnection gateway returns a SIP 100 Trying temporary response to the SIP system.

Step 205: After step 203, the IMPS system processes according to the received invitation request, and returns an invitation response (InviteResponse) of the invitation transaction to the interconnection gateway, indicating that the IMPS user accepts the invitation;

Step 206: The interconnection gateway returns a status response to the IMPS system.

Step 207: The interconnection gateway returns a SIP 200 OK successful response to the SIP system.

Step 208: The SIP system sends a SIP ACK response to the interconnection gateway.

In this way, a message session is established between the SIP system and the interconnection gateway. The SIP user can send a message to the IMPS user through the session. After receiving the message, the interconnection gateway converts the message to the IMPS system, and the IMPS user can send the message to the SIP user. After the message is received, after the interconnection gateway receives the message, the message is converted into a format, and the message is sent to the SIP system by using a message session established with the SIP system.

In the prior art, the interconnection gateway sends a message to the IMPS user according to the user identifier (UserlD) of the IMPS user, and sends a message to the SIP user according to the SIP Uniform Resource Identifier (SIP URI) of the SIP user, if the IMPS user has multiple clients. It is possible that a client is involved in the session negotiation, but the actual message is sent to multiple clients; if the SIP user interacts with the same IMPS user through multiple sessions at the same time, the interconnection gateway receives the IMPS user to send. When the message is received, it cannot be determined which session of the SIP system is sent to the SIP user. For example, SIP user A has two terminals A1 and A2, and IMPS user B has multiple clients B1 and B2. A1 interacts with B1 through session mode, and A2 interacts with B2 through session mode. The prior art cannot be implemented. Therefore, for multi-client IMPS The message service between the SIP user of the user and the multi-client, the prior art does not have a solution that can meet the actual needs. Summary of the invention

In view of this, the embodiments of the present invention provide a method and an interconnection function entity for communication interconnection, which can enable a session between multiple client users supporting different protocols.

The embodiment of the present invention provides a method for communication interconnection, where the interconnection function entity is respectively connected to the first communication system supporting the first communication protocol and the second communication system supporting the second communication protocol, and includes: the interconnection function entity Establishing an association relationship between the session identifier of the first communication system and the session identifier of the second communication system;

The interconnect functional entity forwards the session message between the two communication systems in accordance with the association relationship.

An embodiment of the present invention further provides an interconnecting functional entity, including:

a transceiver module, configured to receive a message from the first communication system, and send a message from the format conversion module to the second communication system according to the association relationship established by the association relationship establishing module; or

Receiving a message from the second communication system, and sending a message from the format conversion module to the first communication system according to the association relationship established by the association relationship establishing module;

An association establishing module, configured to determine a session identifier corresponding to the first communication system and the second communication system, and establish and store an association relationship between the session identifiers;

a format conversion module, configured to convert a message supported by the first communication protocol received by the transceiver module into a format supported by the second communication protocol, and send the converted message to the transceiver module; or

And a method for converting a message supported by the second communication protocol received by the transceiver module into a format supported by the first communication protocol, and sending the converted message to the transceiver module.

It can be seen from the above technical solution that, by establishing an association relationship of session identifiers of different communication protocols, according to the association relationship, the message from the first communication protocol system can be accurately sent to the destination client in the second communication protocol system. The solution of the present invention can enable the multiple clients to support the message service between different clients, and the multiple clients do not interfere with each other. DRAWINGS

1 is a schematic diagram of interconnection between an IMPS user and a SIP user in the prior art;

2 is a flow chart of establishing a message session between a SIP user and an IMPS user in the prior art;

3 is a flowchart of processing an interconnection gateway in a process of establishing a session for a session mode instant message by using a SIP INVITE according to an embodiment of the present invention;

4 is a flowchart of processing an interconnection gateway in an process in which an IMPS user sends an invitation request to an SIP user to perform an instant message according to an embodiment of the present invention;

5 is a flowchart of processing an interconnection gateway in a process in which a SIP user initiates a subscription request and receives a presentation notification sent from an IMPS server according to an embodiment of the present invention;

6 is a flowchart of processing an interconnection gateway in a process in which an IMPS user initiates a subscription request and receives a presence notification sent by a SIMPLE presentation server according to an embodiment of the present invention;

7 is a flow chart of signaling interaction of a SIP user requesting an instant message according to the first embodiment of the present invention; FIG. 8 is a process in which the IMPS client 1 is in a process of talking to a SIP client according to the first embodiment of the present invention;

The IMPS user actively requests the signaling interaction flow chart of the instant message through the IMPS client 2;

9 is a signaling interaction flow diagram of a SIP user subscribing to IMPS user presence information according to a second embodiment of the present invention;

FIG. 10 is a structural block diagram of an interconnection gateway according to a third embodiment of the present invention. detailed description

In the embodiment of the present invention, by establishing an association relationship between a SIP system session and an IMPS system session, the interconnection gateway stores the association relationship during the session, and associates sessions of the two systems according to the association relationship, so that multiple clients can be implemented. In the case of the terminal (terminal), the SIP user uses the session mode for instant message communication with the IMPS user, and the message is sent through the established session, so that multiple messages can be simultaneously performed between the SIP user multi-client and the IMPS user multi-client. Interacting without interfering with each other; it is also possible to implement a subscription for the SIP user or the IMPS user multi-client to present information to another system user.

The association relationship between the session identifier of the SIP system established by the interconnection gateway and the session identifier of the IMPS system in the session establishment process is as shown in Table 1. The User1D of the SIP user in the IMPS system is the address record of the SIP user (Address Of Record, AOR ), which is the SIP URI, ClientlD is generated by the GW, and its function is described below.

System type association note SIP system consists of source tag (from-tag), destination tag (to-tag) and call identity

(Call-ID) composition

SIP URI of the SIP user's UserlD SIP user

SIP user's ClientID is generated by GW

IMPS Department

IMPL user's UserlD

IMPID user's ClientID table 1

At present, the message service is implemented in the SIP system, and mainly includes the following two methods: First, a SIP INVITE request to establish a session for instant messaging in a session mode; and second, a SIP SUBSCRIBE request to establish Conversations are used to present subscriptions and notifications of information. These two cases are described separately below.

Establish a dialog for session mode instant messaging via a SIP INVITE request

Establishing a SIP system dialog through a SIP INVITE for session mode Instant messaging can be divided into two situations. One is that the SIP user initiates a SIP INVITE request, and the other is that the IMPS user initiates an invite request (InviteRequest). In the process, The Interconnect Gateway completes the conversion between the SIP INVITE request and the IMPS invite request.

The SIP user sends a SIP INVITE request to the IMPS user to perform an instant message in the session mode. The processing flow of the GW in this process is as shown in FIG. 3, and includes the following steps:

Step 301: Receive a SIP INVITE request from the SIP user, newly generate an association relationship record, and write the session identifier of the SIP system in the SIP INVITE request into the association relationship record, where the dialog identifier is from the source tag (From tag ), the destination tag (To tag ) and a call identifier (Call-ID); Step 302: Write the AOR of the sender in the SIP INVITE request as a SIP user to the User1D of the IMPS system to write the association relationship record;

Step 303: Write the receiver AOR in the SIP INVITE request as the IMP1 user's User1D to the association record;

Step 304: Generate a ClientID of the SIP user, and the ClientID is unique to the SIP user and the IMPS user who perform the message service of the same pair, that is, the ClientIDs corresponding to different clients of the SIP user are different from each other, and the generated ClientID is written. Enter the relationship record. Generate ClientID The specific manner may be generated according to the user identifier of the SIP user. For example, if the user identifier of the SIP user is: alice@atlanta.com, the ClientlD of each client of the SIP user may be: aliceO 1, alice02, alice03, etc. In other words, other generation methods can be used as long as these ClientlD step 305: map the SIP INVITE request to the corresponding IMPS invitation request, and the sender of the IMPS request is the SIP user identified by UserlD and/or ClientlD, and the request is received. The party is an IMPS user identified by UserlD;

Step 306: Receive a response from the IMPS system, if the response indicates that the IMPS user does not receive the invitation, then go to step 309; if the IMPS user receives the invitation, proceed to step 307;

Step 307: If the IMPS invitation response includes ClientlD or ApplicationlD of the IMPS user, the ClientlD or ApplicationlD is placed into the association relationship record; the successful response corresponding to the SIP INVITE request is returned, and the instant message communication is started;

Step 308: Convert and forward the session message between the SIP system and the IMPS system according to the set association relationship. Specifically include:

Receiving a SIP message sent by the SIP user through the MSRP in the session, searching for the association relationship record according to the session identifier to which the SIP message belongs, obtaining the user identifier, the client identifier, and/or the application identifier of the IMPS user, and converting the message The format supported by the IMPS protocol is sent to the IMPS client corresponding to the IMPS user identifier, the client identifier, and/or the application identifier. The converting the SIP message into the IMPS message includes: setting the sender of the IMPS message to the SIP user identified by User1D and Client1D, and setting the receiver of the IMPS message to be identified by User1D, User1D, and Client1D or User1D and Application1D. The client of the IMPS user.

And/or a message from the IMPS user, according to the user identifier of the IMPS user in the message, the user identifier of the SIP user, and/or the client identifier, searching for the association relationship to obtain the corresponding SIP system session identifier, The message is converted into a SIP-supported format, and the converted formatted message is sent to the SIP system through the SIP session corresponding to the SIP system session identifier.

If the SIP BYE request of the SIP user is received, or the message of the IMPS user is not received within a certain period of time, the SIP system session is ended, the association record is deleted, and the process ends.

Step 309: Returning directly to the SIP user failure response, deleting the association relationship record generated in step 301, and ending the process. The IMPS user sends an invitation request to the SIP user for instant message communication. The processing flow of the GW in this process is as shown in FIG. 4, and includes the following steps:

Step 401: Receive an invitation request of the IMPS user, newly generate an association relationship record, and put the user UserlD in the invitation request into the association relationship record as the User1D of the IMPS user. If the request includes the sender ClientID or ApplicationID, the IMPS is obtained. User's ClientID or

The ApplicationID is placed in the relationship record;

Step 402: Put the user UserlD in the IMPS invitation request as the SIP user's UserlD into the association relationship record;

Step 403: Convert the IMPS invitation request into a SIP INVITE request, the requesting receiver AOR is the SIP user User1D determined in step 402, the requesting sender AOR is the IMP1 user's User1D, and the requested From tag and Call-ID are generated by the GW;

Step 404: Send a SIP INVITE request, receive a response, if it is a failure response, go to step 409; if it is a successful response, perform steps 405 to 408;

Step 405: Put the SIP dialog identifier into the association relationship record.

Step 406: Generate a Client ID of the SIP user. The ClientID is unique to the same pair of SIP users and IMPS users, and the generated ClientID is placed in the association relationship record. The specific generation manner can be analogized to the previous step 304.

Step 407: Convert the successful response into an invitation response, indicating that the SIP user receives the invitation, and identifies the SIP user by using the User1D and the ClientID of the SIP user in the invitation response, and starts an instant message;

Step 408: Convert and forward the session message between the SIP system and the IMPS system according to the set association relationship. Specifically include:

Receiving a SIP message sent by the SIP user through the MSRP in the session, searching for the association relationship record according to the session identifier to which the SIP message belongs, obtaining the user identifier, the client identifier, and/or the application identifier of the IMPS user, and converting the message The format supported by the IMPS protocol is sent to the IMPS client corresponding to the IMPS user identifier, the client identifier, and/or the application identifier. The converting the SIP message into the IMPS message includes: setting the sender of the IMPS message to the SIP user identified by User1D and ClientID, and setting the receiver of the IMPS message to be identified by User1D, UserlD, and ClientID or UserlD and ApplicationID. The client of the IMPS user.

And/or a message from the IMPS user, based on the user ID of the IMPS user in the message, The user identifier and/or the client identifier of the SIP user are searched for the association relationship to obtain the corresponding SIP system session identifier, convert the message into a format supported by the SIP, and pass the converted format message to the SIP system. The SIP session corresponding to the session identifier is sent to the SIP system.

If the SIP BYE request of the SIP user is received, or the IMPS user does not receive the message or receives the cancellation request from the IMPS user within a certain period of time, the SIP system session is ended, and the relationship record is deleted.

Step 409: Replying to the IMPS user invitation response, indicating that the SIP user does not receive the invitation, deleting the association relationship record generated in step 401, and the process ends.

Request to establish a conversation for presentation of information subscriptions and notifications via SIP SUBSCRIBE

The SIP SUBSCRIBE request to establish a conversation can also be divided into two cases: a SIP user initiates a subscription request and an IMPS user initiates a subscription request.

The SIP user initiates a subscription request and receives the presentation notification sent by the IMPS server. The processing flow of the GW in this process is as shown in FIG. 5, and includes the following steps:

Step 501: Receive a SIP SUBSCRIBE request sent by the SIP user, newly generate an association relationship record, and put the SIP identifier in the SIP SUBSCRIBE request into an association relationship record, where the dialog identifier is composed of a From tag, a To tag, and a Call ID. ;

Step 502: Put the sender AOR in the SIP SUBSCRIBE request as a SIP user in the UserlD of the IMPS system, and put the relationship record;

Step 503: Put the receiver AOR in the SIP SUBSCRIBE request as the User1D of the IMPS user into the relationship record;

Step 504: Generate a Client1D of a SIP user, the ClientlD is unique to the same pair of SIP users and IMPS users, and the generated ClientlD is put into the association relationship record; the specific generation manner may be analogous to the previous step 304;

Step 505: Map the SIP SUBSCRIBE request to the corresponding IMPS presentation subscription request or obtain the presence information request. The sender of the IMPS request is the SIP user identified by User1D and Client1D, and the requested receiver is the IMPS user identified by User1D, and the IMPS is sent. Present a subscription request;

Step 506: Receive the response of the IMPS system, if the response indicates that the subscription fails, then go to step 509; if the response indicates that the subscription is successful, then perform steps 507 to 508;

Step 507: Return a successful response corresponding to the SIP SUBSCRIBE request;

Step 508: Receive a notification of the presence information sent by the IMPS system, according to the SIP user of the recipient UserlD and ClientID, UserlD of the sender IMPS user look up the association record, determine the conversation of the SIP system, and send the presence information with the SIP NOTIFY request in the SIP system dialog. If the SIP user's de-subscription request is received, or the SIP system subscription expires and the SIP user does not continue to subscribe, the SIP system session is ended, and the association record is deleted, and the process ends;

Step 509: The association relationship record generated in step 501 is deleted, and the response to the SIP user is directly returned, and the entire process ends.

The IMPS user initiates a subscription request and receives a presentation notification sent by the SIMPLE presentation server. The processing flow of the GW in this process is as shown in FIG. 6, and includes the following steps:

Step 601: Receive a subscription request initiated by the IMPS user, generate an association relationship record, and put the user UserlD in the request into the association relationship record as the User1D of the IMPS user. If the request includes the sender ClientID or ApplicationID, the IMPS user is included. ClientID or

ApplicationID is placed in the association relationship;

Step 602: Put the Subscriber UserlD in the IMPS presentation subscription request as a SIP user in the UserlD of the IMPS system, and put the association relationship record;

Step 603: Convert the IMPS presentation subscription request into a SIP SUBSCRIBE request, the requested recipient AOR is the SIP user User1D determined in step 602, the requested sender AOR is the IMP1 user's User1D, and the requested From tag and Call-ID are generated by the GW. , sending a SIP SUBSCRIBE request;

Step 604: Receive a SIP response, if it is a failure response, then go to step 608; if it is a successful response, then perform steps 605 to 607;

Step 605: Put the conversation identifier into the association relationship record;

Step 606: Convert the SIP successful response into an IMPS success status response, indicating that the subscription is successful, and the status response is sent to the IMPS user;

Step 607: Receive a notification of the presence information of the subscriber SIP user sent by the SIMPLE presentation server in the conversation, and convert the presentation notification into an IMPS format, and the recipient of the presentation notification is set to UserlD, UserlD, ClientID or UserlD according to the association relationship record. The IMPS user identified by the ApplicationID, the presenter in the presentation notification is the SIP user identified by UserlD; if the subscription request of the IMPS user is received, or the subscription of the SIP system is terminated (including the termination of the subscription cannot be resubscribed or the termination of the resubscription fails), Then, the SIP system dialogue is ended, the association record is deleted, and the process ends.

Step 608: Replying to the IMPS user failure response, indicating that the subscription fails, deleting the step generated in step 1 The relationship record, the process ends.

In order to make the objects, technical solutions and advantages of the present invention more comprehensible, the present invention will be further described in detail with reference to the specific embodiments.

Fig. 7 is a diagram showing the signaling interaction process of a SIP user requesting an instant message according to the first embodiment of the present invention. The SIP client in the figure includes multiple clients belonging to the same SIP user. In this embodiment, one SIP user has two SIP clients; the SIP server includes a SIP/IP core network and at least one SIP-based service server. The flow of this embodiment is specifically as follows:

Step 701: The SIP user sends an instant message to the IMPS user, so the SIP INVITE request is sent by the SIP client belonging to the SIP user. In this embodiment, it is assumed that the SIP INVITE request is sent by the SIP client 1, as follows:

INVITE wv:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP c33.atlanta.com;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob <wv:bob@biloxi.com> UserDD From: Alice <sip:alice@atlanta.com>;tag=l 928301774 〃Invited User UserlD and Source Tags

Call-ID: a84b4c76e66710@pc33.atlanta.com 〃call identification

CSeq: 314159 INVITE

Contact: <sip:alice@atlanta.com;gr=urn:

Uuid:f81 d4fae-7dec- 11 d0-a765-00a0c91 e6bf6>

Content- Type: application/sdp

Content-Length: 142 The SIP INVITE request is routed to the SIP server.

Step 702: The SIP server processes the SIP INVITE request, for example, determines a next route, and forwards the SIP INVITE to the interconnection gateway.

Step 703: The interconnection gateway according to the "INVITE" in the above SIP INVITE request

Wv:bob@biloxi.com SIP/2.0" determines that the request is an instant message request, so the SIP INVITE request is mapped to the IMPS InviteRequest, and the content of the InviteRequest is below:

<WV-SSP-Message Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl .3 ">

^Transaction mode="Request" transactionID=" 113 ">

</User>

</Requestor>

</MetaInfo>

<User userID= "sip:alice@atlanta.com"> 〃Initiate the user's UserlD

<ClientID url= "alice01'7> 〃Initiate the client ID of the inviting user

</User>

</Inviting>

<User userID= "wv:bob@biloxi.com"/> User UserlD </Invited> of the invited user

</InviteRequest>

</Transaction>

</Session>

</WV-SSP-Message>

Among the invitees' UserlD "sip:alice@atlanta.com" and the invitee's UserlD

"wv:bob@biloxi.com" comes from the source of the SIP INVITE request ( From ) header field and destination ( To ) header field, the inviter's ClientID "aliceOl", which is generated immediately by the interconnect gateway in this step, the request Is sent to the corresponding IMPS server.

Step 704: The IMPS server returns a status (Status) response to the interconnection gateway.

Step 705: After step 703, the IMPS server sends the InviteRequest of the SSP into an invitation user request (InviteUserRequest) of the CSP to the IMPS Client. Step 705 can be in the step Before or after 704, there is no order relationship between step 704 and step 705.

Step 706: The IMPS client returns a status response to the IMPS server.

Step 707: The IMPS user receives the invitation and returns an Inviting User Response (InviteUserResponse) through the IMPS client to the IMPS server, as follows:

<WV-CSP-Message

Xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.3">

^Transaction mode="Response" transactionID=" 113 ">

<User userID= "sip:alice@atlanta.com"> 〃Initiate the user's UserlD

<ClientID url= "alice01'7> 〃Initiate the client ID of the inviting user

</User>

</Inviting>

<User userID= "wv:bob@biloxi.com"> User UserlD <ClientID of the invited user

Url="http:〃 www.wireless-village.org/applications/MudServer" /> Client ClientID of the invited user

</User>

</Responding>

</InviteUserResponse>

</Transaction>

</Session>

</WV-CSP-Message>

The signaling contains the ClientID of the IMPS Client.

'http:〃 www.wireless-village.org/applications/MudServer'.

Step 708: The IMPS server returns a status response to the IMPS client.

Step 709: After step 707, the IMPS server turns the CSP's InviteUserResponse Switch to the SSP's InviteResponse and send it to the interconnect gateway.

Step 710: The interconnection gateway returns a status response to the IMPS server.

Step 711: After step 709, the interconnection gateway determines that the IMPS user receives the invitation, and therefore returns a successful response SIP 200 OK corresponding to the SIP INVITE in step 702, and the response is first sent to the SIP server, as follows:

SIP/2.0 200 OK

To: Bob <wv:bob@biloxi.com>;tag=a6c85cf 〃 invited user's UserlD and destination tag

From: Alice <sip:alice@atlanta.com>;tag=l 928301774

Call-ID: a84b4c76e66710@pc33.atlanta.com

CSeq: 314159 INVITE

Contact: <sip: gateway @example . com>

Content- Type: application/sdp

Content-Length: 131

At the same time, the interconnection gateway creates a new association record, as shown in Table 2:

Relationship content

Conversation ID From-tag=l 928301774;

To-tag= a6c85cf;

Call-ID= a84b4c76e66710

SIP user

UserlD

SIP user aliceOl

ClientID

User's UserlD

IMPID ClientID=http://www. wireless-village.org/applications/MudServer Client's ClientID

Or

ApplicationID

Table 2 Step 712: The SIP server returns a SIP 200 OK response to the SIP client 1; Step 713: The SIP client 1 sends a SIP ACK request to the SIP server.

Step 714: The SIP server sends a SIP ACK request to the interconnection gateway, and an MSRP session for the instant message is established between the SIP client 1 and the interconnection gateway.

Step 715: The SIP client 1 sends an instant message by using the MSRP sending command (MSRP SEND), and the message is sent to the interconnection gateway, and the specific content is as follows:

MSRP d93kswow SEND

To-Path: msr :〃 gateway. example. com:8888/9di4eae923wzd;tcp

〃source address

From-Path: msr :11 alicemphone . example . com: 7777/iau39 soe2843 z;tcp

〃Destination address

Message-ID: 12339sdqwer //Message ID

Byte-Range: 1-148/148

Content- Type: message/cpim

To: Bob <wv:bob@example.com> //UserlD for IMPS users

From: Alice <si : alice @example . com>

Content- Type: text/plain

Hi, I'm Alice! //Message content

D93kswow$

Step 716: The interconnection gateway returns an MSRP OK response to the SIP client 1;

Step 717: After the step 715, the interconnection gateway receives the MSRP SEND message from the SIP client 1, and determines that the message belongs to the established session, and searches for the relationship record that has been saved according to the session identifier carried in the MSRP SEND message. Determining UserlD and ClientlD of the receiving IMPS user; and, the interconnection gateway performs message format conversion, and converts the MSRP SEND message into an IMPS format sending message request (SendMessageRequest), as follows:

<WV-SSP-Message

Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl.3 ">

</User>

</Requestor>

</MetaInfo>

<Recipient> 〃 message recipient

<ClientID

Url="http://www. wireless-village.org/applications/MudServer" />

</User>

</Recipient>

<Sender> 〃 message sender

</User>

</Sender>

</MessageInfo>

<ContentData contentType= "text/plain" encoding="base64"> II message content

Hi, I'm Alice!

</ContentData >

</SendMessageRequest>

</Transaction>

</Session>

</WV-SSP-Message>

It can be seen that the receivers UserlD and ClientlD in the MessageInfo element are found. UserlD and ClientlD of the IMPS user, UserlD and ClientlD of the SIPS are UserlD and ClientlD of the SIP user, and the SendMessageRequest is sent to the IMPS server.

Step 718: The IMPS server returns a message response to the interconnection gateway.

( SendMessageResponse ).

Step 719: After step 717, the IMPS server converts the SSP's SendMessageRequest into a CSP new message (NewMessage) and sends it to the IMPS client. Since the recipient's UserlD and ClientlD have been confirmed between them, the guarantee message can be sent to the correct IMPS client.

Step 720: The IMPS client returns a message to the IMP server (MessageDelivered).

Step 721: In the process of the SIP user using the SIP client 1 to perform an instant message with the IMPS user, the user may want to use the other terminal SIP client 2 to perform instant messaging with the same IMPS user, and the original SIP client 1 and IMPS The session performed by the user cannot be interrupted, for example, the file is being transferred, so two sessions need to be performed at the same time, and the SIP user uses the SIP client 2 to issue a SIP INVITE request, as follows:

INVITE wv:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP c33.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 The SIP INVITE request is routed to the SIP server as in step 701;

Step 722: The SIP server processes the SIP INVITE request from the SIP client 2, for example, determining the next route, and forwarding the SIP INVITE to the interconnection gateway.

Step 723: The interconnection gateway determines that the request is an instant message request, so the SIP INVITE request is Map the InviteRequest to IMPS as follows:

<WV-SSP-Message

Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl .3 ">

^Transaction mode="Request" transactionID=" 113 ">

</User>

</Requestor>

</MetaInfo>

<Inviting> 〃 Inviter

</User>

</Inviting>

<Invited> 〃 Invitees

</Invited>

</InviteRequest>

</Transaction>

</Session>

</WV-SSP-Message>

The UserlD of the inviter and the UserlD of the invitee are respectively from the From header field and the To header field of the SIP INVITE request, and the inviter's ClientlD is generated for the interconnection gateway, and the request is sent to the corresponding IMPS server. The InviteRequest in step 723 is different from the InviteRequest in step 703 only in that the client identifier of the request is different.

Step 724: The IMPS server returns a status response to the interconnection gateway. Step 725: After step 723, the IMPS server converts the SSP InviteRequest into a CSP InviteUserRequest and sends it to the IMPS client.

Step 726: The IMPS client returns a status response to the IMPS server.

Step 727: The IMPS user receives the invitation, returns the InviteUserResponse through the IMPS client, and sends it to the IMPS Server, as follows:

<WV-CSP-Message

Xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.3">

^Transaction mode="Response" transactionID=" 113 ">

<Inviting> 〃 Inviter

</User>

</Inviting>

<Responding> 〃 Invitees

<ClientID

Url="http://www. wireless-village.org/applications/MudServer" />

</User>

</Responding>

</InviteUserResponse>

</Transaction>

</Session>

</WV-CSP-Message>

The signaling contains the ClientID of the IMPS Client.

Step 728: The IMPS server returns a status response to the IMPS client.

Step 729: After step 727, the IMPS server converts the CSP's InviteUserResponse into an SSP's InviteResponse and sends it to the interconnect gateway. Step 730: The interconnection gateway returns a status response to the IMPS server.

Step 731: After step 729, the interconnection gateway determines that the IMPS user receives the invitation, and therefore returns a successful response of the SIP INVITE in the corresponding step 722. The SIP 200 OK, the response is first sent to the SIP server, and the following:

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

At the same time, the interconnection gateway creates a new association record, as shown in Table 3:

Relationship content

Conversation ID From-tag=7723 ;To-tag= 1234;Call-ID= 12345@pc33.atlanta.com SIP User sip: alice@atlanta.com

UserlD

SIP user alice02

ClientID

IMPS uses wv:bob(3⁄4biloxi.com

UserlD

IMPS uses ClientID=http://www.wireless-village.org/applications/MudServer ClientID or

ApplicationID

table 3

Step 732: The SIP server returns a SIP 200 OK response to the SIP client 2.

Step 733: The SIP client 2 sends a SIP ACK request to the SIP server.

Step 734: The SIP server sends a SIP ACK request to the interconnection gateway, and an MSRP session for the instant message is established between the SIP client 2 and the interconnection gateway.

Step 735: For the IMPS user, this can be sip with a UserlD: alice@example.com The two clients of the user perform instant messaging. The clientlDs of the two clients are aliceO 1 and alice02 respectively. The IMPS user sends an instant message to the newly issued invitation alice02 by using the IMPS client, and the message is sent to the IMPS server, as follows:

<WV-CSP-Message

Xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.3">

<Recipient> 〃 message recipient

</User>

</Recipient>

<Sender> 〃 message sender

<ClientID url=

"http://www.wireless-village.org/applications/MudServer'7>

</User>

</Sender>

</MessageInfo>

<ContentData contentType= "text/plain" encoding="base64"> II message content

Why change client?

</ContentData >

</SendMessageRequest>

</Transaction>

</Session>

</WV-CSP-Message>

Step 736: The IMPS server returns a SendMessageResponse response to the IMPS client. Step 737: After step 735, the IMPS server converts the CSP's SendMessageRequest. The SendMessageRequest of the SSP is sent to the interconnection gateway.

Step 738: The Interconnect Gateway returns a response to the IMPS server SendMessageResponse.

Step 739: After step 737, the interconnection gateway receives the message sent by the SendMessageRequest, according to the sender of the message UserlD, the receiver UserlD and the ClientID, finds the association record, determines the dialog identifier of the SIP system, and the GW performs message format conversion and converts into MSRP. The format of the MSRP SEND message, and the message is sent in the found dialog, the MSRP SEND content is as follows: MSRP d93kswow SEND

To-Path: msr:〃 alicepc. example. com:3020/iau39soe2844z;tcp

From-Path: msr:〃 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? 〃Message content

D93kswow$

The message is sent to the SIP client 2;

Step 740: The SIP client 2 receives the MSRP SEND message and returns an MSRP OK port response to the interconnection gateway.

During the above session, it is possible that the IMPS user will establish another session with the same SIP user with another client. Figure 8 shows that the IMPS client is in the process of talking to the SIP client, and the IMPS user passes the IMPS client. 2 Actively requesting the signaling process of the instant message, including the following steps: Step 801 to step 814: The IMPS user sends an instant message invitation to the same SIP user through the IMPS client 2, the interconnection gateway performs signaling conversion, and sends a SIP INVITE to the SIP user. The request, the SIP user receives the invitation, the response is successful, and the gateway converts to the IMPS invitation response, indicating that the SIP user receives the instant message invitation, and creates a new association record in the interconnection gateway as shown in Table 4:

The dialog identifier is From-tag=7745; To-tag= 4456; Call-ID= 23456@pc33.atlanta.com

SIP user sip: alice@atlanta.com

UserlD

SIP user alice03

ClientID

For IMPS

Corpse UserlD

IMPS with ClientID=bobIM

User ClientID or

ApplicationID

Table 4

Step 815 to step 820: The SIP user sends a message to the new IMPS user client by using the newly created session. After receiving the message, the GW receives the association table and sends the message to the client of the IMPS user. The client ID of the client is "bobIM". .

The above-mentioned first embodiment illustrates the client-to-client message flow, and is also applicable to a scenario where a SIP user or an IMPS user uses a multi-terminal to join another system chat room.

FIG. 9 is a flowchart showing a signaling interaction process for a SIP user to subscribe to IMPS user presence information according to a second embodiment of the present invention, which specifically includes the following steps:

Step 901: The SIP user wants to subscribe to the presentation information of the IMPS user, so the SIP SUBSCRIBE request is sent through the SIP client 1, and the specific content of the request is as follows:

SUBSCRIBE wv:bob(3⁄4biloxi.com SIP/2.0

〃Subscribing to the presenter

//subscriber

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:f81 d4fae-7dec- 11 d0-a765-00a0c91 e6bf6> Expires: 600

Content-Length: ...

The request is first sent to the presence server (Presence Server).

Step 902: The presence server determines that the subscriber is an IMPS user, and sends a SIP SUBSCRIBE request to the interconnection gateway.

Step 903: The interconnection gateway converts the SIP SUBSCRIBE request into an IMPS

SubscribeRequest, sent to the IMPS server, as follows:

<WV-SSP-Message

Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl .3 ">

^Transaction mode="Request" transactionID=" 113 ">

<Requestor> //Subscriber

</User>

</Requestor>

</MetaInfo>

<UserID userID= "wv:bob@biloxi.com'7> 呈现Subscribed by the presenter

</SubscribeRequest>

</Transaction>

</Session>

</WV-SSP-Message>

Step 904: The IMPS server checks the authorization status, determines that the SIP user is allowed to subscribe to the presentation information of the IMPS user, and returns a status response, indicating that the subscription is successful.

Step 905: The interconnection gateway receives the status response, converts to a SIP 200 OK response, and returns the response to the presence server. The content of the SIP 200 OK response is as follows:

SIP/2.0 200 OK To: <wv:bob@biloxi.com>; tag=ffd2

From: <si : alice@atlanta.com>;tag=xfg9

Call-ID: 2010@biloxi.com

CSeq: 17766 SUBSCRIBE

Expires: 600

Contact: <sip: gateway @example . com>

Content-Length: 0

At the same time, the interconnection gateway creates a new association record as shown in Table 5:

UserlD

SIP user aliceOl

ClientID

IMPS uses wv:bob(3⁄4biloxi.com

UserlD

IMPS uses NULL

User ClientID or

ApplicationID

table 5

Step 906: The presence server returns a SIP 200 OK response to the SIP client 1;

Step 907: After step 904, the IMPS server sends the subscriber's presence information to the subscriber, as follows:

<WV-SSP-Message

Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl .3 ">

^Transaction mode="Request" transactionID=" 113 ">

<User userID= " si : alice @atlanta. com"> 〃 subscribers

<Presence Value userID="wv:bob(3⁄4biloxi.com"> 〃 Presenter's presence information

</PresenceValue>

</PresenceNotification>

</Transaction>

</Session>

</WV-SSP-Message>

The message is first sent to the interconnection gateway;

Step 908: The interconnection gateway returns a Status response to the IMPS server.

Step 909: After step 907, the interconnection gateway searches for the association record according to the subscriber UserID, the ClientID, and the subscriber UserlD in the received PresenceNotification, and finds a corresponding SIP system subscription conversation, and receives the SIP NOTIFY request in the conversation. The presence information is sent to the SIP client 1, as follows:

NOTIFY sip:alice@atlanta.com;gr=urn:

Uuid:f81 d4fae-7dec- 11 d0-a765-00a0c91 e6bf6 SIP/2.0

From: <wv: bob @biloxi . com>;tag=ffd2

To: <si : alice@atlanta. com>;tag=xfg9

Call-ID: 2010@ 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: ...

Step 910: The SIP client 1 returns a SIP 200 OK response to the interconnection gateway.

Step 911: The SIP user opens another terminal SIP client 2, and subscribes to the same through the terminal.

Some other presentation information of the IMPS user, firstly sending a SIP SUBSCRIBE request through the SIP client 2, as follows: 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

The request is first sent to the presence server.

Step 912: The presence server determines that the subscriber is an IMPS user, and sends a SIP SUBSCRIBE request to the interconnection gateway.

Step 913: The interconnection gateway converts the SIP SUBSCRIBE request into an IMPS

SubscribeRequest, sent to the IMPS server, as follows:

<WV-SSP-Message

Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl .3 ">

^Transaction mode="Request" transactionID=" 113 ">

</User>

</Requestor>

</MetaInfo>

</Transaction>

</Session>

</WV-SSP-Message>

Step 914: The IMPS server checks the authorization status, determines that the SIP user is allowed to subscribe to the presentation information of the IMPS user, and returns a Status response, indicating that the subscription is successful;

Step 915: The interconnection gateway receives the Status response, converts it into a SIP 200 OK response, and returns it to the presentation server, as follows:

SIP/2.0 200 OK

To: <wv:bob@biloxi.com>; tag=ffd3

From: <si : alice@atlanta.com>;tag=xfg8

Call-ID: 2011@biloxi.com

CSeq: 177 SUBSCRIBE

Expires: 600

Contact: <sip: gateway @example . com>

Content-Length: 0

At the same time, the interconnection gateway creates a new association record as shown in Table 6:

Conversation ID From-tag= xfg8;To-tag= ffd3; 2011 @biloxi.com

SIP user sip: alice @atlanta. com

UserlD

SIP user alice02

ClientID

IMPS uses wv: bob@biloxi.com

UserlD

IMPS uses NULL

User ClientID or

ApplicationID

Table 6

Step 916: The presence server returns a SIP 200 OK response to the SIP client 2;

Step 917: After step 904, the IMPS server sends the subscriber's presence information to the subscriber: under:

<WV-SSP-Message

Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl .3 ">

</User>

</PresenceValue>

</PresenceNotification>

</Transaction>

</Session>

</WV-SSP-Message>

The message is first sent to the interconnection gateway;

Step 918: The interconnection gateway returns a Status response to the IMPS server.

Step 919: After step 907, the interconnection gateway searches for the association record according to the subscriber UserID, the ClientID, and the subscriber UserlD in the received PresenceNotification, and finds a corresponding SIP system subscription conversation, and receives the SIP NOTIFY request in the conversation. The presence information is sent to the SIP client 1, as follows:

NOTIFY sip:alice@atlanta.com;gr=kjh29x97us97d SIP/2.0

From: <wv: bob @biloxi . com>;tag=ffd3

To: <si : 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: ...

Step 920: The SIP client 1 returns a SIP 200 OK response to the interconnection gateway.

Step 921: After a period of time, the presentation information of the IMPS user subscribed by the SIP client 1 changes, and the IMPS server issues PresenceNotification, as follows:

<WV-SSP-Message

Xmlns="http://www. openmobilealliance.org/DTD/WV-SSPl .3 ">

^Transaction mode="Request" transactionID=" 115 ">

</User>

</PresenceValue>

</PresenceNotification>

</Transaction>

</Session>

</WV-SSP-Message>

The message is first sent to the interconnection gateway;

Step 922: The interconnection gateway returns a Status response to the IMPS server.

Step 923: After step 907, the interconnection gateway searches for the association record according to the subscriber UserID, the ClientID, and the subscriber UserlD in the received PresenceNotification, and finds a corresponding SIP system subscription conversation, and receives the SIP NOTIFY request in the conversation. The presence information is sent to the SIP client 1, as follows:

NOTIFY sip:alice@atlanta.com;gr=urn: Uuid:f81 d4fae-7dec- 11 d0-a765-00a0c91 e6bf6 SIP/2.0

From: <wv: bob @biloxi . com>;tag=ffd2

To: <si : 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: ...

Step 924: The SIP client 1 returns a SIP 200 OK response to the interconnection gateway.

The process of presenting the same SIP user's presence information for multiple IMPS clients of the same IMPS user is reversed in the above process, except that the interconnection gateway does not assign a ClientID to each SIP session, but associates the SIP dialog to the UserlD and ClientID of the IMPS user. The specific process is not detailed.

A third embodiment of the present invention provides an interconnection gateway. The structural block diagram is as shown in FIG. 11, and includes: a transceiver module 1001, configured to receive a message from a SIP system (or an IMPS system), and query the module 1003 according to the association relationship. Sending a message from the format conversion module 1004 to the IMPS system (or SIP system);

The association relationship establishing module 1002 is configured to determine a session identifier of a message service corresponding to the SIP system and the IMPS system, and establish and store an association relationship between the session identifiers; the SIP system session identifier includes a dialog identifier of the SIP system; The session identifier of the IMPS system includes the user identifier and the client identifier of the SIP user participating in the session, the user identifier and the client identifier of the IMPS user participating in the session, where the client identifier of the IMPS user may be a ClientID or an ApplicationID; The relationship query module 1003 is configured to query the association relationship stored in the association relationship establishing module 1002 according to the content of the message received by the transceiver module 1001 from the SIP system (or the IMPS system), to obtain the message to be sent. The IMPS system (or SIP system) session identifier, and notifying the transceiver module 1001 of the obtained session identifier;

The format conversion module 1004 is configured to convert a SIP (or IMPS protocol) supported message received by the transceiver module 1001 into a format supported by the IMPS protocol (or SIP), and convert the converted The information is sent to the transceiver module 1001.

The association establishing module 1002 further includes:

And an obtaining unit, configured to obtain, from the SIP request/response or IMPS request/response received by the transceiver module 1001, the user identifier of the SIP user, the session identifier of the SIP system, the user identifier of the IMPS user, and the client identifier of the IMPS user. And using the obtained identifiers as the content in the relationship record;

The generating unit is configured to generate a client identifier of the SIP user in the relationship record.

The foregoing embodiments are all message services between the IMPS user and the SIP user. In fact, the present invention is not limited thereto, and the message service between multiple client users supporting different communication protocols can be applied to the solution of the present invention. In addition, the network element used in the foregoing embodiment for connecting the SIP system and the IMPS system and performing message conversion between the foregoing systems is an interconnection gateway, and may actually be implemented by other network elements capable of implementing the foregoing interconnection function, and thus The network elements can be collectively referred to as interconnected functional entities.

A person skilled in the art can understand that all or part of the steps of implementing the above embodiments can be completed by a program to instruct related hardware, and the program can be stored in a computer readable storage medium, the above mentioned storage. The medium can be a readable and writable memory RAM, a read only memory ROM, a magnetic disk or an optical disk.

The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection of the present invention. Within the scope.

Claims

Rights request

A communication interconnection method, wherein an interconnection function entity is respectively connected to a first communication system supporting a first communication protocol and a second communication system supporting a second communication protocol, and is characterized in that:

The interconnection function entity establishes an association relationship between a session identifier of the first communication system and a session identifier of the second communication system;

2. The method according to claim 1, wherein the first communication protocol is a session initiation protocol, the first communication system is a session initiation protocol system, and the second communication protocol is an instant message and a presence service. The second communication system is an instant message and a presence service system;

Or the first communication system is an instant message and a presence service protocol, the first communication system is an instant message and a presence service system, the second communication protocol is a session initiation protocol, and the second communication system is a session initiation protocol. Protocol system.

The method according to claim 2, wherein the session identifier of the session initiation protocol system is a session initial protocol session identifier, and the instant message and the session identifier of the presence service are user identifiers of the session initiation protocol user, The client identifier of the session initiation protocol user, the instant message and the user identity and/or instant message of the presence of the service user, and the client identity of the presence service user.

The method according to claim 3, wherein the step of establishing an association between the session identifier of the first communication system and the session identifier of the second communication system by the interconnection function entity is specifically:

The interconnection function entity receives the session initial protocol request from the session initial protocol user in the session initial protocol system, creates a session identifier of the session initial protocol system, and records the association relationship between the instant message and the session identifier of the service system;

Writing the content in the session initiation protocol request into the association relationship record;

Translating the session initiation protocol request into an instant message and a presence service request, and transmitting the instant message and the presence service request to the instant message and the presence service system;

A response is received from the instant message and the presence of the service system, and the content in the response is written to the association record.

The method according to claim 4, wherein the session initiation protocol is requested Writing the content in the request to the association relationship record includes: a session identifier of the initial protocol system; and recording, as the user of the session initiation protocol user in the association relationship record, a sender address record in the session initiation protocol request Identifying, by using the receiver address record in the session initiation protocol request as an instant message in the association relationship record and a user identifier of the presence service user; the interconnection function entity generates a client of the session initiation protocol user in the association relationship record End identifier, the session initial protocol user and the instant message and the client identifier of the session initial protocol user corresponding to the presence service user remain unique;

The converting the initial protocol request to the instant message and the presence service request includes:

Using the user identifier of the session initiation protocol user and/or the client identifier of the session initiation protocol user as the sender of the instant message and the presence service request, using the instant message and the user identifier of the presence service user as The instant message and the recipient of the presence of the service request.

The method according to claim 4, wherein the writing the content in the response to the association relationship record comprises:

The instant message in the response and the client identifier or application identifier of the presence of the service user are used as the instant message in the association record and the client identifier of the presence service user.

The method according to claim 3, wherein the interconnection function establishes an association relationship between the session identifier of the first communication system and the session identifier of the second communication system, including: Receiving an instant message and a presence service request from the instant message and the presence of the service user, creating a session identifier of the session initiation protocol system and an association record of the instant message and the session identifier of the presence service system;

Writing the content in the instant message and the presence service request into the association relationship record; converting the instant message and the presence service request into a session initiation protocol request, and sending the session initiation protocol request to the session initiation protocol In the system;

Receiving a successful response from the session initial protocol system, using the session identifier of the session initial protocol success response as the session identifier of the session initial protocol system in the association record, and generating the client of the session initiation protocol user in the association record And the client identifier of the session initiation protocol user and the instant message and the presence of the service user are unique.

8. The method according to claim 7, wherein said said instant message and presence The content in the business request is written into the relationship record including:

Using the sender user identifier in the instant message and the presence service request as the instant message in the association relationship record and the user identifier of the presence service user, and the sender client identifier in the instant message and the presence service request or Applying the identifier as the instant message in the association record and the client identifier of the presence service user, and using the receiver user identifier in the instant message and the presence service request as the user of the session initiation protocol user in the association relationship record Identification

The converting the instant message and the presence service request into the session initiation protocol request comprises: recording, by using the user identifier of the session initiation protocol user as a recipient address in the session initiation protocol request, the instant message and the presence The user ID of the business user is recorded as the address of the sender.

The method according to any one of claims 4 to 8, wherein the session initiation protocol request is a session initiation protocol invitation request, and the instant message and the presence service request are an instant message and a presence service invitation request; Or the session initiation protocol request is a session initial protocol subscription request, and the instant message and the presence service request are an instant message and a presence service subscription request.

The method according to any one of claims 4 to 8, wherein the interconnecting function entity forwards the session message between the two communication systems according to the association relationship, including:

The interconnection function entity receives the message from the user of the session initiation protocol, searches for the association relationship according to the conversation identifier to which the message belongs, and obtains the user identifier, the client identifier, and/or the application identifier of the service user. Transmitting the message into a format supported by the instant message and the presence service protocol, and sending the converted format message to the instant message and the presence of the service user identifier, the client identifier, and/or the application identifier corresponding to the instant message and the presence service Client

Or the interconnecting function entity receives the message from the instant message and the existing service user, and searches according to the instant message in the message and the user identifier of the service user, the user identifier of the session initiation protocol user, and/or the client identifier. The association relationship is obtained by the corresponding session initial protocol system session identifier, and the message is converted into a format supported by the session initial protocol, and the converted format message is sent through the session initial protocol session corresponding to the session initial protocol system session identifier. To the session initial protocol system.

An interconnecting functional entity, which is respectively connected to a first communication system supporting a first communication protocol and a second communication system supporting a second communication protocol, and is characterized in that:

a transceiver module, configured to receive a message from the first communication system, according to the association relationship The association established by the vertical module sends a message from the format conversion module to the second communication system; or

And a method for converting a message supported by the second communication protocol received by the transceiver module into a format supported by the first communication protocol, and transmitting the converted message to the transceiver module.

The interconnecting functional entity of claim 11, wherein the interconnecting functional entity further comprises:

The association relationship query module is configured to query an association relationship stored in the association relationship establishing module according to the session identifier of the message from the first communication system received by the transceiver module, to obtain a session identifier of the second communication system, And notifying the transceiver module of the obtained session identifier of the second communication system; or

Querying, according to the session identifier of the message received by the transceiver module from the second communication system, the association relationship stored in the association relationship establishing module, obtaining the session identifier of the first communication system, and obtaining the obtained session identifier The session identifier of the first communication system notifies the transceiver module.

The interconnection function entity according to claim 12, wherein the first communication protocol is a session initiation protocol, the second communication protocol is an instant message and a presence service; or the first communication protocol is an instant message. And the presence of the service, the second communication protocol is the session initiation protocol.

The interconnecting functional entity according to claim 13, wherein the transceiver module is further configured to receive a session initiation protocol request from a session initiation protocol system or an instant message and presence service from an instant message and a presence service system. Request

The association establishing module further includes:

An obtaining unit, configured to obtain, from a session initiation protocol request/response or an instant message and a presence service request/response received by the transceiver module, a user identity of a session initiation protocol user, a session identifier of a session initiation protocol system, an instant message, and User ID and/or instant message and presence of the business user The client identifier of the user is used as the content in the association record; the generating unit is configured to generate the client identifier of the session initiation protocol user in the association record.