WO2008049371A1

WO2008049371A1 - A method and system for transferring service event

Info

Publication number: WO2008049371A1
Application number: PCT/CN2007/070923
Authority: WO
Inventors: Peng Wang; Dongming Zhu; Hengliang Zhang; Peili Xu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-10-18
Filing date: 2007-10-18
Publication date: 2008-05-02
Also published as: CN101166162B; CN101166162A

Abstract

A method for transferring service event is provided. When service event occurs during call process, the intercommunication device between the first network to which said user belongs and the second network to which the user on the opposite side of the call process belongs receives the service event message generated by the service control entity to which the said user belongs; the said intercommunication device receives the said service event message, converts the service event message into the form that can be recognized by the second network, and sends it to the second network along the path which the call is established. Meanwhile, a system for transferring service event is also provided. By applying the method and system provided in the present invention, when service event occurs to a user, the user on the opposite side and the control device of the network to which the user on the opposite side belongs can acquire the service event of the user, the intercommunication of the service event information between both parties of the call can be realized, which assures the correct execution of the service between both parties of the call. Moreover, an IMS network service control entity, a MGCF are also provided.

Description

Method and system for transmitting business events

Technical field

The present invention relates to an IP multimedia subsystem technology, and more particularly to a method and system for delivering service events, an IMS network service control entity, and an MGCF.

Background of the invention

The successful application of Circuit Switched (CS) GSM and WCDMA technologies has made mobile voice services popular around the world. As the demand for data services grows and wireless packet technologies continue to break, the converged IP Multimedia Subsystem (IMS) architecture makes voice calls possible.

After two users establish a call, if a party to the call has a service event, each service control entity that provides the service for the user in the call needs to know what kind of service event occurred to the party that has the service event, so that each service control entity According to the business events that occur, the business events can be updated in time and the corresponding business logic can be adjusted, so that the calls between the users can be operated efficiently and normally.

However, when two users are respectively located in the CS network and the IMS network, or respectively located in two CS networks that are transited through the IMS network, in the event that a service event occurs on one of the calling parties, the existing IMS network communicates with the CS network. In the specification, no corresponding technology is provided to implement interworking of service event information between the CS domain and the IMS domain. Therefore, in this case, the business event information cannot be processed by the service control entity of the other party, so that the service event information cannot be interworked between the calling parties, which affects the correct execution of the services of the calling parties.

For example, when user A is located in the IMS network and user B is located in the CS network, the application server (AS) provides services for user B in the IMS domain. After user A successfully completes the call setup process to the called subscriber B through the IMS network and the CS network, the subscriber B initiates an explicit call transfer (ECT) service, and transfers the call to the subscriber C who is also located in the CS network. This At the time, the MSC of the user B is responsible for completing the establishment of the payload, and transmitting a service event message indicating the service event to the media gateway control function (MGCF) located between the IMS network and the CS network. Since the MGCF responsible for interworking between the IMS network and the CS network does not pass the service event message to the IMS network according to the definition of the existing related specifications. Therefore, after the call forwarding service of the user B succeeds, the user B enters the idle event to accept the new call, but the AS that provides the service to the user in the IMS network does not know the current state of the user B and considers that the user B is still busy. In the state, it is considered that User B cannot accept the new call, and the call that needs to be connected to User B cannot be correctly connected. Summary of the invention

In view of this, the main object of the present invention is to provide a method and system for transmitting a service event, which can implement interworking of user service events in a network.

At the same time, the present invention also provides an IMS network service control entity, and an MGCF.

In order to achieve the above object, the technical solution of the present invention is achieved as follows:

The present invention provides a method for delivering a business event, performing the following steps: A method of delivering a business event, performing the following steps:

The service device between the first network where the user is located and the second network where the peer user is located in the current call process receives the service event message generated by the service control entity of the user;

The interworking device receives the service event message, converts the service event message into a form recognizable by the second network, and transmits the message to the second network along the call setup path.

The present invention further provides a system for delivering a service event, the system comprising: at least: a first network where the user is located, a second network where the peer user is located, and an interworking device responsible for interworking between the first network and the second network; Including a first service control entity that provides services to users; The first service control entity is configured to generate a service event message when the user generates a service event during the call, and send the service event message to the interworking device;

The interworking device is configured to receive a service event message, convert the service event message into a form identifiable by the second network where the peer user is located, and send the message to the second network along the call setup path.

In addition, the present invention further provides an IMS network service control entity, including: an obtaining unit, configured to acquire service event information according to a service event performed by a user, and send the service event information to a generating unit;

a generating unit, configured to generate a service event message in a SIP protocol format according to the service event information, and send the generated service event message in a SIP protocol format to the sending unit;

And a sending unit, configured to send a service event message in the SIP protocol format.

Meanwhile, the present invention also provides an MGCF, which at least includes:

a receiving unit, configured to receive and send a service event message sent by the CS network to the conversion unit;

a converting unit, configured to convert the received service event message into a service event message in a SIP protocol format, and send the service event message in the SIP protocol format to the sending unit, where the sending unit is configured to send the SIP protocol format Business event message.

The invention also provides an MGCF, comprising at least:

a receiving unit, configured to receive and send a service event message in a SIP protocol format to the inverse conversion unit;

And an inverse conversion unit, configured to convert the service event message in the SIP protocol format into a service event message supported by the CS network, and send the service event message supported by the CS network to the sending unit;

And a sending unit, configured to send a service event message supported by the CS network.

A method for delivering a service event provided by the present invention occurs during a call During the service event, the service event message is generated by the service control entity of the user, and is sent to the interworking device between the second network where the peer user is located in the current call process and the first network where the user is located; the interworking device receives the service event message, and the service The event message is converted and sent to the second network along the call setup path in a form recognizable by the second network, thereby implementing interworking between the user and the peer user service event information. The present invention also provides a system for transmitting service events. By applying the method and system provided by the present invention, a user can generate a service event, so that the peer user and the control device of the network where the peer user is located can learn the user's service event. Then, the call process between the user and the peer user is processed accordingly, so that the service event information is intercommunicated between the calling parties, and the correct execution of the services of the calling parties is ensured. In addition, the present invention also provides a SIP message generating apparatus, a SIP message converting apparatus, and a SIP message inverse converting apparatus. BRIEF DESCRIPTION OF THE DRAWINGS

1 is a structural diagram of a system according to an embodiment of the present invention;

2 is a structural diagram of an MGCF in the present invention;

3 is a flowchart of a method according to an embodiment of the present invention;

4 is a structural diagram of a system according to Embodiment 2 of the present invention;

5 is a structural diagram of an IMS network service control entity in the present invention;

Figure 6 is a structural diagram of still another MGCF in the present invention;

7 is a flowchart of a method according to Embodiment 2 of the present invention;

8 is a structural diagram of a system according to Embodiment 3 of the present invention;

FIG. 9 is a structural diagram of a system according to Embodiment 4 of the present invention. Mode for carrying out the invention

In the detailed description of this section, only the most anticipated by the inventors of the present invention DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The preferred embodiments of the present invention are shown and described. It will be appreciated that modifications may be made in various obvious aspects without departing from the invention. The drawings and the description are to be regarded as illustrative in nature and not restrictive.

In the present invention, the first network may be an IMS network, and the second network may be an CS network, and the interworking device between the corresponding first network and the second network is an MGCF. In addition, the first network may also be an CS network, and the second network may be an IMS network, and the interworking device between the corresponding first network and the second network is an MGCF. In addition, the first network and the second network may also be CS networks, and the two networks communicate with each other through the IMS network, and the corresponding interworking device is a first MGCF that connects the first CS network and the IMS network, and connects to the IMS. The network is connected to the second MGCF of the second CS network. Certainly, the first network and the second network may both be IMS networks, and the two networks communicate with each other through the CS network, and the corresponding interworking device is a first MGCF that connects the first IMS network and the CS network, and connects the CS network. A second MGCF with a second IMS network.

The call process described in the technical solution of the present invention includes calls that are established by both parties or have been successfully established. In addition, from the above description, it is not difficult to conclude that the interworking device is a network entity that connects the CS network and the IMS network.

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 below with reference to the embodiments.

Embodiment 1

The first network described in the first embodiment is an IMS network, and the second network is a CS network. The interworking unit between the first network and the second network is an MGCF. During the calling process between the calling user A and the called user B, The case where the called user B initiates a business event.

A call is being established or has been successfully established between the user A in the IMS network and the user B in the CS network. When the user B has a service event, the service control entity of the user B generates an event indication message indicating the current service event, and sends the event indication message to the The case where the MGCF performs the conversion. Here, in the described embodiment of the present invention, the referred service control entity may be a physical entity or a logical entity. For example, MSC is an entity described above.

In this embodiment, since the service event notification mechanism exists in the CS network, the service control entity MSC in the CS network can generate a service event message according to the existing service event notification mechanism. For the MGCF that receives the service event message, it only needs to obtain the service event information from the service event message and send it in the format supported by the IMS network.

FIG. 1 is a system structural diagram of a method for implementing the embodiment. The system includes at least an IMS network 11, an MGCF 12, and a CS network 13. The IMS network 11 includes at least an IMS network service control entity 111 and a user terminal 112. The CS network 13 includes at least an MSC 131 and a user terminal 132. A call is established between the user terminal 112 and the user terminal 132 via the IMS network service control entity 111, the MGCF 12, and the MSC 131.

The MSC 131 generates a service event message when the user terminal 132 generates a service event, and sends the message to the MGCF 12.

The MGCF 12 receives the service event message sent by the MSC 131, and carries the service event information in the service event message in the SIP message sent to the user terminal 112, and sends the path to the IMS network along the path established by the call between the user terminal 112 and the user terminal 132. 11.

Here, the structure of the MGCF 12 may be as shown in FIG. 2, including: a receiving unit 121, configured to receive and send a service event message sent by the CS network to the converting unit 122; and a converting unit 122, configured to convert the received service event message The service event message in the SIP protocol format is sent to the sending unit 123, and the sending unit 123 is configured to send the service event message in the SIP protocol format.

Here, there are many types of service events, such as multiple services in the conference service, and the ECT service. The technical solution of the present embodiment is described in detail by taking the ECT service of the user B as an example. In this embodiment, User B transfers the call to User C, which is also located in the CS network, where User B and User C belong to the same MSC. FIG. 3 is a flowchart of the method in this embodiment, and the specific description is as follows:

Step 301: The IMS network service control entity establishes a call between the user A and the user B with the MGCF and the service control entity MSC of the user B.

Here, the IMS network service control entity is a service control entity that provides the user A with a monthly service. If there is no service control entity that provides services for the user in the IMS network, this part of the function can also be completed by the MGCF. In the introduction of this document, User A and User B are in the form of cartridges of User Terminal A and User Terminal B.

Step 302: User C calls User B.

Step 303: User B initiates an ECT service, requesting to connect user A and user C.

Step 304: The MSC sends a service event message to the MGCF, where the service event message carries the service event information indicating the user B.

Here, if an ISDN (Integrated Services Digital Network) User Part (ISUP) or Bearer Independent Call Control (BICC) protocol is used between the MGCF and the MSC, then the service event message is a Call Progress (CPG) message or facility (FACILITY). The message is transmitted by the Generic Notification Indicator, where the generic notification indicator in the Generic Notification Indicator is ECT Connect, indicating the call forwarding service, and the destination user has answered.

Here, the service event message sent by the MSC may adopt a method of generating a service event message already existing in the public switched telephone network PSTN.

Step 305: After receiving the service event message sent by the MSC, the MGCF carries the service event information in the service event message in an appropriate SIP message. In the present invention, the SIP message carrying the service event information may also be referred to as a service event message in the SIP protocol format.

Step 306: The MGCF sends the SIP message carrying the service event information to the IMS network along the path established by the user A and the user B.

Wherein, in step 305, the service event information in the service event message is carried in the appropriate The methods in the SIP message can be divided into three types. The first type is that the service event information is obtained, and the SIP message header is extended or the SIP message body is extended; the second type is that the service event information is obtained, and the message header or the message body in the SIP message is used. The third is, when the MGCF receives the CPG or FACILITY message carrying the service event information, the CPG message or the FACILITY is encapsulated according to the ITU-T Q.1912.5 and the SIP protocol encapsulation method of the IETF SIP-T. Appropriate SIP messages. Here, obtaining the service event information described in the first and second methods means: obtaining the service event information from the received service event message. The business event information may be a business event type corresponding to a business event, or a business event parameter, or a business event type and a business event parameter.

The appropriate SIP message is described as follows: if the MGCF needs to send a SIP message to the IMS network, the MGCF may encapsulate the currently received service event information into the SIP message to be sent for transmission; if the MGCF does not currently need it When the SIP message is sent to the IMS network, the IMS network can initiate a new SIP request message, such as INFO, which carries the service event information. Here, INFO is a request method defined by the SIP protocol, and the INFO request message is a request message using the INFO request method. Other SIP request or response messages can be used in addition to the INFO request message.

The first method of carrying the business event information in the service event message in the appropriate SIP message is now described. The specific mode in which MGCF delivers service event information by extending the SIP message header field can be seen in the following form:

P-Service-Notification: <Business Event Type> [; <Business Event Parameter>].

The P-Service-Notification is the header field name of the extended message header field; the service event type is used to indicate the type of the current service event; the service event parameter part is the information corresponding to the service event type, and the content of the part is optional, such as For the call forwarding type business, the event parameter can be a forward-number parameter. Here, the method for obtaining the service event parameter may be obtained according to related content in the service event message received by the MGCF from the MSC, It can also be obtained according to other methods in the prior art.

Here, the specific value of the business event information may be a business event comparison table shown in Table 1. The business event comparison table includes business events and corresponding business event types. Business event business event type user keeps call user-sustended user resumes call user-resumed bearer service change bearer- service-change call completion delay call-completion-delay conference established conference-established conference disconnected conference-disconnected other parties join The conference other-party-added user or call is quarantined isolated and quarantined and rejoined after the conference is reattached. Other conference parties are quarantined other-party-isolated. Other quarantined conference parties are rejoined to the conference other-party-reattached Other conference methods From the conference split other-party- split There is a conference party leaving the conference other-party- disconnected Conference control in the conference-floating call is a waiting call call-is-a-wait-call (the other party is in the call waiting service)

Call forwarding activated diversion-activate Call forwarding and transfer destination user is ringing ect-alerting Call transfer and transfer destination user has answered ect- active

Call is being transferred call-is-diverting According to Table 1, when the service event received by an IMS network entity is ect-active, it indicates that the call is transferred and the destination user has answered.

In this embodiment, when the service event message received by the MGCF indicates that the current service event of the user B is the ECT service, and the transfer destination user has responded, the MGCF may obtain the mapping according to the current service event message through the table-first mapping. The service event information that needs to be sent to the IMS network is: ect-active ; and the call number to which the call is transferred is: 010-28780808. The message that the MGCF sends the current service event information through the INFO message is as follows:

INFO sip: usera @ examplea.com SIP/2.0

P-Service-Notification: ect-active; redirect-number=tel:010-28780808 where SIP message consists of three parts, namely: start line, message header and message body, the start behavior request line in the request message , the start behavior status line in the response message. Here, only the request line of the INFO request message and the message header field related to the service event information are given, and other parts of the INFO request message may adopt the default form.

Since the service event information is transmitted by extending the SIP message header field, the extended header field is: P-Service-Notification: ect-active; redirect-number=tel: 010-28780808, indicating that P-Service-Notification is added. Header field. The service event information indicated by the header field is: the service event type is: ect-active; the service event parameter is redirect-number=tel: 010-28780808, the service event parameter is the number of user C; the other part of the INFO request message is not required change.

When the INFO message is a newly generated SIP message for transmitting the service event information, the request line part needs to be filled according to the Uniform Resource Identifier (URI) of the destination user when generating the message, and the URI of the user A is assumed here. Usera@examplea.com. When the message is a SIP message that the MGCF needs to send to the user A, the request in the INFO message is only when the SIP message sent to the user A carries the service event information. User A's URI already exists in the line, so you only need to keep the contents.

In addition, when the MGCF delivers service event information by extending the message body of the SIP message, the extended message body may adopt an extended Bacchus (ABNF) text encoding method, an Extensible Markup Language (XML) encoding method, or an abstraction. Syntax code 1 ( ASN.1 ) Binary encoding. Since the message body of the SIP message supports the binary coding mode and also supports the text mode, if the third mode is adopted, the MGCF directly writes the binary code of the service event information obtained from the CS network into the message body of the SIP message; In the ABNF mode, the same as the extended header, the business event comparison table is set in advance, and the encoded business event information can be expressed as:

861^ 6^(^ &11011=<business event type> [; <business event parameter>].

Service-Notification indicates that the line carries the service event information; the meaning of the service event type and the service event parameter is the same as that described in the extended SIP message header field delivery service event information, and will not be described in detail herein.

In this embodiment, when the MGCF transmits the service event information by extending the message body of the SIP message, the form of the SIP message sent by the MGCF is as follows. Here, the INVITE message in the SIP message is taken as an example for description.

INVITE sip: usera@examplea.com SIP/2.0

Content-Type: application/Service-Notification

Service-No tification=ect-active; redirect-number=tel:010-28780808 Here, only the request line of the INVITE message and the message header field and message body related to the service event information are given. Here, the request behavior: INVITE sip:usera@examplea.com SIP/2.0, indicates the destination user to which the INVITE message is sent. The URI of the destination user is: usera@ examplea.com.

Here, since the service event information is carried by the extended message body, it is necessary to add a corresponding header field, and the header field is expressed as: Content-Type: Application/Service-Notification, where application/Service-Notification indicates that the message body carried by the message is business event information. The corresponding extension message body is: Service-Notification=ect-active; redirect-number=tel: 010-28780808, which is a service event information message body generated according to the above ABNF coding. The message body indicates that the service event type is: ect-active, and the call number to which the call is transferred is: 010-28780808. When the INVITE is a SIP message that needs to be sent to the IMS network, the other part of the INVITE message that is currently added to the extended message body is the original content in the INVITE message.

The second method of carrying the business event information in the service event message in the appropriate SIP message is described below.

When the service event message received by the MGCF indicates that the current business event of user B is

The ECT service, and the transfer destination user has responded, the MGCF may map the forwarding number corresponding to the current ECT service to the SIP message and send it to the IMS network according to the indication of the current service event message. The manner of mapping to the SIP message may be the P-Asserted-Identity existing in the SIP message or when the communication parties support the modification of the From or To header field of the SIP message, the From or To header field may also be used.

For example, the message that the MGCF sends the current service event information through the UPDATE request message is as follows:

UPDATE sip :usera @ examplea.com SIP/2.0

P- Asserted-Identity: td:010-28780808

Here, only the request line of the UPDATE request message and the service event parameter corresponding to the current business event are given, that is, the forwarding number corresponding to the current business event. The rest of the UPDATE request message can be in the default form.

Or,

INVITE sip: usera@examplea.com SIP/2.0

From: <td:010-28780808>;tag=12345 Here, only the request line of the INVITE request message and the service event parameter corresponding to the current service event are given, that is, the forwarding number corresponding to the current business event. The rest of the INVITE request message can be in the default form.

For the method of carrying the service event parameter in the existing message body of the SIP message, refer to the method of carrying the service event parameter in the existing message header, which is not described in detail herein. Of course, according to the actual situation, this method may also be adopted: an extended message header carried by part of the service event information, an existing message body carried by all the service event information or the remaining part of the service event information, or other Type such a method.

As can be seen from the introduction of the second method, the business event information used here is a business event parameter, and only the business event parameter is used in the service notification message, and the purpose of the present invention can also be achieved. For example, for the ECT service, when the user B generates the ECT service, since the IMS network service control entity in the IMS network manages the service used by the user B, when the IMS network service control entity receives the service notification sent by the user B, In the case of a message, according to the forwarding number carried in the service notification message, that is, the number of the user C, it can be known that the current user B is in an idle state. Therefore, when there is a call that needs to be connected to User B, User B can continue the call.

Of course, the business event information is a business event type, or a business event parameter, or a business event type and a business event parameter, and is determined according to the function, characteristics, and network operation requirements of the network device. When the service event information includes the service event type, the same can be introduced in the first method. According to the preset business event comparison table, when the user has a business event, the corresponding business event type is obtained according to the search service event comparison table.

When using the third method, there is no need to set the business event comparison table. Since the BICC protocol message and the ISUP protocol message itself support the business event notification mechanism, it is only necessary to follow the technology provided in the existing SIP-I/SIP-T protocol. The BICC protocol message and the ISUP protocol message can be encapsulated into an appropriate SIP message. In the present invention, the BICC protocol is encapsulated A SIP message of a message or an ISUP protocol message may also be referred to as a service event message in the SIP protocol format.

The device in the IMS network can receive the above SIP message with service event information, and process the call between user A and user B accordingly.

The technical solution described in this embodiment is also applicable to the case where a calling user has a business event.

Embodiment 2

The first network described in the second embodiment is a CS network, and the second network is an IMS network. The interworking unit between the first network and the second network is an MGCF. During the calling process between the calling user A and the called user B, The case where the called user B initiates a business event.

This embodiment mainly describes that a call is being established or has been successfully established between the user A in the CS network and the user B in the IMS network. If the user B triggers a certain service, such as an ECT service, the service of the user B is The control entity needs to generate a service event message according to the currently triggered service and the state of the service, and send it to the MGCF for conversion.

In this embodiment, since the service control entity in the IMS network does not generate a service event message, the method for generating the service event message here is: Consider that the IMS network is based on the SIP protocol, so when the user B corresponds to the service in the IMS network The control entity carries the service event information corresponding to the service triggered by the user B in the appropriate SIP message when the user has a business event. After receiving the SIP message carrying the service event information sent by the service control entity in the IMS network, the MGCF extracts the service event information from the message and sends it to the CS network in a format that can be recognized by the CS network.

4 is a system structural diagram of a method for implementing the embodiment. The system includes a CS network 41, an MGCF 42 and an IMS network 43. The CS network 41 includes at least an MSC 411 and a user terminal 412. The IMS network 43 includes at least an IMS network service control entity 431 and a user. Terminal 432. The MSC 411, MGCF 42 and IMS network service control entity 431 are responsible for establishing calls between the user terminal 432 and the user terminal 412.

The IMS network service control entity 431 is configured to generate a SIP message carrying the service event information according to the service event performed by the called user terminal 432, and send the message to the MGCF. The specific structure of the IMS network service control entity 431 is as shown in FIG. 5, and at least includes: an obtaining unit 4311, configured to acquire service event information according to a service event performed by the user, and send the service event information to the generating unit 4312; The generating unit 4312 is configured to generate a service event message in a SIP protocol format according to the service event information, and send the generated service event message in the SIP protocol format to the sending unit 4313. The sending unit 4313 is configured to send the service in the SIP protocol format. Event message.

The MGCF 42 is configured to receive a service event message, convert the service event message into a form recognizable by the CS network, and send the message to the CS network where the calling user terminal is located. Here, the internal structure of the MGCF 42 may be as shown in FIG. 6, including a receiving unit 421 for receiving and transmitting a service event message in a SIP protocol format to the inverse conversion unit 422, and an inverse converting unit 422 for using the SIP protocol format. The service event message is converted into a service event message supported by the CS network, and the service event message supported by the CS network is sent to the sending unit 423. The sending unit 423 is configured to send the service event message supported by the CS network.

There are also three methods in the SIP information carried by the service control entity in the IMS network. The first one is to carry the service event information by extending the SIP message header or the message body; the second is, The existing message header or message body of the SIP message carries service event information. The third method is: The service control entity in the IMS network generates a service event message supported by the CS network according to the ISUP protocol, and is carried in the call message body of the SIP message.

The second method may be implemented by using an INVITE in the session in the SIP message, an INVITE request message outside the session, or a REFER request message. An example of a concrete implementation of an INVITE request message through a session is:

INVITE sip: usera@examplea.com SIP/2.0

P- Asserted-Identity: td:010-28780808

Here, the ECT service event information is transmitted through the INVITE request message in the original session, that is, the INVITE request message in the session.

An example of a concrete implementation of an out-of-session INVITE request message is:

INVITE sip: usera@examplea.com SIP/2.0

P- Asserted-Identity: td:010-28780808

Replaces: dlg-id-call-id; from-tag=dlg-id-from-tag; to-tag=dlg-id-to-tag where the INVITE request message containing the Replaces header field is an out-of-session INVITE request message A specific example. The Replaces header field carries the conversation ID of the original session, including the Call-ID, From-tag, and To-tag parameters of the SIP conversation corresponding to the original session.

An example of a concrete implementation of a REFER request message is:

REFER sip: usera @ mgcf42.example.com SIP/2.0

Refer-To: tel: 010-28780808

The Refer-To header field carries the user number to which the call is transferred. After receiving the message, the MGCF initiates a call to the indicated user, and generates a service event message supported by the CS network and sends the message to the CS network.

Here, the first method and the second method are different from the first embodiment in that, in the first embodiment, the corresponding service event information is obtained according to the received service event message, and in this embodiment is triggered according to the user. The business and business status obtain corresponding business event information.

The appropriate SIP message refers to the same meaning as the appropriate SIP message in the first embodiment, that is, if the service control entity in the IMS network needs to send a SIP message, the service control entity may receive the current message. The service event information is encapsulated into the SIP message to be sent. If there is no SIP message to be sent, the service control entity in the IMS network may initiate a new INFO request message carrying the service event information. Here, there are many types of service events, such as multiple services in the conference service, and the ECT service. The technical solution of the present embodiment is described in detail by taking the ECT service of the user B as an example. In this embodiment, User B transfers the call to User C, also located within the IMS network. In the introduction of the method flow in this embodiment, it is assumed that user B and user C belong to one IMS network service control entity. When the user B and the user C belong to one IMS network service control entity, the same technical solution as the embodiment can be adopted.

FIG. 7 is a flowchart of the method of the embodiment, which is specifically described as follows:

Step 701: The MSC establishes a call between the user A and the user B with the MGCF and the IMS network service control entity.

Here, the IMS network service control entity is a service control entity that provides services for user B. If there is no service control entity that provides services for users within the IMS network, this part of the function can also be completed by the MGCF.

Step 702: User C calls user B.

Step 703: User B requests the ECT service, and requests to connect user A and user C. Step 704: The service control entity of user B generates a service event message according to the service event performed by user B.

The service event message here is a SIP message carrying service event information. Can be of the form:

INFO sip: usera @ examplea.com SIP/2.0

P-Service-Notification: ect- active; redirect-number=tel:010-28780808 or the following form:

INVITE sip: usera® examplea.com SIP/2.0

Content-Type: application/Service-Notification

Service-No tification=ect-active; redirect-number=tel: 010-28780808 The specific meaning is the same as that described in Embodiment 1, and will not be described in detail herein. Step 705: The service control entity of the user B sends the generated service event message to the MGCF.

Step 706: After receiving the service event message sent by the service control entity of the user B in the IMS network, the MGCF converts the received service event message into a format recognizable by the CS network, along the path established by the user A and the user B. CS network direction is sent.

Since there is a mechanism for service event notification in the CS network, the MGCF can convert the service event information received from the service control entity into a format recognizable by the CS network entity according to the service event notification mechanism in the CS network. For example, the SIP message carrying the service event information is converted into an ISUP protocol message or a BICC protocol message, and the specific conversion method may be according to the ISUP protocol message and the relevant provisions of the BICC protocol message; or according to the existing ITU-T defined SIP-I or The SIP-T technology defined by the IETF converts SIP messages and sends them to the CS domain. Since the ISUP protocol and the BICC protocol support the service event mechanism in the CS network, if the ISUP protocol message or the BICC protocol message is adopted, the specific situation of the CS network can be more adapted.

Embodiment 3

The first network and the second network described in Embodiment 3 are both CS networks, and the interworking devices between the corresponding first network and the second network are: a first MGCF connecting the first CS network and the IMS network, and an IMS network; A second MGCF connecting the IMS network to the second CS network. The first MGCF and the second MGCF communicate through the IMS network.

In this embodiment, the interworking device is responsible for converting the received service notification information sent by the second CS network where the called user is located into a SIP message that can be transmitted in the network, and transmitting to the first location of the calling user terminal. When the CS network is re-converted into a format recognizable by the CS network, it is sent to the first CS network. In this embodiment, the called user terminal is mainly introduced. The circumstances in which a business event is initiated.

FIG. 8 is a structural diagram of the system of the present embodiment, including a CS network 81, an IMS network 82, and an CS network 83. The CS network 81 includes at least a user terminal 812 and an MSC 811; the IMS network 82 includes at least an MGCF 821 and an MG CF 822; and the CS network 83 includes at least a user terminal 832 and a CS network MSC 831.

Here, the MGCF 821 is responsible for connecting the CS network 81 and the IMS network 82; the MGCF 822 is responsible for connecting the IMS network 82 and the CS network 83. The MSC 811, MG CF 821, MG CF 822, and MSC 831 are responsible for establishing a call between the calling user terminal 812 and the called 832.

The MSC 831 corresponding to the called user terminal 832 generates a service event message when a service event occurs on the called user terminal.

The MGCF 822, which is responsible for connecting the IMS network 82 and the CS network 83, is configured to receive a service event message, convert the service event message into a SIP message, and send it to the MGCF 821 in the IMS network 82. Here, the specific structure of the MGCF822 can be the same as that shown in FIG. 2, and will not be described in detail herein.

The MGCF 821 in the IMS network 82 is configured to convert the received SIP message into

The CS network can recognize the form and send it to the CS network 81 where the calling user terminal is located. Here, the specific structure of the MGCF 821 may be the same as that shown in FIG. 6, and will not be described in detail herein.

In the network environment shown in FIG. 8, the calling user A is located in the CS network 81, and the called user B is located in the CS network 83.

During the call process between the calling user A and the called user B, the called user B generates a service event, and the MSC 831 corresponding to the called user B generates a service event message, and sends it to the MGCF 822; the MGCF822 will receive the service event message. The corresponding service event indication is encapsulated into a SIP message and sent to the MGCF 821 through the IMS network; the MGCF 821 converts the SIP information carrying the service event indication into a format recognizable by the CS network, and sends it to the CS network 81 along the call setup path. For the method of carrying the service event information in the SIP message, refer to the related description of the step 305 in the first embodiment. For the method of converting the service event information into a format that can be recognized by the CS network, refer to step 706 in the second embodiment. Related introductions are not detailed here.

The technical solution described in this embodiment is also applicable to the case where a service event occurs on the calling user terminal.

Embodiment 4

The first network and the second network described in Embodiment 4 are both IMS networks, and the interworking devices between the corresponding first network and the second network are: a first MGCF connecting the first IMS network and the CS network, and a connection station The CS network and the second MGCF of the second IMS network. The first MGCF and the second MGCF communicate through the CS network.

In this embodiment, for the purpose of the invention, the CS network as the interworking device is responsible for converting the received service event information sent by the IMS network of the called user into a message that can be transmitted in the network, and sending it to the When the calling party is in the IMS network, it re-converts into a SIP message that the IMS network can recognize and sends it to the IMS network where the calling user is located. In this embodiment, the case where the called user terminal initiates a service event is mainly introduced.

Figure 9 is a structural diagram of the system of the present embodiment, including an IMS network 91, a CS network 92, and an IMS network 93. The IMS network 91 includes at least a user terminal 912 and an IMS network service control entity 911; the CS network 92 includes at least an MGCF 921 and an MGCF 922; and the IMS network 93 includes at least an IMS network user 932 and an IMS network service control entity 931. Here, the IMS network service control entity is an MSC; the MGCF 921 and the MGCF 922 may be an MGCF.

Here, the MGCF 921 is responsible for connecting the IMS network 91 and the CS network 92; the MGCF 922 is responsible for connecting the CS network 92 and the IMS network 93. The IMS network service control entity 911, MGCF 921, MGCF 922, and IMS network service control entity 931 are responsible for establishing calls between the calling user terminal 912 and the called user terminal 932.

The IMS network service control entity 931 is configured to perform business operations according to the called user. A SIP message carrying service event information is generated and sent to the MGCF 921. Here, the specific structure of the IMS network service control entity 931 may be the same as that shown in FIG. 5, and will not be described in detail herein.

The MGCF 922 is configured to convert the received SIP message into a form recognizable by the CS network and send it to the MGCF 921. Here, the specific structure of the MGCF 922 may be the same as that shown in FIG. 6, and will not be described in detail herein.

The MGCF 921 is configured to receive a message sent by the MGCF 922, and convert the message into a SIP message, and send the message to the IMS network 91 where the calling user terminal is located. Here, the specific structure of the MGCF 921 can be the same as that shown in FIG. 2 and will not be described in detail herein.

In the network environment shown in FIG. 9, the calling user A is located in the IMS network 91, and the called user B is located in the IMS network 93.

During the call process between the calling user A and the called user B, the called user B generates a service event, and the IMS network service control entity 931 corresponding to the called user B encapsulates the service event corresponding to the service event of the user B. The SIP message is sent to the MGCF 922; after receiving the SIP message carrying the service event indication, the MGCF922 converts the SIP information carrying the service event indication into a service event message that can be recognized by the CS network 92, and sends it to the MGCF 921 through the CS network 92. The MGCF 921 encapsulates the service event indication into the SIP message according to the service event indication corresponding to the service event message, and sends it to the IMS network 91 along the call setup path.

For the method of carrying the service event information in the SIP message, refer to the related description of the step 604 in the second embodiment. For the method of converting the service event information into a format that can be recognized by the CS network, refer to step 706 in the second embodiment. For the method of carrying the service event information in the SIP message, refer to the related description of step 305 in the first embodiment, or the reverse process according to the conversion format of the CS network MGCF922, which will not be described in detail herein.

The technical solution described in this embodiment is also applicable to a service event occurring at a calling user terminal. Case.

In the foregoing description of the specific implementation, the main description is the case where the service control entity where the user is located sends a service event message to the network where the peer user is located when the user has a business event. In the present invention, business event information can also be obtained by subscribing to a business event. That is, if user A needs to receive a service event at user B, and user A and user A's service control entity can receive service event information about user B, then user A needs to be in the process of calling itself with user B. Sending a subscription service event request to the user B; the service control entity where the user B is located only sends the service event information about the user B to the user A when the user B has a service event after receiving the subscription service event request sent by the user A. .

Here, the method for the user A to send the subscription service event request to the user B may be a method of adding a SIP event packet, and the event type of the SIP event packet is: Service-Notification, and the subscription service event request may be sent by expanding the header field method. , can refer to the following message form:

SUBSCRIBE sip: userb @ csdomian .example SIP/2.0

Event: Service-Notification

At the same time, the service control entity where the user B is located sends the service event information for the user B to the network where the user A is located. The method described in the first embodiment to the fourth embodiment is used according to the specific network environment, and details are not described in detail.

When the service event information of the user is obtained by subscribing to the service event, the format of the service event message carrying the service event information may be in the following form:

NOTIFY sip: usera@example.com SIP/2.0

Content-Type: application/Service-Notification

Service-Notification=ect-connect; redirect-number=tel:+86-28781234 Here is the way to extend the message body in NOTIFY. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalents, improvements, etc., which are made within the spirit and principles of the present invention, should be included in the present invention. Within the scope of protection.

Claims

Claim

A method for transmitting a service event, characterized in that: performing the following steps: when a user has a service event during a call, the first network where the user is located and the second network where the peer user is located in the current call process The device receives a service event message generated by the service control entity where the user is located;

2. The method according to claim 1, wherein the first network is: a circuit switched CS network; the second network is: an internet multimedia subsystem IMS network; and the interworking device is a media gateway control function. MGCF;

The interworking device transmits the service event message to the second network identifiable form: the MGCF converts the received service event message into a session initiation protocol SIP message and sends the message to the IMS network.

3. The method according to claim 2, wherein the MGCF converts the received service event message into a SIP message:

Obtaining service event information corresponding to the service event included in the service event message; and encapsulating the service event information into the SIP message.

The method according to claim 2, wherein when the received service event message is an integrated service digital network user part ISUP protocol message or a bearer independent call control BICC protocol message;

The MGCF converts the received service event message into a SIP message as: Encapsulating the received service event message into a SIP message.

The method according to claim 1, wherein the first network is: an IMS network; the second network is: a CS network; the interworking device is an MGCF; The service control entity generates a service event message as follows: The service control entity in the IMS network of the user obtains the corresponding service event information according to the service event that the user generates, and generates a service event message in the SIP protocol format according to the obtained service event information.

The method according to claim 5, wherein the service event message for generating a SIP protocol format is:

The service control entity encapsulates the service event information into the SIP message; or generates a service event message in the ISUP protocol format according to the service event information, and encapsulates the service event message in the protocol format into the SIP message.

7. A method according to claim 5 or 6, characterized in that

The interworking device converts the service event message and sends it in a form recognizable by the second network as:

The MGCF converts the SIP message into an ISUP protocol message or a BICC protocol message.

The method according to claim 1, wherein the first network and the second network are: a CS network; the interworking device is: a first MGCF and a connection connecting the first CS network and the IMS network And the IMS network and the second MGCF of the second CS network; the interworking device converting the service event message into a second network identifiable form, and sending the message to the second network along the call setup path includes:

The first MGCF converts the received service event message into a SIP message, and sends the message to the second MGCF through the IMS network;

The second MGCF converts the SIP message into a format recognizable by the CS network and transmits it along the call setup path to the second CS network.

The method according to claim 8, wherein the first MGCF converts the received service event message into a SIP message as:

Obtaining service event information corresponding to the service event corresponding to the service event message; and encapsulating the service event information into the SIP message.

The method according to claim 8, wherein when the received service event message is an ISUP protocol message or a BICC protocol message;

The first MGCF converts the received service event message into a SIP message by encapsulating the received service event message into the SIP message.

11. A method according to claim 8, 9 or 10, characterized in that

The second MGCF converts the SIP message into a format that the CS network can recognize as: converting the SIP message into an ISUP protocol message or a BICC protocol message.

The method according to claim 1, wherein the first network and the second network are: an IMS network; the interworking device is: a first MGCF and a connection connecting the first IMS network and the CS network The CS network and the second MGCF of the second IMS network; the service control entity generating the service event message includes: the service control entity in the first IMS network where the user is located obtains the corresponding service event information according to the service event that occurs by the user, A service event message in a SIP protocol format is generated according to the obtained service event information.

The method according to claim 12, wherein the generating a service event message in a SIP protocol format comprises:

The service control entity encapsulates the service event information into the SIP message; or generates a service event message in the ISUP protocol format according to the service event information, and encapsulates the service event message in the ISUP protocol format into the SIP message.

14. Method according to claim 12 or 13, characterized in that

The interworking device converts the service event message into a form recognizable by the second network, and sends the message to the second network along the call setup path, including:

After receiving the SIP message, the first MGCF converts the SIP message into a service event message in a format recognizable by the CS network, and sends the message to the second MGCF through the CS network; the second MGCF receives the message from the first MGCF. The business event message is converted into a SIP message and sent along the call setup path to the second IMS network.

15. The method of claim 14 wherein:

The method according to claim 15, wherein when the received service event message is an ISUP protocol message or a BICC protocol message, the second MGCF receives a service event message from the first MGCF. Convert to SIP message as:

The received service event message in the ISUP protocol format or the BICC protocol format is encapsulated into a SIP message.

The method according to claim 14, wherein the second MGCF converts the service event message received from the first MGCF into a SIP message:

18. The method according to claim 3, 6, 9, or 13, wherein the encapsulating the service event information into the SIP message is:

The service event information is encapsulated into an extended header field of the SIP message, or an extended message body.

The method according to claim 3, 6, 9, or 13, wherein the encapsulating the service event information into the SIP message is: encapsulating the service event information into an existing header field in the SIP message , or in an existing message body.

20. The method of claim 3, 5, 9, 12 or 16, wherein the business event information is: a business event type and/or a business event parameter.

The method according to claim 20, wherein the service event information is a service event type; the method further comprises: setting a correspondence between the service event and the service event type;

The obtaining the service event information is: obtaining a service event type corresponding to the service event according to the correspondence between the service event and the service event type.

22. A method according to any one of claims 1 to 6, 8 to 10, 12, 13 wherein:

When the service control entity of the user receives the service event subscription message sent by the peer user, the service control entity of the user generates a service event message, where the first network where the user is located and the second network where the peer user is located in the current call process The interworking device receives the generated service event message.

The method according to claim 3, 4, 5, 6, 9, 10 or 13, wherein the encapsulated SIP message is: a SIP message to be sent currently, or a newly initiated SIP request message .

24. The method of claim 3, 4, 5, 6, 9, 10 or 13 characterized in that

The SIP message is: an INVITE request message within a session or outside the session; or a REFER request message.

A system for transmitting a service event, the system comprising: at least: a first network where the user is located, a second network where the peer user is located, and an interworking device responsible for interworking between the first network and the second network; At least including a first service control entity that provides services to users;

The first service control entity is configured to generate a service event message when the user generates a service event during the call, and send the service event message to the interworking device;

The system according to claim 25, wherein the first network is a CS network; the second network is an IMS network; and the interworking device is an MGCF;

Receiving, by the MGCF, a service event message, converting the service event message into a SIP message, Send to the IMS network where the peer user is located.

The system according to claim 25, wherein the first network is an IMS network; the second network is a CS network; and the interworking device is an MGCF;

The first service control entity generates a service event message in a SIP protocol format according to a service event performed by the user, and sends the message to the MGCF.

The MGCF receives the service event message, and converts the service event message into a form that can be recognized by the CS network, and sends the message to the CS network where the peer user is located.

The system according to claim 25, wherein the first network and the second network are both CS networks; the interworking device is: a first MGCF connecting the first CS network and the IMS network, and a connection The IMS network and the second MGCF of the second CS network; the first MGCF and the second MGCF communicate with each other through the IMS network;

Receiving, by the first MGCF, a service event message, converting the service event message into a SIP message, and sending the message to the second MGCF through the IMS network;

The second MGCF converts the received SIP message into a form recognizable by the CS network and sends it to the second CS network where the peer user is located.

The system according to claim 25, wherein the second network and the first network are both IMS networks; the interworking device is: a first MGCF connecting the first IMS network and the CS network, and a connection The CS network and the second MGCF of the second IMS network; the first MGCF and the second MGCF communicate with each other through the CS network;

The first network service control entity generates a service event message in a SIP protocol format according to a service event performed by the user, and sends the message to the first MGCF.

The first MGCF converts the received SIP message into a form recognizable by the CS network, and sends the message to the second MGCF through the CS network;

The second MGCF receives the message sent by the first MGCF, and converts the message into a SIP message, and sends the message to the second IMS network where the peer user is located.

An IMS network service control entity, comprising: an obtaining unit, configured to acquire service event information according to a service event performed by a user, and send the service event information to a generating unit;

31. An MGCF, comprising: at least:

a receiving unit, configured to receive and send a service event message sent by the CS network to the converting unit;

a converting unit, configured to convert the received service event message into a service event message in a SIP protocol format; and send the service event message in the SIP protocol format to the sending unit; and send, in a sending unit, the SIP protocol format Business event message.

32. An MGCF, comprising: at least:

a receiving unit, configured to receive and send a service event message in a SIP protocol format to the reverse switching unit;

An anti-transformation unit, configured to convert the service event message in the SIP protocol format into a service event message supported by the CS network, and send the service event message supported by the CS network to the sending unit;