A method for expanding the concurrent incoming call volume of VoIP equipment based on SIP messages

Abstract

This invention discloses a method for expanding the concurrent inbound call capacity of VoIP devices based on SIP messages, belonging to the VoIP-related field. Specifically, for VoIP device A to initiate a call, the user sets the number and call type of the peer device B; it determines whether to use the standard SIP call procedure. If so, the call proceeds normally; otherwise, device A sends a pre-call SMS to device B, at which point device B allows multiple devices to make concurrent calls; then, device B's event handling module calls the SMS to send a response pre-call message to device A, stores the corresponding call event in the call list, and simultaneously transmits it to device B's user interface module to display an incoming call notification with the same style as a standard SIP call; user B0 presses a physical or virtual button to select accept, reject, or forward the pre-call; device B's event handling module processes the button event. This invention improves the concurrent inbound call capacity of VoIP devices and realizes the conversion of SIP messages into call control logic.

Description

Technical Field

[0001] This invention belongs to the field of VoIP (Voice over Internet Protocol), specifically a method for expanding the concurrent incoming call volume of VoIP devices based on SIP (Session Initialization Protocol) messages. Background Technology

[0002] With the continuous advancement of audio and video communication technologies, their user base is rapidly expanding, and the demand for calls carried on these technologies is also increasing daily.

[0003] VoIP devices offer advantages such as privacy protection, rich functionality, and low call costs, making them widely used in various high-frequency, high-load communication scenarios, including factories, data centers, healthcare, transportation, and commerce. However, a single VoIP device terminal has limited computing power, and calls exceeding its processing capacity will be dropped. If the customer group happens to be sensitive to message drop and cannot tolerate call loss, the VoIP device's dropping behavior will reduce the customer's experience satisfaction.

[0004] SIP messaging refers to the short message service based on SIP, providing a point-to-point text transmission capability between VoIP devices. Compared to standard SIP calls, SIP message reception and transmission are simpler to implement and transmit smaller amounts of data, thus placing lower performance requirements on devices. Therefore, if, after a call is initiated but not yet connected, a standard SIP call is not initiated, but rather SIP messages are used to pre-negotiate call-related information, delaying the creation of a standard SIP call until the called party answers, the consumption of limited resources by VoIP devices in processing standard SIP calls can be reduced, effectively increasing the volume of incoming calls that have not yet been connected for VoIP devices.

[0005] VoIP products are based on SIP and have the necessary hardware and software infrastructure for sending and receiving SIP messages. Therefore, no modifications to existing hardware are required; software support for pre-negotiation of SIP messages can be implemented directly. This not only meets the needs of specific application scenarios and saves costs but also facilitates the promotion of VoIP devices. Summary of the Invention

[0006] To address the aforementioned problems in existing technologies, this invention provides a method for expanding the concurrent incoming call volume of VoIP devices based on SIP messages. By converting SIP messages into call control logic, it realizes functions such as pre-call initiation, pre-call termination, and pre-call transfer, and provides a user interface consistent with standard SIP calls. Users can easily get started and use it without needing additional operational knowledge.

[0007] The method for converting SIP messages into call control logic comprises the following steps:

[0008] Step 1: For VoIP device A that is to initiate a call, user A0 sets the number and call method type of the other VoIP device B to the function key DSS Key of device A.

[0009] Each VoIP device includes a user input module, an SMS control module, a call control module, an event handling module, and a user interface module.

[0010] The user input module is responsible for receiving key events from physical buttons and virtual buttons on the touchscreen, and distributing them to the event handling module.

[0011] The SMS control module is responsible for sending and receiving SMS messages and distributing SMS events to the event handling module.

[0012] The call control module is responsible for initiating, hanging up, and transferring calls, and distributes call events to the event handling module.

[0013] The event handling module first receives the SMS message sent by the other end, responds to the other end indicating that the call has been received and stores it locally. Then, the local call list changes, thereby triggering a change in the user interface. Finally, when the user presses a key, the user interface module calls the event handling module to continue processing according to the user's selection.

[0014] The user interface module is responsible for presenting events to the user through screen images and speaker sounds.

[0015] Call method types include: standard SIP call type, or call type based on SIP messages to extend the concurrent incoming call volume of VoIP devices.

[0016] Step 2: When user A0 presses the function button DSS Key, device A determines whether to use the standard SIP call process based on the configured call method type. If so, it calls device A's call control module to call device B's number; otherwise, proceed to step 3.

[0017] Step 3: Device A selects the call type based on SIP message to extend the concurrent call volume of VoIP devices, that is, it calls the sending interface of the SMS control module to send a pre-call SMS to the number of device B. At this time, device B allows multiple devices to make concurrent calls.

[0018] Pre-call SMS messages include a header and a body;

[0019] The From field in the protocol header contains the number of device A; the To field contains the number of device B.

[0020] The protocol body includes:

[0021] The cid field represents the pre-call ID, which identifies different pre-calls of the VoIP device;

[0022] The event field indicates the call event operation to be performed in this call, including initiating a pre-call invite, responding to a pre-call invite back, the caller hanging up the pre-call end, the called party hanging up the pre-call know, and transferring the pre-call unattended;

[0023] Other business information: Other information required by the actual business, including protocol version number, message priority (callType), device name (callUser), device ID, device IP address, device MAC address, and device location information.

[0024] Step 4: Device B's SMS control module receives the pre-call SMS and transmits it to its own event handling module; the event handling module calls the SMS control module to send a response pre-call message to Device A, indicating that the call has been received;

[0025] Step 5: The event handling module of device B stores the call event corresponding to the pre-call SMS into the call list and simultaneously transmits it to the user interface module to update the call status, that is, display an incoming call reminder with the same style as a standard SIP call.

[0026] Step 6: User B0 presses the physical button or the virtual button on the screen of device B to select to accept the pre-call, reject the pre-call, or transfer the pre-call.

[0027] Step 7: The user input module of device B receives the key press event and transmits it to the event handling module for key press event processing.

[0028] If user B0 chooses to accept the pre-call, device B invokes the call control module to proactively initiate a standard SIP call to device A. This postpones the standard SIP call that should have been initiated by device A to device B, and changes device B to the call initiator. Simultaneously, device A automatically answers the call, creating the illusion of a connected call for user A0.

[0029] If user B0 chooses to reject the pre-call, device B sends a hang-up pre-call message to the peer device A, indicating that it has actively rejected the call.

[0030] The hang-up pre-call message body includes the following fields:

[0031] The endUser field: The number of device B;

[0032] The endType field indicates the reason for the hang-up; 0 indicates that device A received a hang-up from device B, 1 indicates that the hang-up was caused by device B not answering within a timeout period, 2 indicates that device A actively hung up, and 3 indicates that the hang-up was caused by a call priority adjustment.

[0033] If user B0 selects to forward a pre-call, user B0 should enter the number of device C for forwarding the pre-call and select the call type. Device B then sends a forwarding message to the peer device A, indicating that it will re-initiate a call to device C according to the selected call type.

[0034] The pre-call transfer message body includes the following fields:

[0035] The `transferTargetUser` field: The number of device C;

[0036] The `transferTargetDevice` field indicates the call type.

[0037] The `transferTargetIp` field: The IP address of device C.

[0038] The advantages of this invention are:

[0039] A method for increasing the concurrent inbound call volume of VoIP devices based on SIP messages is proposed. Based on VoIP products that support SIP messages, this method increases the concurrent inbound call volume of VoIP devices; it realizes the conversion of SIP messages into call control logic; and it implements a user operation interface consistent with standard SIP calls, reducing the skill requirements for VoIP device users and making it easier for users to use. Attached Figure Description

[0040] Figure 1 This is a flowchart of a method for expanding the concurrent inbound call volume of a VoIP device based on SIP messages according to the present invention;

[0041] Figure 2 This is a schematic diagram illustrating the communication principle between VoIP devices performing a pre-call process according to an embodiment of the present invention. Detailed Implementation

[0042] To facilitate understanding and implementation of the present invention by those skilled in the art, the present invention will be further described in detail and in depth below with reference to the accompanying drawings.

[0043] This invention discloses a method for expanding the concurrent incoming call capacity of VoIP devices based on SIP messages, specifically as follows: A user uses a VoIP device that supports this method and configures the desired device number and calling method on the DSS Key function key. After the user presses the DSS Key, the device will pre-negotiate with the remote VoIP device via SIP information. The called device displays an incoming call message in the same style as a standard SIP call. After the pre-call is initiated, it supports caller hanging up, call recipient hanging up, and call recipient pre-call transfer. Figure 1 As shown, the specific steps are as follows:

[0044] Step 1: For VoIP device A that is to initiate a call, user A0 sets the number and call method type of the other VoIP device B to the function key DSS Key of device A.

[0045] Each VoIP device includes a user input module, an SMS control module, a call control module, an event handling module, and a user interface module.

[0046] The user input module is responsible for receiving key events from physical buttons and virtual buttons on the touchscreen, and distributing them to the event handling module.

[0047] The SMS control module is responsible for sending and receiving SMS messages and distributing SMS events to the event handling module.

[0048] The call control module is responsible for initiating, hanging up, and transferring calls, and distributes call events to the event handling module.

[0049] The event handling module first receives the SMS message sent by the other end, responds to the other end to indicate that the call has been received and stores it locally. Then, the call list corresponding to the local call event changes, thereby triggering a change in the user interface. Finally, when the user presses a key, the user interface module calls the event handling module to continue processing according to the user's selection.

[0050] The user interface module is responsible for presenting events to the user through screen images and speaker sounds.

[0051] Call method types include: standard SIP call type, or call type based on SIP messages to extend the concurrent incoming call volume of VoIP devices.

[0052] Step 2: When user A0 presses the function button DSS Key, device A determines whether to use the standard SIP call process based on the configured call method type. If so, it calls device A's call control module to call device B's number; otherwise, proceed to step 3.

[0053] Step 3: Device A selects the call type based on SIP message to extend the concurrent call volume of VoIP devices, that is, it calls the sending interface of the SMS control module to send a pre-call SMS to the number of device B. At this time, device B allows multiple devices to make concurrent calls.

[0054] Device A sends a pre-call SMS to transmit incoming call information without initiating a SIP call. Since SIP SMS consumes fewer resources than SIP calls, more devices are allowed to call device B simultaneously, thus increasing the concurrent incoming call volume of device B.

[0055] Initiating a pre-call SMS includes a header and a body;

[0056] The From field in the protocol header is in the form of "6".<sip:6@1.hotspot> ;tag=596308316, contains the number of device A; the To field is in the form of "0"<sip:0@1.hotspot> It includes the number of device B.

[0057] The protocol body is in the following form:

[0058] {"version":"0.1","cid":53,"event":"invite","event.params":{"deviceType":"Y501W-Y","callType":0,"port":0,"areaSn":1,"r oomName":3,"bedName":0,"bedCode":1,"url":"","bindingCode":"","callIp":"172.16.66.208","callUser":"802617"},"type":"0"}

[0059] The cid field: Pre-call ID, which identifies different pre-calls for the VoIP device;

[0060] The event field indicates the call event to be performed, including initiating a pre-call (invite), responding to a pre-call (invite back), the caller ending the pre-call (end), the called party ending the pre-call (know), and transferring the pre-call (unattended).

[0061] Other business information: Other information required by the actual business. For example, protocol version number, message priority (callType), device name (callUser), device ID, device IP address, device MAC address, device location information, etc.

[0062] Step 4: Device B's SMS control module receives the pre-call SMS and transmits it to its own event handling module; the event handling module calls the SMS control module to send a response pre-call message to Device A, indicating that the call has been received;

[0063] The response pre-call message body is as follows:

[0064] {"version":"0.1","cid":55,"event":"invite back","event.params":{"calledUser":"802617","calledIp":"172.16.66.6"},"type":"0"}

[0065] Step 5: The event handling module of device B stores the call event corresponding to the pre-call SMS into the call list and simultaneously transmits it to the user interface module to update the call status, that is, display an incoming call reminder with the same style as a standard SIP call.

[0066] Step 6: User B0 presses the physical button or the virtual button on the screen of device B to select to accept the pre-call, reject the pre-call, or transfer the pre-call.

[0067] Step 7: The user input module of device B receives a key press event, and the event handling module processes the key press event:

[0068] If user B0 chooses to accept the pre-call, device B invokes the call control module to proactively initiate a standard SIP call to device A. This postpones the standard SIP call that should have been initiated by device A from device A to device B in step two to this step, and changes device B to the call initiator. Simultaneously, device A automatically answers the call, creating the illusion of a connected call for user A0.

[0069] If user B0 chooses to reject the pre-call, device B sends a hang-up pre-call message to the peer device A, indicating that it has actively rejected the call.

[0070] The hang-up pre-call message body is as follows:

[0071] {"version":"0.1","cid":53,"event":"end","event.params":{"endUser":"802617","endType":2,"areaSn":1},"type":"0"}

[0072] The endUser field: The number of device B;

[0073] The `endType` field indicates the reason for the hang-up. 0 indicates that device A received a hang-up notification from device B; 1 indicates that the hang-up occurred because device B did not answer within the timeout period; 2 indicates that device A actively hung up; and 3 indicates that the hang-up was caused by a call priority adjustment.

[0074] If user B0 selects to forward a pre-call, user B0 should enter the number of the forwarding device C and select the call type. Device B then sends a forwarding pre-call message to the peer device A, indicating that the call should be forwarded to device C again using the above type.

[0075] The format of the pre-call transfer message body is as follows:

[0076] {"version":"0.1","cid":"55","event":"unattended","event.params":{"tranferTargetUser:"002","tranferTargetDevice":"NurseStationDevice","tranferTargetIp":"172.16.20.20"},"type":"0"}

[0077] The `transferTargetUser` field: The number of device C;

[0078] The `transferTargetDevice` field indicates the call type.

[0079] The `transferTargetIp` field: The IP address of device C.

[0080] Example:

[0081] like Figure 2 As shown, including Figure 2 a. The principle of pre-calling after the called party hangs up Figure 2 b. Caller hang-up pre-call principle Figure 2 c. The principle of pre-calling for the called party to answer. Figure 2 d. The principle of initiating a standard SIP call after transferring a pre-call; Figure 2 The principle behind initiating a pre-call after e-transfer pre-call; the specific steps are as follows:

[0082] Step 1: For VoIP device A that is to initiate a call, user A0 sets the number of the peer device B and the call method type to the DSS Key of device A.

[0083] The specific configuration process is as follows: Through the user-friendly interface of VoIP device A, user A0 inputs the necessary parameters for the function keys according to the instruction manual; or through a browser, user A0 accesses the background management system provided by VoIP device A and inputs the relevant call parameters in the function key settings interface of the configuration page.

[0084] The parameters include: device number and call method type;

[0085] Step 2: When user A0 presses the DSS Key function button, device A determines whether to use the standard SIP call process or the pre-call process based on the configured call method type.

[0086] When user A0 presses the DSS Key function key configured on VoIP device A, the user input module receives the key press and release events, and notifies the event handling module to read the key parameter configuration information of the DSS Key and write it into the key event, which is then sent to the event handling module for judgment.

[0087] Key events refer to the data information transmitted by the user input module to other modules based on the state and duration of the physical keys or virtual keys on the touch screen of VoIP device A.

[0088] Step 3: Depending on the user's selection, if the standard SIP call process is used, the call control module is invoked to call the configured peer VoIP device B number; if the pre-call process is used, the SMS control module's sending interface is invoked to send a pre-call SIP SMS to the peer device B number.

[0089] The event handling module constructs a standard VoIP call request or pre-call request based on the pre-registered call line or other call lines specified by the user, and the set call type. If the call type of the DSS Key is set to pre-call, a pre-call request is constructed, which involves calling the SMS control module's sending interface to create an SMS message containing pre-call information, creating a UDP or TCP socket, and sending the pre-call information to the SIP server or the peer VoIP device B via Ethernet.

[0090] A voice call line, also known as a SIP line, is a telephone line that uses the SIP protocol for communication; a voice call line should support:

[0091] 1) Registration: This refers to the process by which a VoIP device provides its IP address and the network protocol and port used for VoIP communication to the SIP server before initiating a call or other data communication.

[0092] 2) Signaling forwarding: After the aforementioned registration process, the SIP server should be able to forward request and response messages such as call initiation, call termination, call transfer, call renegotiation, and information sending to both parties based on the device number.

[0093] Pre-call SIP SMS is based on the SIP SMS (a method of text exchange in a communication system using the SIP protocol) function and is a method for achieving pre-call negotiation.

[0094] The SIP SMS message header stores the peer device number, and the message body of the SIP SMS contains the necessary parameters for the pre-negotiation call; its message body should include:

[0095] 1) Device protocol version number: This refers to the protocol stack version number that processes the pre-call negotiation information. The communicating parties can provide different communication service capabilities or different business processing logic based on different version numbers;

[0096] 2) Device IP address: This refers to the IP address of the device that sent the pre-call negotiation information. To ensure device communication availability and effectively improve the disaster recovery capability of VoIP communication, when the device number used by the VoIP device becomes abnormal and cannot make calls normally, it will attempt to bypass the SIP server, the intermediate device for VoIP communication, and directly continue negotiation or pre-negotiation with the IP address of the other VoIP device.

[0097] 3) Pre-call ID: This refers to the identifier of a call between a pair of VoIP devices. When a pair of VoIP devices are processing the same pre-call, they should both use the same pre-call ID in their signaling. The significance of the pre-call ID is to distinguish different calls between a pair of VoIP devices, preventing call logic processing errors caused by signaling overlap and mutual interference between different calls due to device lag, network latency, or other reasons when both VoIP devices are processing multiple calls.

[0098] 4) Pre-call event types: including five signaling types, namely, initiating a pre-call, responding to a pre-call, calling party hanging up a pre-call, called party hanging up a pre-call, and transferring a pre-call;

[0099] 5) Other Business Information: The Other Business Information field allows VoIP developers to expand the scope of other business information required during the pre-call process, such as message priority, device name, device ID, device MAC address, and device location information. Its functions include: adding, deleting, and modifying text, image, voice, animation, ringtones, alert tones, and alarm sounds displayed to the user interface module; setting the duration and frequency of information displayed in the user interface module; dynamically modifying the business logic of the event handling module, such as whether to write to the call log, set the ringtone volume of the called device, whether to push relevant business information to other external devices physically connected to this VoIP device, whether to write relevant business information to the VoIP device's built-in storage, and whether to upload relevant business information to other terminals or servers that have established network communication with the VoIP device in various formats such as XML, CSV, and JSON; etc.

[0100] Step 4: The SMS control module of the called device B receives the pre-call SMS and transmits it to the event handling module; the event handling module calls the SMS control module to send a response pre-call message to the device A that initiated the pre-call, indicating that the call has been received;

[0101] If the initiating VoIP device A does not receive an acknowledgment message from the peer B for the pre-call information as specified by the SIP protocol, i.e., the peer SIP protocol stack times out of processing the SIP message, the initiating device A will attempt to retransmit at the intervals specified by the SIP protocol standard; if the initiating VoIP device A does not receive a response pre-call information from the peer using the same pre-call ID, i.e., the peer pre-call protocol stack times out of processing the pre-call message or the peer device does not support the pre-negotiation method, the initiating VoIP device A will hang up the local call after 5 seconds, and the user processing module will display the new call status to the user in the form of images and sounds;

[0102] Step 5: The event handling module of the called device B stores the call event in the call list;

[0103] The event handling module packages the relevant information of this call into a call event, sorts it according to factors such as time and call priority in other business information, and stores it in a linked list for later use.

[0104] Step 6: The event handling module of the called device B transmits the call event to the user interface module to update the call status;

[0105] The user interface module reads relevant information from the call event, renders a notification window for the call information on the screen of device B, and calls the device's speaker to play specified audio at a set volume.

[0106] Prompt window: Reads the device's configuration information, corresponds to the message priority value in other service information, and displays a window with the corresponding color and background image;

[0107] Specify audio: Based on the device's configuration information and the message priority value in other service information, play the specified music file at the specified volume.

[0108] Step 7: User B0 updates the call information through the user interface module and chooses to accept the pre-call, reject the pre-call, or transfer the pre-call.

[0109] Step 8: The user input module of the called device B receives a key press event, and the event handling module processes the key press event.

[0110] If the user chooses to accept the pre-call, the called device B calls the call control module to initiate a standard SIP call to the peer A, and the peer A will automatically answer the call to the user A0, creating the phenomenon of a caller being connected.

[0111] If user B0 chooses to reject the pre-call, the called device B sends a hang-up pre-call message to the other device indicating that it has actively rejected the call.

[0112] If user B0 selects to forward a pre-call, the called device sends a forwarding message to the peer device indicating what type of call should be made to the specified number again.

[0113] 1) Accept pre-calls;

[0114] The user interface module will select and transmit the call to the call control module, which will then initiate a standard SIP call to the pre-call initiating device A. After the pre-call initiating device A automatically answers, both devices will enter the standard SIP call process.

[0115] 2) Reject pre-call;

[0116] The user interface module will select to transmit to the SMS control module, which will send a pre-negotiation SMS message indicating that the called party has rejected the pre-call to the pre-call initiating device A, and both devices will end the pre-call process.

[0117] 3) Transfer pre-call.

[0118] The user interface module will select to transmit to the SMS control module, send a pre-negotiation SMS for transferring the pre-call to the pre-call initiating device A, the pre-call initiating device extracts the peer VoIP device number C and the call method type from the pre-call SMS protocol body, and repeat step three to initiate a standard SIP call or pre-call.

Claims

1. A method for expanding the concurrent inbound call volume of a VoIP device based on SIP messages, characterized in that, The specific steps are as follows: Step 1: For VoIP device A that is to initiate a call, user A0 sets the number and call method type of the other VoIP device B to the function key DSS Key of device A. Each VoIP device includes a user input module, an SMS control module, a call control module, an event handling module, and a user interface module; Call method types include: standard SIP call type, or call type based on SIP messages to extend the concurrent incoming call volume of VoIP devices; Step 2: When user A0 presses the function button DSS Key, device A determines whether to use the standard SIP call process based on the configured call method type. If so, it calls device A's call control module to call device B's number; otherwise, proceed to step 3. Step 3: Device A selects the call type based on SIP message to extend the concurrent call volume of VoIP devices, that is, it calls the sending interface of the SMS control module to send a pre-call SMS to the number of device B. At this time, device B allows multiple devices to make concurrent calls. Step 4: Device B's SMS control module receives the pre-call SMS and transmits it to its own event handling module; the event handling module calls the SMS control module to send a response pre-call message to Device A, indicating that the call has been received; Step 5: The event handling module of device B stores the call event corresponding to the pre-call SMS into the call list and simultaneously transmits it to the user interface module to update the call status, that is, display an incoming call reminder with the same style as a standard SIP call. Step 6: User B0 presses the physical button or the virtual button on the screen of device B to select to accept the pre-call, reject the pre-call, or transfer the pre-call. Step 7: The user input module of device B receives the key press event and transmits it to the event handling module for key press event processing. If user B0 chooses to accept the pre-call, device B calls the call control module to actively initiate a standard SIP call to device A. This postpones the standard SIP call that should have been initiated by device A to device B and changes device B to be the call initiator. At the same time, device A will automatically answer the call to user A0, creating the appearance of a call being connected. If user B0 chooses to reject the pre-call, device B sends a hang-up pre-call message to the peer device A, indicating that it has actively rejected the call. If user B0 selects to forward a pre-call, user B0 should enter the number of device C for forwarding the pre-call and select the call type. Device B then sends a forwarding message to the peer device A, indicating that it will re-initiate a call to device C according to the selected call type.

2. The method for expanding the concurrent inbound call volume of a VoIP device based on SIP messages as described in claim 1, characterized in that, In step one, the user input module is responsible for receiving key events from physical buttons and virtual buttons on the touch screen, and distributing them to the event processing module. The SMS control module is responsible for sending and receiving SMS messages and distributing SMS events to the event handling module. The call control module is responsible for initiating, hanging up, and transferring operations, and distributing call events to the event handling module. The event handling module first receives an SMS from the other end, responds to the other end indicating that the call has been received and stores it locally. Then, the local call list changes, thereby triggering a change in the user interface. Finally, when the user presses a key, the user interface module calls the event handling module to continue processing according to the user's selection. The user interface module is responsible for presenting events to the user through screen images and speaker sounds.

3. The method for expanding the concurrent inbound call volume of a VoIP device based on SIP messages as described in claim 1, characterized in that, In step three, the pre-call SMS includes a protocol header and a protocol body; The From field in the protocol header contains the number of device A; the To field contains the number of device B. The protocol body includes: The cid field represents the pre-call ID, which identifies different pre-calls of the VoIP device; The event field indicates the call event operation to be performed in this call, including initiating a pre-call invite, responding to a pre-call invite back, the caller hanging up the pre-call end, the called party hanging up the pre-call know, and transferring the pre-call unattended; Other business information: Other information required by the actual business, including protocol version number, message priority (callType), device name (callUser), device ID, device IP address, device MAC address, and device location information.

4. The method for expanding the concurrent inbound call volume of a VoIP device based on SIP messages as described in claim 1, characterized in that, In step seven, the pre-call disconnect message body includes the following fields: The endUser field: The number of device B; The endType field indicates the reason for the hang-up; 0 indicates that device A received a hang-up from device B, 1 indicates that the hang-up was caused by device B not answering within a timeout period, 2 indicates that device A actively hung up, and 3 indicates that the hang-up was caused by a call priority adjustment.

5. The method for expanding the concurrent inbound call volume of a VoIP device based on SIP messages as described in claim 1, characterized in that, In step seven, the pre-call transfer message body includes the following fields: The `transferTargetUser` field: The number of device C; The `transferTargetDevice` field indicates the call type. The `transferTargetIp` field: The IP address of device C.

Images