WO2008154842A1 - Procédé et dispositif pour fournir un service de transfert d'appel pour les utilisateurs - Google Patents

Procédé et dispositif pour fournir un service de transfert d'appel pour les utilisateurs Download PDF

Info

Publication number
WO2008154842A1
WO2008154842A1 PCT/CN2008/071264 CN2008071264W WO2008154842A1 WO 2008154842 A1 WO2008154842 A1 WO 2008154842A1 CN 2008071264 W CN2008071264 W CN 2008071264W WO 2008154842 A1 WO2008154842 A1 WO 2008154842A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
message
network entity
ims network
call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2008/071264
Other languages
English (en)
French (fr)
Inventor
Dongming Zhu
Hengliang Zhang
Songhai Ye
Chunyan Ding
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP08757675A priority Critical patent/EP2141902A4/en
Publication of WO2008154842A1 publication Critical patent/WO2008154842A1/zh
Priority to US12/612,769 priority patent/US20100054159A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1225—Details of core network interconnection arrangements
    • H04M7/123—Details of core network interconnection arrangements where the packet-switched network is an Internet Protocol Multimedia System-type network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42365—Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity
    • H04M3/42374—Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity where the information is provided to a monitoring entity such as a potential calling party or a call processing server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/121—Details of network access arrangements or protocols
    • H04M7/122—Details of network access arrangements or protocols where the PSTN/ISDN access is used as an access to networks other than PSTN/ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42025—Calling or Called party identification service
    • H04M3/42085—Called party identification service
    • H04M3/42102—Making use of the called party identifier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42365—Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/0024—Services and arrangements where telephone services are combined with data services
    • H04M7/0057—Services where the data services network provides a telephone service in addition or as an alternative, e.g. for backup purposes, to the telephone service provided by the telephone services network

Definitions

  • the present invention relates to the field of communications, and more particularly to a method and apparatus for providing a call forwarding service to a user, and a method of transmitting a call forwarding notification message.
  • IP Multimedia Subsystem is a subsystem superimposed on an existing packet switched domain (PS) in a mobile switching network. It uses a packet switched domain as its 7-channel channel for upper layer control signaling and media transmission.
  • the session initiation protocol SIP (Session Inition Protocol) protocol is introduced as a service control protocol.
  • SIP Session Inition Protocol
  • the SIP package is simple, easy to expand, and the media combination is convenient. By separating the service control from the bearer control, a rich multimedia service is provided.
  • the main functional entities in the IMS include the Call Session Control Function (CSCF), which controls the user registration and session control functions, and the application server AS (Application Server) that provides various service logic control functions to centrally manage user subscription data.
  • CSCF Call Session Control Function
  • AS Application Server
  • IM-MGW IMS-Media Gateway Function
  • P-CSCF Proxy-CSCF
  • S-CSCF Service-CSCF
  • IMS is the third Generation Partnership Project 3GPP (3 rd Generation Partnership Project) and advanced telecommunications and Internet interconnection of centralized service and protocol Tispan (Telecommunications and InternetConverged Services and Protocols for Advanced Networking) described in 3GPP2 (3 rd Generation Partnership Project 2)
  • 3GPP2 3 rd Generation Partnership Project 2
  • MMD Multimedia Domain
  • the function of the call session control function entity CSCF is the same as above.
  • the call is routed to its home IMS network, providing services to the user in the IMS domain.
  • a new entity ICCF IMS CS Control Function, called IMS circuit control function entity
  • IMS circuit control function entity IMS circuit control function entity
  • the interface Ix between the ICS UE and the ICCF is also called ICCC (IMS CS Control Channel), and may be different protocols according to different network access environments, collectively referred to as ICCP, for example, only exists in FIG.
  • ICCC IMS CS Control Channel
  • the interface Ix is an Unstructured Supplementary Service Data (USSD) interface between the UE and the ICCF, an SMS interface or a DTMF interface; when in the case of a PS connection, it is a UE and SIP protocol between ICCF.
  • USB Unstructured Supplementary Service Data
  • the embodiment of the invention provides a method and a device for providing a call forwarding service for a user, which provides a call forwarding service for a called user accessing from a CS domain in an IMS domain.
  • the embodiment of the present invention further provides a method for transmitting a call transfer notification message to implement call forwarding notification for accessing a user from a CS domain.
  • a method for providing a call forwarding service for a user includes the following steps: The IMS network entity receives a call directed to a user accessing from the CS domain; and the IMS network entity obtains the current session connection state of the user and/or User wishes; and providing call forwarding services based on the obtained session connection status and/or user wishes.
  • An IMS network entity includes: a receiving unit, configured to receive a call directed to a user accessing from a CS domain; and an obtaining unit, configured to obtain, after the receiving unit receives the call, the current current of the user Session connection status and/or user wishes.
  • a media gateway control function entity of the embodiment of the present invention includes: a first converting unit, configured to convert an 181 notification message (SIP call forwarding notification message) into a CS domain message carrying call forwarding information; and/or a second a converting unit, configured to convert a CS domain message carrying user inaccessible information into an unreachable response message in the SIP; and/or a third converting unit, configured to convert the CS domain message carrying the user no response information into a SIP No response message in .
  • a first converting unit configured to convert an 181 notification message (SIP call forwarding notification message) into a CS domain message carrying call forwarding information
  • a second a converting unit configured to convert a CS domain message carrying user inaccessible information into an unreachable response message in the SIP
  • a third converting unit configured to convert the CS domain message carrying the user no response information into a SIP No response message in .
  • a method for transmitting a call forwarding notification message includes the following steps: a call initiated by a user accessed from a CS domain, or a call directed to a user accessed from a CS domain is called a call; an IMS network entity receives a call forwarding notification message; converting a call forwarding notification message of the IMS domain into a message satisfying the receiving capability of the CS domain access user; and transmitting the converted message to the user accessing the CS domain.
  • the method and device for providing a call forwarding service for a user in an embodiment of the present invention after receiving a call directed to a user accessing the CS domain, the IMS network entity obtains the current connection state and/or the user's will of the user, thereby The obtained connection status or user's willingness provides a call transfer service for the called user accessing from the CS domain.
  • the method for transmitting a call forwarding notification message according to the embodiment of the present invention after the call initiated by the user accessing the CS domain or the call directed to the user accessing the CS domain is transferred, the IMS network entity receives the IMS domain.
  • Call forwarding notification message the IMS network entity itself or instructing other network elements to convert the call forwarding notification message of the IMS domain into a message satisfying the receiving capability of the CS domain access user, and connecting the converted message to the CS domain
  • the incoming user sends it.
  • a call transfer notification for accessing the user from the CS domain is realized.
  • Figure 1 is a schematic diagram of an existing centralized service control ICS architecture
  • FIG. 2 is a flow chart showing the steps of a method for providing a call forwarding service for a user according to an embodiment of the present invention
  • FIG. 3 is a schematic diagram of an IMS network entity according to an embodiment of the present invention.
  • FIG. 4 is a schematic diagram of another IMS network entity according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of Embodiment 1 of the present invention.
  • FIG. 6 is a flowchart of Embodiment 2 of the present invention.
  • FIG. 7 is a flowchart of Embodiment 3 of the present invention.
  • FIG. 8 is a flowchart of Embodiment 4 of the present invention.
  • FIG. 9 is a flowchart of Embodiment 5 of the present invention.
  • FIG. 10 is a flowchart of Embodiment 6 of the present invention.
  • FIG. 11 is a flowchart of Embodiment 7 of the present invention.
  • FIG. 12 is a flowchart of Embodiment 8 of the present invention.
  • FIG. 13 is a flowchart of Embodiment 9 of the present invention.
  • FIG. 14 is a flowchart of Embodiment 10 of the present invention.
  • FIG. 15 is a flowchart of Embodiment 11 of the present invention.
  • Figure 16 is a flowchart of Embodiment 12 of the present invention.
  • Figure 17 is a flowchart of Embodiment 13 of the present invention.
  • Figure 18 is a flowchart of Embodiment 14 of the present invention.
  • FIG. 19 is a flowchart of Embodiment 15 of the present invention.
  • FIG. 20 is a flowchart of Embodiment 16 of the present invention.
  • Figure 21 is a flowchart of Embodiment 17 of the present invention.
  • Figure 22 is a flowchart of Embodiment 18 of the present invention.
  • FIG. 23 is a flowchart of Embodiment 19 of the present invention.
  • Figure 24 is a flowchart of Embodiment 20 of the present invention.
  • FIG. 25 is a flowchart of steps of a method for transmitting a call transfer notification message according to an embodiment of the present invention. detailed description
  • the call forwarding service enables the called user to transfer a call to another number or to the user's voice mailbox, mainly in the following forms:
  • CFU Call Forwarding Unconditional
  • CFB Call Forwarding Busy
  • This service allows the user to transfer its incoming call to another phone number preset or in the user's voicemail.
  • the "user busy” includes two situations, that is, the user judged by the network is busy or is busy by the user.
  • Call Forwarding on No Reply (CFNRy) Service This service enables the user to transfer the call to a preset number or the user's voicemail when the user is unable or unwilling to answer the call. in.
  • Call Forwarding on Mobile Subscriber Not Reachable (CFNRc) Service When the call cannot reach the user for some reason, this service enables the network to automatically transfer the call to a preset number of the user. Or in the user's voicemail.
  • Communication Forwarding on Not Logged-in (CFNL) Service When the user is not registered to the network, the service enables the network to automatically transfer the call to a user-preset number or user's voice. In the mailbox.
  • Call Deflection (Call Deflection) Service This service allows the user to temporarily transfer a call to another number after receiving a call.
  • the embodiment of the invention provides a method for providing a call forwarding service for a user. Referring to FIG. 2, the following main steps are included:
  • the IMS network entity receives a call directed to a user accessing from the CS domain.
  • the IMS network entity obtains the current session connection state of the user and/or the user's will.
  • the IMS network entity obtains the session connection status or the user's will in one of the following ways:
  • the mode a the CS domain network entity or the user's UE actively reports the session connection status or the user's will; the IMS network entity obtains the user's session connection status or user according to the received reported information.
  • the IMS network entity interacts with the related network element that saves the session connection state or the user's will, or queries the IMS network entity, learns the information of the existing session, and further obtains the session connection state or the user's will according to the learned information.
  • the connection state of the session mainly refers to whether the session can reach the user's terminal, and whether the user connects to the session, and the connection state of the session can provide the user with the CFNRc, CFNRy service; while the CFB and CD services are provided for the user. It is necessary to use the user's willingness to use the connection state of the session.
  • CFB user decides to be busy
  • CD service the terminal will give The network returns the user is busy or the user wants to execute the CD.
  • the IMS network entity is an application server that provides a call forwarding service, and the IMS network entity is based on the obtained current session connection state of the user or The user's willingness to provide the corresponding call forwarding service directly to the user; the IMS network entity is not the application server that provides the call forwarding service, and the IMS network entity forwards the session according to the obtained connection status of the user's current session or the user's will The connection state or the user's willingness to notify the application server that provides the call forwarding service for the user, and the application server that provides the call forwarding service provides the call forwarding service for the user.
  • An embodiment of the present invention further provides an IMS network entity, including: a receiving unit and a obtaining unit.
  • a receiving unit configured to receive a call directed to a user accessing from the CS domain
  • an obtaining unit configured to obtain, after the receiving unit receives the call, the current session connection state and/or the user's will of the user. Specifically, the obtaining unit obtains the session connection state and/or the user's will in one of the following ways:
  • the mode a the CS domain network entity or the UE of the user actively reports the session connection status or the user's will; the obtaining unit obtains the user's session connection status or the user's will according to the received reported information;
  • Method b The obtaining unit interacts with the related network element that saves the session connection state or the user's will, or queries the IMS network entity, learns the information of the existing session, and further obtains the session connection state or the user's will according to the learned information.
  • the method further includes: a notification unit, configured to obtain a session connection state and/or a user intention according to the obtaining unit.
  • the notification provides the user with the call forwarding service of the application server, the session connection status or the user's will.
  • the method may further include: a converting unit, configured to: convert the received IMS domain call forwarding notification message into a message that satisfies the receiving capability of the CS domain access user; and send, by the sending unit, the converted unit converted message Sent from the user accessing the CS domain.
  • the method further includes: an execution unit, configured to obtain the unit according to The obtained session connection status and/or user willingness to provide the call forwarding service for the user. Further, the method may further include: a converting unit, configured to: convert the received IMS domain call forwarding notification message into a message that satisfies the receiving capability of the CS domain access user; and send, by the sending unit, the converted unit converted message Sent from the user accessing the CS domain. In this embodiment, the notification unit notifies the execution unit of the session connection status and/or the user's will.
  • a media gateway control function entity including: a first conversion unit, and/or a second conversion unit, and/or a third conversion unit.
  • a first converting unit configured to convert the SIP call forwarding notification message into a CS domain message carrying call forwarding information, for example: Call Progress (Call Progress) message; by using the notification message, the user obtains the status of the session , enhance the user experience.
  • Call Progress Call Progress
  • a second converting unit configured to convert the CS domain message carrying the user inaccessibility information into a SIP unreachable response message (for example, a 503 response message, a 408 response message, or a 500 response message).
  • the IMS network entity obtains the connection state of the session that is inaccessible to the user, so that the CFNRc service can be provided to the user according to the state of the session.
  • a third converting unit configured to convert the CS domain message carrying the user no response information into a non-response response message in the SIP.
  • the IMS network entity obtains the connection status of the session as no response from the user, so that the CFNRy service can be provided to the user according to the state of the session.
  • the following is specifically described by the 20 embodiments.
  • the following embodiment is only a case of ICCF and TAS, and describes the process of providing a call forwarding service for a user. It is also possible that ICCF and TAS are combined so that internal messages can be exchanged between them.
  • the following embodiments are described by taking the ISUP of the user in the CS domain as an example.
  • the signaling of the user in the CS domain may also be other signaling such as BICC.
  • Embodiment 1 A method for providing a CFNRc service, as shown in FIG. 5, includes the following steps: 1 ⁇ 2.
  • the ICCF receives a call directed to the user UE-A; wherein the IAM is an Initial Address Message; 3 ⁇ 4, ICCF sends the call through the CS domain;
  • the MSC returns a Release message, and the reason for the failure is carried out: the paging fails (the user is out of reach);
  • the media gateway control function entity MGCF converts the Release message (user inaccessible) into a SIP 480 message (temporary unavailable response message) and sends it to the ICCF;
  • ICCF does not receive 180 message (ringing response message) before, and receives 480 message (temporary unavailable response message), and it is perceived that user UE-A is "unreachable"; therefore ICCF returns 503 to TAS. Message to inform the telecommunication service application server TAS
  • CFNRc service (telphony application service) User UE-A "unreachable", the CFNRc service is executed by the TAS.
  • the ICCF converts the state that is inaccessible to the user into a 503 message.
  • the ICCF can also convert the state that is inaccessible to the user into an inaccessible response message in other SIPs, such as: 408 message or 500 message. , passed to TAS, TAS will also execute CFNRc.
  • ICCF does not receive the SIP 180 message (ringing response message) and receives 480 message (temporary unavailable response message), then the user is perceived as " "Unreachable”; For example: If the TAS receives a 503 message, a 408 message, or a 500 message, the CFNRc service is executed.
  • Embodiment 2 The second method for providing the CFNRc service, as shown in FIG. 6, includes the following steps: 1 ⁇ 2, the ICCF receives a call directed to the user UE-A;
  • ICCF sends the call through the CS domain
  • the MSC paging user UE-A fails or fails to take the roaming number
  • the MSC returns a Release message, and the reason for the failure is carried:
  • the paging fails (the user does not Accessible);
  • the MGCF converts the Release (user inaccessible) into a SIP 503 message and sends it to the ICCF;
  • the ICCF judges that the UE-A is inaccessible according to the received 503 message, and returns a 503 message to the TAS, and the CFNRc service is performed by the TAS.
  • MGCF can also convert Release (unable to users) to other unreachable response messages in SIP, such as: SIP408 message or SIP500 message.
  • ICCF receives 503 message, 408 message or 500 message, then sends 503 message, 408 message or 500 message to TAS; for example: TAS receives 503 message
  • TAS receives 503 message
  • the 408 message or the 500 message, the CFNRc service is executed.
  • Embodiment 3 The third method for providing the CFNRc service, as shown in FIG. 7, includes the following steps: 1 ⁇ 2, the ICCF receives a call directed to the user UE-A;
  • the ICCF sends the call to the MSC through the USSD message.
  • the MSC sends a Paging message to page the user UE-A, and the UE-A does not respond;
  • the MSC returns the user to the ICCF through the USSD message.
  • UE-A does not respond;
  • the ICCF learns that the user UE-A is inaccessible through the USSD response message, returns a 503 message to the TAS, and performs the CFNRc service by the TAS.
  • the ICCF converts the state that is inaccessible to the user into a 503 response message.
  • the ICCF can also convert the state that is inaccessible to the user into an inaccessible response message in other SIPs, such as: 408 message or 500.
  • the message, passed to the TAS, TAS will also execute CFNRc.
  • the service logic corresponding to different response messages, for example: If the ICCF receives the USSD response message, it determines that the user UE-A is inaccessible; for example: TAS receives 503 If the message is 408 or 500, the CFNRc service is executed.
  • Embodiment 4 Mode 4 of providing CFNRc service, as shown in FIG. 8, includes the following steps:
  • ICCF receives a call directed to user UE-A, and starts a timer
  • ICCF sends the call through the CS domain
  • the ICCF still does not receive the call response from the UE-A, and returns a 503 message to the TAS, indicating that the UE-A is inaccessible in the CS domain, and the CFNRc service is performed by the TAS.
  • the ICCF converts the state that is inaccessible to the user into a 503 message.
  • the ICCF can also convert the state that is inaccessible to the user into an inaccessible response message in other SIPs, such as: 408 message or 500 message. , passed to TAS, TAS will also execute CFNRc.
  • the service logic corresponding to different response messages. For example, if the TAS receives the 503 message, the 408 message, or the 500 message, the CFNRc service is executed.
  • the above only takes the ICCF start timer as an example, or it may be the TAS start timer. If the user's response cannot be obtained within a certain time, the CFNRc service is executed.
  • the ICCF may also send a call through the USSD message.
  • the user is aware that the user is performing the CFNRc in the CS domain.
  • the implementation may also need to sense the connection status of the IMS domain.
  • the CFNRc is executed. For example, when the P-CSCF finds that the user cannot report the unreachable status of the user to the ICCF or TAS in time.
  • Embodiment 5 The first method for providing CFNL service, as shown in FIG. 9, includes the following steps: 1.
  • the TAS receives the call directed to the user UE-A, and obtains the connection status of the user UE-A as follows: The CS domain is not registered, and then the CFNL service is executed.
  • the way in which the TAS obtains the connection status of the UE-A is mainly as follows:
  • TAS Under normal circumstances, when receiving a call, TAS has been informed that the user is not registered in the CS domain.
  • TAS to HSS/HLR queries the registration status of the user.
  • Embodiment 6 The second method for providing the CFNL service, as shown in FIG. 10, includes the following steps: 1 ⁇ 2, the ICCF receives a call directed to the user UE-A.
  • the ICCF obtains the connection status of the UE-A as follows: If the CS domain is unregistered, the TAS is notified, and the TAS provides the CFNL service for the UE-A.
  • the way in which the ICCF obtains the connection status of the user UE-A is mainly as follows:
  • ICCF to HSS/HLR queries the registration status of the user.
  • the CFNL is executed only when the user is not registered in the CS domain.
  • the implementation may also require that the user perform the CFNL for the user when the IMS domain is also not registered.
  • the ICCF or TAS user knows whether the user is registered in the IMS domain and can obtain the registration status of the user's IMS domain through third-party registration.
  • Embodiment 7 is the first way for the CF Ry service, as shown in Figure 11, including the following steps:
  • ICCF receives a call directed to user UE-A
  • the MSC After receiving the Alerting message, the MSC sends an ACM message (Address Complete Message) to the MGCF;
  • the MGCF converts the ACM message sent by the MSC into a 180 message (ringing response message) and sends it to the ICCF.
  • the ICCF forwards the 180 message (ringing response message) to the TAS; after receiving the 180 message (ringing response message), the TAS starts the timer; when no further response of the UE-A is received at the specified time, Perform CFNRy business.
  • the time setting of the above timer is the same as the time setting of the user in the CS domain for the consistency of the user's service experience.
  • Embodiment 8 The second method of providing the CFNRy service, as shown in FIG. 12, includes the following steps:
  • ICCF receives a call directed to user UE-A
  • the MSC After receiving the Alerting message, the MSC sends an ACM message to the MGCF.
  • the MGCF converts the ACM message sent by the MSC into a 180 message (ringing response message) and sends it to the ICCF;
  • the ICCF forwards the 180 message (ringing response message) to the TAS; the TAS receives the 180 message (ringing response message);
  • the MSC Since the user UE-A does not answer, the MSC returns a Release message, and carries the failure reason #19, that is, the user UE-A does not respond;
  • the MGCF converts the Release message into a SIP 480 message (temporary unavailable response message) and sends it to the ICCF;
  • the ICCF forwards the 480 message (temporary unavailable response message) to the TAS; the TAS receives the 180 message (ringing response message), and receives the 480 message (temporary unavailable response message) to determine that the user UE-A has no Answer, thus providing CFNRy service to user UE-A.
  • the service logic corresponding to different response messages is preset. For example: When the MGCF receives the Release message, it converts the Release message into a SIP 480 message (temporary unavailable response message) and sends it to the ICCF; for example: TAS Upon receiving the 180 message (ringing response message) and receiving the 480 message (temporary unavailable response message), the CFNRy service is provided.
  • the MGCF can also convert the Release message to other SIP user no response messages. It is used to indicate that the user is "no answer", and the TAS judges that the user is unanswered according to the converted message, thereby providing the user with the CFNRy service.
  • Embodiment 9 is the third way for the CFNRy service, as shown in Figure 13, including the following steps:
  • ICCF receives a call directed to user UE-A
  • the MSC After receiving the Alerting message, the MSC sends an ACM message to the MGCF.
  • the MGCF converts the ACM message sent by the MSC into a 180 message (ringing response message) and sends it to the ICCF;
  • the ICCF forwards the 180 message (ringing response message) to the TAS; the TAS receives the 180 message (ringing response message);
  • the MSC Since the user UE-A does not answer, the MSC returns a Release message, and carries the failure reason #19, that is, the user UE-A does not respond;
  • the MGCF converts the Release message into a SIP 480 message (temporary unavailable response message) and sends it to the ICCF;
  • the ICCF forwards the 480 message (temporary unavailable response message) to the TAS;
  • the MSC perceives that the user is unresponsive, and enhances the customized application of the mobile network through the mobile network (Customized Applications for Mobile network Enhanced Logic)
  • CAMEL reports the user's unanswered information to the ICCF;
  • the VMSC is the Visited Mobile Switching Center;
  • the ICCF notifies the user of the non-response information, and notifies the TAS of the information, and the TAS executes CFNRy.
  • the ICCF may directly notify the TAS according to the direct information that is not available to the user reported by the CAMEL, and the user may not be able to access the response message according to the call response message and the CAMEL.
  • the Service Control Point (SCP) and ICCF in the figure can be deployed in the same physical entity or separately. When deployed together, the information is exchanged through the internal interface; when deployed separately, the information can be exchanged through existing protocols such as CAP, MAP, SIP, and the private interface.
  • Embodiment 10 A method for providing a CFB service, as shown in FIG. 14, includes the following steps:
  • ICCF receives a call directed to user UE-A
  • ICCF sends the call through the CS domain
  • the MSC determines that the user already has a session, and then returns a Release (#17) message indicating that the user is busy;
  • the MGCF converts the Release (#17) message into a 486 message and sends it to the ICCF.
  • the ICCF senses that the user UE-A is busy according to the received 486 message, returns a 486 message to the TAS, and performs the CFB service by the TAS.
  • the service logic corresponding to different response messages is preset. For example: When the MGCF receives the Release (#17) message, it converts the Release message into a SIP 486 message and sends it to the ICCF. For example: TAS receives 486. The message then executes the CFB service.
  • Embodiment 11 The second method for providing CFB service, as shown in FIG. 15, includes the following steps:
  • ICCF receives a call to the user UE-A
  • ICCF sends the call through the CS domain
  • the MGCF converts the Release (#17) message into a 486 message and sends it to the ICCF.
  • the ICCF senses that the user UE-A is busy according to the received 486 message, returns a 486 message to the TAS, and performs the CFB service by the TAS.
  • the service logic corresponding to different response messages is preset. For example: When the MGCF receives the Release (#17) message, it converts the Release message into a SIP 486 message and sends it to the ICCF. For example: TAS receives 486. The message then executes the CFB service.
  • Embodiment 12 The third method for providing CFB service, as shown in FIG. 16, includes the following steps: 1 ⁇ 2, the ICCF receives a call directed to the user UE-A;
  • the ICCF notifies the user UE-A through the USSD message that it has a new call
  • the ICCF learns that the user UE-A is busy according to the busy status of the user returned by the USSD message, and therefore returns a 486 message to the TAS, indicating that the user UE-A is busy, and the CFB service is performed by the TAS.
  • the user may also notify the ICCF through other IMS CS Control Protocol (IMS) messages, such as SMS, DTMF, and SIP messages.
  • IMS IMS CS Control Protocol
  • Embodiment 13 Mode 4 of providing CFB service, as shown in FIG. 17, includes the following steps: 1 ⁇ 2, ICCF receives a call directed to user UE-A;
  • the ICCF judges that the user UE-A already has a session and is in a busy state (all the user's sessions will pass through the ICCF, so the ICCF can know that the user already has a session); therefore, the TAS returns a 486 message, and the TAS is the user UE.
  • -A provides CFB services.
  • Embodiment 14 Method 5 of providing CFB service, as shown in FIG. 18, includes the following steps:
  • the TAS receives a call directed to the user UE-A, and determines that the user UE-A already has a session (if the user subscribes to the CFB service, all sessions of the user pass through the TAS, so the TAS knows that the user has a session); It is determined that the user UE-A is in a busy state, and the CFB service is directly provided to the user UE-A.
  • Embodiment 15 Method 6 of providing CFB service, as shown in FIG. 19, includes the following steps:
  • ICCF receives a call to the user UE-A
  • ICCF sends the call through the CS domain
  • the user UE-A cannot answer the call, and the user UE-A returns the information that the user is busy, so UE-A returns Release (#17) Message, used to indicate that the user is busy;
  • the mobile switching center determines that the user is busy, triggers the CAMEL to report the busy information of the user to the ICCF;
  • the ICCF learns that the user is busy returning 486 to the TAS, indicating that the user is busy.
  • the TAS performs the CFB service.
  • the above ICCF may return 186 to the TAS according to the busy information reported by the CAMEL, indicating that the user is busy, or may wait for the response of the call to jointly determine the busy information of the user through the call response and the information on the CAMEL.
  • the busy information reported by the MSC may be that the user determined by the MSC is busy, that is, NDUB; or the user may decide to be busy, that is, UDUB.
  • the S C P and I C C F in the figure can be deployed in the same physical entity or separately. When deployed together, information is exchanged through internal interfaces; when deployed separately, information can be exchanged through existing protocols such as CAP, MAP, SIP, and private interfaces.
  • Embodiment 16 The first method of providing CD service, as shown in FIG. 20, includes the following steps:
  • ICCF receives a call directed to user UE-A
  • ICCF sends the call through the CS domain
  • the user UE-A requests to perform the CD service, and notifies the ICCF through the USSD message, where the USSD message carries the number that the user UE-A requests to connect to;
  • the ICCF determines, according to the received USSD message, that the user UE-A is to perform the CD service, and therefore converts the USSD message into a 302 message (the 302 message carries the number that the user UE-A requests to connect to) and sends it to the TAS.
  • the CD service is performed by the TAS for the user UE-A.
  • the user may also return to the user to request CD services through other ICCP messages, such as SMS, DTMF, SIP messages.
  • ICCP messages such as SMS, DTMF, SIP messages.
  • the service logic corresponding to different response messages is preset in advance. For example, if the TAS receives the 302 message, the CD service is executed.
  • Embodiment 17 When a call initiated by a user accessing a CS domain is transferred by a call, a process 1 of the call forwarding notification message, as shown in FIG. 21, includes the following steps: 1 ⁇ 2, the user UE-A initiates a request to establish a call;
  • the user UE-A Since the call of the user UE-A is forwarded by the opposite end, the user UE-A returns a 181 message (SIP call transfer notification message), indicating that the call is forwarded;
  • the ICCF converts the 181 message (SIP Call Transfer Notification Message) into a USSD message, notifying the user that the UE-A call is forwarded.
  • ICCF may also notify users through other ICCP messages such as SMS, DTMF, and SIP.
  • Embodiment 18 When a call initiated by a user accessing from a CS domain is transferred by a call, a process of transmitting a call forwarding notification message 2, as shown in FIG. 22, includes the following steps:
  • User UE-A initiates a request to establish a call
  • the user UE-A Since the call of the user UE-A is forwarded by the opposite end, the user UE-A returns a 181 message (SIP call transfer notification message), indicating that the call is forwarded;
  • the ICCF sends a 181 message (SIP call transfer notification message) to the MGCF;
  • the MGCF converts the 181 message (SIP call transfer notification message) into a CPG message, notifying the user that the UE-A call is forwarded.
  • the MGCF may also convert the 181 message (SIP Call Transfer Notification Message) into another notification message.
  • Embodiment 19 User UE-A accessing from the CS domain, whose CFU service is in an active state, and the network notifying the user UE-A that its CFU service is in an active state 3, as shown in FIG. 23, includes the following steps:
  • User UE-A initiates a request to establish a call
  • the TAS returns a message to the UE-A, indicating that the CFU service of the UE-A is in the active state.
  • the ICCF After receiving the message sent by the TAS to the UE-A, the ICCF informs the user through the USSD message that the CFU service is in the active state.
  • ICCF may also pass other ICCP messages, such as: SMS, DTMF, SIP Notify the user.
  • Embodiment 20 When a call directed to a user accessing from the CS domain is transferred by a call, the user is notified that there is a process in which the session is forwarded. Referring to FIG. 24, the following steps are included:
  • the TAS receives a call directed to the user UE-A;
  • the TAS performs the CFU service, and forwards the call; and informs the user through the Message message that the UE-A has a call directed to the UE-A to be forwarded;
  • the ICCF After receiving the Message message sent by the TAS to the UE-A, the ICCF informs the user through the USSD message that the UE-A has a call directed to the UE-A.
  • ICCF may also notify users through other ICCP messages such as SMS, DTMF, and SIP.
  • the embodiment of the present invention provides a method for transmitting a call forwarding notification message, as shown in FIG. Includes the following main steps:
  • a call initiated by a user accessing from the CS domain, or a call directed to a user accessing from the CS domain is called a call.
  • the IMS network entity receives a call transfer notification message of the IMS domain.
  • the call directed to the user accessing from the CS domain is called, and the user is notified of one of the following:
  • Method 81 The IMS network entity converts the received SIP Message message carrying the call transfer information into an ICCP message carrying the call transfer information, and sends the message to the user.
  • the call initiated by the user accessing the cs domain is called by the call, and the manner of notifying the user is one of the following:
  • Method 91 The IMS network entity converts the received 181 notification message (SIP call forwarding notification message) into an ICCP message carrying the call forwarding information, and sends the message to the user;
  • the mode 920 the IMS network entity forwards the received 181 notification message (SIP call transfer notification message) to the MGCF; the MGCF converts the 181 notification message (SIP call transfer notification message) into a CS domain message carrying the call forwarding information, and Send to the user;
  • SIP call transfer notification message SIP call transfer notification message
  • Mode 93 The IMS network entity converts the received SIP Message carrying the call forwarding service to an active state, and sends an ICCP message with the call forwarding service in an active state, and sends the message to the user.
  • the method and device for providing a call forwarding service for a user in the embodiment of the present invention, after the IMS network entity receives a call directed to a user accessing the CS domain, obtains the connection state or user will of the current session of the user. Therefore, the call forwarding service can be provided for the called user accessing from the CS domain according to the obtained connection state or the user's will.
  • embodiments of the present invention provide several implementations for various call forwarding services, which better support the present invention.
  • the method for transmitting a call forwarding notification message after the call initiated by the user accessing the CS domain or the call directed to the user accessing the CS domain is transferred, the IMS network entity receives the IMS domain. Call forwarding notification message; the IMS network entity itself or notifying other network elements to convert the call forwarding notification message of the IMS domain into a message satisfying the receiving capability of the CS domain access user, and connecting the converted message to the CS domain The incoming user sends it. This enables call forwarding notifications to access users from the CS domain.
  • the spirit and scope of the invention Thus, it is intended that the present invention cover the modifications and modifications of the invention

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

为用户提供呼叫转移业务的方法及装置
技术领域
本发明涉及通信领域， 特别是涉及为用户提供呼叫转移业务的方法及 装置， 以及传递呼叫转移通知消息的方法。 背景技术
一、 IP多媒体子系统 IMS介绍：
IP多媒体子系统 IMS (IP Multimedia Subsystem)是移动交换网络中的 叠加在已有分组交换域（PS )之上的一个子系统， 采用分组交换域为其上 层控制信令和媒体传输的 7 载通道， 引入会话启动协议 SIP(Session Inition Protocol)协议作为业务控制协议， 利用 SIP筒单、 易扩展、 媒体组合方便 的特点， 通过将业务控制与承载控制分离， 提供丰富的多媒体业务。 IMS 中主要的功能实体包括控制用户注册、 会话控制等功能的呼叫会话控制功 能 CSCF(Call Session Control Function), 提供各种业务逻辑控制功能的应 用服务器 AS(Application Server), 集中管理用户签约数据的归属签约用户 服务器 HSS(Home Subscriber Server) , 以及用于实现与电路交换网互通的
IM-MGW(IMS-Media Gateway Function)„ 用户通过当前所在地代理节点 P-CSCF(Proxy-CSCF)接入 IMS , 会话和业务触发控制及与 AS的业务控制 交互则由其注册地的归属域服务节点 S-CSCF(Service-CSCF)完成。
IMS是第三代合作伙伴计划 3GPP(3rd Generation Partnership Project)和 高级互联电信和互联网的集中业务和协议 Tispan(Telecommunications and InternetConverged Services and Protocols for Advanced Networking)的描述, 在 3GPP2(3rd Generation Partnership Project 2)中也有一个类似的多媒体子 系统称为 MMD ( Multimedia Domain, 多媒体域） ， 其和 IMS的结构类似， 所以下文为了筒便起见， 就都是以 IMS描述， 但是^艮明显下文描述的方法 同样也适用于 MMD。
二、 集中业务控制 ICS介绍：
在网络向 IMS 演变过程中， 将会出现一段时间电路域 （ Circuit Switched, 筒称 CS ) 、 IMS并存的情况。 此时， 运营商希望网络中有一个 控制点能够对两个域的业务进行集中控制， 以便减少部署和管理的成本以 及提供一致的业务体验， 这个集中控制的点一般都处于 IMS网络， 由 AS 来实现。 也就是当用户通过 CS网络接入的时候， 同样在 IMS网络为其提 供业务。 其中， 目前提出的一种集中业务控制 ICS ( IMS Centralized Service ) 的架构， 参见图 1所示：
其中，呼叫会话控制功能实体 CSCF的功能与上述相同。 当用户在 CS 发起或接收呼叫时， 呼叫将被控制路由到其归属的 IMS 网络， 在 IMS域 为用户提供业务。 同时， 为了实现业务控制过程中用户与 IMS网络业务控 制实体的交互， 在 IMS网络增加了一个新的实体 ICCF ( IMS CS Control Function, 筒称 IMS电路控制功能实体） ， 该实体完成了 UE通过 CS域 接入到 IMS网络的适配控制功能。
ICS UE和 ICCF之间的接口 Ix又称为 ICCC( IMS CS Control Channel, IMS电路域控制信道） ， 根据不同的网络接入环境可能是不同的协议， 统 称为 ICCP, 比如在图 1中仅存在 CS连接的时候， 接口 Ix是 UE和 ICCF 之间的非结构化补充业务数据 ( Unstructured Supplementary Service Data , 筒称 USSD )接口、 SMS接口或者 DTMF接口； 当在 PS连接的情况下， 它是 UE和 ICCF之间的 SIP协议。
发明人在发明过程中发现， 目前在 ICS架构中， 被叫用户从 CS域接 入， 在 IMS域不能为该用户提供呼叫转移业务。 而且未提供对从 CS域接 入用户的呼叫转移通知方案。 发明内容
本发明实施例提供了为用户提供呼叫转移业务的方法及装置， 实现了 在 IMS域为从 CS域接入的被叫用户提供呼叫转移业务。
本发明实施例还提供了一种传递呼叫转移通知消息的方法， 以实现对 从 CS域接入用户的呼叫转移通知。
本发明实施例的一种为用户提供呼叫转移业务的方法， 包括下列步 骤： IMS网络实体收到指向从 CS域接入的用户的呼叫； IMS网络实体获 得该用户当前的会话接续状态和 /或用户意愿；以及根据所述获得的会话接 续状态和 /或用户意愿， 提供呼叫转移业务。
本发明实施例的一种 IMS网络实体， 包括： 接收单元， 用于接收指向 从 CS域接入的用户的呼叫； 获得单元， 用于在接收单元收到所述呼叫后， 获得该用户当前的会话接续状态和 /或用户意愿。
本发明实施例的一种媒体网关控制功能实体， 包括： 第一转换单元， 用于将 181通知消息 （SIP呼叫转移通知消息） 转换为携带有呼叫转移信 息的 CS 域消息； 和 /或第二转换单元， 用于将携带有用户不可及信息的 CS域消息转换为 SIP中的不可及响应消息； 和 /或第三转换单元， 用于将 携带有用户无应答信息的 CS域消息转换为 SIP中的无应答响应消息。
本发明实施例的一种传递呼叫转移通知消息的方法， 包括下列步骤： 从 CS域接入的用户发起的呼叫， 或指向从 CS域接入的用户的呼叫被呼 叫转移； IMS网络实体收到呼叫转移通知消息； 将 IMS域的呼叫转移通知 消息转换为满足 CS域接入用户的接收能力的消息； 以及将转换后的消息 向所述从 CS域接入的用户发送。
本发明实施例的为用户提供呼叫转移业务的方法及装置，由 IMS网络 实体收到指向从 CS域接入的用户的呼叫后， 获得该用户当前的接续状态 和 /或用户意愿， 从而可根据获得的接续状态或用户意愿为从 CS域接入的 被叫用户提供呼叫转移业务。 本发明实施例的传递呼叫转移通知消息的方法， 由于从 CS域接入的 用户发起的呼叫， 或指向从 CS域接入的用户的呼叫被呼叫转移后， IMS 网络实体会收到 IMS域的呼叫转移通知消息； IMS网络实体自身或指示其 它网元将该 IMS域的呼叫转移通知消息转换为满足 CS域接入用户的接收 能力的消息， 并将转换后的消息向所述从 CS域接入的用户发送。 从而实 现了对从 CS域接入用户的呼叫转移通知。 附图说明
图 1为现有集中业务控制 ICS架构示意图；
图 2 为本发明实施例的为用户提供呼叫转移业务的方法的步骤流程 图；
图 3为本发明实施例的 IMS网络实体示意图；
图 4为本发明实施例的另一种 IMS网络实体示意图；
图 5为本发明实施例 1的流程图；
图 6为本发明实施例 2的流程图；
图 7为本发明实施例 3的流程图；
图 8为本发明实施例 4的流程图；
图 9为本发明实施例 5的流程图；
图 10为本发明实施例 6的流程图；
图 11为本发明实施例 7的流程图；
图 12为本发明实施例 8的流程图；
图 13为本发明实施例 9的流程图；
图 14为本发明实施例 10的流程图；
图 15为本发明实施例 11的流程图；
图 16为本发明实施例 12的流程图；
图 17为本发明实施例 13的流程图； 图 18为本发明实施例 14的流程图；
图 19为本发明实施例 15的流程图；
图 20为本发明实施例 16的流程图；
图 21为本发明实施例 17的流程图；
图 22为本发明实施例 18的流程图；
图 23为本发明实施例 19的流程图；
图 24为本发明实施例 20的流程图；
图 25为本发明实施例的传递呼叫转移通知消息的方法的步骤流程图。 具体实施方式
呼叫转移业务能够使被叫用户将一个呼叫转移到另外的一个号码或 者用户的语音信箱中， 主要的包含以下几种形式：
无条件呼叫前转（ Call Forwarding Unconditional, 筒称 CFU ) 业务： 这项业务允许用户将他的所有来话转接到预先设置的另一个电话号码上 或用户的语音信箱中。
遇忙呼叫前转（ Call Forwarding Busy, 筒称 CFB )业务： 当用户忙时， 这项业务允许用户将它的来话转接到预先设置的另一个电话号码上或用 户的语音信箱中。 所述 "用户忙" 包含两种情况， 即网络判断的用户忙或 者是用户自己决定的忙。
无应答呼叫前转（ Call Forwarding on No Reply, 筒称 CFNRy ) 业务： 当用户不能或者不愿意接听电话的时候， 这项业务使得用户能将呼叫转移 到一个预先设定的号码或者用户的语音信箱中。
无法到达呼叫前转 ( Call Forwarding on Mobile Subscriber Not Reachable , 筒称 CFNRc ) 业务： 当由于某些原因呼叫无法到达用户时， 这项业务使得网络能够自动的将呼叫转移到用户预先设定的一个号码或 者用户的语音信箱中。 未注册前转 ( Communication Forwarding on Not Logged-in , 筒称 CFNL ) 业务： 当用户没有注册到网络的时候， 该业务使得网络能够自动 的将呼叫转移到一个用户预先设定的号码或者用户的语音信箱中。
呼叫偏转 （Call Deflection, 筒称 CD ) 业务： 这项业务使得用户在收 到一个呼叫后， 能够将呼叫临时的转移到另外一个号码上。 本发明实施例提供了一种为用户提供呼叫转移业务的方法， 参见图 2 所示， 包括下列主要步骤：
511、 IMS网络实体收到指向从 CS域接入的用户的呼叫。
512、 IMS网络实体获得该用户当前的会话接续状态和 /或用户意愿。 其中， IMS 网络实体通过下述方式之一获得会话接续状态或用户意 愿：
方式 a、 CS域网络实体或用户的 UE主动上报会话接续状态或用户意 愿； IMS网络实体根据收到的上报的信息获得用户的会话接续状态或用户
方式 b、 IMS网络实体与保存有会话接续状态或用户意愿的相关网元 交互或查询该 IMS网络实体， 获知已有会话的信息，根据获知的信息进一 步获得会话接续状态或用户意愿。
513、 根据所述获得的会话接续状态和 /或用户意愿， 提供呼叫转移业 务。
其中， 会话的接续状态主要是指会话是否能够到达用户的终端， 以及 用户是否接通会话，利用会话的接续状态可以为用户提供 CFNRc, CFNRy 业务；而在为用户提供 CFB和 CD业务的时候可能既要用到用户的意愿也 要使用到会话的接续状态， 当用户忙不想接通会话而想要执行 CFB (用户 决定忙） 的时候， 或者用户想要执行 CD业务的时候， 终端就会给网络返 回用户忙或者是用户要执行 CD。 所述 IMS网络实体为提供呼叫转移业务 的应用服务器，则该 IMS网络实体根据获得的用户当前的会话接续状态或 用户意愿， 直接为该用户提供相应的呼叫转移业务； 所述 IMS网络实体不 为提供呼叫转移业务的应用服务器，则该 IMS网络实体根据获得的用户当 前会话的接续状态或用户意愿， 把会话当前的接续状态或用户意愿通知到 为用户提供呼叫转移业务的应用服务器， 由提供呼叫转移业务的应用服务 器为用户提供呼叫转移业务。
本发明实施例中还提供了一种 IMS网络实体， 其包括： 接收单元和获 得单元。
接收单元， 用于接收指向从 CS域接入的用户的呼叫；
获得单元， 用于在接收单元收到所述呼叫后， 获得该用户当前的会话 接续状态和 /或用户意愿。具体的， 获得单元通过下述方式之一获得会话接 续状态和 /或用户意愿：
方式 a、 CS域网络实体或用户的 UE主动上报会话接续状态或用户意 愿； 获得单元根据收到的上报的信息获得用户的会话接续状态或用户意 愿；
方式 b、 获得单元与保存有会话接续状态或用户意愿的相关网元交互 或查询该 IMS网络实体， 获知已有会话的信息，根据获知的信息进一步获 得会话接续状态或用户意愿。
基于上述 IMS网络实体的实施例， 若该 IMS网络实体为 IMS电路控 制功能实体 ICCF, 则参见图 3所示， 还包括： 通知单元， 用于根据获得 单元获得的会话接续状态和 /或用户意愿，通知为用户提供呼叫转移业务的 应用服务器该会话接续状态或用户意愿。 进一步， 还可包括： 转换单元， 用于将收到的 IMS域呼叫转移通知消息转换为满足 CS域接入用户的接收 能力的消息； 发送单元， 用于将转换单元转换后的消息向所述从 CS域接 入的用户发送。
基于上述 IMS 网络实体的实施例， 若该 IMS 网络实体为电信业务应 用服务器 TAS , 则参见图 4所示， 还包括： 执行单元， 用于根据获得单元 获得的会话接续状态和 /或用户意愿，为该用户提供呼叫转移业务。进一步， 还可包括： 转换单元， 用于将收到的 IMS域呼叫转移通知消息转换为满足 CS 域接入用户的接收能力的消息； 发送单元， 用于将转换单元转换后的 消息向所述从 CS域接入的用户发送。 本实施例中， 通知单元将会话接续 状态和 /或用户意愿通知给执行单元。
为了支撑本发明实施例，还提供了一种媒体网关控制功能实体， 包括： 第一转换单元， 和 /或第二转换单元， 和 /或第三转换单元。
第一转换单元，用于将 SIP 呼叫转移通知消息转换为携带有呼叫转移 信息的 CS域消息， 例如： 呼叫进展（Call Progress, 筒称 CPG ) 消息； 通过该通知消息， 用户获得了会话的状态， 增强了用户的体验。
第二转换单元，用于将携带有用户不可及信息的 CS域消息转换为 SIP 不可及响应消息 （例如： 503响应消息、 408响应消息或 500响应消息 ) 。
通过消息转换， IMS网络实体获得了会话的接续状态为用户不可及， 这样就能够根据会话的状态， 为用户提供 CFNRc业务。
第三转换单元，用于将携带有用户无应答信息的 CS域消息转换为 SIP 中的无应答响应消息。
通过消息转换， IMS网络实体获得了会话的接续状态为用户无应答， 这样就能够根据会话的状态， 为用户提供 CFNRy业务。
以下通过 20个实施例具体描述。 下述的实施例只是以 ICCF与 TAS 分设的情况下为例，描述了为用户提供呼叫转移业务的过程，也可能 ICCF 和 TAS合设， 这样可通过他们之间的内部消息交互。 下述实施例， 只是 以用户在 CS域的信令是 ISUP为例进行说明，用户在 CS域的信令也可能 是 BICC等其它的信令。
实施例 1 :提供 CFNRc业务的方式一，参见图 5所示， 包括下列步骤： 1~2、 ICCF收到一个指向用户 UE-A的呼叫； 其中 IAM为初始地址消 息 ( Initial Address Message ) ； 3~4、 ICCF通过 CS域下发该呼叫；
5、 移动交换中心 MSC寻呼用户 UE-A失败或者是取漫游号码失败；
6、 MSC返回 Release消息， 其中携带失败原因： 寻呼失败（用户不 可及） ；
7、 媒体网关控制功能实体 MGCF将该 Release消息 （用户不可及） 转换为 SIP 480消息 （临时不可用响应消息） ， 并向 ICCF发送；
8、 ICCF根据之前没有收到 180消息 （振铃响应消息） ， 此时收到了 480消息 （临时不可用响应消息） ， 感知到用户 UE-A是 "不可及的" ； 因此 ICCF 向 TAS 返回 503 消息， 以告知电信业务应用服务器 TAS
( telephony application service )用户 UE-A "不可及"，由 TAS执行 CFNRc 业务。
【注】 1. 上述只是以 ICCF将用户不可及的状态， 转化为 503消息为 例， ICCF还可以将用户不可及的状态转换为其它 SIP 中的不可及响应消 息， 如： 408消息或者 500消息， 传递到 TAS , TAS同样会执行 CFNRc。
2. 用户不可及可能存在两种情况： 在 MSC去取用户的漫游号码时， 未取到， 则判定该用户是不可及， 并用 # 20表示； 在 MSC寻呼用户时， 该用户未响应， 则判定该用户不可及， 并用 # 18表示。
3. 预先设定不同的响应消息分别对应的业务逻辑， 例如： ICCF没有 收到 SIP 180消息 （振铃响应消息） 且却收到了 480消息 （临时不可用响 应消息） ， 则感知到用户是 "不可及的" ； 又例如： TAS收到 503消息、 408消息或者 500消息， 则执行 CFNRc业务。
实施例 2:提供 CFNRc业务的方式二，参见图 6所示， 包括下列步骤： 1~2、 ICCF收到一个指向用户 UE-A的呼叫；
3~4、 ICCF通过 CS域下发该呼叫；
5、 MSC寻呼用户 UE-A失败或者是取漫游号码失败；
6、 MSC返回 Release消息， 其中携带失败原因： 寻呼失败（用户不 可及） ；
7、 MGCF将 Release (用户不可及）转换为 SIP 503消息， 并向 ICCF 发送；
8、 ICCF根据收到的 503消息， 判断用户 UE-A是不可及的， 并且给 TAS返回 503消息， 由 TAS执行 CFNRc业务。
【注】 1. MGCF也可将 Release (用户不可及） 转换为其它 SIP中的 不可及响应消息， 如： SIP408消息或 SIP500消息。
2. 用户不可及可能存在两种情况： 在 MSC去取用户的漫游号码时， 未取到， 则判定该用户是不可及， 并用 # 20表示； 在 MSC寻呼用户时， 该用户未响应， 则判定该用户不可及， 并用 # 18表示。
3. 预先设定不同的响应消息分别对应的业务逻辑， 例如： ICCF收到 503消息、 408消息或者 500消息， 则向 TAS发送 503消息、 408消息或 者 500消息; 又例如： TAS收到 503消息、 408消息或者 500消息， 则执 行 CFNRc业务。
实施例 3:提供 CFNRc业务的方式三，参见图 7所示， 包括下列步骤： 1~2、 ICCF收到一个指向用户 UE-A的呼叫；
3、 ICCF通过 USSD消息， 将该呼叫下发到 MSC;
4、 MSC发送 Paging消息寻呼用户 UE-A, 用户 UE-A没有响应；
5、 MSC通过 USSD消息向 ICCF返回用户 UE-A没有响应；
6、 ICCF通过 USSD响应消息得知用户 UE-A是不可及的， 给 TAS返 回 503消息， 由 TAS执行 CFNRc业务。
【注】 1. 上述只是以 ICCF将用户不可及的状态， 转化为 503响应消 息为例， ICCF还可以将用户不可及的状态转换为其它 SIP 中的不可及响 应消息，如： 408消息或者 500消息，传递到 TAS , TAS同样会执行 CFNRc。
2. 预先设定不同的响应消息分别对应的业务逻辑， 例如： ICCF收到 USSD响应消息， 则判定用户 UE-A是不可及； 又例如： TAS收到 503消 息、 408消息或者 500消息， 则执行 CFNRc业务。
3. 也可由 ICCF发出的 USSD消息传输路径中任一 CS域网元， 如： HLR返回用户 UE-A不可及。
实施例 4:提供 CFNRc业务的方式四，参见图 8所示， 包括下列步骤：
1~2、 ICCF收到一个指向用户 UE-A的呼叫， 并且启动定时器；
3~4、 ICCF通过 CS域下发该呼叫；
5、定时器超时， ICCF仍然没有收到用户 UE-A的呼叫响应，则向 TAS 返回 503消息， 表示用户 UE-A在 CS域是不可及的， 由 TAS执行 CFNRc 业务。
【注】 1. 上述只是以 ICCF将用户不可及的状态， 转化为 503消息为 例， ICCF还可以将用户不可及的状态转换为其它 SIP 中的不可及响应消 息， 如： 408消息或者 500消息， 传递到 TAS , TAS同样会执行 CFNRc。
2. 预先设定不同的响应消息分别对应的业务逻辑， 例如： TAS 收到 503消息、 408消息或者 500消息， 则执行 CFNRc业务。
3. 上述只是以 ICCF启动定时器为例， 也可能是 TAS启动定时器， 在特定的时间内不能得到用户的响应， 则执行 CFNRc业务。
4. 这儿只是以通过 ISUP信令下发呼叫为例， 实施上 ICCF也可能通 过 USSD消息下发呼叫。
上述 CFNRc的实施例中只是以用户感知了用户在 CS域不可及就执行 CFNRc为例， 实施上也可能还需要感知 IMS域的接续状态， 当发现两个 域都是不可及时， 再执行 CFNRc。 比如， 当 P-CSCF发现用户不可及时上 报该用户的不可及的状态到 ICCF或者 TAS。
在上述的 CFNRc 的业务中， 只是描述了尝试一个用户的终端不可及 后就执行 CFNRc,实施上也可能把用户其余的终端都尝试为不可及后再执 行 CFNRc。
实施例 5: 提供 CFNL业务的方式一， 参见图 9所示， 包括下列步骤： 1、 TAS 收到了指向用户 UE-A的呼叫， 并且获得用户 UE-A的接续 状态为： 在 CS域未注册， 于是执行 CFNL业务。
其中， TAS获得用户 UE-A的接续状态的方式主要的有以下几种：
1、 正常情况下， 在收到呼叫的时候 TAS 已经获知了用户在 CS域是 未注册的。
2、 TAS到 HSS/HLR查询用户的注册状态。
实施例 6:提供 CFNL业务的方式二，参见图 10所示， 包括下列步骤： 1~2、 ICCF收到一个指向用户 UE-A的呼叫。
3、 ICCF获得用户 UE-A的接续状态为： 在 CS域是未注册的， 则通 知 TAS , 由 TAS为用户 UE-A提供 CFNL业务。
其中， ICCF获得用户 UE-A的接续状态的方式主要的有以下几种：
1、 正常情况下， 在收到的呼叫的时候 ICCF已经获知了用户在 CS域 是未注册的。
2、 ICCF到 HSS/HLR查询用户的注册状态。
上述 CFNL的实施例中只是以感知用户在 CS域未注册就执行 CFNL 为例，实施上也可能需要感知用户在 IMS域同样也未注册的时候才为用户 执行 CFNL。而 ICCF或者 TAS用户感知用户在 IMS域是否注册可以通过 第三方注册获取用户的 IMS域的注册状态的。
实施例 7: ·!是供 CF Ry业务的方式一， 参见图 11所示， 包括下列步骤：
1~2、 ICCF收到了指向用户 UE-A的呼叫；
3~5、 ICCF通过 CS下发该呼叫；
6、 UE-A返回 Alerting消息；
7、 MSC在收到 Alerting消息后， 发送 ACM消息 （ Address Complete Message , 地址全消息） 到 MGCF;
8、 MGCF将 MSC发来的 ACM消息转换为 180消息（振铃响应消息 ), 向 ICCF发送； 9、 ICCF向 TAS转发该 180消息 （振铃响应消息） ； TAS收到 180 消息 （振铃响应消息）后， 启动定时器； 当在规定的时间没有收到 UE-A 的进一步的响应， 则执行 CFNRy业务。
上述定时器的时间设置为了用户业务感受的一致性， 可以和用户在 CS域的时间设置是相同的。
实施例 8: 提供 CFNRy业务的方式二， 参见图 12所示， 包括下列步骤：
1~2、 ICCF收到了指向用户 UE-A的呼叫；
3~5、 ICCF通过 CS下发该呼叫；
6、 UE-A返回 Alerting消息；
7、 MSC在收到 Alerting消息后， 发送 ACM消息到 MGCF;
8、 MGCF把 MSC发来的 ACM消息转换为 180消息（振铃响应消息 ), 向 ICCF发送；
9、 ICCF向 TAS转发该 180消息 （振铃响应消息） ； TAS收到 180 消息 （振铃响应消息） ；
10、 由于用户 UE-A没有应答， MSC返回 Release消息， 并且携带失 败原因 # 19, 即用户 UE-A没有应答；
11、 MGCF将该 Release消息转换为 SIP 480消息 （临时不可用响应 消息 ) , 并向 ICCF发送；
12、 ICCF将该 480消息 （临时不可用响应消息） 转发到 TAS; TAS 根据收到了 180消息 （振铃响应消息） ， 并且收到了 480消息 （临时不可 用响应消息）判断出用户 UE-A无应答， 因此为用户 UE-A提供 CFNRy业务。
注： 预先设定不同的响应消息分别对应的业务逻辑， 例如： MGCF收 到 Release消息， 则将该 Release消息转换为 SIP 480消息 (临时不可用响 应消息） ， 并向 ICCF发送； 又例如： TAS收到了 180消息 （振铃响应消 息）并且收到了 480消息（临时不可用响应消息） ， 则提供 CFNRy业务。
另外， MGCF也可以把 Release消息转换其它 SIP 用户无应答消息， 用来表示用户是 "无应答的" ， 有 TAS 根据转换后的消息判断用户是无 应答的， 从而为用户提供 CFNRy业务。
实施例 9: ·!是供 CFNRy业务的方式三， 参见图 13所示， 包括下列步骤：
1~2、 ICCF收到了指向用户 UE-A的呼叫；
3~5、 ICCF通过 CS下发该呼叫；
6、 UE-A返回 Alerting消息；
7、 MSC在收到 Alerting消息后， 发送 ACM消息到 MGCF;
8、 MGCF把 MSC发来的 ACM消息转换为 180消息（振铃响应消息 ), 向 ICCF发送；
9、 ICCF向 TAS转发该 180消息 （振铃响应消息） ； TAS收到 180 消息 （振铃响应消息） ；
10、 由于用户 UE-A没有应答， MSC返回 Release消息， 并且携带失 败原因 # 19, 即用户 UE-A没有应答；
11、 MGCF将该 Release消息转换为 SIP 480消息 （临时不可用响应 消息 ) , 并向 ICCF发送；
12、 ICCF将该 480消息 （临时不可用响应消息） 转发到 TAS;
13、 MSC感知用户是无应答的，通过移动网络增强逻辑的客户化应用 ( Customized Applications for Mobile network Enhanced Logic， 筒称
CAMEL )上报用户无应答的信息到 ICCF; 其中 VMSC为拜访移动交换中 心 ( Visited Mobile Switching Center ) ；
14、 ICCF根据用户获得用户无应答的信息， 把该信息通知到 TAS , 由 TAS执行 CFNRy。
【注】 ： 上述的 13 , 14步和 10、 11、 12步是任意顺序进行的。
ICCF可能根据直接的根据 CAMEL上报的用户不可及的信息直接通 知 TAS , 用户不可及， 也可能等到用户呼叫响应消息， 根据呼叫响应消息 和 CAMEL共同的判断用户不可及的信息。 图中的业务控制点 （Service Control Point, 筒称 SCP ) 和 ICCF可以 部署在同一个物理实体中， 也可以分开部署。 当部署在一起的时候， 通过 内部接口交互信息； 当分开部署的时候可以通过 CAP、 MAP, SIP等现有 协议以及私有接口交互信息。
实施例 10:提供 CFB业务的方式一，参见图 14所示， 包括下列步骤：
1~2、 ICCF收到一个指向用户 UE-A的呼叫；
3~4、 ICCF通过 CS域下发该呼叫；
5、 MSC判断用户已经存在了会话， 于是返回 Release ( # 17 ) 消息， 表示用户忙；
6、 MGCF将 Release ( # 17 ) 消息转换成 486消息， 发送到 ICCF;
7、 ICCF根据收到的 486消息感知用户 UE-A忙， 给 TAS返回 486消 息， 由 TAS执行 CFB业务。
注： 预先设定不同的响应消息分别对应的业务逻辑， 例如： MGCF收 到 Release ( # 17 ) 消息， 则将该 Release消息转换为 SIP 486消息， 并向 ICCF发送； 又例如： TAS收到了 486消息， 则执行 CFB业务。
实施例 11 :提供 CFB业务的方式二，参见图 15所示， 包括下列步骤：
1~2、 ICCF收到一个指向用户 UE-A的呼叫 ；
3~5、 ICCF通过 CS域下发该呼叫；
6~7、 由于某些原因 （用户不愿意接听该会话） ， 用户返回了用户忙 的信息， 因此 UE-A返回 Release ( # 17 ) 消息， 用来表示用户忙；
8、 MGCF将 Release ( # 17 ) 消息转换成 486消息， 发送到 ICCF;
9、 ICCF根据收到的 486消息感知用户 UE-A忙， 给 TAS返回 486消 息， 由 TAS执行 CFB业务。
注： 预先设定不同的响应消息分别对应的业务逻辑， 例如： MGCF收 到 Release ( # 17 ) 消息， 则将该 Release消息转换为 SIP 486消息， 并向 ICCF发送； 又例如： TAS收到了 486消息， 则执行 CFB业务。 实施例 12:提供 CFB业务的方式三，参见图 16所示， 包括下列步骤： 1~2、 ICCF收到一个指向用户 UE-A的呼叫；
3、 ICCF通过 USSD消息通知用户 UE-A, 其有一个新呼叫；
4、 由于某些原因， 用户不想接通该呼叫， 返回了用户忙的信息， 因 此 UE-A通过 USSD消息返回用户忙状态给 ICCF;
5、 ICCF根据 USSD消息返回的用户忙状态， 得知用户 UE-A忙， 因 此给 TAS返回 486消息，用来表示用户 UE-A忙，由 TAS执行 CFB业务。
注： 1、 预先设定不同的响应消息分别对应的业务逻辑， 例如： TAS 收到了 486消息， 则执行 CFB业务。
2、用户也可能通过其它 IMS CS域控制信令（ IMS CS Control Protocol, 筒称 ICCP ) 消息通知 ICCF, 如： SMS, DTMF, SIP消息。
实施例 13:提供 CFB业务的方式四，参见图 17所示， 包括下列步骤： 1~2、 ICCF收到了一个指向用户 UE-A的呼叫；
3、 ICCF判断用户 UE-A已经存在了一个会话， 处于忙的状态 （用户 所有的会话都会经过 ICCF, 所以 ICCF能够知道用户已经存在了会话） ； 因此给 TAS返回 486消息， 由 TAS为用户 UE-A提供 CFB业务。
实施例 14:提供 CFB业务的方式五，参见图 18所示， 包括下列步骤：
1、 TAS收到了指向用户 UE-A的呼叫， 判断出用户 UE-A 已经存在 了一条会话（如果用户签约了 CFB业务， 用户的所有会话都会经过 TAS , 所以 TAS知道用户存在了会话）； 因此判定用户 UE-A处于忙的状态， 直 接为用户 UE-A提供 CFB业务。
实施例 15:提供 CFB业务的方式六，参见图 19所示， 包括下列步骤：
1~2、 ICCF收到一个指向用户 UE-A的呼叫 ；
3~5、 ICCF通过 CS域下发该呼叫；
6、 由于某些原因 （用户不愿意接听该会话） ， 用户 UE-A 无法接听 该呼叫，用户 UE-A返回了用户忙的信息， 因此 UE-A返回 Release ( # 17 ) 消息， 用来表示用户忙；
7、 移动交换中心判断出用户忙， 触发 CAMEL上报用户忙的信息到 ICCF;
8、 ICCF根据 MSC的上报， 得知用户是忙的给 TAS返回 486, 表示 用户忙。 TAS执行 CFB业务。
【注】上述的 ICCF可能根据 CAMEL上报的用户忙的信息直接给 TAS 返回 186表示用户忙， 也可能等到呼叫的响应后通过呼叫响应和 CAMEL 上才艮的信息共同判断用户忙的信息。
上述 MSC上报的忙的信息， 可以是 MSC决定的用户忙， 即 NDUB; 也可以是用户自己决定的忙， 即 UDUB。
图中的 S C P和 I C C F可以部署在同一个物理实体中，也可以分开部署。 当部署在一起的时候， 通过内部接口交互信息； 当分开部署的时候可以通 过 CAP、 MAP, SIP等现有协议以及私有接口交互信息。
实施例 16: 提供 CD业务的方式一， 参见图 20所示， 包括下列步骤：
1~2、 ICCF收到一个指向用户 UE-A的呼叫；
3~5、 ICCF通过 CS域下发该呼叫；
6. 用户 UE-A要求执行 CD业务， 并通过 USSD消息通知到 ICCF, 该 USSD消息中携带有用户 UE-A要求接续到的号码；
7、 ICCF根据收到的 USSD消息判定用户 UE-A要执行 CD业务， 因 此将该 USSD消息转换为 302消息 （该 302消息中携带有用户 UE-A要求 接续到的号码） ， 并发送到 TAS; 由 TAS为用户 UE-A执行 CD业务。
【注】： 1、 上述第 6步中， 用户也可能通过其它 ICCP消息返回用户 要求执行 CD业务， 如： SMS , DTMF, SIP消息。
2、 预先设定不同的响应消息分别对应的业务逻辑， 例如： TAS 收到 了 302消息， 则执行 CD业务。
实施例 17: 从 CS域接入的用户发起的呼叫被呼叫转移时， 呼叫转移 通知消息的传递流程 1 , 参见图 21所示， 包括下列步骤： 1~2、 用户 UE-A发起一个建立呼叫的请求；
3、 由于用户 UE-A的呼叫被对端前转， 给用户 UE-A返回了 181消息 ( SIP呼叫转移通知消息 ) , 表示呼叫被前转；
4、 ICCF将 181消息 （ SIP呼叫转移通知消息） 转换为 USSD消息， 通知用户 UE-A呼叫被前转。
【注】 ： ICCF也可能通过其它 ICCP 消息， 如： SMS , DTMF, SIP 通知用户。
实施例 18: 从 CS域接入的用户发起的呼叫被呼叫转移时， 呼叫转移 通知消息的传递流程 2, 参见图 22所示， 包括下列步骤：
1~2、 用户 UE-A发起一个建立呼叫的请求；
3、 由于用户 UE-A的呼叫被对端前转， 给用户 UE-A返回了 181消息 ( SIP呼叫转移通知消息 ) , 表示呼叫被前转；
4、 ICCF将 181消息 ( SIP呼叫转移通知消息 )发到 MGCF;
5~6、 MGCF将 181消息（ SIP呼叫转移通知消息）转换成 CPG消息， 通知用户 UE-A呼叫被前转。
注： 这儿只是以 CPG消息为例， MGCF也可能把 181消息（SIP呼叫 转移通知消息） 转换为其它的通知消息。
实施例 19:从 CS域接入的用户 UE-A,其 CFU业务处于激活的状态， 网络通知用户 UE-A其 CFU业务处于激活状态的流程 3 , 参见图 23所示， 包括下列步骤：
1~2、 用户 UE-A发起一个建立呼叫的请求；
3、如果用户 UE-A签约了 CFU业务，并且处于 active状态，那么 TAS 会向用户 UE-A返回 Message消息，说明用户 UE-A的 CFU业务处于 active状态；
4、 ICCF收到 TAS发往用户 UE-A的 Message消息后， 通过 USSD消 息告知用户 UE-A其 CFU业务处于 active状态。
【注】 ： ICCF也可能通过其它 ICCP 消息， 如： SMS , DTMF, SIP 通知用户。
这里只是以 CFU 业务为例， 其它的呼叫转移业务也可以利用同样的 通知方式。
实施例 20: 指向从 CS域接入的用户的呼叫被呼叫转移时， 通知用户 其有会话被前转的流程， 参见图 24所示， 包括下列步骤：
1、 TAS收到一个指向用户 UE-A的呼叫；
2、由于用户 UE-A签约了 CFU业务，并且处于 active状态，于是 TAS 执行 CFU业务，将该呼叫前转； 并且通过 Message消息通知用户 UE-A有 一个指向 UE- A的呼叫被前转；
3、 ICCF收到 TAS发往用户 UE-A的 Message消息后， 通过 USSD消 息告知用户 UE-A有一个指向 UE-A的呼叫被前转。
【注】 ： ICCF也可能通过其它 ICCP 消息， 如： SMS , DTMF, SIP 通知用户。
为了实现对从 CS域接入用户的呼叫转移通知， 从而为从 CS域接入 用户提供更好的体验， 本发明实施例提供了一种传递呼叫转移通知消息的 方法， 参见图 25所示， 包括下列主要步骤：
S21、 从 CS域接入的用户发起的呼叫， 或指向从 CS域接入的用户的 呼叫被呼叫转移。
S22、 IMS网络实体收到 IMS域的呼叫转移通知消息。
523、 将该 IMS域的呼叫转移通知消息转换为满足 CS域接入用户的 接收能力的消息。
524、 将转换后的消息向所述从 CS域接入的用户发送。
其中， 指向从 CS域接入的用户的呼叫被呼叫转移， 通知该用户的方 式为下列之一：
方式 81、IMS网络实体将收到的携带有呼叫被转移信息的 SIP Message 消息转换为携带有呼叫被转移信息的 ICCP消息， 并向该用户发送。 其中， 从 cs域接入的用户发起的呼叫被呼叫转移， 通知该用户的方 式为下列之一：
方式 91、 IMS网络实体将收到的 181通知消息（SIP呼叫转移通知消 息） 转换为携带有呼叫转移信息的 ICCP消息， 并向该用户发送；
方式 92、 IMS网络实体将收到的 181通知消息（SIP呼叫转移通知消 息） 转发到 MGCF; MGCF将该 181通知消息 （ SIP呼叫转移通知消息） 转换为携带有呼叫转移信息的 CS域消息， 并向该用户发送；
方式 93、 IMS网络实体将收到的携带有其呼叫转移业务处于激活状态 的 SIP Message消息转换为携带有其呼叫转移业务处于激活状态的 ICCP 消息， 并向该用户发送。
综上所述， 本发明实施例的为用户提供呼叫转移业务的方法及装置， 由于 IMS网络实体收到指向从 CS域接入的用户的呼叫后， 获得该用户当 前会话的接续状态或用户意愿， 从而可根据获得的接续状态或用户意愿为 从 CS域接入的被叫用户提供呼叫转移业务。
进一步， 本发明实施例还针对各种呼叫转移业务分别提供了若干种实 施方案， 更好的支撑了本发明。
本发明实施例的传递呼叫转移通知消息的方法， 由于从 CS域接入的 用户发起的呼叫， 或指向从 CS域接入的用户的呼叫被呼叫转移后， IMS 网络实体会收到 IMS域的呼叫转移通知消息； IMS网络实体自身或通知其 它网元将该 IMS域的呼叫转移通知消息转换为满足 CS域接入用户的接收 能力的消息， 并将转换后的消息向所述从 CS域接入的用户发送。 从而实 现了对从 CS域接入用户的呼叫转移通知。 本发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权 利要求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在 内。

Claims

权 利 要 求
1、 一种为用户提供呼叫转移业务的方法， 其特征在于， 包括下列步 骤：
IMS网络实体收到指向从 CS域接入的用户的呼叫；
IMS网络实体获得该用户当前的会话接续状态和 /或用户意愿； 以及 根据所述获得的会话接续状态和 /或用户意愿， 提供呼叫转移业务。
2、 如权利要求 1所述的方法， 其特征在于， IMS 网络实体通过下述 方式之一获得用户的会话接续状态或用户意愿：
方式 a、 CS域网络实体或用户的 UE主动上报会话接续状态或用户意 愿； IMS 网络实体根据收到的上报的信息获得用户的会话接续状态或用 户意愿；
方式 b、 IMS网络实体与保存有会话接续状态或用户意愿的相关网元 交互， 或查询该 IMS网络实体， 获知保存的会话的信息， 根据获知的信息 进一步获得所述会话接续状态或用户意愿。
3、 如权利要求 1所述的方法， 其特征在于， IMS 网络实体获得该用 户当前的会话接续状态为用户不可及， 则提供 CFNRc业务；
其中， IMS网络实体通过下述方式之一获得该用户当前的会话接续状 态：
方式 11、 IMS网络实体根据收到的消息为临时不可用响应消息并且之 前未收到振铃响应消息， 则获得该用户当前的会话接续状态为用户不可 及；
方式 12: MGCF将携带有用户不可及信息的 CS域消息转换为 SIP中 的不可及响应消息， 并发送到 IMS网络实体； IMS网络实体根据收到的消 息获得该用户当前的会话接续状态为用户不可及；
方式 13: IMS网络实体以 ICCP消息通过 CS域下发所述呼叫后， 收 到该 ICCP消息传输路径中任一 CS域网元返回的携带有用户不可及信息 的响应消息， 则获得该用户当前的会话接续状态为用户不可及； 方式 14: IMS网络实体通过 CS域下发所述呼叫后， 在限定的时间内 未收到用户的响应， 则获得该用户当前的会话接续状态为用户不可及。
4、 如权利要求 1所述的方法， 其特征在于， IMS 网络实体获得该用 户当前的会话接续状态为用户未注册， 则提供 CFNL业务；
其中， IMS网络实体通过下述方式之一获得该用户当前的会话接续状 态：
方式 21、 IMS网络实体与保存有该用户注册信息的网元交互， 或查询 该 IMS网络实体保存的信息， 获知该用户未注册， 则获得该用户当前的会 话接续状态为用户未注册。
5、 如权利要求 1所述的方法， 其特征在于， IMS 网络实体获得该用 户当前的会话接续状态为用户无应答， 则提供 CFNRy业务；
其中， IMS网络实体通过下述方式之一获得该用户当前的会话接续状 态：
方式 31、 IMS网络实体收到该铃响应消息后， 在限定的时间内未收到 该用户的进一步响应， 则获得该用户当前的会话接续状态为用户无应答； 方式 32、 IMS网络实体根据已经收到了振铃响应消息又收到了临时不 可用响应消息， 则获得该用户当前的会话接续状态为用户无应答。
方式 33、MSC通过 CAMEL上报用户无应答的信息到 IMS网络实体， IMS网络实体根据 CAMEL上报的信息， 获得该用户当前的会话接续状态 为用户无应答。
6、 如权利要求 1所述的方法， 其特征在于， IMS 网络实体获得该用 户当前的会话接续状态为用户忙， 则提供 CFB业务；
其中， IMS网络实体通过下述方式之一获得该用户当前的接续状态： 方式 41、 IMS网络实体根据收到的 SIP消息获得该用户当前的会话接 续状态为用户忙； 方式 42、 IMS网络实体以 ICCP消息通过 CS域下发所述呼叫后， 收 到该用户的 UE返回的携带有用户忙信息的 ICCP消息， 则获得该用户当 前的会话接续状态为用户忙；
方式 43: IMS网络实体与保存有该用户会话接续状态的网元交互， 或 查询该 IMS网络实体保存的信息， 获知该用户已经存在了会话， 则获得该 用户当前的会话接续状态为用户忙。
方式 44、 MSC通过 CAMEL上报用户忙的信息到 IMS网络实体， IMS 网络实体根据 CAMEL上报的信息， 获得该用户当前的会话接续状态为用 户忙。
7、 如权利要求 1所述的方法， 其特征在于， IMS 网络实体获得该用 户意愿为用户要求前转， 则提供 CD业务；
其中， IMS网络实体通过下述方式之一获得该用户意愿：
方式 51、 IMS 网络实体收到该用户返回的携带有要求接续的号码的 ICCP消息， 则获得该用户意愿为用户要求前转。
8、 如权利要求 1所述的方法， 其特征在于， IMS 网络实体通知该用 户， 指向该用户的呼叫被呼叫转移的方式为下列之一：
方式 61、 IMS网络实体将携带有呼叫被转移信息的 SIP Message消息 转换为携带有呼叫被转移信息的 ICCP消息， 并向该用户发送。
9、 如权利要求 1所述的方法， 其特征在于， 主叫用户从 CS域接入， 则 IMS 网络实体通知该主叫用户其发起的呼叫被呼叫转移的方式为下列 之一：
方式 71、 IMS网络实体将 SIP呼叫转移通知消息转换为携带有呼叫转 移信息的 ICCP消息， 并向该主叫用户发送；
方式 72、 IMS网络实体将 SIP呼叫转移通知消息转发到 MGCF; MGCF 将该 SIP呼叫转移通知消息转换为携带有呼叫转移信息的 CS域消息， 并 向该主叫用户发送； 方式 73、 IMS网络实体将收到的携带有其呼叫转移业务处于激活状态 的 SIP Message消息转换为携带有其呼叫转移业务处于激活状态的 ICCP 消息， 并向该用户发送。
10、 如权利要求 1 至 9任一项所述的方法， 其特征在于， 所述 IMS 网络实体为提供呼叫转移业务的应用服务器，则该 IMS网络实体根据获得 的用户当前的会话接续状态或用户意愿， 直接为该用户提供相应的呼叫转 移业务；
所述 IMS 网络实体不为提供呼叫转移业务的应用服务器， 则该 IMS 网络实体根据获得的用户当前的会话接续状态或用户意愿， 通知为用户提 供呼叫转移业务的应用服务器的会话接续状态和 /或用户意愿，由为用户提 供呼叫转移业务的应用服务器为用户提供呼叫转移业务。
11、 一种 IMS网络实体， 其特征在于， 包括：
接收单元， 用于接收指向从 CS域接入的用户的呼叫；
获得单元， 用于在接收单元收到所述呼叫后， 获得该用户当前的会话 接续状态和 /或用户意愿。
12、如权利要求 11所述的实体，其特征在于，该 IMS网络实体为 IMS 电路控制功能实体 ICCF, 则还包括： 通知单元， 用于根据获得单元获得 的会话接续状态和 /或用户意愿，通知为用户提供呼叫转移业务的应用服务 器该会话的接续状态或用户意愿。
13、 如权利要求 11所述的实体， 其特征在于， 该 IMS网络实体为电 信业务应用服务器 TAS , 则还包括： 执行单元， 用于根据获得单元获得的 会话接续状态和 /或用户意愿， 为该用户提供呼叫转移业务。
14、 如权利要求 11至 13任一项所述的实体， 其特征在于， 还包括： 转换单元， 用于将收到的 IMS域呼叫转移通知消息转换为满足 CS域 接入用户的接收能力的消息；
发送单元， 用于将转换单元转换后的消息向所述从 CS域接入的用户 发送。
15、 如权利要求 11至 13任一项所述的实体， 其特征在于， 所述获得 单元通过下述方式之一获得会话接续状态或用户意愿：
方式 a、 CS域网络实体或该用户的 UE主动上报的会话接续状态或用 户意愿； 获得单元根据收到的上报的消息获得会话接续状态或用户意愿； 方式 b、获得单元与保存有会话接续状态或用户意愿的相关网元交互， 或查询该 IMS网络实体， 获知保存的会话的信息，根据获知的信息进一步 获得会话的接续状态或用户意愿。
16、 一种媒体网关控制功能实体， 其特征在于， 包括：
第一转换单元， 用于将 SIP呼叫转移通知消息转换为携带有呼叫转移 信息的 CS域消息； 和 /或
第二转换单元，用于将携带有用户不可及信息的 CS域消息转换为 SIP 中的不可及响应消息； 和 /或
第三转换单元，用于将携带有用户无应答信息的 CS域消息转换为 SIP 中的无应答响应消息。
17、一种传递呼叫转移通知消息的方法， 其特征在于， 包括下列步骤： 从 CS域接入的用户发起的呼叫， 或指向从 CS域接入的用户的呼叫 被呼叫转移；
IMS网络实体收到 IMS域的呼叫转移通知消息；
将该 IMS域的呼叫转移通知消息转换为满足 CS域接入用户的接收能 力的消息； 以及
将转换后的消息向所述从 CS域接入的用户发送。
18、 如权利要求 17所述的方法， 其特征在于， 指向从 CS域接入的用 户的呼叫被呼叫转移， 通知该用户的方式包括：
方式 81、 IMS 网络实体将收到的携带有呼叫被转移信息的 SIP Message消息转换为携带有呼叫被转移信息的 ICCP消息， 并向该用户发 送。
19、 如权利要求 17所述的方法， 其特征在于， 从 CS域接入的用户发 起的呼叫被呼叫转移， 通知该用户的方式为下列之一：
方式 91、 IMS 网络实体将收到的 SIP 呼叫转移通知消息转换为携带 有呼叫转移信息的 ICCP消息， 并向该用户发送；
方式 92、IMS网络实体将收到的 SIP呼叫转移通知消息转发到 MGCF; MGCF将该 SIP呼叫转移通知消息转换为携带有呼叫转移信息的 CS域消 息， 并向该用户发送；
方式 93、 IMS网络实体将收到的携带有其呼叫转移业务处于激活状态 的 SIP Message消息转换为携带有其呼叫转移业务处于激活状态的 ICCP 消息， 并向该用户发送。
PCT/CN2008/071264 2007-06-18 2008-06-11 Procédé et dispositif pour fournir un service de transfert d'appel pour les utilisateurs Ceased WO2008154842A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP08757675A EP2141902A4 (en) 2007-06-18 2008-06-11 METHOD AND DEVICE FOR PROVIDING CALL TRANSFER SERVICE FOR USERS
US12/612,769 US20100054159A1 (en) 2007-06-18 2009-11-05 Method and device for providing call forwarding service for users

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2007101267537A CN101330736B (zh) 2007-06-18 2007-06-18 为用户提供呼叫转移业务的方法及装置
CN200710126753.7 2007-06-18

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/612,769 Continuation US20100054159A1 (en) 2007-06-18 2009-11-05 Method and device for providing call forwarding service for users

Publications (1)

Publication Number Publication Date
WO2008154842A1 true WO2008154842A1 (fr) 2008-12-24

Family

ID=40155900

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/071264 Ceased WO2008154842A1 (fr) 2007-06-18 2008-06-11 Procédé et dispositif pour fournir un service de transfert d'appel pour les utilisateurs

Country Status (4)

Country Link
US (1) US20100054159A1 (zh)
EP (1) EP2141902A4 (zh)
CN (1) CN101330736B (zh)
WO (1) WO2008154842A1 (zh)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100574348C (zh) * 2007-07-27 2009-12-23 中兴通讯股份有限公司 一种实现用户决定用户忙前转的方法
US9154324B2 (en) * 2008-03-10 2015-10-06 Robert Bosch Gmbh Method and filter system for filtering messages received via a serial data bus of a communication network by a user of the network
US20110122867A1 (en) * 2009-11-24 2011-05-26 Telefonaktiebolaget L M Ericsson (Publ) Method and node for routing a call which has services provided by a first and second networks
KR101729336B1 (ko) * 2010-10-15 2017-04-21 삼성전자주식회사 회선 교환 망과 인터넷 프로토콜 멀티미디어 서브시스템 망간 로밍 서비스 제공 방법 및 시스템과 그 장치
CN103634763A (zh) * 2012-08-23 2014-03-12 中兴通讯股份有限公司 呼叫响应方法、装置及云端服务器
CN103973786B (zh) * 2014-05-07 2017-05-24 惠州Tcl移动通信有限公司 电子设备的通知消息的同步方法及电子设备
CN103957150B (zh) * 2014-05-07 2017-05-17 惠州Tcl移动通信有限公司 电子设备的通知消息的同步方法及服务器、电子设备
US10148703B2 (en) 2014-10-09 2018-12-04 T-Mobile Usa, Inc. Service capabilities in heterogeneous network
US11799922B2 (en) * 2016-12-21 2023-10-24 T-Mobile Usa, Inc. Network core facilitating terminal interoperation
EP3579626A4 (en) * 2017-03-20 2020-01-29 Huawei Technologies Co., Ltd. PAGING METHOD AND CORRESPONDING DEVICE
US10771509B2 (en) 2017-03-31 2020-09-08 T-Mobile Usa, Inc. Terminal interoperation using called-terminal functional characteristics
CN109257512B (zh) * 2017-07-13 2022-03-04 中兴通讯股份有限公司 一种呼叫前转方法、装置及计算机可读存储介质
US12052366B2 (en) * 2021-10-29 2024-07-30 Zoom Video Communications, Inc. Telephony outage handling using an on-premises telephony node

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050096029A1 (en) * 2003-10-29 2005-05-05 Lucent Technologies Inc. Method and system for call forwarding in multimedia telecommunication networks
CN1929434A (zh) * 2006-09-22 2007-03-14 中国移动通信集团公司 Ims域与cs域消息互通的方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6181943B1 (en) * 1998-03-30 2001-01-30 Lucent Technologies Inc. Method and apparatus for inter-frequency hand-off in wireless communication systems
EP1135906A1 (en) * 1998-12-03 2001-09-26 Telefonaktiebolaget LM Ericsson (publ) System and method for mobile terminal registration in an integrated wireless packet-switched network
JP3779207B2 (ja) * 1999-06-24 2006-05-24 コンパック・コンピューター・コーポレーション 異なるプロトコルを用いるネットワークを介して電話通信サービスを提供する方法及びシステム
US20020110104A1 (en) * 2001-02-13 2002-08-15 Telefonaktiebolaget Lm Ericsson (Publ). Hybrid media gateway control function providing circuit-switched access to a packet-switched radio telecommunications network
WO2003001836A1 (en) * 2001-06-20 2003-01-03 Nokia Corporation System, device and method for providing call forwarding in dual subscription mode
BRPI0419099B1 (pt) * 2004-10-06 2017-12-12 Telecom Italia S.P.A. Method of providing services combined to users of mobile, and, mobile communication system
US7664491B2 (en) * 2005-03-11 2010-02-16 Research In Motion Limited Advanced call forwarding user interface for mobile communication device
CN100450207C (zh) * 2005-09-30 2009-01-07 华为技术有限公司 电路域用户接入ims域的方法及通信系统
US20090024760A1 (en) * 2006-03-14 2009-01-22 Motorola, Inc. Method and system for managing communication-sessions in a network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050096029A1 (en) * 2003-10-29 2005-05-05 Lucent Technologies Inc. Method and system for call forwarding in multimedia telecommunication networks
CN1929434A (zh) * 2006-09-22 2007-03-14 中国移动通信集团公司 Ims域与cs域消息互通的方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Report on alternative architectures for combining CS Bearers with IMS", 3GPP TR 23.899 V1.2.0, June 2005 (2005-06-01), pages 30 - 31, XP008122030 *
See also references of EP2141902A4 *

Also Published As

Publication number Publication date
CN101330736A (zh) 2008-12-24
EP2141902A1 (en) 2010-01-06
EP2141902A4 (en) 2010-11-03
CN101330736B (zh) 2011-04-20
US20100054159A1 (en) 2010-03-04

Similar Documents

Publication Publication Date Title
CN101330736B (zh) 为用户提供呼叫转移业务的方法及装置
US10110975B2 (en) Inter-domain call routing
KR101548140B1 (ko) 원격통신 네트워크에서 매체 속성들에 기초한 선택적 호 포워딩을 위한 방법 및 시스템
US20110268110A1 (en) Providing Packet-Based Multimedia Services via a Circuit Breaker
WO2008046319A1 (en) A method and system to realize voice call continuity when dealing with emergency business
WO2007014510A1 (fr) Commande de routage interdomaine
WO2007098713A1 (en) An emergency call method and system
WO2007079688A9 (fr) Procede, appareil et systeme de mise en communication de l'utilisateur appele
WO2008049326A1 (en) User device registering, enabling system, method and device in private network management
WO2009024006A1 (fr) Contrôleur de session locale, sous-système multimédia ip et procédé d'enregistrement de session
WO2012027939A1 (zh) 一号通呼叫的方法及业务控制点
CN103125105A (zh) 用于管理向一组用户实体的通信的应用服务器
CN102804820B (zh) 电信网络中的方法和设备
WO2009039688A1 (fr) Procédé de transfert d'appel tardif dans un service centralisé d'un sous-système de réseau central multimédia ip
WO2009046660A1 (en) A method, system and device for establishing association-control relations
CN101325590A (zh) 一种ip多媒体子系统集中控制业务实现终呼的方法
US8363645B2 (en) Method for realizing user decision user busy forwarding
CN101102610B (zh) 一种ims集中控制业务中实现用户忙呼叫前转的方法
CN101102615B (zh) 一种ip多媒体子系统集中控制业务终呼的实现方法
WO2008110110A1 (fr) Procédé et système de fourniture de service de sous-système multimédia ip
CN101102614A (zh) Ims集中控制业务中实现用户决定用户忙前转的方法
CN101626549B (zh) 多域环境中提供遇忙呼叫完成业务的方法和实体
WO2008046313A1 (fr) Procédé de resélection pour un terminal d'utilisateur appelé dans un service de redirection, et système et appareil correspondants
WO2008098469A1 (fr) Procédé et dispositif permettant d'établir une interconnexion de service dans un domaine de circuit
CN101102604B (zh) Ip多媒体子系统集中控制业务中用户关机前转的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08757675

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 3731/KOLNP/2009

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2008757675

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE