Design method of audio routing management system based on IP phone
By dismantling the audio routing management system of IP phones into multiple components and building audio routing states, the defects of the existing system in complex audio switching logic processing are solved, flexible combination and efficient management of audio routing are realized, multi-device output and expansion are supported, and the performance of IP phones is not affected.
Patent Information
- Application Number
- CN202510013491.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-06
- Publication Date
- 2025-05-27
AI Technical Summary
The existing IP phone audio routing management system has defects such as complexity, state explosion, poor scalability, callback hell, complex error handling, performance problems, centralization problems, poor testability, strong dependency, memory leak risk, state consistency problems and performance overhead when dealing with complex audio switching logic, making it difficult to achieve efficient audio routing switching.
By dismantling the audio routing management system of the IP phone into multiple components, and combining different switching modes and audio path connection status, the state of audio routing is constructed and audio path management is carried out in real time, so as to realize flexible combination and efficient routing of audio paths.
It realizes convenient and efficient management of audio routing of IP phones, supports the expansion of multi-device output and multi-audio input, and does not affect the performance of IP phones, which is safe and reliable.
Smart Images

Figure CN120050361A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the audio field of IP phones in the communication industry, and in particular, to a design method for an audio routing management system based on an IP phone. Background Art
[0002] As an IP-based communication device, IP phones have been widely used and promoted globally. Moreover, the changing enterprise-level communication requirements are one of the important driving forces for the development of IP phones because IP phones can meet the growing and diverse communication needs of enterprises.
[0003] In IP phones, the audio routing management system has always played a crucial role. The software implementation of the current audio routing management system generally has the following modes: 1. State machine model, 2. Event-driven model, 3. Using the mediator pattern, 4. Observer pattern, 5. Multithreading and asynchronous processing mode, 6. State management library, etc.
[0004] How to smoothly switch the audio path and efficiently switch the audio routing for various complex application scenarios in IP phones is a crucial topic.
[0005] Among the above-described software technologies, there are more or less certain defects:
[0006] 1. State machine model:
[0007] (1) Complexity: For complex audio switching logic, the state machine may become very complex, resulting in difficult maintenance.
[0008] (2) State explosion: If there are too many states and events involved, state explosion may occur, increasing the difficulty of logical processing.
[0009] (3) Poor scalability: When adding new audio devices or states, the entire state machine may need to be redesigned.
[0010] 2. Event-driven model:
[0011] (1) Callback hell: If the event handling chain is too long, it may lead to nested callback functions, making it difficult to read and maintain.
[0012] (2) Complex error handling: In the process of asynchronous processing, error handling may become complex, and additional logic is required to capture and handle errors.
[0013] (3) Performance issues: Frequent event triggering may lead to performance degradation, especially in high-frequency events.
[0014] 3. Using the mediator pattern:
[0015] (1) Centralization issue: The mediator pattern centralizes all logic in one place. If the mediator's functionality becomes too large, it can become the "single point of failure" of the system.
[0016] (2) Testability: Testing the complex logic of the mediator can be difficult, especially when dealing with the interactions of multiple components.
[0017] (3) Strong dependencies: The dependencies between components are enhanced, which may lead to a chain reaction during modification.
[0018] 4. Observer pattern:
[0019] (1) Risk of memory leak: If the observer is not correctly unregistered, it may lead to a memory leak.
[0020] (2) State consistency: When multiple observers receive a state update simultaneously, it may lead to inconsistent states.
[0021] (3) Performance overhead: In the case of a large number of observers, notifying all observers may cause performance issues.
[0022] 5. Multithreading and asynchronous processing pattern:
[0023] (1) Complexity: Multithreading programming itself has a high level of complexity and is prone to problems such as race conditions and deadlocks.
[0024] (2) Difficult debugging: Errors in a multithreaded environment may not be easily reproducible, and debugging and troubleshooting problems are relatively difficult.
[0025] (3) Context switching overhead: Frequent thread switching may introduce performance overhead.
[0026] 6. State management library:
[0027] (1) Learning curve: For developers, learning how to use and configure a state management library may have a certain threshold.
[0028] (2) Over - reliance: Over - reliance on the library's implementation may lead to the binding of business logic to the library, increasing the complexity of migration and replacement.
[0029] (3) Performance issues: Some state management libraries may perform poorly in large - scale applications, resulting in performance degradation. Summary of the Invention
[0030] To solve the above problems, the present invention provides a design method for an audio routing management system based on an IP phone. By re - defining and dividing the components of the audio path management system of the IP phone, the audio path system of the IP phone is first designed as Figure 1As shown, then in the application layer, according to the switching events of different devices, determine the audio paths to be established and disconnected, and then, based on the audio routing management system designed by the present invention, form the state of the current audio routing and execute the management of the audio paths. This method can more conveniently and efficiently implement the audio routing management of the IP phone. The opening and closing of the audio paths can meet the requirement of smoothly switching the audio paths.
[0031] To achieve the above object, the present invention adopts the following technical solutions:
[0032] In an embodiment of the present invention, a design method of an audio routing management system based on an IP phone is proposed. The method includes:
[0033] Decompose the audio routing management system of the IP phone into multiple components. On one side, there are AUX input, VOIP input, and VOIP output respectively. On the other side, there are BT device output, USB device output, built-in speaker output, built-in handset output, speaker Mic input, handset Mic input, BT Mic input, and USB Mic input respectively. Then combine these components to form the inputs and outputs of different audio paths, and combine different switching modes and the permutations and combinations of different audio path connection states to construct a state of the audio routing and manage the audio paths in real time.
[0034] Further, the audio paths are represented as follows:
[0035] AUX input -> BT device output;
[0036] AUX input -> USB device output;
[0037] AUX input -> built-in speaker output;
[0038] AUX input -> built-in handset output;
[0039] VOIP input -> BT device output;
[0040] VOIP input -> USB device output;
[0041] VOIP input -> built-in speaker output;
[0042] VOIP input -> built-in handset output;
[0043] Speaker Mic input -> VOIP output;
[0044] Handset Mic input -> VOIP output;
[0045] BT device Mic input -> VOIP output;
[0046] USB device Mic input -> VOIP output.
[0047] Furthermore, the status of audio routing consists of the following components:
[0048] Switching mode: Full / Add / Remove / Volume / Idle;
[0049] Audio device: Handset / Handsfree / Headset / Idle;
[0050] Input mode: AuxInput / VoipInput / MicInput;
[0051] Connection type: Usb / Bt / Internal / None;
[0052] Output mode: VoipOutput / AuxOuput;
[0053] Path connection status: Enable / Disable+Volume;
[0054] Among them, when two or more audio paths need to be opened simultaneously, the switching mode Full is used; when only one audio path needs to be opened, the switching mode Add is used; when only one audio path needs to be closed in the current state, the switching mode Remove is used; when only the volume of one audio path needs to be adjusted, the switching mode Volume is used; when all IP audio paths need to be closed, the switching mode Idle is used;
[0055] Among them, through the combination of audio device + connection type, it can be confirmed which device is currently working; through audio device + connection type + MicInput, it can be confirmed which device's Mic is working for the current VOIP call; through audio device + connection type + AuxOuput / VoipOuput, it can be confirmed on which device the current ringtone, ringback tone or VOIP output should be. AuxInput / VoipInput is the VOIP data packet from the network or the data of the ringtone and ringback tone.
[0056] Furthermore, the audio path connection status is expressed as follows:
[0057] AUX input -> BT device output + enable + volume / disable;
[0058] AUX input -> USB device output + enable + volume / disable;
[0059] AUX input -> Built-in speaker output + enable + volume / disable;
[0060] AUX input -> Built-in handle output + enable + volume / disable;
[0061] VOIP input -> BT device output + enable + volume / disable;
[0062] VOIP input -> USB device output + enable + volume / disable;
[0063] VOIP input -> Built-in speaker output + enable + volume / disable;
[0064] VOIP input -> Built-in handle output + enable + volume / disable;
[0065] Speaker Mic input -> VOIP output + enable + volume / disable;
[0066] Handle Mic input -> VOIP output + enable + volume / disable;
[0067] BT device Mic input -> VOIP output + enable + volume / disable;
[0068] USB device Mic input -> VOIP output + enable + volume / disable.
[0069] Further, when the state of the audio routing is successfully built, the following logic is used:
[0070] The application should analyze the switching mode in the current state of the audio routing. If the initial switching mode is Idle, then disconnect all existing audio paths and end the process;
[0071] If the switching mode is Full, first check all audio path connections, disconnect all connections, then parse the audio paths that need to be operated in the current state of the audio routing, and record the connection status of all currently open and closed audio paths in the application;
[0072] If an audio path needs to be added before switching to the Idle mode, the switching mode is Add, and just continue to add this audio path, and update the connection status of all currently open and closed audio paths in the application again;
[0073] If it is necessary to close an audio path separately, the switching mode is set to Remove to directly close this audio path, and update the connection status of all currently open and closed audio paths in the application.
[0074] If the switching mode is Volume, first detect the connection status of all currently open and closed audio paths. If the current audio path has already been opened, there is no need to open it again, and directly adjust the volume on this audio path.
[0075] If it is necessary to switch the status of the IP phone to Idle, the switching mode is set to Idle to close all connected audio paths, and update the connection status of all audio paths to the closed state in the application.
[0076] Beneficial effects:
[0077] The present invention is different from the existing audio routing management system. It splits the audio routing management system into different audio paths and further divides the audio paths into more precise components so as to achieve flexible combination of paths and efficient audio routing. Moreover, the system is simple and clear, easy to analyze and maintain, supports the expansion of multi-device output and multi-audio input, and has no performance impact on the IP phone, being safe and reliable. Brief Description of the Drawings
[0078] Figure 1 It is the audio path design diagram of the audio routing system based on the IP phone of the present invention;
[0079] Figure 2 It is the input-output combination structure diagram of the audio routing system based on the IP phone of the present invention;
[0080] Figure 3 It is the schematic diagram of the usage logic design of the audio routing system based on the IP phone of the present invention. Detailed Embodiments
[0081] Next, the principles and spirit of the present invention will be described with reference to several exemplary embodiments. It should be understood that these embodiments are given only to enable those skilled in the art to better understand and then implement the present invention, rather than limiting the scope of the present invention in any way. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to be able to fully convey the scope of the present disclosure to those skilled in the art.
[0082] Those skilled in the art know that the embodiments of the present invention can be implemented as a system, device, equipment, method or computer program product. Therefore, the present disclosure can be specifically implemented in the following forms: completely hardware, completely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.
[0083] According to an embodiment of the present invention, a design method for an audio routing management system based on an IP phone is proposed. The audio routing management system of the IP phone is disassembled into multiple components, and these components are combined to form inputs and outputs of different audio channels. Combined with different switching modes and permutations of different audio channel connection states, a state of the audio routing is constructed to manage the audio channels in real time.
[0084] Next, with reference to several representative embodiments of the present invention, the principles and spirit of the present invention will be elaborated in detail.
[0085] The first step of the present invention is to divide the audio routing management system, as Figure 1 shown, into the following parts:
[0086] On the far left: 1. AUX input, 2. VOIP input, 3. VOIP output;
[0087] On the far right: 1. BT device output, 2. USB device output, 3. Built-in speaker output, 4. Built-in handle output, 5. Speaker Mic input, 6. Handle Mic input, 7. BT Mic input, 8. USB Mic input.
[0088] As Figure 1 shown and described above, the following audio channels can be established, as Figure 2 shown:
[0089] 1. AUX input -> BT device output;
[0090] 2. AUX input -> USB device output;
[0091] 3. AUX input -> Built-in speaker output;
[0092] 4. AUX input -> Built-in handle output;
[0093] 5. VOIP input -> BT device output;
[0094] 6. VOIP input -> USB device output;
[0095] 7. VOIP input -> Built-in speaker output;
[0096] 8. VOIP input -> Built-in handle output;
[0097] 9. Speaker Mic input -> VOIP output;
[0098] 10. Handle Mic input -> VOIP output;
[0099] 11. Mic input of BT device -> VOIP output;
[0100] 12. Mic input of USB device -> VOIP output.
[0101] In the second step, divide the audio path into the following components:
[0102] 1. Design a state for audio routing, named AudioRouteState;
[0103] 2. This state consists of the following components:
[0104] (1) Switching mode (DeltaType): Full / Add / Remove / Volume / Idle;
[0105] (2) Audio device: Handset / Handsfree / Headset / Idle;
[0106] (3) Input mode: AuxInput / VoipInput / MicInput;
[0107] (4) Connection type: Usb / Bt / Internal / None;
[0108] (5) Output mode: VoipOutput / AuxOuput;
[0109] (6) Path connection status: Enable / Disable+Volume.
[0110] 3. The specific functions of each component are as follows:
[0111] (1) Full: When establishing a VOIP call, it is necessary to simultaneously open an audio path from Mic input -> VOIP output, and an audio path from VOIP input to -> BT / USB / Handsfree / Handset. When it is necessary to open two or more audio paths simultaneously, use the switching mode Full.
[0112] (2) Add: When only a certain audio path needs to be opened, such as playing Aux input (ringtone, call waiting tone, etc.), add an audio path from VOIP input to -> BT / USB / Handsfree / Handset, and add an audio path from AUX input -> BT / USB / Handsfree / Handset. Only use the switching mode Add.
[0113] (3) Remove: When only the closing of an audio path in the current state is required, such as closing an Aux input or closing the audio path from a VOIP input to -> BT / USB / Handsfree / Handset, only the switching mode Remove needs to be used.
[0114] (4) Volume: When only the volume of a certain audio path needs to be adjusted, the volume setting of this audio path can be changed only, keeping other connections unchanged, and the switching mode Volume can be used.
[0115] (5) Idle, when wanting to close all the audio paths of the IP, the switching mode Idle is used.
[0116] (6) Through the combination of the audio device + connection type, it can be known which device is currently working. For example, Handset + Bt means that the Bluetooth handset is currently working. When the audio device is Idle, it means that no device is currently working. At this time, the connection type should also be None, and the switching mode should become Idle.
[0117] (7) Through the audio device + connection type + MicInput, it can be confirmed which device's Mic is working for the current VOIP call. Through the audio device + connection type + AuxOuput / VoipOuput, it can be confirmed on which device the current ringtone, call waiting tone or VOIP output should be. AuxInput / VoipInput is the data of the VOIP data packet or ringtone (call waiting tone, etc.) from the network.
[0118] Therefore, the path connection status can be expressed as follows, as Figure 2 shown:
[0119] 1. AUX input -> BT device output + enable + volume / disable;
[0120] 2. AUX input -> USB device output + enable + volume / disable;
[0121] 3. AUX input -> built-in speaker output + enable + volume / disable;
[0122] 4. AUX input -> built-in handset output + enable + volume / disable;
[0123] 5. VOIP input -> BT device output + enable + volume / disable;
[0124] 6. VOIP Input -> USB Device Output + enable + volume / disable;
[0125] 7. VOIP Input -> Built-in Speaker Output + enable + volume / disable;
[0126] 8. VOIP Input -> Built-in Handset Output + enable + volume / disable;
[0127] 9. Speaker Mic Input -> VOIP Output + enable + volume / disable;
[0128] 10. Handset Mic Input -> VOIP Output + enable + volume / disable;
[0129] 11. BT Device Mic Input -> VOIP Output + enable + volume / disable;
[0130] 12. USB Device Mic Input -> VOIP Output + enable + volume / disable;
[0131] In the third step, based on the description in point (7) of the second step, AudioRouteState can be constructed to manage the audio path in real time. An update of AudioRouteState can consist of a switching mode DeltaType + several audio path connection states. For example:
[0132] 1. Full + (VOIP Input -> Built-in Speaker Output + enable + 80% (representing 80% of the maximum volume of this audio path, representing the volume setting, and all percentages represent the volume setting of this audio path)) + (Speaker Mic Input -> VOIP Output + enable + volume);
[0133] When making a VOIP call using the speaker, this AudioRouteState can be used to open the audio path.
[0134] 2. ADD + (AUX Input -> USB Device Output + enable + 70%);
[0135] When dialing using the USB device, this AudioRouteState can be used to open the Aux path to play the dial tone. When a call comes in, this AudioRouteState can be used to open the Aux path to play the incoming call ringtone.
[0136] 3. Remove + AUX input -> (built-in speaker output + disable);
[0137] When it is necessary to stop playing ringtones, call waiting tones, or dial tones in the speaker, this AudioRouteState can be used to stop playing and close this Aux path.
[0138] 4. Idle + None
[0139] When hanging up the phone and the IP phone returns to the idle state, this AudioRouteState can be used to close all audio paths.
[0140] In actual usage scenarios, different permutations and combinations can be made according to the actual situation to construct a suitable AudioRouteState to meet the exact usage scenario.
[0141] Finally, after the AudioRouteState is successfully constructed, how to use it is as follows Figure 3 shown:
[0142] 1. The application should analyze the switching mode in the current AudioRouteState. If the initial mode is Idle, disconnect all existing audio paths and end the process.
[0143] 2. If the switching mode is Full, to ensure that only the audio paths carried in this AudioRouteState are opened, first check all audio path connections and disconnect all connections. Then parse the audio paths that need to be operated in the current AudioRouteState. For example, if it is necessary to open VOIP input -> BT device output and BT device Mic -> VOIP output, and remember the connection status of all currently opened and closed audio paths in the application.
[0144] 3. If before switching to the Idle mode, it is necessary to add an audio path. For example, based on step 2, it is also necessary to add an audio path from VOIP input to -> USB device output, and the switching mode is Add. Just add this audio path and update the connection status of all currently opened and closed audio paths in the application again.
[0145] 4. Based on step 3, if you want to close the audio path from VOIP input to -> USB device output alone, and the switching mode is Remove, directly close this audio path and update the connection status of all currently opened and closed audio paths in the application.
[0146] 5. If the switching mode is Volume, first detect the connection status of all currently open and closed audio channels. If the current audio channel is already open, there is no need to open it again, and the volume on this audio channel can be directly adjusted.
[0147] 6. If the state of the IP phone needs to be switched to Idle finally, the switching mode Idle needs to be used to close all the connected audio channels, and update the connection status of all audio channels to the closed state in the application.
[0148] By arranging and combining the above multiple audio channels to construct AudioRouteState, efficient audio routing management can be achieved, and this audio routing management system can cover all usage scenarios of the IP phone and is easy to expand.
[0149] The definitions of the above-mentioned English abbreviations are as follows:
[0150] AUX (Auxiliary): Auxiliary audio;
[0151] VOIP (Voice over Internet Protocol): Voice transmission based on the Internet protocol;
[0152] BT (Bluetooth): Bluetooth;
[0153] USB (Universal Serial Bus): Universal Serial Bus;
[0154] Mic (Micphone): Microphone;
[0155] BT Mic (bluetooth micphone): Bluetooth device microphone;
[0156] USB Mic (Universal Serial Bus micphone): Universal Serial Bus device microphone;
[0157] AuxInput (Auxiliary Input): Auxiliary audio input;
[0158] AuxOutput (Auxiliary Output): Auxiliary audio output;
[0159] VoipInput (Voice over Internet Protoco Input): Voice transmission input based on the Internet protocol;
[0160] VoipOutput(Voice over Internet Protoco Ouput): Voice transmission output based on Internet protocol;
[0161] MicInput(Micphone Input): Microphone input;
[0162] AudioRouteState(): A concept that describes the audio routing state, usually used for management between multiple audio output devices;
[0163] Full(): Full, in this article it is the multi-channel mode;
[0164] Add(): Increase, in this article it is the increase channel mode;
[0165] Remove(): Remove, in this article it is the remove channel mode;
[0166] Volume(): Volume, in this article it is the volume mode and also the volume;
[0167] Idle(): Idle, in this article it is the idle mode;
[0168] Enable(): Enable, turn on, activate;
[0169] Disable(): Disable;
[0170] DeltaType(): The term of the Greek letter Δ, used to represent the change amount and difference;
[0171] Handset(): Handset mode;
[0172] Handsfree(): Speaker mode;
[0173] Headset(): Headphone mode;
[0174] Internal(): Internal, in this article it is the internal connection;
[0175] None(): Empty, in this article it means no connection.
[0176] It should be noted that although the operations of the method of the present invention are described in a specific order in the above embodiments and the accompanying drawings, however, this does not require or imply that these operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution.
[0177] To more clearly explain the design method of the above IP phone - based audio routing management system, the following will be described in conjunction with a specific embodiment. However, it should be noted that this embodiment is only for better explaining the present invention and does not constitute an improper limitation of the present invention.
[0178] Taking an incoming call on an IP phone as an example, to better elaborate on the essence of this design, assume that this IP phone uses a built - in speaker and is simultaneously bound to a BT headset and a USB headset. Based on this background, the process of an incoming call will be described.
[0179] 1. When the IP phone receives an incoming call, the first action should be that the incoming call ringtone sounds. Assume that the IP phone allows the incoming call ringtone to be played simultaneously on the USB headset and the built - in speaker. Then, when the ringing event occurs, construct the following AudioRouteState: DeltaType(Add)+(AUX input -> USB device output + enable + 70%)+(AUX input -> built - in speaker output + enable + 70%). At this time, the phone adds two audio channels from the Idle state, that is, the state where all audio channels are closed, so that the ringtone can be played simultaneously from the USB device and the built - in speaker.
[0180] 2. If the user chooses to reject the call at this time, construct the following AudioRouteState: DeltaType(Idle)+None. At this time, the phone will switch to the Idle state and close all audio channel connections. If the user chooses to answer the call at this time, go to step 3.
[0181] 3. Construct the following AudioRouteState according to the device selected by the user to answer the call. Assume that the user chooses to answer the call with the USB headset, and construct the following AudioRouteState: DeltaType(Full)+(VOIP input -> USB device output + enable + 70%)+(USB device Mic input -> VOIP output + enable + 40%). According to the above principle, Full will first disconnect all audio channel connections, then add an audio channel from VOIP input to USB device output to play the voice of the other end, and add an audio channel from USB device Mic input to VOIP output to record the voice of this end and send it to the network. And at this time, the volume of the audio channel VOIP input -> USB device output is 70% of the maximum value, and the volume of the audio channel USB device Mic input -> VOIP output is 40% of the maximum value.
[0182] 4. Assume that the user chooses to answer the call with the USB headset in step 3.
[0183] (1) And at this time, if the call content needs to involve other people in this call, the call mode can be switched to the Handsfree mode. At this time, the AudioRouteState can be constructed as follows: DeltaType(Full)+(VOIP input -> built-in speaker output + enable + 70%)+(built-in speaker Mic input -> VOIP output + enable + 40%). Full will first disconnect all audio path connections, then add an audio path from VOIP input to built-in speaker output to play the voice of the other end, and add an audio path from built-in speaker Mic input to VOIP output to record the voice of this end and send it to the network. And at this time, the volume of the audio path VOIP input -> built-in speaker output is 70% of the maximum value, and the volume of the built-in speaker Mic input -> VOIP output is 40% of the maximum value.
[0184] (2) Suppose the user just wants others to listen to the content of this call, but doesn't want everyone's voice to be transmitted to the other end. The user can keep the call on the USB headset unchanged and construct the following AudioRouteState: DeltaType(Add)+(VOIP input -> built-in speaker output + enable + 70%). Add the output from VOIP to the built-in speaker, so that the audio path of the Mic is only on the USB headset, but the output of VOIP can be output on both the USB headset and the built-in speaker.
[0185] 5. If the call duration is too long and the user feels uncomfortable wearing the USB headset, the user can choose to switch the call mode to the BT handset mode. The AudioRouteState can be constructed as follows: DeltaType(Full)+(VOIP input -> BT device output + enable + 50%)+(BT device Mic input -> VOIP output + enable + 40%).
[0186] 6. If the user feels that the volume of the BT handset is too small, the volume of the BT handset can be adjusted through this AudioRouteState. The AudioRouteState is as follows: DeltaType(Volume)+(VOIP input -> BT device output + enable + 100%).
[0187] 7. When the call ends,
[0188] (1) If our side hangs up the phone first
[0189] then use DeltaType(Idle)+None to disconnect all audio path connections.
[0190] (2) If the other party hangs up the phone first
[0191] You can use DeltaType(Full)+(VOIP input->BT device output+disable)+(BT device Mic input->VOIP output+disable)+(AUX input->BT device output+enable+50%) to close all VOIP audio channels, and open the audio channel of AUX input->BT device output to play the busy tone. When the busy tone ends, you can choose to hang up the call, and use DeltaType(Idle)+None to disconnect all audio channels.
[0192] The design method of the audio routing management system based on IP phone proposed by the present invention has the following improvements:
[0193] 1. Compared with the traditional state machine mode, the present invention is very easy to expand without the need for reconstruction. For example, if two BT devices need to be supported, it only needs to add a VOIP input / AUX input->BT(2) device output, and a BT(2) device Mic->VOIP output, which is easy to maintain.
[0194] 2. There are no dangerous memory operations and no risk of memory leaks.
[0195] 3. All update states are updated in one AudioRouteState, and for Add / Remove / Volume mode, only one audio path change needs to be maintained at a time. For Idle mode, all audio paths are directly closed. For Full mode, all audio paths are disconnected first and then connected as required. The operation mode is simple and does not affect the performance of the IP phone.
[0196] 4. No need to rely on third-party libraries, safe, reliable and easy to maintain.
[0197] 5. For phones with low CPU performance, the disconnection and connection of audio channels can be processed one by one. For phones with good CPU performance, multi-threaded synchronization can be performed to ensure the continuity of voice. Flexible use. And the number of threads is small, which will not affect the performance of the IP phone.
[0198] Although the spirit and principle of the present invention have been described with reference to several specific embodiments, it should be understood that the present invention is not limited to the disclosed specific embodiments, and the division of various aspects does not mean that the features in these aspects cannot be combined to benefit, and such division is only for the convenience of expression. The present invention is intended to cover various modifications and equivalent arrangements contained in the spirit and scope of the attached claims.
[0199] Regarding the limitations on the scope of protection of the present invention, those skilled in the art should understand that, based on the technical solution of the present invention, various modifications or deformations that can be made by those skilled in the art without creative efforts are still within the scope of protection of the present invention.
Claims
1. A design method for an audio routing management system based on an IP phone, characterized in that: The method includes: The audio routing management system of the IP phone is disassembled into multiple components, one side of which is AUX input, VOIP input and VOIP output, and the other side is BT device output, USB device output, built-in speaker output, built-in handle output, speaker Mic input, handle Mic input, BT Mic input and USB Mic input. These components are combined to form inputs and outputs of different audio channels, and combined with different switching modes and permutations and combinations of different audio channel connection states to construct an audio routing state and manage the audio channels in real time.
2. The design method of the audio routing management system based on IP phone according to claim 1 is characterized in that: The audio path is represented as follows: AUX input->BT device output; AUX input->USB device output; AUX input->built-in speaker output; AUX input->built-in handle output; VOIP input->BT device output; VOIP input->USB device output; VOIP input->built-in speaker output; VOIP input->built-in handle output; Speaker Mic input -> VOIP output; Handle Mic input -> VOIP output; BT device Mic input -> VOIP output; USB device Mic input -> VOIP output.
3. The design method of the audio routing management system based on IP phone according to claim 1 is characterized in that: The state of the audio route consists of the following components: Switching modes: Full / Add / Remove / Volume / Idle; Audio device: Handset / Handsfree / Headset / Idle; Input mode: AuxInput / VoipInput / MicInput; Connection type: Usb / Bt / Internal / None; Output mode: VoipOutput / AuxOuput; Path connection status: Enable / Disable+Volume; Among them, when you need to open two or more audio channels at the same time, use the switching mode Full; when you only need to open a certain audio channel, use the switching mode Add; when you only need to close an audio channel in the current state, use the switching mode Remove; when you only need to adjust the volume of a certain audio channel, use the switching mode Volume; when you need to close all audio channels of the IP, use the switching mode Idle; Among them, through the combination of audio device + connection type, you can confirm which device is currently working; through audio device + connection type + MicInput, you can confirm which device's Mic is working for the current VOIP call; through audio device + connection type + AuxOuput / VoipOuput, you can confirm on which device the current ringtone, ringback tone or VOIP output should be on. AuxInput / VoipInput is the VOIP data packet from the network or the data of the ringtone or ringback tone.
4. The design method of the audio routing management system based on IP phone according to claim 1 is characterized in that: The audio path connection status is shown as follows: AUX input->BT device output+enable+volume / disable; AUX input->USB device output+enable+volume / disable; AUX input->built-in speaker output+enable+volume / disable; AUX input->built-in handle output+enable+volume / disable; VOIP input->BT device output+enable+volume / disable; VOIP input->USB device output+enable+volume / disable; VOIP input->built-in speaker output+enable+volume / disable; VOIP input->built-in handle output+enable+volume / disable; Speaker Mic input->VOIP output+enable+volume / disable; Handle Mic input->VOIP output+enable+volume / disable; BT device Mic input->VOIP output+enable+volume / disable; USB device Mic input->VOIP output+enable+volume / disable.
5. The design method of the audio routing management system based on IP phone according to claim 1 is characterized in that: When the state of the audio route is successfully constructed, the usage logic is as follows: The application should analyze the switching mode in the current audio routing state. If the initial switching mode is Idle, all existing audio paths will be disconnected and the processing will end. If the switching mode is Full, all audio path connections are checked first, all connections are disconnected, and then the audio paths that need to be operated in the current audio routing status are analyzed, and the current open and closed audio path connection status is recorded in the application; If you need to add an audio channel before switching to Idle mode, switch the mode to Add, continue to add the audio channel, and update the connection status of all currently opened and closed audio channels in the application again; If you need to close an audio channel separately, switch the mode to Remove, close the audio channel directly, and update the connection status of all currently opened and closed audio channels in the application; If the switching mode is Volume, first detect the connection status of all currently opened and closed audio channels. If the current audio channel has been opened, there is no need to open it again. Just adjust the volume on this audio channel directly. If you need to switch the IP phone to Idle, switch the mode to Idle, close all connected audio channels, and update the connection status of all audio channels to closed in the application.