Automatic call taking-over and intelligent switching method

Abstract

The invention provides an automatic call taking-over and intelligent switching method, belongs to the technical field of communication, and aims at switching a call to a mobile phone of a specified rescue worker by dialing a uniform number according to an emergency rescue elevator number posted in an elevator. The voice gateway provides a basic telephone external line access function, and the PBX provides configuration of incoming and outgoing routing and configuration of IVR voice navigation. A platform service, a voice gateway and a PBX are deployed in the same local area network environment, the voice gateway and the PBX communicate through an SIP protocol, a platform and the PBX establish long connection data communication through a WebSocket protocol, and an OAuth 2.0 protocol is adopted for authentication and authorization. By customizing a data protocol PWD Protocol, the platform can monitor a call event, and reverse control of a call is realized through an HTTP API (Hyper Text Transport Protocol Application Program Interface).

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and particularly to an automated call takeover and intelligent transfer method, which is mainly applied to an elevator emergency call rescue platform. Background Art

[0002] With the acceleration of the urbanization process, elevators, as an important means of transportation in high-rise buildings, have attracted increasing attention to their safety. Traditional elevator emergency call systems mostly rely on fixed telephone lines, suffering from problems such as slow response speed and poor flexibility. The development of modern communication technologies has provided new solutions for elevator emergency call systems, but there is a lack of an efficient, safe, and flexible method for taking over mobile phone calls and handling transfers in the existing technologies. Summary of the Invention

[0003] To solve the above technical problems, the present invention provides an automated call takeover and intelligent transfer method. For an automated emergency duty system, by integrating technical means such as IP telephones, voice codec technologies, communication networks, and data analysis, it can continuously monitor elevators in real time and quickly respond to and handle calls when trapped users send out distress calls.

[0004] The technical solution of the present invention is as follows:

[0005] An automated call takeover and intelligent transfer method includes the following steps:

[0006] a) Receive a call signal from inside the elevator through a voice gateway.

[0007] b) The private branch exchange (PBX) inputs the elevator number through the configured IVR navigation prompt.

[0008] c) Use the OAuth 2.0 protocol for authentication and authorization to ensure the security of communication.

[0009] d) Use the data protocol PWD Protocol to implement the platform's monitoring of call events.

[0010] e) The platform matches rescue personnel according to the elevator number and sends a transfer instruction to the PBX.

[0011] f) Perform reverse control on call events through the HTTP API interface.

[0012] g) Monitor the call status, and the platform saves the call answer record.

[0013] Further, in step a), the voice gateway and the PBX are deployed in the same local area network environment. The voice gateway accesses the telephone digital outside line, and the two communicate through the SIP protocol.

[0014] Specifically, this solution uses a total of two hardware devices, a voice gateway and a PBX, and a software platform. The voice gateway is connected to the telephone line outside to receive call signals from inside the elevator and communicates with the PBX via the SIP protocol.

[0015] Further, in step b), the voice gateway forwards the call to the extension at the back end of the PBX, and the extension plays the pre-set IVR to guide the passenger to input the unique elevator number through the phone keypad.

[0016] Specifically, after receiving the call signal transferred and distributed by the voice gateway, the PBX finally forwards it to the virtual extension number, that is, the corresponding IVR number. The specified IVR 6201 is the virtual extension for prompting the passenger to input the unique elevator number. The final implementation effect is that when the passenger dials the fixed number, the prompt content of IVR 6201 will be prompted during the call.

[0017] Further, in step c), the OAuth 2.0 protocol is used for authentication and authorization between the platform and the PBX. After successful authentication, the establishment of normal communication is completed.

[0018] Specifically, after the call is normally connected, the remaining operations are taken over and operated by the platform. Therefore, data communication is required between the PBX and the software platform. To ensure data security between the two, the OAuth 2.0 protocol is used for authentication and authorization. When using WebSocket or HTTP API, the data request access_token needs to be carried. And the valid duration of the access_token is 1800 seconds.

[0019] Further, in step d), the long connection communication between the platform and the PBX uses the PWD Protocol data protocol to listen for call events by subscribing to different TYPE events.

[0020] Specifically, to ensure the real-time nature of data interaction and the accuracy of various call events, the WebSocket long connection message protocol is used between the platform and the PBX, and a unique protocol PWD Protocol (P WebSocket Data Protocol) is developed. Among them, the event types are mainly distinguished according to the TYPE field attribute. MSG is a general data type, and different event types ensure that the fields are the same but the contents are different.

[0021] Further, in step e), when the platform monitors that the TYPE is the 30017 DTMF key event, it obtains the entered unique elevator number and controls the call transfer according to the mobile phone numbers of the rescue personnel maintained by the platform.

[0022] Specifically, when the platform detects a TYPE 30017 DTMF key event, it obtains the INFOS data in the MSG. It determines whether the last character is the # character. If so, it intercepts the data before the # as the uniquely identified elevator number, and the platform queries the mobile phone number of the rescue personnel for call transfer control.

[0023] Furthermore, step f) the platform's reverse control of the PBX is implemented in the form of an HTTP API. For example, the call transfer control interface uses / call / transfer.

[0024] Specifically, after the platform takes over the call, it queries the phone number of the maintenance personnel and starts an asynchronous thread to make an outgoing call through the HTTP API. The timeout for each call is 30 seconds. By listening for the TYPE 30011 call status change event, if the call is not answered, it is retransferred to another phone. Thus, it enables the passengers to communicate directly and in a timely manner with the corresponding maintenance personnel of the elevator.

[0025] Furthermore, step g) listens for the call answer status of the rescue personnel, generates a call record, and records the call audio.

[0026] Specifically, by listening for the TYPE 30011 call status change event and the TYPE 30012 new call record event, it generates a transferred call answer record and a rescue timeline. If the call is answered, it calls the API interface call / record_start to start recording the call. After the call ends, it calls the API interface / recording / download to obtain the call audio file.

[0027] The beneficial effects of the present invention are

[0028] The unified call number simplifies the operation process and improves the response speed in case of emergency. Automatic transfer reduces the waiting time for passengers to be rescued; using the OAuth 2.0 protocol for authentication and authorization ensures the security and reliability of communication; the platform can obtain the call status in a timely manner by listening for call events through the PWD Protocol; the platform performs reverse control on call events through the HTTP API interface, improving the flexibility and scalability of the system; the platform saves call records and recordings for subsequent management and analysis. Brief Description of the Drawings

[0029] Figure 1 It is a schematic diagram of the communication between the voice gateway and the PBX;

[0030] Figure 2 It is a schematic diagram of call control;

[0031] Figure 3 It is a flowchart for obtaining the access_token. Detailed Embodiments

[0032] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part rather than all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0033] The present invention provides an automated call takeover and intelligent transfer method. By dialing a unified number and according to the emergency rescue elevator number posted in the elevator, the call is transferred to the mobile phone of the designated rescue personnel. This method is based on two hardware devices, namely a voice gateway and a PBX (Private Branch Exchange, user-level switch). Among them, the voice gateway provides the basic function of accessing the telephone outside line, and the PBX provides the configuration of incoming and outgoing call routes and the configuration of IVR voice navigation. The platform service, voice gateway and PBX are deployed in the same local area network environment. The voice gateway and PBX communicate through the SIP protocol. The platform and the PBX establish a long connection data communication through the WebSocket protocol and use the OAuth 2.0 protocol for authentication and authorization. By customizing the data protocol PWD Protocol (P WebSocket Data Protocol), the platform can monitor call events and realize the reverse control of calls through the HTTP API. Specifically as follows:

[0034] 1) The voice gateway and the PBX are deployed in the same local area network environment. The voice gateway accesses the telephone digital outside line, and the two communicate through the SIP protocol, as Figure 1 .

[0035] 2) After receiving the call signal transferred and distributed by the voice gateway, the PBX finally forwards it to the virtual extension number, that is, the corresponding IVR number. The specified IVR 6201 is the virtual extension for prompting passengers to enter the unique elevator number. The final implementation effect is that when a passenger dials a fixed number, the prompt content of IVR 6201 will be prompted. The platform service receives the key event callback and takes over the control of the call. First, query the phone number of the maintenance personnel and then make an outgoing call to enable direct communication between the passenger and the corresponding maintenance personnel.

[0036] 3) To ensure data security between the two, the OAuth 2.0 protocol is used for authentication and authorization. The PBX provides the client ID and secret as the access credentials for the platform.

[0037] Obtain the access_token:

[0038]

[0039] 4) Develop the PWD Protocol application data transmission protocol, using the common JSON data format. By only defining two types of data, TYPE and MSG, in the data content, where TYPE is the event type and MSG stores the specific business data. Thus, the function of defining private business data is realized. The following is an example of the call status change event of 30011:

[0040]

[0041]

[0042] 5) After the platform monitors the TYPE as 30017 DTMF key event, it obtains the INFOS data in MSG. And intercept the data before # as the uniquely numbered elevator entered. The mobile phone number of the rescue personnel queried by the platform is used to start an asynchronous thread to make an outgoing call through the HTTP API. The timeout for each call is 30 seconds. By monitoring the TYPE as 30011 call status change event, if not answered, it will be re-routed to other phones.

[0043] Start an asynchronous thread to transfer the call:

[0044]

[0045]

[0046] Monitor the call status change. If answered, start call recording:

[0047]

[0048] 6) By monitoring the TYPE as 30011 call status change event and the TYPE as 30012 new call record event, generate the transferred call answer record and the rescue timeline.

[0049] If answered, call the API interface call / record_start to start call recording. After the call ends, call the API interface / recording / download to obtain the call recording file.

[0050] The above are only the preferred embodiments of the present invention, which are only used to illustrate the technical solutions of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are all included in the protection scope of the present invention.

Claims

1. A method for automatic call handling and intelligent transfer, characterized in that: The steps include: a) Receive the call signal from the elevator through the voice gateway; b) The user-level PBX prompts the user to enter the elevator number through the configured IVR navigation; c) Use OAuth 2.0 protocol for authentication and authorization to ensure the security of communication; d) Use the data protocol PWD Protocol to enable the platform to monitor call events; e) The platform matches rescue personnel according to the elevator number and sends a transfer instruction to the PBX; f) Reverse control of call events through HTTP API interface; g) Monitor call status and the platform saves call answering records.

2. The method according to claim 1, characterized in that Step a) The voice gateway and PBX are deployed in the same LAN environment, the voice gateway is connected to the telephone digital line, and the two communicate through the SIP protocol.

3. The method according to claim 1, characterized in that Step b) The voice gateway transfers the call to the PBX backend extension, which plays the preset IVR to guide the passenger to enter the unique elevator number through the telephone keys.

4. The method according to claim 1, characterized in that Step c) The OAuth 2.0 protocol is used for authentication and authorization between the platform and the PBX. After the authentication is passed, normal communication is established.

5. The method according to claim 1, characterized in that Step d) The long connection communication between the platform and the PBX adopts the PWD Protocol data protocol, and monitors call events by subscribing to different TYPE events.

6. The method according to claim 1, characterized in that Step e) When the platform monitors the DTMF key event of TYPE 30017, it obtains the unique number of the elevator entered and controls the call transfer according to the rescuer's mobile phone number maintained by the platform.

7. The method according to claim 1, characterized in that Step f) The reverse control of the platform to the PBX is implemented in the form of HTTP API.

8. The method according to claim 7, characterized in that By monitoring the call status change event with TYPE 30011, if the call is not answered, it will be transferred to other phones.

9. The method according to claim 1, characterized in that: Step g) monitors the rescuer's telephone answering status, generates call records and records the call recordings.

10. The method according to claim 9, characterized in that By monitoring the call status change event TYPE 30011 and the new call record event 30012, the call transfer answering record and rescue timeline are generated; if the call is answered, the API interface call / record_start is called to start call recording; After the call ends, call the API interface / recording / download to obtain the call recording file.

Images