WO2008080334A1

WO2008080334A1 - Back to back user agent and the method for transmitting information thereof

Info

Publication number: WO2008080334A1
Application number: PCT/CN2007/071236
Authority: WO
Inventors: Qunbing Jiang; Kai Wen; Kaifeng Yang; Chao Chen
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-12-31
Filing date: 2007-12-14
Publication date: 2008-07-10
Also published as: CN101212418A; CN101212418B

Abstract

A method for transmitting information by the back to back user agent is provided. When the message is received, the original Contact header field in the message is saved, by adding Record-Route header field whose content is the address of the back to back user agent self in the transmitted message, the correct route of the sequent request can be assured and the end to end transmission of the information in the Contact header field can be guaranteed. A back to back user agent and a computer readable medium are also provided.

Description

Back-to-back user agent and method for transmitting information thereof. The present application claims priority to Chinese patent application filed on Dec. 31, 2006, the Chinese Patent Office, Application No. 200610063765.5, entitled "Back-to-Back User Agent and Method for Transmitting Information" The entire contents of which are incorporated herein by reference.

Technical field

The invention relates to the field of communications, in particular to an IP (Internet Protocol) multimedia subsystem (IMS, IP Multimedia Subsystem).

Background technique

In the IMS network, many SIP (Session Initiation Protocol) messages are delivered by the User Agent (UA, User Agent). Due to the heterogeneous capabilities and characteristics of user agents, it is important to understand the capabilities of other user agents when intermediate network elements and/or peer user agents are involved in some dialog establishment and service development. of. RFC 3840 defines a method for carrying the capabilities and feature information of a user agent in the parameters of the Contact header field of the SIP message, so that when the user initiates the registration or conversation, the capability and feature information can be notified in the Contact header field. The intermediate network element and/or the peer user agent serve as an important reference for the intermediate network element and the peer user agent to process the dialogue.

For example, during the conference establishment process, when the conference center invites the user to join the conference, the terminal can use the isfocus parameter in the contact header field to make the terminal aware that the opposite end of the current conversation is the conference center, so as to guide the user to perform related operations on the conference, such as Subscribe to the meeting status. The method of carrying the capability and feature information of the terminal through Contact defined by RFC 3840 can be operated well in the case where the signaling path is Proxy; however, if there is a back-to-back user agent in the signaling path (B2BUA, Back) To Back User Agent), since the back-to-back user agent modifies the Contact header field of the message while forwarding the Invite message, the capability and feature information of the originating UA will be modified at the B2BUA, but cannot be delivered to the subsequent network element and / or UA receiving the conversation.

Please refer to FIG. 1 , which is a schematic diagram of a conference application process in the prior art. Step SI: The user sends an INVITE request, which carries sip: Conf-Factory, indicating that the conference is in progress.

Step S2: The user agent 1 receives the INVITE request and forwards it.

Step S3: The back-to-back user agent receives the INVITE request and forwards it.

Step S4: The user agent 2 receives the INVITE request and forwards it to the conference center.

Step S5: After receiving the INVITE request, the conference center returns a 200 OK response, and carries the Conf-ID and isfocus parameters in the Contact header field.

Step S6: After receiving the 200 OK response, the user agent 2 forwards it to the back-to-back user agent.

Step S7: After receiving the 200 OK response, the back-to-back user agent changes the Contact header field to the address of the back-to-back user agent (Contact: B2BUA), and then forwards it to the user agent 1.

Step S8: After receiving the 200 OK response, the user agent 1 forwards the response to the user.

Since the back-to-back user agent modifies the Contact header field to the address of the back-to-back user agent, the original Conf-ID and isfocus parameters are lost in the Contact header field, so that the user cannot know the address of the conference center according to the Conf-ID and isfocus parameters, and thus cannot Conduct conference-related operations, thereby affecting the provision of conference services.

Summary of the invention

The invention provides a method of transmitting information of a user agent and a back-to-back user agent, which can avoid the influence of back-to-back user agents on the conference service.

The present invention provides a method for back-to-back user agent to transmit information, including: receiving a session establishment request message or a session establishment response message; retaining an original Contact header field in the message, and adding a back-to-back user agent address in the message Record-Route header field; forwards the message to which the Record-Route header field has been added.

The present invention also provides a back-to-back user agent, comprising: a receiving unit, configured to receive a dialog establishment request message or a dialog establishment response message; and a Record-Route processing unit, configured to add a Record carrying a back-to-back user agent address in the message- a route header field, and retaining the original Contact header field in the message; and a sending unit, configured to forward the message processed by the Record-Route processing unit.

The invention also provides a computer readable medium storing a back-to-back user agent transmission letter The software of the method, when the software is executed, includes the following steps: receiving a dialog establishment request message or a dialog establishment response message; retaining the original Contact header field in the message, and adding a back-to-back user agent address in the message Record-Route header field; forwards the message to which the Record-Route header field has been added.

The back-to-back user agent carries the routing address through the Record-Route header field instead of modifying the Contact header field, so that the Conf-ID and isfocus parameters carried in the Contact header field of the conference center are transmitted to the user, and the user can according to the Conf-ID and the isfocus. The parameters carry out other related operations of the conference call, thereby ensuring the normal development of the conference service.

DRAWINGS

1 is a schematic diagram of a conference application process in the prior art;

2 is a schematic diagram of a conference application process according to a first embodiment of the present invention;

3 is a schematic diagram of a back-to-back user agent according to a first embodiment of the present invention;

4 is a schematic diagram of a dialog flow of a second embodiment of the present invention.

detailed description

Please refer to FIG. 2 , which is a schematic diagram of a conference application process according to a first embodiment of the present invention. Since the back-to-back user agent associates two conversations in one conversation, it is necessary to maintain a separate route set for the two conversations, and the two routing sets are independent of each other, so when the back-to-back user agent receives the conversation establishment request message, All Record-Route saves in the dialog establishment request message are taken out as the route set of the dialog establishment requestor. When the back-to-back user agent forwards the request message, all the Record-Routes in the received request are removed first, and the UAS (UA server, user agent server) subsequent request is guaranteed in order not to modify the Contact header field in the original request message. Being able to route to itself correctly, the back-to-back user agent adds a Record-Route header field when forwarding the request message, carrying the address of the back-to-back user agent.

When the back-to-back user agent receives the response message of the session establishment request, it extracts all the Record-Routes in the response message and removes the last Record-Route, and then saves it as the route set to the dialog establishment response party.

When forwarding the response message of the session establishment request, in order not to modify the Contact header field in the original response message, it is necessary to ensure that subsequent requests of the UAC (UA client, user agent client) can be correctly routed to itself, and the back-to-back user agent is in the response message. Add a Record-Route header field with the content Your own address.

Step 1: User A sends an INVITE request, which carries sip: Conf-Factory, indicating that the conference is in progress.

Step 2: After receiving the INVITE request, the user agent 1 adds a Record-Route header field to the INVITE request, and the content is the address of the user agent 1, and then forwards it.

Step 3: After the back-to-back user agent receives the INVITE request, in order for the subsequent request message to be routed to the user A, the back-to-back user agent obtains the Record-Route list in the request message and saves it as the route set to the user A, and needs to be removed. All the Record-Routes in the received request, then add the Record-Route header field in the INVITE request, the content is the address of the back-to-back user agent, and then forward it.

Step 4: After receiving the INVITE request, the user agent 2 adds a Record-Route header field to the address of the User Agent 2 (Record-Route: Proxy2) in the INVITE request, and then forwards it to the conference center.

Step 5: After receiving the INVITE request, the conference center carries the Conf-ID and isfocus parameters in the Contact header field, and then carries the Record-Route to return a 200 OK response.

Step 6: After receiving the 200 OK response, User Agent 2 forwards it to the back-to-back user agent.

Step 7: After the back-to-back user agent receives the 200 OK response, the back-to-back user agent can obtain the Record-Route list in the 200 OK response message and remove the last URI (Uniform Resource Identifier) in the Record-Route list ( Because the last URI is the back-to-back user agent's own address, no need to save), then save the modified Record-Route list as a route set to the conference center; also need to remove all the Record-Route in the response message received, and then respond The Record-Route header field is added to the message, and the content is its own address. In addition, in step 3, the back-to-back user agent has obtained the route set to User A, and the back-to-back user agent removes all the Records in the received response message. After the route, add the Record-Route list of User A saved in Step 3 to the response message, and then add a Record-Route at the top of the Record-Route list, which is the address of the Back-to-Back User Agent (B2BUA), and then forward it to the user. Agent 1.

Step 8: After receiving the 200 OK response, the user agent 1 forwards it to the user A, so that User A can obtain the Conf-ID and isfocus parameters carried in the Contact header field of the conference center, and perform subsequent operations of the conference.

Since the routing addresses of the back-to-back user agents are stored in the Record-Route header field instead of modifying the Contact header field, both the correct routing of the subsequent requests and the end-to-end transmission of the information in the Contact header field are ensured, so that the conference center is in the Contact header. The Conf-ID and isfocus parameters carried in the domain are transmitted to user A. User A can perform other related operations of the conference call according to the Conf-ID and isfocus parameters, thereby ensuring the normal development of the conference service.

The above embodiments are not limited to conversations of a conference call, but can also be used for other forms of conversation, such as conversations between users or conversations between user agents.

Please refer to FIG. 3 , which is a schematic diagram of a back-to-back user agent according to a first embodiment of the present invention. The back-to-back user agent unit 10 includes: a receiving unit 2, a Record-Route processing unit 5, a storage unit 8 and a transmitting unit 9, the receiving unit 2 is configured to receive a message; and the Record-Route processing unit 5 is configured to remove the received message. All the Record-Route in the message, then add the Record-Route header field in the received message, the content is the back-to-back user agent unit's own address. The Record-Route processing unit 5 is further configured to obtain a Record-Route list of the request message as a route set of the requester of the request message; and obtain a Record-Route list of the response message, and remove the last URI in the list (because the last a URI is a back-to-back user agent's own address, without saving), as a route set of the responding message sender; the storage unit 8 is configured to save a Record-Route list acquired or processed by the Record-Route processing unit 5; 9 Used to send out messages (ie, forwarded) that have been processed by the Record-Route processing unit.

Please refer to FIG. 4, which is a schematic diagram of a dialog flow according to a second embodiment of the present invention. This dialogue process is the dialogue process between two users.

Step 01: User A sends an INVITE request and carries user A's capability information (contact: A) through the contact header field.

Step 02: After receiving the INVITE request, the user agent 1 adds a Record-Route header field to the INVITE request, and the content is the address of the user agent 1 (proxy 1 ), and then forwards it.

Step 03: After the back-to-back user agent receives the INVITE request, the subsequent request message can be routed to the user A, and the back-to-back user agent obtains the Record-Route list in the request message and saves it as the route set to the user A; All received in the request Record-Route, then add the Record-Route header field in the INVITE request, the address of the back-to-back user agent (B2BUA), and then forward it.

Step 04: After receiving the INVITE request, the user agent 2 adds a Record-Route header field to the INVITE request, and the content is the address of the user agent 2 (Proxy2), and then forwards it to the user.

Step 05: After receiving the INVITE request, the user B knows the capability of the user A by carrying the capability information of the user A in the contact header field, and then returns a 200 OK response, and carries the capability information of the user B through the Contact header field (contact: B), and carry the request message in Rscord-Routs.

Step 06: After receiving the 200 OK response, the user agent 2 forwards it to the back-to-back user agent according to the Record-Route therein.

Step 07: After the back-to-back user agent receives the 200 OK response, the back-to-back user agent can obtain the Record-Route list in the 200 OK response message and remove the last URI in the Record-Route list (because the last URI is the back-to-back user agent) Your own address, no need to save), and then save the modified Record-Route list as a route set to User B; also need to remove all the Record-Route in the received response message, and then add a Record-Route header in the response message The domain, the content is its own address; In addition, in step 03, the back-to-back user agent has obtained the route set to user A, and then the back-to-back user agent removes all the Record-Routes in the received response message, in the response message. Add the Record-Route list of User A saved in step 03, then add a Record-Route at the top of the Record-Route list, the content is the address of the Back-to-Back User Agent (B2BUA), and then forward it to User Agent 1.

Step 08: After receiving the 200 OK response, the user agent 1 forwards the response to the user A, so that the user A can obtain the capability information of the user B, and perform subsequent operations.

Step 09: User A sends an ACK message, where Requst-URI is the address of user B, and Route is Proxy 1 and B2BUA.

Step 010: After receiving the ACK message, the user agent 1 forwards the ACK message to the B2BUA. The Requst-URI is the address of the user B, and the route is B2BUA.

Step 011: After the B2BUA receives the ACK message, the Route in the ACK message is the address of the back-to-back user agent, and the Route is deleted; the Request-URI of the ACK message is the address of the user B; The B2BUA needs to add the route set to user B in the forwarded ACK message, and then forward it to user B. The route is Proxy2.

Step 012: After receiving the ACK message, the user agent 2 forwards the ACK message to the user B, where the Requst-URI is the address of the user B.

Step 013: User B sends a Bye message, where Requst-URI is the address of user A.

Route is Proxy2 and B2BUA.

Step 014: After receiving the Bye message, the user agent 2 forwards the message to the B2BUA, where Requst-URI is the address of user A and Route is B2BUA.

Step 015: After the B2BUA receives the Bye message, because the Route in the Bye message is the address of the back-to-back user agent, the route is deleted, because the Request-URI of the Bye message is the address of the user A; the B2BUA needs to be added to the forwarded Bye message. User A's route set, then forwarded to user A, and Route is Proxyl.

Step 016: After receiving the Bye message, the user agent 1 forwards the message to User A, where Requst-URI is the address of User A.

Step 017-020: User A sends the user to the user via user agent 1, B2BUA and user agent 2.

B returns a 200 OK response message.

After the session is established, the B2BUA can also send the request message in the dialog to the two ends of the dialog, such as rernvite, Bye, etc. When constructing the Contact header field of the request message, the B2BUA can fill in the address of the B2BUA, or fill in the pair of the receiver. The contact address of the terminal, for example, when the user sends a renvvite or Bye to the user B, the contact fills in the address of the user A, but since the rernvite message refreshes the remote target URI, it is recommended to fill in the contact information of the receiver at the opposite end when sending the renvite message. .

Since the routing addresses of the back-to-back user agents are stored in the Record-Route header field instead of modifying the Contact header field, both the correct routing of subsequent requests and the end-to-end transmission of information in the Contact header field are ensured, so that two users are in the conversation. In the process, the capability information carried in the Contact header field can be used, and the user can learn the capability information of the peer end.

A person skilled in the art may understand that all or part of the steps in implementing the above method embodiments may be completed by a program instructing related hardware, and the program may be stored in a computer readable storage medium, the storage medium Such as: R0M / RAM, disk, CD, etc.

The above method or device is not limited to transmission capability information, and may also be transmitted through the Contact header domain. Other information with the belt.

The above is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or within the technical scope disclosed by the present invention. Alternatives are intended to be covered by the scope of the present invention. Therefore, the scope of the invention should be determined by the scope of the claims.

Claims

Rights request

A method for transmitting information by a back-to-back user agent, comprising: receiving a session establishment request message or a session establishment response message;

Retaining the original Contact header field in the message, and adding a Record-Route header field carrying the back-to-back user agent address in the message;

The message that has been added to the Record-Route header field is forwarded.

The method of claim 1, wherein: the received dialog establishment request message includes a Record-Route list, and the method further includes:

The Record-Route list in the dialog establishment request message is saved as a route set to the request establishment party.

The method according to claim 1, wherein: the received dialog establishment response message includes a Record-Route list, and the method further includes:

Obtaining the Record-Route list in the dialog setup response message, and deleting the last Record-Route in the Record-Route list, and saving as a route set to the responder to establish the response to the dialog.

4. The method of claim 1, further comprising:

Receiving a request message in a conversation;

If the route of the request message in the conversation is a back-to-back user agent address, the route is deleted, and the route set of the address in the Requst-URI of the request message in the session is added to the message and forwarded.

The method according to any one of claims 1 to 4, wherein if there is a Record-Route in the received dialog establishment request message or the dialog establishment response message, the method further includes before forwarding the message : Remove the original Record-Route from the message.

6. A back-to-back user agent, comprising:

a receiving unit, configured to receive a session establishment request message or a session establishment response message;

a Record-Route processing unit, configured to add a Record-Route header field carrying the back-to-back user agent address in the message, and retain the original Contact header field in the message;

And a sending unit, configured to forward the message processed by the Record-Route processing unit.

7. The back-to-back user agent of claim 6 wherein: The Record-Route processing unit is further configured to acquire a Record-Route in the received message, and when the received message is a dialog establishment request message, acquire a Record-Route of the session establishment request message. The list is used as a route set to the dialog establishment requestor; when the received message is a response message of the dialog establishment request, the Record-Route list of the dialog response message is obtained, and the last one in the Record-Route list is removed. Record-Route is used as a route set to establish a responder to the dialog.

8. The back-to-back user agent according to claim 7, further comprising: a storage unit, configured to save the Record-Route 歹 'J table processed by the Record-Route processing unit.

The back-to-back user agent according to any one of claims 6 to 8, wherein: the Record-Route processing unit is further configured to: when the received dialog establishment request message or the dialog establishment response message has a Record -Route removes the original Rscord-Routs from the message.

10. A computer readable medium, characterized by storing software for implementing a back-to-back user agent transmission information method, the software, when executed, comprising the steps of: receiving a dialog establishment request message or a dialog establishment response message; retaining the message The original Contact header field, and adding a Record-Route header field carrying the back-to-back user agent address in the message; forwarding the message to which the Record-Route header field has been added.