WO2014019226A1 - 一种处理呼叫冲突的方法、系统和业务控制设备 - Google Patents

一种处理呼叫冲突的方法、系统和业务控制设备 Download PDF

Info

Publication number
WO2014019226A1
WO2014019226A1 PCT/CN2012/079669 CN2012079669W WO2014019226A1 WO 2014019226 A1 WO2014019226 A1 WO 2014019226A1 CN 2012079669 W CN2012079669 W CN 2012079669W WO 2014019226 A1 WO2014019226 A1 WO 2014019226A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
context
current call
current
called
Prior art date
Application number
PCT/CN2012/079669
Other languages
English (en)
French (fr)
Inventor
周文
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2012/079669 priority Critical patent/WO2014019226A1/zh
Priority to CN201280001195.0A priority patent/CN102893691B/zh
Publication of WO2014019226A1 publication Critical patent/WO2014019226A1/zh

Links

Classifications

    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/22—Synchronisation circuits

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method, system, and service control device for handling call conflicts.
  • terminal A calls terminal B
  • terminal B initiates a call to terminal A.
  • a call conflict occurs, and calls initiated by terminal A and terminal B are busy, and thus cannot Successfully establishing a call between A and B reduces the call success rate.
  • Embodiments of the present invention provide a method, system, and service control device for handling call conflicts to improve call success rate.
  • a method for handling a call conflict includes:
  • the service control device acquires the primary called identity of the current call; and according to the primary called identity, searches for the cached call context, and determines whether there is a context of the call that conflicts with the current call;
  • the context of the current call is cached, and the MSC is instructed to connect to the current call.
  • the context of the current call is deleted; wherein the context of the cached current call includes The calling party ID of the current call.
  • the service control device performs a delay waiting, and reaches a preset delay duration.
  • the MSC sends an instruction to reconnect the current call.
  • the service control device detects the called state of the current call in real time, and when the called party is detected to be idle In the status, an instruction to reconnect the current call is sent to the MSC.
  • a third possible implementation if the cached call context does not distinguish between the calling and the called The context of the call that conflicts with the current call is specifically the call context containing the primary called identity of the current call.
  • the cached call context has a distinction between the calling party and the called party
  • the context of the call that conflicts with the current call is specifically as follows:
  • the recorded caller is the called party of the current call
  • the recorded called call is the calling context of the calling party of the current call.
  • the service control device searches for The cached call context, determining the context of the call that does not conflict with the current call, and indicating that the context of the current call is buffered, instructs the MSC to continue to connect to the current call.
  • the service control device includes:
  • An acquiring unit configured to acquire a calling and called identifier of a current call during a call setup process
  • a control unit configured to: search for a cached call context according to the calling and called identifier obtained by the acquiring unit, to determine whether there is a conflict with the current call The context of the call; if so, instructing the mobile switching center MSC to release the current call; if not, buffering the context of the current call and instructing the MSC to connect to the current call, successfully connecting to the current call or discovering the current call during the connection
  • the context of the current call is deleted; wherein the context of the cached current call includes the primary called identity of the current call.
  • the service control device further includes: a delay The unit is configured to monitor the delay duration, and notify the control unit when the preset delay duration is reached; the control unit is further configured to wait for a delay when receiving the busy event during the process of connecting the current call. And triggering the delay unit to start monitoring, and when receiving the notification that the delay unit sends the preset delay duration, sending an instruction to re-send the current call to the MSC.
  • the service control device further includes: a detecting unit, configured to detect a called state of the current call in real time, and notify the control unit when detecting that the called party resumes the idle state
  • the control unit is further configured to: when receiving the busy event, trigger the detecting unit to start detecting, and when receiving the notification that the called unit returns the idle state sent by the detecting unit, An instruction to reconnect the current call is sent to the MSC.
  • the cached call context does not distinguish between the calling party and the called party
  • the context of the call that conflicts with the current call is specifically the call context containing the primary called identity of the current call.
  • the cached call context has a distinction between the calling party and the called party
  • the context of the call that conflicts with the current call is specifically as follows:
  • the recorded caller is the called party of the current call
  • the recorded called call is the calling context of the calling party of the current call.
  • the processing unit is further configured to: when receiving the current call, if the MSC is received from the communication unit, the MSC is initiated at the monitoring point DP12.
  • the initial detection point IDP message searches for the cached call context in the storage unit, determines the context of the call that does not conflict with the current call, and the MSC continues to connect to the current call when the context of the current call has been cached.
  • a third aspect a system for handling a call conflict, comprising a mobile switching center MSC and a first possible implementation of the second aspect or the second aspect or a second possible implementation of the second aspect or a third aspect of the second aspect Possible implementation or a fourth possible implementation of the second aspect
  • the service control device in the fifth possible implementation manner of the second aspect, wherein the MSC is configured to process the current call according to the indication delivered by the service control device.
  • the context of the current call is deleted when the current call is successfully connected or the current call has been released during the connection process, thereby ensuring that the context cached by the service control device is the context of the call that is in the process of establishing the call. . Therefore, when receiving the call, the service control device may determine whether there is a call conflict according to the cached call context, and release the current call when there is a call conflict, thereby ensuring a successful connection of another call to a certain extent, thereby improving The call completion rate avoids the waste of network resources.
  • FIG. 1 is a flowchart of a method for processing a call conflict according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a call conflict processing method in scenario 1 according to an embodiment of the present invention
  • FIG. 3 is a flowchart of another embodiment of a call conflict processing method in scenario 1
  • FIG. 4 is a flowchart provided by an embodiment of the present invention
  • 2 is a flowchart of a call conflict processing method in FIG. 2
  • FIG. 5 is a flowchart of another embodiment of a call conflict processing method in scenario 2
  • FIG. 6 is a flowchart of a call conflict processing method in scenario 3 according to an embodiment of the present invention
  • Figure 7 is a schematic structural diagram of a service control device according to an embodiment of the present invention
  • FIG. 8 is a schematic structural diagram of a service control device according to another embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of a service control device according to another embodiment of the present invention.
  • FIG. 10 is a schematic structural diagram of a service control device based on a computer system according to an embodiment of the present invention
  • FIG. 11 is a schematic structural diagram of a system for solving a call conflict according to an embodiment of the present invention.
  • FIG. 1 is a flowchart of a method for processing a call conflict according to an embodiment of the present invention. As shown in the figure, a method for processing a call conflict in this embodiment includes:
  • the service control device acquires the primary and called identity of the current call; wherein, the service control device is a device that performs service processing and performs call control during the call process, for example, a service control point in the intelligent network (
  • the service control point (SCP) is used to process the call conflict service in the embodiment of the present invention.
  • the call collision service is a service for resolving call conflicts.
  • the mobile switching center After receiving the call initiated by the calling terminal, the mobile switching center (MSC) sends a message for triggering the call conflict service to the service control device, if it is determined that the calling or called terminal subscribes to the call conflict service, such as An initial domain part (IDP) message, the service control device obtains the primary called identity of the current call from the message.
  • a message for triggering the call conflict service such as An initial domain part (IDP) message
  • the MSC may determine whether to subscribe to the call conflict service according to the subscription information of the calling party or the called party, and the subscription information may be a customized application for mobile network enhanced logic (CAMEL) subscription inf or mat ion, CSI).
  • the MSC may also sign the call conflict service by default, and send a message triggering the call conflict service to the service control device according to the address of the pre-configured service control device after receiving the call.
  • CAMEL mobile network enhanced logic
  • S102 determining, according to the calling called identifier, the cached call context, determining whether there is a context of a call that conflicts with the current call; if yes, executing S104; if not, executing S106; wherein, the service control device cache is in the presence
  • the context of each call includes the callee ID of the call.
  • the service control device can determine if there is a conflicting call by looking up the cached call context.
  • the service control device can cache the call context locally, or cache the call context on an external storage device.
  • the service control device may distinguish the primary called party (ie, only the identity of the calling party and the called party itself) in the cached call context, and may also distinguish the calling party and the called party (ie, in addition to the identity of the cached calling party and the called party itself, Whether the logo belongs to the calling or called).
  • the context of the call that conflicts with the current call is specifically the call context containing the primary called identity of the current call.
  • the service control device finds the call context containing the primary and called identity of the current call in the cached call context, it determines that there is a call that conflicts with the current call.
  • whether or not there is a call conflict can be determined according to whether there is a call context including the calling party ID in the cached call context.
  • the context of the call that conflicts with the current call is specifically: the called party is the called party of the current call, and the recorded called party is the calling party of the current call.
  • Call context The service control device finds a call context in the cached call context, and records the caller's identity as the called identity of the current call, and the call context record is the called identity as the current call.
  • the calling identity is called, it is determined that there is a call that conflicts with the current call.
  • the service control device sends an instruction to release the current call to the MSC, such as releasing a call (RC) signaling, and the MSC releases the current call according to the instruction.
  • an instruction to release the current call to the MSC such as releasing a call (RC) signaling
  • RC call
  • S106 Cache the context of the current call, and instruct the MSC to connect to the current call.
  • the context of the current call is deleted; where the context of the cached current call includes the current The calling party ID of the call.
  • the service control device sends an instruction to the MSC to connect to the current call, such as a cont inue message, instructing the MSC to continue the current call.
  • the service control device may determine that the current call is successfully connected by receiving the called response message reported by the MSC, to receive the release event reported by the MSC, to determine that the current call has been released during the connection.
  • the cached context in step S106 can be used as a basis for judging the call conflict in the subsequent processing, for example, before deleting the context of the current call, receiving the call initiated by the called party of the current call to the calling party of the current call, at this time, the service control The device can determine that there is a conflicting call based on the cached call context.
  • the context of the current call is deleted because the current call has been released when the current call is successfully connected or during the connection, thereby ensuring that the context cached by the service control device is the context of the call that is in the process of establishing the call. . Therefore, when receiving the call, the service control device can determine whether there is a call conflict according to the cached call context, and release the current call when there is a call conflict, thereby ensuring to some extent another call that conflicts with the current call. The success of the connection improves the call completion rate and avoids the waste of network resources.
  • the MSC receives the connection current call indication, and connects the call initiated by the terminal A to the terminal B, the call initiated by the terminal B to the terminal A is released in the future (from the release to the terminal to restore the idle state). Have a certain delay;), At this time, there will be a busy situation, and the MSC will report the busy event to the service control device. Therefore, in order to solve this special case, the service processing device can further perform further processing on the basis of the embodiment shown in FIG. Specifically, the following two treatment methods can be used:
  • Manner 1 During the process of connecting the current call, if the busy event is received, the service control device waits for the delay, and sends an instruction to re-send the current call to the MSC when the preset delay time is reached.
  • the preset delay duration can be preset according to the experience value, for example, 10 seconds.
  • Manner 2 In the process of connecting the current call, if the busy event is received, the service control device detects the called state of the current call in real time, and when detecting that the called party resumes the idle state, sends a reconnection to the current call to the MSC. instruction.
  • the problem of unsuccessful connection in some special cases is solved, and the call connection rate is further improved.
  • the above two methods have advantages, and the processing of the first method does not need to interact with other devices, and can directly wait for, and save network resources; the second method can directly know the called state, and the accuracy is high.
  • the service processing device instructs the MSC to connect to the current call, the MSC according to the called terminal's subscription information (eg, T-CSI)
  • a message eg, an IDP message
  • the service processing device may further include the following processing on the basis of FIG.
  • the solution of the embodiment of the present invention can be applied to an intelligent network or other network.
  • the embodiments of the present invention are described by using the message in the intelligent network as an example, and can be replaced with other networks when applied to other networks. A message with similar functionality.
  • the home location register is needed.
  • the user subscribes to the call conflict service. That is, before the step S100 shown in FIG. 1 , the contract information setting is performed in advance, and the contract information setting process is as follows:
  • the HLR creates and saves the user's subscription information, including the originating CAMEL subscription information.
  • the service key in the O-CSI and the T-CSI is the service key of the call collision service
  • the address in the 0-CSI and the T-CSI is the address of the service control device that handles the call collision service.
  • the service control device acquiring the primary called identity of the current call may include: the service control device receiving, by the mobile switching center, a message for triggering the call conflict service according to the calling or called subscription information, and the message is received from the message. Get the primary and called identity of the current call.
  • the service control device is an SCP in the intelligent network.
  • Terminal A has a call collision service, and terminal B does not subscribe to a call collision service.
  • the call from terminal A to terminal B is called call a, and the call from terminal B to terminal A is called call b. Occurs before call b.
  • the call conflict processing method in this embodiment includes:
  • A201 the visited mobile switching center of the terminal A, the MSCa receives the call initiated by the terminal A to the terminal B a;
  • the MSCa sends an IDP message for triggering the call conflict service to the SCP according to the 0-CSI of the terminal A.
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call a.
  • Terminal A's subscription information 0-CSI can be from the visitor location register (visitor location) Register, VLR).
  • VLR visitor location Register
  • the VLR may be combined with the MSC in one physical entity or two independent physical entities. The embodiment of the present invention is described by taking an example in which the VLR can be combined with the MSC.
  • A203 The SCP obtains the calling party identifier of the call a, searches for the cached call context by using the obtained calling party identifier, and determines that there is no call conflicting with the call a;
  • the calling party identifier of the corresponding call is included in each call context. By searching the cached call context, it can be determined whether there is a call context including the calling party identifier of the call a, thereby determining whether there is a call conflicting with the call a. In this embodiment, since the call a occurs before the call b, the call context containing the calling party ID of the call a cannot be found.
  • A204 Cache the context of the call a, where the context of the cached call a includes the primary called identity of the call a;
  • the primary and secondary call identifiers may be distinguished, and the identifier A and the identifier B are directly stored.
  • A205 Send a continue message to the MSC, instructing the MSC to continue the call a;
  • the request may be further sent to the MSC to report a basic call state mode (BCSM) event RRBE message, where the RRBE message is used to instruct the MSCa to monitor the called party. Answer, busy, no answer, unreachable, etc., the process can be implemented with reference to the prior art.
  • BCSM basic call state mode
  • steps a204 and a205 are not sequentially limited in execution.
  • A206 MSCA sends an initial address message to the visited MSCb of terminal B (Initial Address
  • the SCP processes the call b as follows:
  • the visited mobile switching center of the terminal B, the MSCb receives the call initiated by the terminal B to the terminal A b;
  • MSCb sends a call to the SCP according to the T-CSI of the called party (terminal A) for triggering call rush IDP message of the business;
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call b.
  • B203 The SCP obtains the calling party identifier of the call b, and obtains the called call context by the obtained calling party identifier, and determines that there is a call that conflicts with the call b;
  • the terminal A identifier and the terminal are cached in a204.
  • the call context identified by B therefore, in this step, the call context containing the primary called identity of call b can be found to determine the presence of a conflicting call.
  • B204 Send an RC message to the MSCb, instructing the MSCb to release the call b;
  • the MSCb releases the resource of the call b, and restores the B terminal to the idle state.
  • the processing of the call b is completed before the step a206. Therefore, when the MSC receives the IAM message, the call b has been released, so the call a can be successfully connected.
  • the specific process is as follows:
  • Step a207 MSCb pages terminal B and returns an address complete message (ACM) to MSCa;
  • A208 After the called terminal answers, the MSCb sends an address answer message (ANM) to the MSCa;
  • NAM address answer message
  • A209 The MSCA sends an event report basic call state model (ERB) message to the SCP to report the response event.
  • ERP event report basic call state model
  • A210 The SCP sends a Continue message to the MSCa to instruct the MSCa to connect to the call a;
  • A211 The SCP deletes the context of the cached call a.
  • steps a210 and a211 are not sequentially limited in execution.
  • A212 Call a is successfully established, and terminal A and terminal B start talking.
  • FIG. 3 is a flowchart of another embodiment of a call conflict processing method in the scenario 1.
  • the call conflict processing method in this embodiment includes: a 301: the visited mobile switching center MSCa of the terminal A receives the call a initiated by the terminal A to the terminal B;
  • the MSCa sends an IDP message for triggering the call conflict service to the SCP according to the 0-CSI of the terminal A.
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call a.
  • the calling party identifier of the corresponding call is included in each call context. By searching the cached call context, it can be determined whether there is a call context including the calling party identifier of the call a, thereby determining whether there is a call conflicting with the call a. In this embodiment, since the call a occurs before the call b, the call context containing the calling party ID of the call a cannot be found.
  • A304 Cache the context of the call a, where the context of the cached call a includes the calling and called identity of the call a;
  • the main called party may not be distinguished.
  • A305 Send a continue message to the MSC, instructing the MSC to continue the call a;
  • the request report BCSM (basic call state mode) event (RRBE) message may be further sent to the MSC, where the RRBE message is used to instruct the MSCa to monitor the called party. Answer, busy, no answer, unreachable, etc., the process can be implemented with reference to the prior art.
  • BCSM basic call state mode
  • RRBE basic call state mode event
  • steps a304 and a305 are not executed in sequence when executed.
  • the MSCA sends an initial address message (IM AM) to the visited MSCb of the terminal B;
  • the SCP processes the call b
  • the steps b301-b305 are the processing of the call b, wherein the processing of the steps b301-b305 the process can be illustrated with reference to the step of FIG. 1 b201-b205 o in the present embodiment, only the processing of the call prior to step b a306 is not yet completed, because Therefore, when the MSC receives the IAM message, the call b is not released, so the call a cannot be successfully connected.
  • the subsequent processing of call a includes:
  • MSCb returns a REL message to MSCa to notify the connection failure, and carries the reason value: Called busy
  • a 309 The SCP waits for a delay
  • the delay is to wait for the processing of the call b to be completed, and the terminal B returns to the idle state, and the delay time can be preset according to the empirical value.
  • this step can also use another alternative method, that is, the SCP detects the state of the terminal B in real time, and when detecting that the terminal B resumes the idle state, sends a Reconnect message to the MSC.
  • A310 Send a Reconnect message to the MSC when the delay reaches a preset delay duration, instructing the MSC to reconnect the call a;
  • A311 MSCa sends a ring to MSCb.
  • the call conflict processing method in this embodiment includes:
  • A401 the visited mobile switching center of the terminal A, the MSCa receives the call initiated by the terminal A to the terminal B a;
  • the MSCa sends an IDP message for triggering the call conflict service to the SCP according to the 0-CSI of the terminal A.
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call a.
  • A403 The SCP obtains the calling party identifier of the call a, and obtains the called party context to obtain the cached call context, and determines that there is no call conflicting with the call a; The calling party identifier of the corresponding call is included in each call context. By searching the cached call context, it can be determined whether there is a call context including the calling party identifier of the call a, thereby determining whether there is a call conflicting with the call a. In this embodiment, since the call a occurs before the call b, the call context containing the calling party ID of the call a cannot be found.
  • A404 Cache the context of the call a, where the context of the cached call a includes the primary called identity of the call a;
  • A405 Send a cont inue message to the MSC, instructing the MSC to connect to the call a;
  • the message may be further sent to the MSC to report a basic call state model event (RBS) message, where the RRBE message is used.
  • RBS basic call state model event
  • the process of instructing the MSCa to monitor the called response, busy, no answer, unreachable, etc., may be implemented by referring to the prior art.
  • steps a404 and a405 are not sequentially limited in execution.
  • A406 MSCa sends an IDP message for triggering the call conflict service to the SCP according to the T-CS I of the called party (terminal B);
  • MSCa Since terminal B also subscribes to the call collision service, MSCa triggers the IDP message according to the called T-CS I, and this trigger is triggered by the detection point DP12.
  • the IDP message carries the service key of the call conflict service and the calling party ID of the call a.
  • the MSCa can obtain the subscription information T-CSI of the terminal B from the HLR of the terminal B.
  • A407 After receiving the IDP message triggered by the DP12, the SCP searches the cached call context to determine that there is no conflicting call and the context of the call a is cached;
  • the call context containing the calling party ID of the call a is found when searching, because the calling identifier in the call context found here is A, the called identifier For B, it is consistent with the calling party ID of call a. Therefore, there is no conflicting call and the calling context of call a is cached. Therefore, the SCP will directly instruct the MSC to continue. Continue to call a.
  • A408 The SCP sends a cont inue message to the MSCa, instructing the MSC to continue to connect to the call a.
  • the SCP processes the call b as follows:
  • the visited mobile switching center of the terminal B, the MSCb receives the call initiated by the terminal B to the terminal A b;
  • the MSCb sends an IDP message for triggering the call conflict service to the SCP according to the 0-CS I of the terminal B.
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call b.
  • B403 The SCP obtains the calling party identifier of the call b, and obtains the called party context to obtain the cached call context, and determines that there is a call that conflicts with the call b;
  • the call context including the terminal A identifier and the terminal B identifier is cached in a404. Therefore, in this step, the call context containing the calling party identifier of the call b can be found to determine the existence of the call context. Conflict call.
  • B404 Send an RC message to the MSCb, instructing the MSCb to release the call b;
  • the MSCb releases the resource of the call b, and restores the B terminal to the idle state.
  • This embodiment is a case where the processing of the call b is completed before the step a409. Therefore, when the MSC receives the IAM message sent in the step a409, the call b has been released, so the call a can be successfully connected, and the specific process is :
  • Step a410 MSCb pages terminal B and returns ACM to MSCa;
  • the call conflict processing method in this embodiment includes: For the processing of the steps a501-a509, refer to a401-a409 in FIG. 4, which is not mentioned here.
  • the SCP processes the call b, and the steps b501-b505 are the processing of the call b, wherein the processing of the step b501_b505 Refer to step b401_b405.
  • step a510 the MSCb returns a REL message to the MSCa to notify the connection failure, and carries the cause value: busy;
  • A511 MSCa sends an ERB message to the SCP, and reports a busy event
  • A512 The SCP waits for a delay
  • the delay is to wait for the processing of the call b to be completed, and the terminal B returns to the idle state, and the delay time can be preset according to the empirical value.
  • this step can also use another alternative method, that is, the SCP detects the state of the terminal B in real time, and when detecting that the terminal B resumes the idle state, sends a Reconnect message to the MSC.
  • A513 Send a Reconnect message to the MSC when the delay reaches the preset delay duration, indicating
  • A514 MSCa sends an IAM to MSCb.
  • Scenario 3 Both terminal A and terminal B have a call collision service and belong to different SCPs. Terminal A belongs to SCPa, and terminal B belongs to SCPb. Among them, the call from terminal A to terminal B becomes call a, the call from terminal B to terminal A becomes call b, and the call from terminal B to call b occurs.
  • FIG. 6 is a flowchart of a call conflict processing method in the scenario 3, as shown in the figure, in the embodiment, the call conflict processing method includes:
  • A601 the visited mobile switching center of the terminal A, the MSCa receives the call initiated by the terminal A to the terminal B a;
  • MSCa sends a call for triggering a call collision service to the SCPa according to the 0-CSI of the terminal A.
  • I DP message
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call a.
  • A603 The SCPa obtains the calling party identifier of the call a, and obtains the calling called context of the obtained called party identifier to determine that there is no call conflicting with the call a;
  • the calling party identifier of the corresponding call is included in each call context. By searching the cached call context, it can be determined whether there is a call context including the calling party identifier of the call a, thereby determining whether there is a call conflicting with the call a. In this embodiment, since the call a occurs before the call b, the call context containing the calling party ID of the call a cannot be found.
  • A604 Cache the context of the call a, where the context of the cached call a includes the primary called identity of the call a;
  • the calling party context may not be distinguished when the call context is cached.
  • A605 Send a cont inue message to the MSC, instructing the MSC to connect to the call a;
  • the message may be further sent to the MSC to report a basic call state model event (BCS) message, where the RRBE message is used.
  • BCS basic call state model event
  • the process of instructing the MSCa to monitor the called response, busy, no answer, unreachable, etc., may be implemented by referring to the prior art.
  • steps a604 and a605 are not sequentially limited in execution.
  • A606 MSCa sends an IDP message for triggering the call conflict service to the SCPb according to the T-CS I of the called party (terminal B);
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call a.
  • step b604 occurs before step a606
  • SCPb judges that it already exists.
  • the call that conflicts with call a therefore, will release call a.
  • step a607 the SCPb obtains the calling party identifier of the call a, and obtains the calling party identifier to search the cached calling context, and determines that there is a calling context including the calling party identifier of the call a;
  • A609 The MSCa sends an ERB message reporting release event to the SCPa.
  • A610 SCPa deletes the cached call a context
  • A611 SCPa sends an RC message to MSCa, instructing MSCa to continue to release call a;
  • the MSCa releases the resources of the call a, and restores the A terminal to the idle state.
  • processing for call b is as follows:
  • the visited mobile switching center of the terminal B, the MSCb receives the call initiated by the terminal B to the terminal A b;
  • the MSCb sends an IDP message for triggering the call conflict service to the SCPb according to the 0-CSI of the terminal B.
  • the IDP message carries the service key of the call conflict service and the calling party identifier of the call b.
  • B603 The SCPb obtains the calling party identifier of the call b, and obtains the calling party identifier of the obtained called party identifier to determine that there is no call conflicting with the call b;
  • step b603 occurs before step a606, there is no call context containing the primary called identity of call b in the SCPb, thereby determining that there is no call that conflicts with call b.
  • B604 Cache the context of the call b, wherein the context of the cached call b includes the primary called identity of the call b;
  • the primary and secondary call identifiers may be distinguished, and the identifier A and the identifier B are directly stored.
  • B605 Send a continue message to the MSCb, instructing the MSCb to continue the call b;
  • the request report BCSM basic call state mode event (RRBE) message is further sent to the MSC, where the RRBE message is used to instruct the MSCb to monitor the called party. Answer, busy, no answer, unreachable, etc., the process can be implemented with reference to the prior art.
  • BCSM basic call state mode
  • RRBE basic call state mode event
  • steps b604 and b605 are not sequentially limited in execution.
  • B606 The MSCb sends a touch to the SCPa according to the T-CSI of the called party (terminal A) of the call b. Sending an IDP message for the call collision service;
  • step b606 after step a 612 as an example.
  • the SCPa obtains the calling party identifier of the call b, and obtains the called party context of the cached call context by the obtained calling party identifier, and determines that there is no call conflicting with the call b;
  • step b606 occurs after step a612, call a has been released and the context of call a has been deleted, so that the call context containing the primary called identity of call b is not found, thereby determining that no call conflicts with call b.
  • B608 the context of the cached call b, wherein the context of the cached call b includes the primary called identity of the call b;
  • B609 Send a cont inue message to the MSCb, instructing the MSCb to connect to the call b;
  • Step b61 0-step b619 is a call connection process, wherein steps b610-b615 can refer to step a206_a211, and details are not described herein again.
  • step b616 MSCb sends an ERB message to the SCPa to report the response event;
  • B617 SCPa sends a Cont inue message to MSCb indicating that MSCb connects to call b;
  • steps b617 and b618 are not executed in sequence.
  • FIG. 6 shows only one embodiment under the scenario 3, and for other embodiments, similar processing can be performed with reference to the embodiments shown in FIGS. 2 to 6.
  • scenario 3 if call b occurs after step a606 and is released in the future before call a is connected to terminal B, this will occur during the process of connecting call a, and SCPa receives the event that MSCa reports the busy event.
  • call b can be processed with reference to step a 309-a 310 of FIG.
  • FIG. 7 shows an embodiment of a service control device.
  • the service control device includes:
  • the obtaining unit 701 is configured to acquire a calling and called identity of the current call during the call setup process
  • the control unit 702 is configured to search, according to the calling and called identity acquired by the acquiring unit 701, the cached calling context, to determine whether the current and the current Calling the context of the conflicting call; if so, instructing the mobile switching center MSC to release the current call; if not, buffering the context of the current call, and instructing the MSC to continue the current call, when successfully connecting to the current call or during the connection
  • the context of the current call is deleted; wherein the context of the cached current call includes the primary called identity of the current call.
  • the mobile control center After the mobile switching center (MSC) receives the call initiated by the calling terminal, if it is determined that the calling or called terminal subscribes to the call conflict service, the mobile control center sends a call conflict service to the service control device.
  • the message such as an initial domain part (IDP) message, after the receiving unit 701 in the service control device receives the message, obtains the calling and called identity of the current call from the message.
  • IDP initial domain part
  • the MSC may determine whether to subscribe to the call conflict service according to the subscription information of the calling or called party, and the subscription information may be a customized application for mobile network enhanced logic (CAMEL) subscription information (CSI). .
  • the MSC may also sign the call conflict service by default, and send a message triggering the call conflict service to the service control device after receiving the call.
  • the subscription information of the call conflict service may include 0-CSI and T-CSI.
  • the obtaining unit 701 provides the primary called identity of the current call to the control unit 702, and the control unit 702 searches for the cached call context according to the primary called identity to determine whether there is a context of the call that conflicts with the current call. If the cached call context does not distinguish between the primary and the called, the context of the call that conflicts with the current call is specifically the call context that includes the primary called identity of the current call.
  • the control unit 702 finds the main party containing the current call in the cached call context. When the called call context is called, it is determined that there is a call that conflicts with the current call.
  • the context of the call that conflicts with the current call is specifically:
  • the called party is the called party of the current call
  • the recorded called party is the calling context of the calling party of the current call.
  • the control unit 702 finds a call context in the cached call context, and records the caller's identity as the called identity of the current call, and the call context record is determined by the caller's identity as the caller identity of the current call. There is a call that conflicts with the current call.
  • control unit 702 may instruct MSC to release the current call by transmitting an instruction to the MSC to release the current call, such as a call release (RC) signaling.
  • control unit 702 can instruct MSC to continue the current call by sending an instruction to the MSC to continue the current call, such as a cont inue message.
  • the control unit 702 may determine that the current call is successfully connected by receiving the called response message reported by the MSC, to receive the release event reported by the MSC to determine that the current call has been released during the connection.
  • control unit 702 controls the buffering of the call context, and determines whether there is a call conflict according to the cached call context, and releases the current call when it is determined that there is a call conflict, thereby ensuring to a certain extent.
  • the successful connection of another call that conflicts with the current call improves the call completion rate and avoids waste of network resources.
  • the service processing device may further include a delay unit 703 on the basis of the embodiment shown in FIG. 7.
  • FIG. 8 is a service processing device according to another embodiment of the present invention. Schematic diagram of the structure.
  • the delay unit 703 is configured to monitor the delay duration, and when the preset delay duration is reached, notify the control unit 702; the control unit 702 is further configured to be in the process of connecting the current call. If the busy event is received, delay waiting is performed, and the triggering delay unit 703 starts monitoring. When receiving the notification that the delay unit sends the preset delay duration, the MSC sends a reconnection to the current call. instruction.
  • the service processing device may further include a detecting unit 704 on the basis of the embodiment shown in FIG. 7.
  • FIG. 9 is a service according to another embodiment of the present invention. Schematic diagram of the processing equipment.
  • the detecting unit 704 is configured to detect the called state of the current call in real time, and notify the control unit 702 when detecting that the called party resumes the idle state; the control unit 702 is further configured to receive the busy call during the process of connecting the current call.
  • the trigger detecting unit 704 starts detecting, and when receiving the notification that the called unit sends the idle state returned by the detecting unit 704, sends an instruction to re-send the current call to the MSC.
  • the problem of unsuccessful connection in some special cases is solved, and the call connection rate is further improved.
  • the above two methods have advantages, and the processing of the first method does not need to interact with other devices, and can directly wait for, and save network resources; the second method can directly know the called state, and the accuracy is high.
  • the control unit 702 may further include the following functions on the basis of the embodiment shown in FIG. 7, FIG. 8 or FIG.
  • the cached call context is searched, it is determined that there is no conflicting call and the context of the current call is buffered, indicating that the MSC continues to connect to the current call.
  • the cached call context needs to distinguish between the primary and the called.
  • This embodiment is also a processing in a special case, and aims to further improve the call completion rate to save network resources.
  • the function of the service control device may be as shown in FIG. 2 to FIG. 6 of the method embodiment, where the interaction between the service control device and the MSC may be controlled by the control unit 702. production.
  • the service control device in the embodiment of the present invention may be implemented based on a computer system, and FIG. 1
  • FIG. 10 illustrates an embodiment of a service control device implemented based on a computer system.
  • the service control device in this embodiment may include: a processor 1001, a memory 1002, and a communication interface 1003.
  • Memory 1002 is used to store program code.
  • the processor 1001 is for executing program code stored in the memory 1002.
  • the memory 1002 stores the first program code
  • the processor 1001 is configured to execute the first program code, and the following operations are performed: in the call setup process, acquiring the calling and called identifier of the current call;
  • the called identity looks up the cached call context, determines whether there is a context of the call that conflicts with the current call; if so, instructs the mobile switching center MSC to release the current call; if not, caches the context of the current call and instructs the MSC to continue the current call
  • the call deletes the context of the current call when the current call is successfully connected or the current call has been released during the connection; wherein the context of the cached current call includes the primary called identity of the current call.
  • the communication interface 1003 is configured to communicate with an external device, such as with the MSC.
  • the messages exchanged between the service control device and the MSC (as shown in Figures 1-6 of the method embodiment) are both transmitted and received via the communication interface 1003.
  • the processor 1001 processes the message received by the communication interface 1003 according to the program code in the memory 1002, and interacts with the external device through the communication interface 1003.
  • the processor 1001 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or the like.
  • the service control device in this embodiment may include a bus 1104.
  • the processor 1101, the memory 1002, and the communication interface 1103 can be connected and communicated via the bus 1104.
  • the memory 1002 may include: a random access memory (RAM), a read-only memory (ROM), a disk and the like having a storage function.
  • the call context in the embodiment of the present invention can be cached in the RAM.
  • the context of the call that conflicts with the current call is specifically the call context that includes the primary called identity of the current call.
  • processor 1001 when performing the above operation of determining whether there is a context of a call that conflicts with the current call, specifically, when finding a call context including the calling and called identity of the current call in the cached call context, determining that there is a conflict with the current call Call. If the cached call context has a distinction between the calling party and the called party, the context of the call that conflicts with the current call is specifically: The called party is the called party of the current call, and the recorded called party is the calling context of the calling party of the current call.
  • the processor 1001 performs the foregoing operation of determining whether there is a context of a call that conflicts with the current call, specifically, the identifier of the recorded caller is found in the cached call context as the called identifier of the current call, and the recorded When the called party's identity is the calling context of the calling identity of the current call, it is determined that there is a call that conflicts with the current call.
  • the memory 1002 also stores the second program code, and the processor 1001 is further configured to execute the second program code, including: performing the following operations: if the busy event is received during the process of connecting the current call, delaying Waiting, when the preset delay time is reached, an instruction to reconnect the current call is sent to the MSC.
  • the memory 1002 further stores a third program code, where the processor 1001 is further configured to execute the third program code, including: performing real-time detection of the called state of the current call, when detecting that the called party resumes the idle state, An instruction to reconnect the current call is sent to the MSC.
  • the service processing device instructs the MSC to connect to the current call, the MSC according to the called terminal's subscription information (eg, T-CSI)
  • a message eg, an IDP message
  • triggering a conflicting service is sent to the service processing device.
  • the memory 1002 further stores a fourth program code
  • the processor 1001 is further configured to execute the fourth program code, including: performing the following operations: if the MSC is received at the detection point during the connection of the current call The initial detection point IDP message initiated by the DP) 12, the processor 1001 searches for the cached call context, determines that there is no conflicting call, and the context of the current call is buffered, instructing the MSC to continue to connect to the current call. In the case of a call collision in this case, the cached call context needs to distinguish between the primary and the called.
  • Embodiments of the present invention further provide a system embodiment for implementing the steps in the foregoing method embodiments.
  • Figure 11 illustrates an embodiment of a system for handling call collisions.
  • the system for handling call conflicts includes: a service control device 1101 and a mobile switching center (MSC) 1102.
  • the specific structure of the service control device 1101 may refer to the device embodiment part of the service control device, such as the service control device in FIG. 7, FIG. 8, FIG. 9, and FIG.
  • the MSC is configured to process the current call according to the indication delivered by the service control device 1101. If the solution of the embodiment of the present invention is applied to an intelligent network, the service control device 1101 and the MSC 1102 may be based on a customized appl ica t ions for mobi le network enhanced log ic (CAMEL) protocol. Communicate.
  • the service control device 1101 may be an SCP in an intelligent network.
  • a service switching point (SSP) in the intelligent network can be deployed on the MSC 1102, and the MSC 1102 interacts with the service control device 1101 through the SSP.
  • SSP service switching point
  • Computer readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one location to another.
  • a storage medium may be any available media that can be accessed by a computer.
  • computer readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage media or other magnetic storage device, or can be used for carrying or storing in the form of an instruction or data structure.
  • the desired program code and any other medium that can be accessed by the computer may suitably be a computer readable medium.
  • the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable , fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwaves are included in the fixing of the associated media.
  • coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwaves are included in the fixing of the associated media.
  • a disk (Disk) and discs (CDs) include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy discs, and Blu-ray discs, where discs are usually magnetically replicated, while discs are laser-reproduced optically. . Combinations of the above should also be included within the scope of the computer readable media.

Landscapes

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

Abstract

本发明公开了一种处理呼叫冲突的方法、系统和业务控制设备，该方法包括：在呼叫建立过程中，业务控制设备获取当前呼叫的主被叫标识；根据该主被叫标识查找緩存的呼叫上下文，确定是否有与当前呼叫相冲突的呼叫的上下文；若有，则指示MSC释放当前呼叫；若没有，则緩存当前呼叫的上下文，并指示MSC接续当前呼叫，当成功接续当前呼叫或在接续过程中发现当前呼叫已被释放时，删除当前呼叫的上下文；其中，緩存的当前呼叫的上下文包括当前呼叫的主被叫标识。应用本发明实施例，在一定程度上提高了呼叫接通率，减少呼损。

Description

一种处理呼叫冲突的方法、 系统和业务控制设备
技术领域 本发明涉及通信技术领域， 特别涉及一种处理呼叫冲突的方法、 系统 和业务控制设备。
背景技术 在现有的呼叫过程中， 若终端 A呼叫终端 B的时候， 终端 B正向终端 A 发起呼叫， 此时， 发生呼叫冲突， 终端 A和终端 B发起的呼叫均会遇忙， 从而无法成功建立 A与 B之间的呼叫， 降低了呼叫成功率。
发明内容 本发明实施例提供一种处理呼叫冲突的方法、 系统和业务控制设备， 以提高呼叫成功率。
第一方面， 处理呼叫冲突的方法包括：
在呼叫建立过程中， 业务控制设备获取当前呼叫的主被叫标识； 根据该主被叫标识查找緩存的呼叫上下文， 确定是否有与当前呼叫相 冲突的呼叫的上下文；
若有， 则指示移动交换中心 MSC释放当前呼叫；
若没有， 则緩存当前呼叫的上下文， 并指示 MSC接续当前呼叫， 当成 功接续当前呼叫或在接续过程中发现当前呼叫已被释放时， 删除当前呼叫 的上下文； 其中， 緩存的当前呼叫的上下文包括当前呼叫的主被叫标识。
在第一方面的第一种可能的实现方式中， 在接续当前呼叫的过程中， 若接收到遇忙事件， 业务控制设备进行延时等待， 达到预设延时时长时向 MSC发送重新接续当前呼叫的指令。
在第一方面的第二种可能的实现方式中， 在接续当前呼叫的过程中， 若接收到遇忙事件， 业务控制设备实时检测当前呼叫的被叫状态， 当检测 到所述被叫恢复空闲状态时， 向 MSC发送重新接续当前呼叫的指令。
结合第一方面或第一方面的第一种可能的实现方式或第一方面的第二 种可能的实现方式， 在第三种可能的实现方式中， 若緩存的呼叫上下文中 未区分主被叫， 则与当前呼叫相冲突的呼叫的上下文具体为包含有当前呼 叫的主被叫标识的呼叫上下文。
结合第一方面或第一方面的第一种可能的实现方式或第一方面的第二 种可能的实现方式， 在第四种可能的实现方式中， 若緩存的呼叫上下文中 有区分主被叫， 则与当前呼叫相冲突的呼叫的上下文具体为： 记录的主叫 为当前呼叫的被叫， 且记录的被叫为当前呼叫的主叫的呼叫上下文。
结合第一方面的第四种可能的实现方式， 在第五种可能的实现方式中， 在接续当前呼叫过程中，若接收到 MSC在检测点 DP12发起的初始检测点 IDP 消息， 业务控制设备查找緩存的呼叫上下文， 确定没有与当前呼叫相冲突 的呼叫的上下文， 且当前呼叫的上下文已緩存时， 指示 MSC继续接续当前 呼叫。
第二方面， 业务控制设备包括：
获取单元， 用于在呼叫建立过程中， 获取当前呼叫的主被叫标识； 控制单元， 用于根据所述获取单元获取的主被叫标识查找緩存的呼叫 上下文， 确定是否有与当前呼叫相冲突的呼叫的上下文； 若有， 则指示移 动交换中心 MSC释放当前呼叫； 若没有， 则緩存当前呼叫的上下文， 并指 示所述 MSC接续当前呼叫， 当成功接续当前呼叫或在接续过程中发现当前 呼叫已被释放时， 删除当前呼叫的上下文； 其中， 所述緩存的当前呼叫的 上下文包括当前呼叫的主被叫标识。
在第二方面的第一种可能的实现方式中， 业务控制设备还包： 括延时 单元， 用于监控延时时长， 当到达预设延时时长时， 通知所述控制单元； 控制单元还用于在接续当前呼叫的过程中， 若接收到遇忙事件， 则进行延 时等待， 并触发所述延时单元启动监控， 当接收到所述延时单元发送的达 到预设延时时长的通知时， 向所述 MSC发送重新接续当前呼叫的指令。
在第二方面的第二种可能的实现方式中， 业务控制设备还包： 检测单 元， 用于实时检测当前呼叫的被叫状态， 当检测到所述被叫恢复空闲状态 时通知所述控制单元； 控制单元还用于在接续当前呼叫的过程中， 若接收 到遇忙事件， 则触发所述检测单元启动检测， 当接收到所述检测单元发送 的所述被叫恢复空闲状态的通知时， 向所述 MSC发送重新接续当前呼叫的 指令。
在第三种可能的实现方式中， 结合第二方面或第二方面的第一种可能 的实现方式或第二方面的第二种可能的实现方式， 若緩存的呼叫上下文中 未区分主被叫， 则与当前呼叫相冲突的呼叫的上下文具体为包含有当前呼 叫的主被叫标识的呼叫上下文。
在第四种可能的实现方式中， 结合第二方面或第二方面的第一种可能 的实现方式或第二方面的第二种可能的实现方式， 若緩存的呼叫上下文中 有区分主被叫， 则与当前呼叫相冲突的呼叫的上下文具体为： 记录的主叫 为当前呼叫的被叫， 且记录的被叫为当前呼叫的主叫的呼叫上下文。
在第五种可能的实现方式中， 结合第二方面的第四种可能的实现方式， 处理单元还用于在接续当前呼叫的过程中， 若从通信单元接收到所述 MSC 在监测点 DP12发起的初始检测点 IDP消息， 则查找存储单元中緩存的呼叫 上下文， 确定没有与当前呼叫相冲突的呼叫的上下文， 且当前呼叫的上下 文已緩存时， 所述 MSC继续接续当前呼叫。
第三方面， 处理呼叫冲突的系统， 包括移动交换中心 MSC 以及第二方 面或第二方面的第一种可能的实现方式或第二方面的第二种可能的实现方 式或第二方面的第三种可能的实现方式或第二方面的第四种可能的实现方 式或第二方面的第五种可能的实现方式中的业务控制设备； 其中， MSC用于 根据所述业务控制设备下发的指示对当前呼叫进行处理。
本发明实施例中， 由于在成功接续当前呼叫或在接续过程中发现当前 呼叫已被释放时将当前呼叫的上下文删除， 从而确保业务控制设备緩存的 上下文为正处于呼叫建立过程中的呼叫的上下文。 因此， 在接收到呼叫时， 业务控制设备可以根据緩存的呼叫上下文来确定是否存在呼叫冲突， 当存 在呼叫冲突时将当前呼叫释放掉， 从而在一定程度上保证了另一呼叫的成 功接续， 提高了呼叫接通率， 避免了网络资源的浪费。
附图说明 为了更清楚地说明本发明实施例的技术方案， 下面将对实施例中所需 要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本发 明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动的 前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明实施例提供的处理呼叫冲突的方法流程图；
图 2为本发明实施例提供的场景 1下的呼叫冲突处理方法流程图； 图 3为场景 1下的呼叫冲突处理方法的另一实施例的流程图； 图 4为本发明实施例提供的场景 2下的呼叫冲突处理方法的流程图； 图 5为场景 2下的呼叫冲突处理方法的另一实施例的流程图； 图 6为本发明实施例提供的场景 3下的呼叫冲突处理方法的流程图； 图 7为本发明实施例提供业务控制设备的结构示意图；
图 8为本发明另一实施例提供业务控制设备的结构示意图；
图 9为本发明另一实施例提供业务控制设备的结构示意图；
图 10为本发明实施例提供基于计算机系统的业务控制设备的结构示意 图； 图 11为本发明实施例提供解决呼叫冲突的系统的结构示意图。
具体实施方式 下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没 有作出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的 范围。
在主叫终端呼叫被叫终端的过程中， 被叫终端也正处于呼叫主叫终端 的过程中， 这种现象在本发明实施例中被称之为呼叫冲突。 图 1 为本发明 实施例提供的处理呼叫冲突的方法流程图， 如图所示， 该实施例中处理呼 叫冲突的方法包括：
S100, 在呼叫建立过程中， 业务控制设备获取当前呼叫的主被叫标识； 其中， 业务控制设备是在呼叫过程中进行业务处理并进行呼叫控制的 设备， 比如， 智能网中的业务控制点 （service control point, SCP ), 在 本发明实施例中用于处理呼叫冲突业务。 呼叫冲突业务是用于解决呼叫冲 突的业务。
移动交换中心 （mobile switching center, MSC )接收到主叫终端发 起的呼叫后， 若确定主叫或被叫终端签约了呼叫冲突业务， 则向业务控制 设备发送用于触发呼叫冲突业务的消息， 如初始检测点 （initial domain part, IDP) 消息， 业务控制设备从该消息中获取当前呼叫的主被叫标识。
其中， MSC 可以根据主叫或被叫的签约信息确定是否签约呼叫冲突业 务， 该签约信息可以是移动网增强逻辑的用户应用签约信息（customized applications for mobile network enhanced logic (CAMEL) subscription inf ormat ion, CSI)。 可选的， MSC也可以默认所有用户都签约了呼叫冲突业务， 在接收到呼 叫后按照预先配置的业务控制设备的地址， 向业务控制设备发送触发呼叫 冲突业务的消息。
S102 , 根据该主被叫标识查找緩存的呼叫上下文， 确定是否存在与当 前呼叫相冲突的呼叫的上下文； 若有， 则执行 S104; 若没有， 则执行 S106; 其中， 业务控制设备緩存有正处于呼叫建立过程中的呼叫的上下文， 每个呼叫的上下文中都包括该呼叫的主被叫标识。 业务控制设备通过查找 已緩存的呼叫上下文可以确定是否存在冲突呼叫。 当然， 业务控制设备可 以在本地緩存呼叫上下文， 也可以将呼叫上下文緩存在外部的存储设备中。
具体的， 业务控制设备在緩存的呼叫上下文时可不区分主被叫 （即仅 緩存主被叫的标识本身）， 也可以区分主被叫 （即除緩存主被叫的标识本身 外， 还标记出该标识是属于主叫还是被叫）。
若緩存的呼叫上下文中未区分主被叫， 与当前呼叫相冲突的呼叫的上 下文具体为包含有当前呼叫的主被叫标识的呼叫上下文。 业务控制设备在 緩存的呼叫上下文中查找出包含当前呼叫的主被叫标识的呼叫上下文时， 确定存在与当前呼叫冲突的呼叫。
通常情况下， 根据緩存的呼叫上下文中是否有包含该主被叫标识的呼 叫上下文即可确定是否存在呼叫冲突。 在一些特定需求下， 如在同一个呼 叫中第二次向业务控制设备发送用于触发呼叫冲突业务的消息时， 可以进 一步确定呼叫上下文中的记录的主叫是否为当前呼叫的被叫， 被叫是否为 当前呼叫的主叫， 以免将该呼叫自身作为冲突呼叫， 因为该呼叫第一次触 发呼叫冲突业务时緩存了该呼叫的上下文。 具体的， 若緩存的呼叫上下文 中有区分主被叫， 则与当前呼叫相冲突的呼叫的上下文具体为： 记录的主 叫为当前呼叫的被叫， 且记录的被叫为当前呼叫的主叫的呼叫上下文。 业 务控制设备在緩存的呼叫上下文中查找出有呼叫上下文， 其记录为主叫的 标识为当前呼叫的被叫标识， 且该呼叫上下文记录为被叫的标识为当前呼 叫的主叫标识时， 确定存在与当前呼叫冲突的呼叫。
S104 , 指示 MSC释放当前呼叫。
具体的， 业务控制设备向 MSC发送释放当前呼叫的指令， 如释放呼叫 ( re lea se ca l l , RC )信令， MSC根据该指令释放当前呼叫。
S106 , 緩存当前呼叫的上下文， 并指示 MSC接续当前呼叫， 当成功接 续当前呼叫时或在接续过程中发现当前呼叫已被释放时， 删除当前呼叫的 上下文； 其中， 緩存的当前呼叫的上下文包括当前呼叫的主被叫标识。
具体的， 在不存在冲突呼叫的情况下， 业务控制设备向 MSC发送接续 当前呼叫的指令， 如接续 （cont inue ) 消息， 指示 MSC接续当前呼叫。 其 中， 业务控制设备可以以接收到 MSC 上报的被叫应答消息来确定成功接续 当前呼叫， 以接收到 MSC上报的释放事件来确定在接续过程中发现当前呼 叫已被释放。
步骤 S106中緩存的上下文在后续处理中可作为判断呼叫冲突的依据， 比如， 在删除当前呼叫的上下文以前， 接收到当前呼叫的被叫向当前呼叫 的主叫发起的呼叫， 此时， 业务控制设备可根据緩存的呼叫上下文确定存 在冲突的呼叫。
上述实施例中， 由于在成功接续当前呼叫时或在接续过程中发现当前 呼叫已被释放时将当前呼叫的上下文删除， 从而确保业务控制设备緩存的 上下文为正处于呼叫建立过程中的呼叫的上下文。 因此， 在接收到呼叫时， 业务控制设备可以根据緩存的呼叫上下文来确定是否存在呼叫冲突， 当存 在呼叫冲突时将当前呼叫释放掉， 从而在一定程度上保证了与当前呼叫冲 突的另一呼叫的成功接续， 提高了呼叫接通率， 避免了网络资源的浪费。
由于在呼叫建立过程中， 信令传送存在延时， 因此， 在一些特殊场景 下， 还需要进行进一步的处理。 比如， 在前述步骤 S1 06之后， MSC接收到 接续当前呼叫指示， 并将终端 A发起的呼叫接续到终端 B时， 终端 B向终 端 A发起的呼叫还未来得及释放(从释放到终端恢复空闲状态有一定时延；)， 此时， 会出现遇忙的情况， MSC会向业务控制设备上报遇忙事件。 因此， 为 了解决此特殊情况， 业务处理设备还可以在图 1 所示实施例的基础上进行 进一步的处理。 具体可釆用下述两种处理方式：
方式一： 在接续当前呼叫的过程中， 若接收到遇忙事件， 业务控制设 备进行延时等待， 达到预设延时时长时向 MSC发送重新接续当前呼叫的指 令。 其中， 预设延时时长可以根据经验值预先设定， 比如 10秒。
方式二： 在接续当前呼叫的过程中， 若接收到遇忙事件， 业务控制设 备实时检测当前呼叫的被叫状态， 当检测到所述被叫恢复空闲状态时， 向 MSC发送重新接续当前呼叫的指令。
通过上述处理， 解决了一些特殊情况下接续不成功的问题， 使得呼叫 接通率得到了更进一步的提高。 而且上述两种方式各有优点， 方式一的处 理无需和其它设备交互， 直接等待即可， 节省网络资源； 方式二可直接获 知被叫状态， 精确度高。
此外， 在主被叫双方均签约了呼叫冲突业务的情况， 还可能会出现以 下情况： 当业务处理设备指示 MSC接续当前呼叫后， MSC根据被叫终端的签 约信息（如， T-CSI )再次向该业务处理设备发送用于触发冲突业务的消息 (如， IDP消息）。 此时， 业务处理设备在图 1或上述其它实施例的基础上 还可以进一步包括如下处理： 在接续当前呼叫过程中， 若接收到 MSC在检 测点 （detect ion point, DP ) 12发起的初始检测点 IDP消息时， 业务控 制设备查找緩存的呼叫上下文， 确定不存在冲突呼叫且当前呼叫的上下文 已緩存， 指示 MSC继续接续当前呼叫。 本实施例也是对特殊情况下的处理， 目的在于进一步的提高呼叫接通率， 以节约网络资源。
本发明实施例的方案可以应用在智能网或其它网络中， 为了便于理解， 本发明实施例均以智能网中的消息为例进行说明， 在应用到其它网络中时， 可替换为其它网络中具有类似功能的消息。
若以智能网来实现本发明实施例提供的方案， 需要在归属位置寄存器 (home location register, HLR ) 中为用户签约呼叫冲突业务。 即在图 1 所示的步骤 S100之前还包括预先进行签约信息设置， 签约信息设置过程如 下： HLR 制作并保存用户的签约信息， 包括始发 CAMEL 签约信息
( originating CAMEL subscription information, 0-CSI )和终止 CAMEL 签约信息 （ terminated CAMEL subscription information, T-CSI )。 O-CSI 和 T-CSI中的业务键为呼叫冲突业务的业务键， 0-CSI和 T-CSI中的地址为 处理呼叫冲突业务的业务控制设备的地址。 若签约用户做主叫， MSC根据该 用户的 0-CSI 向业务控制设备发送用于触发呼叫冲突业务的消息， 若签约 用户做被叫， MSC根据该用户的 T-CSI向业务控制设备发送用于触发呼叫冲 突业务的消息。 前述步骤 S100中业务控制设备获取当前呼叫的主被叫标识 可具体包括： 业务控制设备接收移动交换中心根据主叫或被叫的签约信息 发送的用于触发呼叫冲突业务的消息， 并从该消息中获取当前呼叫的主被 叫标识。
下面以具体的应用场景对本发明实施例进行进一步的说明， 以下场景 均以智能网为例， 因此， 在以下实施例中业务控制设备为智能网中的 SCP。
场景 1: 终端 A签约有呼叫冲突业务， 终端 B未签约呼叫冲突业务， 其 中，终端 A到终端 B的呼叫称为呼叫 a,终端 B到终端 A的呼叫称为呼叫 b, ^^定呼叫 a先于呼叫 b发生。
图 2为场景 1下的呼叫冲突处理方法流程图， 如图所示， 本实施例中 呼叫冲突处理方法包括：
a201: 终端 A的拜访地移动交换中心 MSCa接收终端 A发起的对终端 B 的呼叫 a;
a 202: MSCa根据终端 A的 0-CSI向 SCP发送用于触发呼叫冲突业务的 IDP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 a的主被叫标识。 终端 A 的签约信息 0-CSI 可以从拜访地位置寄存器 （visitor location register, VLR)获得。 其中， VLR可以与 MSC合设在一个物理实体中， 也 可以是两个独立的物理实体。 本发明实施例以 VLR可以与 MSC合设为例进 行说明。
a203: SCP获取呼叫 a的主被叫标识， 以获取的主被叫标识查找緩存的 呼叫上下文， 确定不存在与呼叫 a冲突的呼叫；
其中， 每个呼叫上下文中包括相应呼叫的主被叫标识， 通过查找已緩 存的呼叫上下文， 可以确定是否有包含呼叫 a的主被叫标识的呼叫上下文， 从而确定是否存在与呼叫 a冲突的呼叫，本实施例中由于呼叫 a先于呼叫 b 发生， 因此， 查找不到包含呼叫 a的主被叫标识的呼叫上下文。
a204: 緩存呼叫 a的上下文， 其中， 緩存的呼叫 a的上下文包括呼叫 a 的主被叫标识；
具体的， 在緩存呼叫上下文的时候， 可以不对主被叫标识加以区分， 直接存储标识 A和标识 B。
a205: 向 MSC发送 continue消息， 指示 MSC接续呼叫 a;
可选的， 在发送 continue消息时， 可进一步向 MSC发送请求^艮告基本 呼叫状态模型事件（ request report ( Basic Call State Mode, BCSM) event RRBE) 消息， 该 RRBE消息用于指示 MSCa监测被叫应答、 忙、 无应答、 不 可达等事件， 该处理可参考现有技术来实现。
需要说明的是步骤 a204和 a205在执行时并没有先后顺序限制。
a206:MSCa向终端 B的拜访地 MSCb发送初始地址消息（ Initial Address
Message, I AM );
在 MSCa将呼叫 a接续到终端 B之前， 即在步骤 a206之前， 如果终端 B 发起了呼叫 b, SCP对呼叫 b的处理， 具体如下：
b201: 终端 B的拜访地移动交换中心 MSCb接收终端 B发起的对终端 A 的呼叫 b;
b202: MSCb根据被叫 （终端 A) 的 T-CSI向 SCP发送用于触发呼叫冲 突业务的 IDP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 b的主被叫标识。 b203: SCP获取呼叫 b的主被叫标识， 以获取的主被叫标识查找緩存的 呼叫上下文， 确定存在与呼叫 b冲突的呼叫；
由于呼叫 a先于呼叫 b发生， 在 a204中已緩存包含终端 A标识和终端
B标识的呼叫上下文， 因此， 在本步骤中可以查找到包含呼叫 b的主被叫标 识的呼叫上下文， 从而确定存在冲突呼叫。
b204: 向 MSCb发送 RC消息， 指示 MSCb释放呼叫 b;
b205: MSCb释放呼叫 b的资源， 使 B终端恢复到空闲状态。
本实施例中， 对呼叫 b的处理在步骤 a206之前完成， 因此， 在 MSC接 收到 IAM消息时， 呼叫 b已经被释放， 所以呼叫 a可以被成功接续， 具体 的过程如下：
步骤 a207: MSCb寻呼终端 B 并向 MSCa 返回地址全消息 （address complete message, ACM);
a208: 在被叫终端应答后， MSCb向 MSCa发送地址应答消息 （address answer message, ANM );
a209: MSCa向 SCP发送基本呼叫状态模型事件上报（ event report basic call state model, ERB ) 消息来上报应答事件；
a210: SCP向 MSCa发送 Continue消息指示 MSCa接通呼叫 a;
a211: SCP删除緩存的呼叫 a的上下文。
需要说明的是步骤 a210和 a211在执行时并没有先后顺序限制。
a212: 呼叫 a成功建立， 终端 A和终端 B开始通话。
由于信令传送存在延时， 因此， 有可能存在虽然呼叫 b发生在 MSCa将 呼叫 a接续到终端 B之前， 但在步骤 a206之前未来得及释放的情况， 对于 此情况， 处理如图 3所示， 图 3为场景 1下的呼叫冲突处理方法的另一实 施例的流程图， 本实施例中呼叫冲突处理方法包括： a 301: 终端 A的拜访地移动交换中心 MSCa接收终端 A发起的对终端 B 的呼叫 a;
a 302: MSCa根据终端 A的 0-CSI向 SCP发送用于触发呼叫冲突业务的 IDP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 a的主被叫标识。 a303: SCP获取呼叫 a的主被叫标识， 以获取的主被叫标识查找緩存的 呼叫上下文， 确定不存在与呼叫 a冲突的呼叫；
其中， 每个呼叫上下文中包括相应呼叫的主被叫标识， 通过查找已緩 存的呼叫上下文， 可以确定是否有包含呼叫 a的主被叫标识的呼叫上下文， 从而确定是否存在与呼叫 a冲突的呼叫，本实施例中由于呼叫 a先于呼叫 b 发生， 因此， 查找不到包含呼叫 a的主被叫标识的呼叫上下文。
a304: 緩存呼叫 a的上下文， 其中， 緩存的呼叫 a的上下文包括呼叫 a 的主被叫标识；
具体的， 在緩存呼叫上下文的时候， 可以不区分主被叫。
a305: 向 MSC发送 continue消息， 指示 MSC接续呼叫 a;
可选的， 在发送 continue消息时， 可进一步向 MSC发送请求^艮告基本 呼叫状态模型事件 ( request report BCSM ( basic call state mode ) event, RRBE) 消息， 该 RRBE消息用于指示 MSCa监测被叫应答、 忙、 无应答、 不 可达等事件， 该处理可参考现有技术来实现。
需要说明的是步骤 a304和 a305在执行时并没有先后顺序限制。
a306:MSCa向终端 B的拜访地 MSCb发送初始地址消息（ initial address message, I AM );
在 MSCa将呼叫 a接续到终端 B之前， 即在步骤 a306之前， 如果终端 B 发起了呼叫 b, SCP对呼叫 b进行处理， 步骤 b301-b305为呼叫 b的处理过 程， 其中步骤 b301-b305的处理过程可参考图 1所示的步骤 b201-b205o 只是在本实施例中， 对呼叫 b的处理在步骤 a306之前尚未完成的， 因 此， 在 MSC接收到 IAM消息时， 呼叫 b未被释放， 所以呼叫 a无法成功接 续。 此时， 对呼叫 a的后续处理包括：
a307: MSCb向 MSCa返回 REL消息通知接续失败， 并携带原因值： 被叫 忙
a308: MSCa向 SCP发送 ERB消息， 上报遇忙事件；
a 309: SCP进行延时等待；
此处延时是为了等待呼叫 b的处理完成， 终端 B恢复到空闲状态， 延 时时长可以根据经验值预先设置。 为了精确度更高， 本步骤还可以釆用另 一种替代方式， 即 SCP实时检测终端 B的状态， 当检测到终端 B恢复空闲 状态时， 向 MSC发送 Reconnect消息。
a310: 在延时达到预设延时时长时向 MSC发送 Reconnect消息， 指示 MSC重新接续呼叫 a;
a311: MSCa向 MSCb发送環。
此后 a312-a317的处理可参考图 2中的 a207-a212, 这里不再赘述。 场景 2:终端 A和终端 B均签约有呼叫冲突业务，并且归属于相同 SCP。 其中， 终端 A到终端 B的呼叫称为呼叫 a, 终端 B到终端 A的呼叫称为呼叫 b, ^^定呼叫 a先于呼叫 b发生。
图 4为场景 2下的呼叫冲突处理方法流程图， 如图所示， 该实施例中 呼叫冲突处理方法包括：
a401: 终端 A的拜访地移动交换中心 MSCa接收终端 A发起的对终端 B 的呼叫 a;
a402: MSCa根据终端 A的 0-CSI向 SCP发送用于触发呼叫冲突业务的 IDP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 a的主被叫标识。 a403: SCP获取呼叫 a的主被叫标识， 以获取的主被叫标识查找緩存的 呼叫上下文， 确定不存在与呼叫 a冲突的呼叫； 其中， 每个呼叫上下文中包括相应呼叫的主被叫标识， 通过查找已緩 存的呼叫上下文， 可以确定是否有包含呼叫 a的主被叫标识的呼叫上下文， 从而确定是否存在与呼叫 a冲突的呼叫，本实施例中由于呼叫 a先于呼叫 b 发生， 因此， 查找不到包含呼叫 a的主被叫标识的呼叫上下文。
a404: 緩存呼叫 a的上下文， 其中， 緩存的呼叫 a的上下文包括呼叫 a 的主被叫标识；
本实施例中， 在緩存呼叫上下文的时候需要对主被叫加以区分， 如釆 用 "主叫标识 =A , 被叫标 的形式。
a405: 向 MSC发送 cont inue消息， 指示 MSC接续呼叫 a;
可选的， 在发送 cont inue消息时， 可进一步向 MSC发送请求^艮告基本 呼叫状态模型事件 ( reques t repor t BCSM ( bas ic ca l l s ta te mode ) event, RRBE ) 消息， 该 RRBE消息用于指示 MSCa监测被叫应答、 忙、 无应答、 不 可达等事件， 该处理可参考现有技术来实现。
需要说明的是步骤 a404和 a405在执行时并没有先后顺序限制。
a406: MSCa根据被叫 （终端 B ) 的 T-CS I向 SCP发送用于触发呼叫冲 突业务的 IDP消息；
由于终端 B也签约了呼叫冲突业务， MSCa根据被叫的 T-CS I触发 IDP 消息， 此次触发为检测点 DP12触发。 IDP消息中携带呼叫冲突业务的业务 键和呼叫 a的主被叫标识。 其中， MSCa可以从终端 B的 HLR获得终端 B的 签约信息 T- CSI。
a407: SCP接收到 MSCa在 DP12触发的 IDP消息后， 查找緩存的呼叫上 下文， 确定不存在冲突呼叫且呼叫 a的上下文已緩存；
由于步骤 a404中已緩存呼叫 a的上下文， 此处查找的时候会发现有包 含呼叫 a 的主被叫标识的呼叫上下文， 由于此处查找出来的呼叫上下文中 的主叫标识为 A , 被叫标识为 B, 与呼叫 a的主被叫标识一致， 因此， 不存 在冲突呼叫且呼叫 a的呼叫上下文已緩存， 因此， SCP将直接指示 MSC继续 接续呼叫 a。
a408 : SCP向 MSCa发送 cont inue消息， 指示 MSC继续接续呼叫 a。 a409 : MSCa向终端 B的拜访地 MSCb发送 I AM;
在 MSCa将呼叫 a接续到终端 B之前， 即在步骤 a409之前， 如果终端 B 发起了呼叫 b , SCP对呼叫 b的处理， 具体如下：
b401 : 终端 B的拜访地移动交换中心 MSCb接收终端 B发起的对终端 A 的呼叫 b;
b402 : MSCb根据终端 B的 0-CS I向 SCP发送用于触发呼叫冲突业务的 IDP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 b的主被叫标识。 b403: SCP获取呼叫 b的主被叫标识， 以获取的主被叫标识查找緩存的 呼叫上下文， 确定存在与呼叫 b冲突的呼叫；
由于呼叫 a先于呼叫 b发生， 在 a404中已緩存包含终端 A标识和终端 B标识的呼叫上下文， 因此， 在本步骤中可以查找到包含呼叫 b的主被叫标 识的呼叫上下文， 从而确定存在冲突呼叫。
b404 : 向 MSCb发送 RC消息， 指示 MSCb释放呼叫 b;
b405 : MSCb释放呼叫 b的资源， 使 B终端恢复到空闲状态。
本实施例为对呼叫 b的处理在步骤 a409之前完成的情况，因此，在 MSC 接收到步骤 a409中发送的 IAM消息时， 呼叫 b已经被释放， 所以呼叫 a可 以被成功接续， 具体的过程为：
步骤 a410: MSCb寻呼终端 B并向 MSCa返回 ACM;
此后步骤 a411-a415的处理可参考图 2中的 a208-a212 ,这里不再赘述。 类似的， 在场景 2中， 也可能存在虽然呼叫 b发生在 MSCa将呼叫 a接 续到终端 B之前， 但在步骤 a409之前未来得及释放的情况， 对于此情况， 处理如图 5所示， 图 5为场景 1下的呼叫冲突处理方法的另一实施例的流 程图， 该实施例中呼叫冲突处理方法包括： 其中， 步骤 a501-a509的处理可参考图 4中的 a401-a409, 这里不再赞 述。
在 MSCa将呼叫 a接续到终端 B之前， 即在步骤 a509之前， 如果终端 B 发起了呼叫 b, SCP对呼叫 b进行处理， 步骤 b501-b505为呼叫 b的处理过 程， 其中， 步骤 b501_b505的处理过程可参考步骤 b401_b405。
只是本实施例中， 对呼叫 b的处理在步骤 a409之前尚未完成， 因此与 图 3所示实施例类似， 在步骤 a510: MSCb向 MSCa返回 REL消息通知接续 失败， 并携带原因值： 忙；
a511: MSCa向 SCP发送 ERB消息， 上报遇忙事件;
a512: SCP进行延时等待；
此处延时是为了等待呼叫 b的处理完成， 终端 B恢复到空闲状态， 延 时时长可以根据经验值预先设置。 为了精确度更高， 本步骤还可以釆用另 一种替代方式， 即 SCP实时检测终端 B的状态， 当检测到终端 B恢复空闲 状态时， 向 MSC发送 Reconnect消息。
a513: 在延时达到预设延时时长时向 MSC发送 Reconnect消息， 指示
MSC重新接续呼叫 a;
a514: MSCa向 MSCb发送 IAM。
此后 a515-a520的处理可参考图 2中的 a207-a212, 这里不再赘述。 场景 3:终端 A和终端 B均签约有呼叫冲突业务，并且归属于不同 SCP, 终端 A归属于 SCPa, 终端 B归属于 SCPb。 其中， 终端 A到终端 B的呼叫成 为呼叫 a,终端 B到终端 A的呼叫成为呼叫 b, 4艮定呼叫 a先于呼叫 b发生。
图 6为场景 3下的呼叫冲突处理方法的流程图， 如图所示， 该实施例 中， 呼叫冲突处理方法包括：
a601: 终端 A的拜访地移动交换中心 MSCa接收终端 A发起的对终端 B 的呼叫 a;
a 602: MSCa根据终端 A的 0-CSI向 SCPa发送用于触发呼叫冲突业务的 I DP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 a的主被叫标识。 a603: SCPa获取呼叫 a的主被叫标识， 以获取的主被叫标识查找緩存 的呼叫上下文， 确定不存在与呼叫 a冲突的呼叫；
其中， 每个呼叫上下文中包括相应呼叫的主被叫标识， 通过查找已緩 存的呼叫上下文， 可以确定是否有包含呼叫 a的主被叫标识的呼叫上下文， 从而确定是否存在与呼叫 a冲突的呼叫，本实施例中由于呼叫 a先于呼叫 b 发生， 因此， 查找不到包含呼叫 a的主被叫标识的呼叫上下文。
a604: 緩存呼叫 a的上下文， 其中， 緩存的呼叫 a的上下文包括呼叫 a 的主被叫标识；
本实施例中， 在緩存呼叫上下文的时候可以不对主被叫加以区分。 a605: 向 MSC发送 cont inue消息， 指示 MSC接续呼叫 a;
可选的， 在发送 cont inue消息时， 可进一步向 MSC发送请求^艮告基本 呼叫状态模型事件 ( reques t repor t BCSM ( bas ic ca l l s ta te mode, ) event RRBE ) 消息， 该 RRBE消息用于指示 MSCa监测被叫应答、 忙、 无应答、 不 可达等事件， 该处理可参考现有技术来实现。
需要说明的是步骤 a604和 a605在执行时并没有先后顺序限制。
a606: MSCa根据被叫 （终端 B )的 T-CS I向 SCPb发送用于触发呼叫冲 突业务的 IDP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 a的主被叫标识。 此时， 如果在步骤 a606之前呼叫 b 已发生， 且 SCPb中已緩存呼叫 b 的上下文， 即步骤 b604发生在步骤 a606之前， 当 SCPb收到步骤 a606中 的 IDP消息时， SCPb会判断出已存在与呼叫 a冲突的呼叫， 因此， 会将呼 叫 a释放掉， 具体处理参见步骤 a607_a612.
在步骤 a607 : SCPb获取呼叫 a的主被叫标识， 以获取的主被叫标识查 找緩存的呼叫上下文， 确定存在包含呼叫 a的主被叫标识的呼叫上下文； a608: 向 MSCa发送 RC消息， 指示 MSCa释放呼叫 a;
a609: MSCa向 SCPa发送 ERB消息上报释放事件；
a610: SCPa删除緩存的呼叫 a的上下文；
a611: SCPa向 MSCa发送 RC消息， 指示 MSCa继续释放呼叫 a;
a 612： MSCa释放呼叫 a的资源， 使 A终端恢复到空闲状态。
在本实施例中， 对于呼叫 b的处理如下：
b601: 终端 B的拜访地移动交换中心 MSCb接收终端 B发起的对终端 A 的呼叫 b;
b602: MSCb根据终端 B的 0-CSI向 SCPb发送用于触发呼叫冲突业务的 IDP消息；
其中， IDP消息中携带呼叫冲突业务的业务键和呼叫 b的主被叫标识。 b603: SCPb获取呼叫 b的主被叫标识， 以获取的主被叫标识查找緩存 的呼叫上下文， 确定不存在在与呼叫 b冲突的呼叫；
由于步骤 b603发生在步骤 a606之前， 因此， SCPb中不存在包含呼叫 b的主被叫标识的呼叫上下文， 从而确定不存在与呼叫 b冲突的呼叫。
b604: 緩存呼叫 b的上下文， 其中， 緩存的呼叫 b的上下文包括呼叫 b 的主被叫标识；
具体的， 在緩存呼叫上下文的时候， 可以不对主被叫标识加以区分， 直接存储标识 A和标识 B。
b605: 向 MSCb发送 continue消息， 指示 MSCb接续呼叫 b;
可选的， 在发送 continue消息时， 可进一步向 MSC发送请求^艮告基本 呼叫状态模型事件 ( request report BCSM ( basic call state mode ) event, RRBE) 消息， 该 RRBE消息用于指示 MSCb监测被叫应答、 忙、 无应答、 不 可达等事件， 该处理可参考现有技术来实现。
需要说明的是， 步骤 b604和 b605在执行时并没有先后顺序限制。 b606: MSCb根据呼叫 b的被叫 （终端 A )的 T-CSI向 SCPa发送用于触 发呼叫冲突业务的 IDP消息；
本实施例以步骤 b606发生在步骤 a 612之后为例进行说明。
b607 : SCPa获取呼叫 b的主被叫标识， 以获取的主被叫标识查找緩存 的呼叫上下文， 确定不存与呼叫 b冲突的呼叫；
由于步骤 b606发生在步骤 a612之后， 呼叫 a已释放且呼叫 a的上下 文已删除， 因此， 查找不到包含呼叫 b 的主被叫标识的呼叫上下文， 从而 确定不存与呼叫 b冲突的呼叫。
b608 : 緩存呼叫 b的上下文， 其中， 緩存的呼叫 b的上下文包括呼叫 b 的主被叫标识；
b609 : 向 MSCb发送 cont inue消息， 指示 MSCb接续呼叫 b;
步骤 b61 0-步骤 b619为呼叫接续过程， 其中步骤 b610-b615可参考步 骤 a206_a211 , 这里不再赘述。
步骤 b615之后， 在步骤 b616 : MSCb向 SCPa发送 ERB消息上报应答事 件；
b617 : SCPa向 MSCb发送 Cont inue消息指示 MSCb接通呼叫 b;
b618 : SCPa删除緩存的呼叫 b的上下文。
需要说明的是步骤 b617和 b618在执行时并没有先后顺序限制。
b619 : 呼叫 b成功建立， 终端 A和终端 B开始通话。
图 6所示仅是场景 3下的一种实施例， 对于其它实施例， 可参考图 2 至图 6所示实施例进行类似处理。 如在场景 3下， 如果呼叫 b发生在步骤 a606之后且在呼叫 a接通到终端 B之前还未来得及释放， 此时会出现在接 续呼叫 a的过程中， SCPa接收到 MSCa上报遇忙事件的情况， 此情况下， 可 参照图 3步骤 a 309-a 310对呼叫 b进行处理。
需要说明的是， 解决上述任一场景下的呼叫冲突问题， 都可在一定程 度上提高呼叫接通率， 减小呼损。 因此， 在实际实施时， 可根据需要， 选 择仅对某些场景下的呼叫冲突问题进行处理。 本发明实施例进一步给出实现上述方法实施例中各步骤的装置实施 例。 图 7 示出了一种业务控制设备的实施例。 在该实施例中， 业务控制设 备包括：
获取单元 701, 用于在呼叫建立过程中， 获取当前呼叫的主被叫标识； 控制单元 702,用于根据所述获取单元 701获取的主被叫标识查找緩存 的呼叫上下文， 确定是否有与当前呼叫相冲突的呼叫的上下文； 若有， 则 指示移动交换中心 MSC释放当前呼叫； 若没有， 则緩存当前呼叫的上下文 緩， 并指示 MSC接续当前呼叫， 当成功接续当前呼叫或在接续过程中发现 当前呼叫已被释放时， 删除当前呼叫的上下文； 其中， 緩存的当前呼叫的 上下文包括当前呼叫的主被叫标识。
具体的， 移动交换中心 ( mobile switching center, MSC)接收到主 叫终端发起的呼叫后， 若确定主叫或被叫终端签约了呼叫冲突业务， 则向 业务控制设备发送用于触发呼叫冲突业务的消息， 如初始检测点（initial domain part, IDP ) 消息， 业务控制设备中的获取单元 701接收到该消息 后， 从该消息中获取当前呼叫的主被叫标识。
其中， MSC 可以根据主叫或被叫的签约信息确定是否签约呼叫冲突业 务， 该签约信息可以是移动网增强逻辑的用户应用签约信息（customized applications for mobile network enhanced logic (CAMEL) subscription information, CSI)。 可选的， MSC也可以默认所有用户都签约了呼叫冲突 业务， 在接收到呼叫后直接向业务控制设备发送触发呼叫冲突业务的消息。 需要说明的是， 呼叫冲突业务的签约信息中可包括 0-CSI和 T-CSI。
获取单元 701将当前呼叫的主被叫标识提供给控制单元 702,控制单元 702根据该主被叫标识查找緩存的呼叫上下文，确定是否存在与当前呼叫相 冲突的呼叫的上下文。 其中， 若緩存的呼叫上下文中未区分主被叫， 与当 前呼叫相冲突的呼叫的上下文具体为包含有当前呼叫的主被叫标识的呼叫 上下文。 控制单元 702 在緩存的呼叫上下文中查找出包含当前呼叫的主被 叫标识的呼叫上下文时， 确定存在与当前呼叫冲突的呼叫。 若緩存的呼叫 上下文中有区分主被叫， 与当前呼叫相冲突的呼叫的上下文具体为： 记录 的主叫为当前呼叫的被叫， 且记录的被叫为当前呼叫的主叫的呼叫上下文。 控制单元 702在緩存的呼叫上下文中查找出有呼叫上下文， 其记录为主叫 的标识为当前呼叫的被叫标识， 且该呼叫上下文记录为被叫的标识为当前 呼叫的主叫标识时， 确定存在与当前呼叫冲突的呼叫。
在上述图 7所示的实施例中， 控制单元 702可以通过向 MSC发送释放 当前呼叫的指令， 如释放呼叫 （re lea se ca l l, RC )信令， 来指示 MSC释 放当前呼叫。 在不存在冲突呼叫的情况下， 控制单元 702 可以通过向 MSC 发送接续当前呼叫的指令， 如接续 （cont inue ) 消息， 指示 MSC接续当前 呼叫。 此外， 控制单元 702 可以以接收到 MSC上报的被叫应答消息来确定 成功接续当前呼叫， 以接收到 MSC上报的释放事件来确定在接续过程中发 现当前呼叫已被释放。
上述实施例中， 通过控制单元 702控制呼叫上下文的緩存， 并根据緩 存的呼叫上下文来确定是否存在呼叫冲突， 以及在确定出存在呼叫冲突时， 将当前呼叫释放掉， 从而在一定程度上保证了与当前呼叫相冲突的另一呼 叫的成功接续， 提高了呼叫接通率， 避免了网络资源的浪费。
由于在呼叫建立过程中， 信令传送存在延时， 因此， 在一些特殊场景 下， 还需要进行进一步的处理。 比如在 MSC接收到控制单元 702发送的接 续指示， 并将终端 A发起的呼叫接续到终端 B时， 终端 B向终端 A发起的 呼叫还未来得及释放（从释放到终端恢复空闲状态有一定时延）， 此时， 会 出现遇忙的情况， MSC会向业务控制设备上报遇忙事件。 因此， 为了解决此 特殊情况， 业务处理设备还可以在图 7 所示实施例的基础上进一步包括延 时单元 703 , 如图 8所示， 图 8为本发明另一实施例提供的业务处理设备的 结构示意图。 其中， 延时单元 703用于监控延时时长， 当到达预设延时时 长时， 通知控制单元 702; 控制单元 702还用于在接续当前呼叫的过程中， 若接收到遇忙事件， 则进行延时等待， 并触发延时单元 703 启动监控， 当 接收到所述延时单元发送的达到预设延时时长的通知时， 向 MSC发送重新 接续当前呼叫的指令。
可选的， 在另一实施例中， 业务处理设备也可以在图 7 所示实施例的 基础上进一步包括检测单元 704 , 如图 9所示， 图 9为本发明另一实施例 提供的业务处理设备的结构示意图。 其中， 检测单元 704 用于实时检测当 前呼叫的被叫状态， 当检测到该被叫恢复空闲状态时通知控制单元 702 ; 控 制单元 702还用于在接续当前呼叫的过程中， 若接收到遇忙事件， 则触发 检测单元 704启动检测， 当接收到检测单元 704发送的被叫恢复空闲状态 的通知时， 向 MSC发送重新接续当前呼叫的指令。
通过上述处理， 解决了一些特殊情况下接续不成功的问题， 使得呼叫 接通率得到了更进一步的提高。 而且上述两种方式各有优点， 方式一的处 理无需和其它设备交互， 直接等待即可， 节省网络资源； 方式二可直接获 知被叫状态， 精确度高。
此外， 在主被叫双方均签约了呼叫冲突业务的情况， 还可能会出现以 下情况： 当业务处理设备指示 MSC接续当前呼叫后， MSC根据被叫终端的签 约信息（如， T-CS I )再次向该业务处理设备发送用于触发冲突业务的消息 (如， IDP消息）。 此时， 控制单元 702在图 7 , 图 8或图 9所示实施例的 基础上， 还可以进一步包括如下功能： 用于在接续当前呼叫过程中， 若接 收到 MSC在检测点 （ de tec t i on po int, DP ) 12发起的初始检测点 IDP消 息时， 查找緩存的呼叫上下文， 确定不存在冲突呼叫且当前呼叫的上下文 已緩存， 指示 MSC继续接续当前呼叫。 在解决此情况下的呼叫冲突时， 緩 存的呼叫上下文中需区分主被叫。 本实施例也是对特殊情况下的处理， 目 的在于进一步的提高呼叫接通率， 以节约网络资源。
在具体的应用场景中， 业务控制设备的功能可以如方法实施例图 2 至 图 6所示， 其中， 业务控制设备与 MSC之间的交互均可由控制单元 702控 制 成。
本发明实施例中的业务控制设备可以基于计算机系统来实现， 图 1-图
6所示的方法均可在基于计算机系统的业务控制设备中实现。 图 10示出了 基于计算机系统来实现的业务控制设备的实施例。 本实施例中业务控制设 备可以包括： 处理器 1001、 存储器 1002和通信接口 1003。 存储器 1002用 于存储程序代码。 处理器 1001用于执行存储器 1002中存储的程序代码。 本发明实施例中， 存储器 1002存储有第一程序代码， 处理器 1001用于执 行该第一程序代码， 包括执行如下操作： 在呼叫建立过程中， 获取当前呼 叫的主被叫标识； 根据该主被叫标识查找緩存的呼叫上下文， 确定是否有 与当前呼叫相冲突的呼叫的上下文； 若有， 则指示移动交换中心 MSC释放 当前呼叫； 若没有， 则緩存当前呼叫的上下文， 并指示 MSC接续当前呼叫， 当成功接续当前呼叫或在接续过程中发现当前呼叫已被释放时， 删除当前 呼叫的上下文； 其中， 緩存的当前呼叫的上下文包括当前呼叫的主被叫标 识。 通信接口 1003, 用于与外部设备通信， 如与 MSC通信。 业务控制设备 与 MSC之间交互的消息 （如方法实施例图 1-6所示） 均通过通信接口 1003 发送和接收。 其中， 处理器 1001根据存储器 1002 中的程序代码对通信接 口 1003接收到的消息进行处理， 并通过通信接口 1003与外部设备交互。 处理器 1001 可以是中央处理器 （central processing unit, CPU), 专用 集成电路 (application-specific integrated circuit, ASIC )等。 其中, 本实施例中的业务控制设备可以包括总线 1104。 处理器 1101、存储器 1002 以及通信接口 1103之间可通过总线 1104连接并通信。 其中， 存储器 1002 可以包括： 随机存取存储器 （random access memory, RAM), 只读存储器 ( read-only memory, ROM), 磁盘等具有存储功能的实体。 本发明实施例 中的呼叫上下文可緩存在 RAM中。
其中， 若緩存的呼叫上下文中未区分主被叫， 与当前呼叫相冲突的呼 叫的上下文具体为包含有当前呼叫的主被叫标识的呼叫上下文。 处理器 1001在执行上述确定是否有与当前呼叫相冲突的呼叫的上下文的操作时， 具体为在緩存的呼叫上下文中查找出包含当前呼叫的主被叫标识的呼叫上 下文时， 则确定存在与当前呼叫冲突的呼叫。 若緩存的呼叫上下文中有区 分主被叫， 与当前呼叫相冲突的呼叫的上下文具体为： 记录的主叫为当前 呼叫的被叫， 且记录的被叫为当前呼叫的主叫的呼叫上下文。 处理器 1001 在执行上述确定是否有与当前呼叫相冲突的呼叫的上下文的操作时， 具体 为在緩存的呼叫上下文中查找出有记录的主叫的标识为当前呼叫的被叫标 识， 且记录的被叫的标识为当前呼叫的主叫标识的呼叫上下文时， 确定存 在与当前呼叫冲突的呼叫。
在具体实现时， 由于存在信令传送延时等问题， 因此， 在一些特殊场 景下， 还需要进行进一步的处理。 在此情况下， 存储器 1002还存储第二程 序代码， 处理器 1001还用于执行该第二程序代码， 包括执行如下操作： 若 在接续当前呼叫的过程中， 接收到遇忙事件， 进行延时等待， 达到预设延 时时长时向 MSC发送重新接续当前呼叫的指令。 或者， 存储器 1002还存储 第三程序代码， 处理器 1001还用于执行该第三程序代码， 包括执行如下操 作： 实时检测当前呼叫的被叫状态， 当检测到所述被叫恢复空闲状态时， 向 MSC发送重新接续当前呼叫的指令。
另外， 在主被叫双方均签约了呼叫冲突业务的情况， 还可能会出现以 下情况： 当业务处理设备指示 MSC接续当前呼叫后， MSC根据被叫终端的签 约信息（如， T-CSI )再次向该业务处理设备发送用于触发冲突业务的消息 (如， IDP 消息）。 此情况下， 存储器 1002还存储第四程序代码， 处理器 1001还用于执行该第四程序代码， 包括执行如下操作： 若在接续当前呼叫 过程中， 接收到 MSC在检测点 （detect ion point, DP ) 12发起的初始检 测点 IDP消息， 处理器 1001查找緩存的呼叫上下文， 确定不存在冲突呼叫 且当前呼叫的上下文已緩存时， 指示 MSC继续接续当前呼叫。 在解决此情 况下的呼叫冲突时， 緩存的呼叫上下文中需区分主被叫。 本发明实施例进一步给出实现上述方法实施例中各步骤的系统实施 例。 图 11示出了一种处理呼叫冲突的系统的实施例。 在该实施例中， 处理 呼叫冲突的系统包括： 业务控制设备 1101 和移动交换中心 （mobi le swi tching center, MSC ) 1102。 其中， 业务控制设备 1101 的具体结构可 以参考业务控制设备的装置实施例部分， 如图 7、 图 8、 图 9和图 10中的 业务控制设备。 MSC则用于根据业务控制设备 1101下发的指示对当前呼叫 进行处理。 若将本发明实施例的方案应用在智能网中， 业务控制设备 1101 与 MSC 1102 之间可基于移动网增强逻辑的用户应用 （ cus tomized appl ica t ions for mobi le network enhanced log ic, CAMEL )协议进行通 信。 业务控制设备 1101可以是智能网中的 SCP。 MSC 1102上可部署智能网 中的业务交换点 ( servi ce swi tching point, SSP ), MSC 1102通过 SSP与 业务控制设备 1101交互。
通过以上的实施方式的描述 ， 所属领域的技术人员可以清楚地了解到 本发明可以用硬件实现， 或固件实现， 或它们的组合方式来实现。 当使用 软件实现时， 可以将上述功能存储在计算机可读介质中或作为计算机可读 介质上的一个或多个指令或代码进行传输。 计算机可读介质包括计算机存 储介质和通信介质， 其中通信介质包括便于从一个地方向另一个地方传送 计算机程序的任何介质。 存储介质可以是计算机能够存取的任何可用介质。 以此为例但不限于： 计算机可读介质可以包括 RAM、 ROM, EEPR0M、 CD-ROM 或其他光盘存储、 磁盘存储介质或者其他磁存储设备、 或者能够用于携带 或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的 任何其他介质。 此外。 任何连接可以适当的成为计算机可读介质。 例如， 如果软件是使用同轴电缆、 光纤光缆、 双绞线、 数字用户线（DSL )或者诸 如红外线、 无线电和微波之类的无线技术从网站、 服务器或者其他远程源 传输的， 那么同轴电缆、 光纤光缆、 双绞线、 DSL或者诸如红外线、 无线和 微波之类的无线技术包括在所属介质的定影中。 如本发明所使用的， 盘 (Disk)和碟（disc) 包括压缩光碟（CD)、 激光碟、 光碟、 数字通用光碟 (DVD)、 软盘和蓝光光碟， 其中盘通常磁性的复制数据， 而碟则用激光来 光学的复制数据。 上面的组合也应当包括在计算机可读介质的保护范围之 内。
以上所述， 仅为本发明的具体实施例， 但本发明的保护范围并不局限 于此， 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻 易想到变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本发明的 保护范围应以权利要求的保护范围为准。

Claims

权利要求
1、 一种处理呼叫冲突的方法， 其特征在于， 所述方法包括：
在呼叫建立过程中， 业务控制设备获取当前呼叫的主被叫标识； 根据所述主被叫标识查找緩存的呼叫上下文， 确定是否有与当前呼叫 相冲突的呼叫的上下文；
若有， 则指示移动交换中心 MSC释放当前呼叫；
若没有， 则緩存当前呼叫的上下文， 并指示所述 MSC接续当前呼叫， 当成功接续当前呼叫时或在接续过程中发现当前呼叫已被释放时， 删除当 前呼叫的上下文； 其中， 所述緩存的当前呼叫的上下文包括当前呼叫的主 被叫标识。
2、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括： 在接续 当前呼叫的过程中， 若接收到遇忙事件， 所述业务控制设备进行延时等待， 达到预设延时时长时向所述 MSC发送重新接续当前呼叫的指令。
3、 如权利要求 1所述的方法， 其特征在于， 所述方法还包括： 在接续 当前呼叫的过程中， 若接收到遇忙事件， 所述业务控制设备实时检测当前 呼叫的被叫状态， 当检测到所述被叫恢复空闲状态时， 向所述 MSC发送重 新接续当前呼叫的指令。
4、 如权利要求 1-3任一项所述的方法， 其特征在于， 若緩存的呼叫上 下文中未区分主被叫， 所述确定是否有与当前呼叫相冲突的呼叫的上下文 具体包括： 确定是否查找到包含有当前呼叫的主被叫标识的呼叫上下文， 若查找到包含有当前呼叫的主被叫标识的呼叫上下文， 则表示有与当前呼 叫相冲突的呼叫的上下文。
5、 如权利要求 1-3任一项所述的方法， 其特征在于， 若緩存的呼叫上 下文中有区分主被叫， 所述确定是否有与当前呼叫相冲突的呼叫的上下文 具体包括： 确定是否查找到主叫为当前呼叫的被叫， 且被叫为当前呼叫的 主叫的呼叫上下文， 若查找到主叫为当前呼叫的被叫， 且被叫为当前呼叫 的主叫的呼叫上下文， 则表示有与当前呼叫相冲突的呼叫的上下文。
6、 如权利要求 5所述的方法， 其特征在于， 在接续当前呼叫过程中， 若接收到 MSC在检测点 DP12发起的初始检测点 IDP消息， 业务控制设备查 找緩存的呼叫上下文， 确定没有与当前呼叫相冲突的呼叫的上下文， 且当 前呼叫的上下文已緩存时， 指示所述 MS C继续接续当前呼叫。
7、 一种业务控制设备， 其特征在于， 包括：
获取单元， 用于在呼叫建立过程中， 获取当前呼叫的主被叫标识； 控制单元， 用于根据所述获取单元获取的主被叫标识查找緩存的呼叫 上下文， 确定是否有与当前呼叫相冲突的呼叫的上下文； 若有， 则指示移 动交换中心 MSC释放当前呼叫； 若没有， 则緩存当前呼叫的上下文， 并指 示所述 MSC接续当前呼叫， 当成功接续当前呼叫或在接续过程中发现当前 呼叫已被释放时， 删除当前呼叫的上下文； 其中， 所述緩存的当前呼叫的 上下文包括当前呼叫的主被叫标识。
8、 如权利要求 7所述的业务控制设备， 其特征在于， 还包括： 延时单 元， 用于监控延时时长， 当到达预设延时时长时， 通知所述控制单元； 所述控制单元还用于在接续当前呼叫的过程中， 若接收到遇忙事件， 则进行延时等待， 并触发所述延时单元启动监控， 当接收到所述延时单元 发送的达到预设延时时长的通知时， 向所述 MSC发送重新接续当前呼叫的 指令。
9、 如权利要求 7所述的业务控制设备， 其特征在于， 还包括： 检测单 元， 用于实时检测当前呼叫的被叫状态， 当检测到所述被叫恢复空闲状态 时通知所述控制单元；
所述控制单元还用于在接续当前呼叫的过程中， 若接收到遇忙事件， 则触发所述检测单元启动检测， 当接收到所述检测单元发送的所述被叫恢 复空闲状态的通知时， 向所述 MSC发送重新接续当前呼叫的指令。
10、 如权利要求 7-9任一项所述的业务控制设备， 其特征在于， 若緩 存的呼叫上下文中未区分主被叫， 所述与当前呼叫相冲突的呼叫的上下文 具体为包含有当前呼叫的主被叫标识的呼叫上下文。
11、 如权利要求 7-9任一项所述的业务控制设备， 其特征在于， 若緩 存的呼叫上下文中有区分主被叫， 所述与当前呼叫相冲突的呼叫的上下文 具体为： 记录的主叫为当前呼叫的被叫， 且记录的被叫为当前呼叫的主叫 的呼叫上下文。
12、 如权利要求 11所述的业务控制设备， 其特征在于， 所述控制单元 还用于在接续当前呼叫的过程中， 若接收到所述 MSC在监测点 DP12发起的 初始检测点 IDP 消息， 则查找緩存的呼叫上下文， 确定没有与当前呼叫相 冲突的呼叫的上下文， 且当前呼叫的上下文已緩存时， 指示所述 MSC继续 接续当前呼叫。
1 3、 一种处理呼叫冲突的系统， 其特征在于， 包括移动交换中心 MSC 以及权利要求 7-12任一项所述的业务控制设备；
所述 MSC , 用于根据所述业务控制设备下发的指示对当前呼叫进行处 理。
PCT/CN2012/079669 2012-08-03 2012-08-03 一种处理呼叫冲突的方法、系统和业务控制设备 WO2014019226A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2012/079669 WO2014019226A1 (zh) 2012-08-03 2012-08-03 一种处理呼叫冲突的方法、系统和业务控制设备
CN201280001195.0A CN102893691B (zh) 2012-08-03 2012-08-03 一种处理呼叫冲突的方法、系统和业务控制设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2012/079669 WO2014019226A1 (zh) 2012-08-03 2012-08-03 一种处理呼叫冲突的方法、系统和业务控制设备

Publications (1)

Publication Number Publication Date
WO2014019226A1 true WO2014019226A1 (zh) 2014-02-06

Family

ID=47535614

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/079669 WO2014019226A1 (zh) 2012-08-03 2012-08-03 一种处理呼叫冲突的方法、系统和业务控制设备

Country Status (2)

Country Link
CN (1) CN102893691B (zh)
WO (1) WO2014019226A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016119233A1 (zh) * 2015-01-30 2016-08-04 华为技术有限公司 一种终端设备呼叫冲突的处理方法和终端设备
CN105991594A (zh) * 2015-02-15 2016-10-05 中兴通讯股份有限公司 一种呼叫处理方法和装置
US11239907B2 (en) 2015-12-07 2022-02-01 Hytera Communications Corporation Limited Call processing method and device
JP6803482B2 (ja) * 2017-02-22 2020-12-23 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 呼設定方法及び装置
EP3769562A1 (en) * 2018-03-21 2021-01-27 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for call setup failure control

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101155389A (zh) * 2006-09-27 2008-04-02 大唐移动通信设备有限公司 处理呼叫冲突的方法及装置
KR20090021509A (ko) * 2007-08-27 2009-03-04 에스케이 텔레콤주식회사 이동통신망에서의 호 충돌 방지 시스템 및 방법
WO2010111830A1 (zh) * 2009-03-31 2010-10-07 阿尔卡特朗讯公司 通信网络中处理呼叫冲突的方法和相关设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101155389A (zh) * 2006-09-27 2008-04-02 大唐移动通信设备有限公司 处理呼叫冲突的方法及装置
KR20090021509A (ko) * 2007-08-27 2009-03-04 에스케이 텔레콤주식회사 이동통신망에서의 호 충돌 방지 시스템 및 방법
WO2010111830A1 (zh) * 2009-03-31 2010-10-07 阿尔卡特朗讯公司 通信网络中处理呼叫冲突的方法和相关设备

Also Published As

Publication number Publication date
CN102893691A (zh) 2013-01-23
CN102893691B (zh) 2015-11-25

Similar Documents

Publication Publication Date Title
US12015682B2 (en) Service subscription method and system for reporting service change in communication system
WO2020073838A1 (zh) 一种网络切片接入控制的方法及装置
CN102843765B (zh) 一种确定终端状态的方法、装置和系统
US11533666B2 (en) Communication method, communications apparatus, and communications system
EP2858389B1 (en) Device and system for sending trigger message
WO2014019226A1 (zh) 一种处理呼叫冲突的方法、系统和业务控制设备
US20140341366A1 (en) Call control for web calls
WO2009089704A1 (fr) Procédé, système et dispositif associé pour traiter un service du domaine à commutation de circuits dans un réseau par paquets évolué
KR20110099771A (ko) 아이피 멀티미디어 서브 시스템 집중식 서비스의 로그아웃 방법 및 시스템
EP3258644B1 (en) Monitoring processing method and device
JP2022537643A (ja) リソース購読方法、機器、サーバ及びコンピュータ記憶媒体
WO2018166328A1 (zh) 信息处理方法、装置、计算机可读存储介质及电子设备
EP3185598B1 (en) Application registration method and apparatus
WO2020135536A1 (zh) 一种通信方法及装置
WO2012113178A1 (zh) 检测终端连接丢失的方法及装置
CN104507054B (zh) 一种群组成员信息更新的方法及相关设备
EP2806688B1 (en) Method of improving mobile terminating call handling during circuit switched fallback (CSFB)
KR20190126855A (ko) 제어 평면 접속 관리 방법 및 디바이스
CN106998546B (zh) 一种联合位置更新方法、系统和相关设备
RU2487503C1 (ru) Способ осуществления переключения на местный прием, центр коммутации мобильной связи и система связи
TW201114309A (en) Method of handling P-TMSI change in a wireless communication system and related communication device
EP3407585B1 (en) Generation of information based on event data of a call
WO2015000121A1 (zh) 一种呼叫处理的方法、设备和移动性管理实体
WO2018121182A1 (zh) 一种处理求助的方法和装置和计算机存储介质
WO2016086386A1 (zh) 一种网络回落方法以及相关用户设备

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201280001195.0

Country of ref document: CN

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

Ref document number: 12882505

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12882505

Country of ref document: EP

Kind code of ref document: A1