CN119697126A - SIP signaling transmission and flow control method, device and computer equipment - Google Patents

Abstract

The present application is applicable to the field of communication technology, and provides a SIP signaling transmission and flow control method, device and computer equipment, including: obtaining the SIP signaling flow prediction value in the SIP network through a flow prediction model, and triggering the flow regulation strategy when the SIP signaling flow prediction value exceeds the threshold; the SIP network includes at least one SIP device and at least one SIP server, and any SIP device monitors its own state in real time. If there is state change information that needs to be synchronized, a difference data packet is generated according to the state change information, and the difference data packet is transmitted to the corresponding SIP server, so that the SIP server updates the state information of the SIP device stored in it according to the difference data packet; otherwise, a heartbeat signaling is sent to complete the SIP periodic registration. On the one hand, through flow prediction and signaling priority allocation, signaling accumulation and network congestion are effectively alleviated, and on the other hand, redundant data transmission is reduced through difference updates.

Description

SIP signaling transmission and flow control method, device and computer equipment

Technical Field

The present application belongs to the field of communication technology, and in particular, relates to a method and apparatus for SIP signaling transmission and flow control, and a computer device.

Background

With the rapid development of real-time communication technology, the SIP protocol (Session Initiation Protocol ) has become a major technology for audio-video calls, instant messaging, and multimedia communications. In the conventional SIP signaling interaction process, there are problems that firstly, even if the device state is unchanged in the conventional registration process, a complete REGISTER request needs to be periodically sent, and a redundant signaling transmission phenomenon is serious, and secondly, when the device scale is large or the instantaneous concurrency is high, a server needs to process a large amount of redundant signaling, which increases the calculation load of a system and causes an increase in response delay, and in addition, SIP signaling traffic has obvious time sequence fluctuation characteristics, network congestion is easily caused in a traffic peak period, and delay sensitive signaling (such as INVITE) cannot be timely processed, thereby influencing communication quality.

Disclosure of Invention

The embodiment of the application provides a method, a device and a computer device for SIP signaling transmission and flow control, which can solve the problems of network congestion and redundant signaling transmission.

In a first aspect, an embodiment of the present application provides a method for transmitting SIP signaling and controlling flow, including:

The method comprises the steps of obtaining a SIP signaling flow prediction value in a SIP network through a flow prediction model, and triggering a flow regulation strategy when the SIP signaling flow prediction value exceeds a threshold value, wherein the flow regulation strategy comprises the steps of distributing flow priority to SIP signaling according to the type of the SIP signaling and preferentially forwarding high-priority signaling;

The SIP network comprises at least one SIP device and at least one SIP server, wherein any SIP device monitors the state of the SIP device in real time, if state change information to be synchronized occurs, a difference data packet is generated according to the state change information, the difference data packet is transmitted to the corresponding SIP server, so that the SIP server updates the stored state information of the SIP device according to the difference data packet, and otherwise, heartbeat signaling is sent according to a preset time period to complete periodic registration of the SIP.

Illustratively, the method further comprises:

Grouping the SIP devices in the SIP network according to the target characteristics of the SIP devices, wherein the characteristic values of the target characteristics of the SIP devices in each group are the same;

When the SIP devices in the SIP network are started, each group of SIP devices transmits a registration request to the SIP server according to the allocated time for transmitting the registration request.

Illustratively, the method further comprises:

The SIP server caches static parameters of any SIP equipment according to a first registration request of the SIP equipment;

after receiving the difference data packet of any SIP device, the SIP server performs parameter verification and status update according to the status change information in the difference data packet and the self-cached static parameters of the SIP device.

Illustratively, the method further comprises:

Any SIP device generates an INVITE message by populating the required dynamic fields in a predefined INVITE template that includes the INVITE message structure and the required static fields of the INVITE message.

Illustratively, the method further comprises:

And for any SIP equipment, predicting the probability of giving correct response by the opposite terminal equipment within preset response time according to the historical session data of the opposite terminal equipment, if the predicted probability is larger than a threshold value, sending an ACK message in advance, otherwise, waiting for the normal response of the opposite terminal equipment and then sending the ACK message.

Illustratively, sending the ACK message includes:

the ACK message is generated by filling the required dynamic fields in a predefined ACK template that includes the ACK message structure and the required static fields of the ACK message.

Illustratively, obtaining the SIP signaling traffic prediction value in the SIP network by the traffic prediction model includes:

and the historical SIP signaling flow time sequence is used as a flow prediction model to be input to obtain an SIP signaling flow prediction value output by the flow prediction model, and the flow prediction model is generated based on long and short memory network LSTM model training.

In a second aspect, an embodiment of the present application provides a device for SIP signaling transmission and flow control, including:

the flow control module is used for acquiring an SIP signaling flow prediction value in an SIP network through a flow prediction model, and triggering a flow regulation strategy when the SIP signaling flow prediction value exceeds a threshold value, wherein the flow regulation strategy comprises the steps of distributing flow priority for the SIP signaling according to the type of the SIP signaling and preferentially forwarding the high-priority signaling;

The SIP device comprises a signaling transmission module, a SIP server and a heartbeat signaling module, wherein the signaling transmission module is used for controlling any SIP device to monitor the state of the SIP device in real time, generating a difference data packet according to state change information needing to be synchronized if the state change information appears, and transmitting the difference data packet to the corresponding SIP server so that the SIP server updates the stored state information of the SIP device according to the difference data packet, otherwise, sending a heartbeat signaling according to a preset time period to finish the periodic registration of the SIP.

In a third aspect, an embodiment of the present application provides a computer apparatus, including:

A memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method of any one of the above first aspects when executing the computer program.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program which when executed by a processor implements the method of any one of the first aspects.

In a fifth aspect, embodiments of the present application provide a computer program product for, when run on a computer device, causing the computer device to perform the method of any one of the first aspects.

It will be appreciated that the advantages of the second to fifth aspects may be found in the relevant description of the first aspect, and are not described here again.

Compared with the prior art, the method has the advantages that the method utilizes the flow prediction model to acquire the signaling flow prediction value in the SIP network in real time, triggers the flow adjustment strategy to optimize signaling transmission when the flow exceeds the threshold value, monitors the state of the SIP equipment in real time, generates a difference data packet when the state changes and transmits the difference data packet to the server to update the state information, and only sends heartbeat signaling to complete periodic registration when the state does not change. The application can dynamically optimize signaling transmission by a flow prediction and adjustment strategy, reasonably allocate signaling priority, ensure that high priority signaling is transmitted preferentially at the time of flow peak, effectively relieve network congestion, reduce network delay and improve the real-time performance and stability of a communication system, and on the other hand, only transmit differential data packets with state change by adopting a differential updating mechanism, greatly reduce redundant data transmission, reduce network bandwidth occupation and server processing burden and improve the resource utilization efficiency and response speed of the system.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments or the description of the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic diagram of a SIP registration flow according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a Digest authentication procedure according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of a collaborative operation of a differential update mechanism, a packet registration mechanism and a pre-cache mechanism according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a use flow of a quick invitation template according to an embodiment of the application;

FIG. 5 is a flowchart of a pre-resolution ACK mechanism according to an embodiment of the present application;

FIG. 6 is a flow chart of a dynamic flow adjustment strategy according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a SIP signaling transmission and flow control device according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

As used in the present description and the appended claims, the term "if" may be interpreted as "when..once" or "upon" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".

In addition, in the description of the present specification and the appended claims, the terms "first," "second," "third," and the like are used merely to distinguish between descriptions and are not to be construed as indicating or implying relative importance.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more, but not all, embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

The embodiment of the application provides a method for transmitting SIP signaling and controlling flow, which comprises the following steps:

The method comprises the steps of obtaining a SIP signaling flow prediction value in an SIP network through a flow prediction model, and triggering a flow regulation strategy when the SIP signaling flow prediction value exceeds a threshold value, wherein the flow regulation strategy comprises the steps of distributing flow priority to SIP signaling according to the type of the SIP signaling, and preferentially forwarding high-priority signaling;

Any SIP device monitors the state of the device in real time, if the state change information to be synchronized appears, a difference data packet is generated according to the state change information, and the difference data packet is transmitted to a corresponding SIP server, so that the SIP server updates the stored state information of the SIP device according to the difference data packet, otherwise, heartbeat signaling is sent according to a preset time period to complete periodic registration of the SIP.

According to the method, on one hand, signaling transmission can be dynamically optimized through a flow prediction and adjustment strategy, signaling priority can be reasonably distributed, priority transmission of high-priority signaling is guaranteed when the flow is high, network congestion is effectively relieved, network delay is reduced, instantaneity and stability of a communication system are improved, and on the other hand, a difference update mechanism is adopted, only difference data packets with state change are transmitted, redundant data transmission is greatly reduced, network bandwidth occupation and server processing burden are reduced, and resource utilization efficiency and response speed of the system are improved.

The following describes the technical scheme in the embodiment of the present application in detail. It should be understood that the sequence number of each step in the embodiments described below does not mean the sequence of execution, and the execution sequence of each process should be determined by its functions and internal logic, and should not be construed as limiting the implementation process of the embodiments of the present application.

The following describes the technical scheme in the embodiment of the present application in detail.

(1) Signaling transmission optimization

In terms of signaling transmission, the embodiment of the application designs the SIP registration flow in detail, and the following detailed description is given:

(1.1) registration flow optimization

(1.1.1) Differential update mechanism

The conventional SIP registration process has the following problems that SIP equipment needs to periodically send a REGISTER request (registration request) to update registration information recorded by a server, complete data is required to be transmitted even if no state changes exist, when multiple equipment are registered simultaneously, the signaling quantity is large, the load of the server and the communication time delay are increased at the moment, and the patent adopts a difference update mechanism from the perspective of the registration process. It should be noted that a REGISTER request typically requires that a user prove the validity of their identity to a server through an authentication mechanism (e.g., digest authentication). The server will verify the identity information of the user (e.g. username, password, etc.), ensuring that only legitimate users can register.

In view of the above, embodiments of the present application reduce the amount of redundant data by communicating a field of a device state change only in the case of a device state change when a REGISTER requests periodic registration. If there is no state change, only heartbeat signaling needs to be sent to maintain the registration state without sending a complete REGISTER message. Fig. 1 shows a schematic diagram of a SIP registration flow provided in an embodiment of the present application. As shown in fig. 1, the process specifically includes:

s101, detecting device state change.

In this step, the SIP device detects its own state in real time. The status information (or fields) of a SIP device illustratively includes a device identification, an IP address, a port number, authentication information (key or verification information of the device), and a device operational status. When any one of the state information of the SIP equipment is detected to change, specific change content is recorded. For example, if the IP address of the SIP device is changed from 192.168.0.10 to 192.168.0.11 and the communication port is changed from 5060 to 5062, a change in the above two status information is detected, and the specific change content is recorded.

S102, generating a difference data packet.

In this step, the SIP device generates a differential packet according to the detected state change information to be synchronized.

Illustratively, the differential data packet may contain only information different from the SIP device initial state information. For example, the differential packet format may be { "IP": "192.168.0.11", "Port": "5062" }, i.e., containing only the changed IP address and communication Port number.

If the SIP device status information is unchanged, only a simple heartbeat signaling needs to be sent to the SIP server periodically to maintain the registration status, and no differential packet needs to be generated.

S103, transmitting the difference data packet.

In this step, the SIP device transmits the difference packet to the SIP server through the REGISTER request, so as to avoid repeated transmission of the complete registration information. The following are examples of differential packet transmissions:

upon first registration, the SIP device sends a complete REGISTER request to the SIP server, containing all necessary fields:

REGISTER sip:example.com SIP/2.0

Via:SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK001

Contact:<sip:user1@192.168.0.10:5060>

Expires:3600

Call-ID:abc123@example.com

CSeq:1 REGISTER

The REGISTER request contains the destination domain of the registration request, the SIP protocol version used, the path information (Via) the request passes through, the BRANCH identity (branch_id), the SIP device address information (Contact), the validity period of the registration information (expire), the session identity (call_id), and the sequence number (CSeq).

When the state of the SIP equipment changes, the SIP equipment only sends a difference data packet to the SIP server according to the changed state information:

REGISTER sip:example.com SIP/2.0

Call-ID:abc123@example.com

CSeq:2 REGISTER

Status-Change:{ "IP":"192.168.0.11","Port":"5062" }

the REGISTER request contains the destination domain of the registration request, the SIP protocol version used, the session identification (call_id), the sequence number (CSeq) and the changed state information (IP address and communication port number).

By comparing the data packet sent by the first registration with the difference data packet, it can be seen that the difference data packet in the embodiment of the application effectively reduces the data volume required to be transmitted to the SIP server when the state of the SIP device changes.

S104, state updating processing.

Illustratively, in this step, after the SIP server receives the differential data packet of the SIP device, the SIP server checks the integrity and validity of the differential data (e.g. through authentication information verification), and updates the stored state information of the SIP device according to the content therein. Such as updating the IP address and communication port number of the SIP device.

In one embodiment, the SIP protocol may use a Digest authentication approach. Fig. 2 illustrates a Digest authentication procedure, as shown in fig. 2, which includes:

s201, the SIP device initially sends a REGISTER request to the SIP server without an Authorization header.

S202, the SIP server returns a 401 Unauthorized response and appends a WWW-Authenticate header.

Illustratively, the response returned by the SIP server is as follows:

SIP/2.0 401 Unauthorized

WWW-Authenticate:Digest realm="example.com",nonce="xyz123",algorithm=MD5,qop="auth"

s203, the SIP device resends the REGISTER request with an Authorization header.

Illustratively, the REGISTER request retransmitted by the SIP device is as follows:

REGISTER sip:example.com SIP/2.0

Call-ID:abc123@example.com

CSeq:2 REGISTER

Authorization:Digest username="device1",realm="example.com",nonce="xyz123",response="abcd5678"

s204, the SIP server verifies whether the response is correct, and checks whether the same nonce is used.

The difference data packet needs to be authenticated, and an authentication header needs to be extracted, so that legal equipment is ensured to update own information. Whereas heartbeat signaling does not require authentication information and is only used to maintain online status.

(1.1.2) Packet registration mechanism

The application also provides an optimization mechanism aiming at large-scale SIP equipment registration, and the application reduces the instantaneous load of the server and improves the registration efficiency through technical means such as grouping registration, pre-caching, difference updating and the like.

In order to avoid excessive instantaneous load of a server caused by simultaneous registration of large-scale equipment, the embodiment of the application provides a batch registration method based on grouping management. The grouping strategy can be dynamically adjusted according to the geographic location of the device, the IP address segment, the device priority or the network status. The method comprises the steps of receiving a registration request from a SIP server, wherein the registration request is sent to the SIP server by the SIP equipment, and the SIP equipment is distributed to the SIP network according to the characteristic value of the target characteristic of the SIP equipment.

The following is an example of grouping according to the IP address field by the grouping policy, device group a (priority registration): 192.168.1.0/24 for high priority areas, which are typically core communication nodes of a metropolitan area such as beijing shanghai, etc., and device group B (delay registration): 192.168.2.0/24 for normal areas. When the device is started, the device selects an appropriate time to send a registration request according to the grouping strategy. For example, device group A transmits a registration time of t=0 seconds and device group B transmits a registration time of t=5 seconds. The SIP server gradually receives the device registration, avoiding bursty traffic.

The grouping policy may be configured to the SIP device in a variety of ways, such as server dynamic delivery, manual configuration, etc. For example, the grouping policy may be dynamically issued by the SIP server to the respective devices after the SIP device is booted. Common SIP devices (e.g., door access, camera) support active pull and server push functions. The packet policy may be issued by referring to 1) after the SIP device is started, sending device information (IP address, MAC address, device ID, etc.) to the SIP server, 2) the SIP server returns a corresponding packet policy according to the device information, and 3) the SIP device periodically queries the SIP server whether there is a new packet policy.

In some embodiments, a packet registration mechanism is used to alleviate problems that may result in server transient overload when large-scale devices are registered simultaneously. The packet registration mechanism is applicable to both first registration and periodic registration, in which the packet information may remain unchanged or be dynamically adjusted. The grouping information of the equipment is stored in the server during the first registration, and the cached data can be directly compared and rapidly verified during the subsequent registration. Whether the subsequent packet information may vary depends on the specific traffic requirements.

(1.1.3) Pre-caching mechanism

Existing SIP devices typically require that the server check the integrity parameters (e.g., user authentication, device configuration, etc.) at each registration, which increases the computational burden on the server. The embodiment of the application provides a pre-caching mechanism, which reduces repeated verification of information by caching static parameters of equipment in an SIP proxy server. The SIP server caches static parameters (such as equipment ID and authentication information) of any SIP equipment according to a first registration request of the SIP equipment, and after receiving a difference data packet of any SIP equipment, the SIP server performs parameter verification and state update according to state change information in the difference data packet and the static parameters of the SIP equipment cached by the SIP server.

To facilitate understanding of the pre-caching mechanism provided by the embodiments of the present application, the following description is provided with reference to an example:

the device is registered for the first time (complete authentication), 1) the SIP device sends a registration request containing device information (including authentication information such as device ID, key or signature, IP address, network port and the like) to the SIP server, 2) the SIP server checks the device key or signature and records the device information, 3) the server stores static data into a cache (Redis, memcached and the like), and 4) after the device is successfully authenticated by the server, an authentication Token is returned to the SIP device for subsequent rapid verification.

The subsequent registration (quick verification) of the device comprises 1) the SIP device sends a registration request (comprising a device ID, an IP address, a network port and an authentication Token) to the SIP server, 2) the SIP server reads static data (device ID, a secret key and the like) of the device from a cache, 3) the SIP server only compares dynamic data (IP address, network port and authentication Token), if the authentication Token is valid, the authentication is directly passed, otherwise, the authentication needs to be completed again, and 4) if the SIP server successfully authenticates the SIP device, the latest strategy or the heartbeat confirmation is returned.

It should be noted that, each mechanism provided by the embodiment of the present application may be used separately or in combination. Fig. 3 illustrates a flow diagram of a cooperation of a differential update mechanism, a packet registration mechanism, and a pre-caching mechanism. As shown in fig. 3, in the device initialization phase in the first step, the SIP device decides the registration time according to the packet policy and detects its own state at a moment. In the second step of the differential update stage, the SIP device generates a differential packet when detecting a change of its own state, where the differential packet only includes a state change field, and transmits the differential packet to the server through a REGISTER request. And in the third step of grouping registration, the SIP equipment REGISTERs according to the group batches, so that the excessive high instantaneous flow is avoided, and meanwhile, the REGISTER request for registering each batch is based on a difference updating mechanism and only transmits necessary data. In the fourth step of server processing, for the first registration request, the SIP server stores the static field of the device into a cache, and for the subsequent registration request, the SIP server verifies the difference field according to the cache data and the authentication Token, thereby rapidly completing the state update.

Through the cooperative work of the difference updating mechanism, the grouping registering mechanism and the pre-caching mechanism, the application realizes the high efficiency of the registering process of the SIP equipment. The difference updating mechanism reduces redundant data transmission, the grouping registration mechanism smoothes the instantaneous load of the server, and the pre-caching mechanism further improves the verification efficiency.

(1.2) Session invite optimization:

In the SIP session establishment process, the interaction of the INVITE message and its response easily generates redundant content, affecting the efficiency. The application provides an optimal design aiming at the problem, and the key points include a quick invitation template and a pre-analysis ACK mechanism.

(1.2.1) Quick invite templates

The conventional INVITE message contains a large number of repeated fields (e.g., via, call-ID, etc.), and a complete INVITE message needs to be generated each time a session is established, which places a large burden on message generation and transmission. The conventional INVITE message is exemplified as follows:

INVITE sip:user2@example.com SIP/2.0

Via:SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK776asdhds

Max-Forwards:70

From:<sip:user1@example.com>;tag=1928301774

To:<sip:user2@example.com>

Call-ID:asd88asd77a@192.168.1.10

CSeq:1 INVITE

Contact:<sip:user1@192.168.1.10>

Content-Type:application/sdp

Content-Length:150

< SDP information omission >

The present application reduces unnecessary field generation and transmission by having any SIP device generate an INVITE message by populating the required dynamic fields in a predefined INVITE template that includes the INVITE message structure and the required static fields of the INVITE message. Fig. 4 is a schematic diagram illustrating a use flow of a quick invitation template, as shown in fig. 4, where the flow specifically includes:

s401, establishment and distribution of a predefined INVITE template.

In the device production phase, the Template file is written into the device storage through the configuration tool, and the Template version information (such as template_v1.0) is recorded in the device firmware. When the device is registered, the server verifies the template version. If the device template version is lower than the server version, the server distributes the latest template to the device through a PUBLISH message. Templates include static fields (e.g., protocol type, basic field structure) and dynamic fields (e.g., destination address, device IP)

An example template is as follows:

INVITE sip:[TARGET] SIP/2.0

Via:SIP/2.0/UDP [DEVICE_IP];branch=[BRANCH_ID]

Max-Forwards:[MAX_FORWARDS]

From:<sip:[USER_FROM]>;tag=[TAG]

To:<sip:[TARGET]>

Call-ID:[CALL_ID]

CSeq:1 INVITE

Contact:<sip:[USER_CONTACT]>

Content-Type:application/sdp

Content-Length:[CONTENT_LENGTH]

< SDP information omission >

S402, dynamic field collection and filling.

The DEVICE collects dynamic field values in real time at session initiation, including a TARGET address ([ TARGET ]), a DEVICE IP ([ device_ip ]), a session identification ([ call_id ]), and the like. Acquisition of dynamic fields there are many implementations possible, for example, DEVICEs acquire dynamic field values in real time at session initiation, including the acquisition of the TARGET address ([ TARGET ]) from the user operating DEVICE configuration, the dynamic reading of the DEVICE IP ([ device_ip ]) from the network stack, the generation of the session identification ([ call_id ]) from the DEVICE timestamp and unique identification, other fields (e.g., [ TAG ], [ branch_id ], etc.) from the DEVICE state or internal random generator.

And after the acquisition is completed, filling the dynamic field according to the placeholder position in the template. For example:

[TARGET] -> sip:user2@example.com

[DEVICE_IP] -> 192.168.1.10

[CALL_ID] -> asd88asd77a@192.168.1.10

S403, INVITE message generation and transmission.

The SIP device quickly generates a final INVITE message based on the INVITE template and dynamic field filling results. The static field is not required to be repeatedly generated, the dynamic field is assembled through real-time filling, and finally the dynamic field is sent to the SIP server.

S404, the server receives and processes.

After receiving the INVITE message, the server parses the dynamic field according to the predefined template and verifies the validity of the field content (e.g., whether the address matches the authenticated user, whether the message structure meets the protocol standard). And if the session meets the standard, generating a response message according to the session.

By the quick invitation template provided by the application, static fields (such as protocol type, equipment IP format, message structure and the like) are defined in the template without repeated generation, thereby effectively reducing redundant information generation, and simultaneously, as the equipment end only needs to fill dynamic fields (such as target address and user information), the calculation time and transmission data volume of signaling generation are reduced, and the transmission efficiency is effectively improved.

(1.2.2) Pre-resolved ACK mechanism

In the conventional INVITE procedure, an ACK message needs to be generated and sent after receiving the 200 OK response, which easily causes interaction delay. The embodiment of the application generates possible ACK response in advance through a pre-analysis technology, for example, for any SIP equipment, the probability of giving correct response by the opposite terminal equipment in preset response time is predicted according to the historical session data of the opposite terminal equipment, if the predicted probability is larger than a threshold value, the ACK message is sent in advance, otherwise, the ACK message is sent after the opposite terminal equipment normally responds, so that the sending time of the ACK message can be effectively shortened. Fig. 5 illustrates a schematic flow diagram of a pre-resolution ACK mechanism, as shown in fig. 5, and the flow is specifically implemented as follows:

S501, collecting historical sessions.

The method comprises the steps of extracting a response mode of opposite terminal equipment of the SIP equipment by analyzing historical session logs, and providing basic data for pre-analysis. The collection of historical sessions illustratively includes collecting a log of the device's communication records, recording session response information after each INVITE request, including the peer IP address, port number, type of response (e.g., 200 OK), and response time (time interval from INVITE transmission to response receipt).

S502, data preprocessing.

And analyzing the acquired data to form a unified format. For example:

[ { "peer IP": "192.168.1.15", "response type": "200 OK", "response delay": 2 "," To: tag ":"123456 "},

{ "Peer IP": "192.168.1.15", "response type": "200 OK", "response delay": 1 "," To: tag ":"123457 "},

{ "Peer IP": "192.168.1.15", "response type": "200 OK", "response delay": 3 "," To: tag ":"123458 "},

{ "Opposite IP": "192.168.1.20", "response type": "486 Busy Here", "response delay": 4 "," To: tag ":"123459 "} ]

S503, extracting a response mode of the opposite terminal equipment.

And carrying out statistical analysis on the preprocessed data, extracting a response mode of opposite terminal equipment, and providing a basis for generating a prediction rule.

Illustratively, the conditions and targets are first determined. If condition a is peer ip= 192.168.1.15 and response type= 200 OK, target B is response delay less than or equal to 2 milliseconds. The number of times that the condition A and both A and B are satisfied is calculated, thereby calculating the conditional probability P (B|A).

S504, generating an ACK prediction rule and sending an ACK message according to the rule.

The following rule is generated according to the statistics of S503:

If P (B|A) is more than or equal to the threshold value (such as 90%), ACK is sent in advance, otherwise normal response is waited.

In one embodiment, to reduce the computational burden of generating ACK messages in real time, the present application also provides a pre-generated ACK template mechanism. The mechanism comprises that a possible ACK message template (namely an ACK message framework) is generated in advance according to a SIP protocol standard, wherein the template comprises a static field (namely a general field) and a dynamic field, the dynamic field comprises a TARGET address [ TARGET ], an opposite terminal label [ REMOTE_TAG ], a serial NUMBER [ SEQ_NUMBER ] and the like, and the SIP equipment dynamically fills the content of the specific field to the corresponding position in the ACK template.

The ACK template is exemplified as follows:

ACK sip:[TARGET] SIP/2.0

Via:SIP/2.0/UDP [DEVICE_IP];branch=[BRANCH_ID]

From:<sip:[USER_FROM]>;tag=[TAG]

To:<sip:[TARGET]>;tag=[REMOTE_TAG]

Call-ID:[CALL_ID]

CSeq:[SEQ_NUMBER] ACK

Content-Length:0

Illustratively, when generating the ACK message, the ACK pre-generated template file may be loaded at startup of the SIP device and stored in memory. And generating the ACK message of the pre-filling static field according to the ACK template according to the steps at the same time when the INVITE message is sent. And calling a filling function when the session is established, filling the actual value of the dynamic field into the placeholder (namely the corresponding position) in the template, and dynamically updating the opposite-end tag (such as the To: tag field carried in the 200 OK response) according To the actual session.

Illustratively, the dynamic field may be obtained in real time when generating the ACK message, wherein the TARGET address ([ TARGET ]) is extracted FROM the TARGET field of the INVITE message, the DEVICE IP address ([ device_ip ]) is queried in real time through the network interface of the DEVICE, the BRANCH identity ([ branch_id ]) is dynamically generated by the random generator, the initiating USER information ([ user_from ] and [ TAG ]) is read FROM the DEVICE configuration file, the opposite end TAG ([ remote_tag ]) is extracted FROM the received 200 OK response, the session identity ([ call_id ]) is inherited FROM the INVITE message, and the sequence NUMBER ([ seq_number ]) is incremented per session.

For example, a partial ACK may be sent in advance. For example, after receiving a partial response (e.g., 180 Ringing), a partial ACK message is sent in advance, reducing latency. If the parameters of the subsequent acknowledgements at the opposite end change (e.g., the tags are different), the final ACK is resent to cover the previous message. The parameters of the dynamic fields in the ACK template may all change.

In one embodiment, the present application also provides collision detection and rollback mechanisms. If the 200 OK response received by the SIP device does not match the expected response (e.g., the tag or destination address is different), the system immediately rolls back and resends the matching ACK message. Wherein the rollback operation will force the interruption of the current session, regenerate the matching ACK message and send it to resume the session to the correct state.

(2) Dynamic flow control

The goal of dynamic flow control is to reduce network congestion and avoid signaling accumulation or packet loss problems in overload situations by dynamic adjustment. The application adopts a flow prediction model based on LSTM (Long Short-Term Memory network), monitors network flow regularly and adjusts signaling forwarding strategy in advance. Meanwhile, different QoS tags are allocated to SIP traffic using DiffServ (differentiated services) mechanism, ensuring preferential treatment of delay sensitive signaling (e.g., INVITE).

(2.1) LSTM-based SIP Signaling traffic prediction model

SIP signaling is delay sensitive in real-time communications, and particularly critical signaling such as INVITE requires a fast response. SIP signaling traffic in networks typically exhibits a timing characteristic of alternating peaks and valleys. By introducing the LSTM model to predict the flow trend, the flow peak can be perceived in advance, and the flow priority and the forwarding strategy can be dynamically adjusted, so that the signaling processing efficiency is improved. The model establishment specifically comprises the following steps:

(2.1.1) data acquisition and Pre-processing

Data collection illustratively, real-time traffic statistics per time interval (Δt in seconds) are counted from a network device (switch or router), and the data types include INVITE, REGISTER, BYE and other different SIP signaling.

Feature construction by constructing traffic for each type of signaling into time series

During each time interval (e.g., 10 seconds), the system counts INVITE, REGISTER, BYE or the like signaling amounts and organizes these statistics into time series in time order as input data for the model. For example:

Time point 1:invite=120, register=90, bye=30

Time point 2 invite=140, register=85, bye=25

By constructing such a time series, it is clearly observed that the INVITE traffic gradually increases, possibly just before reaching the peak, while the REGISTER and BYE traffic is relatively smooth.

The LSTM model is used as a deep learning model for processing time series data, and can effectively capture the time sequence characteristics of signaling traffic. The input features are the signaling flow values of the past N time points, and the predicted values are output as the predicted values of the future flow. For example, inputs [120,90,30], [140,85,25], then the output may be [150,87,28]. This indicates that the model predicts that the INVITE traffic will reach 150 at the next time point, showing a trend of traffic peaks.

Constructing traffic data for each type of signaling into a time series can more effectively capture the dynamic change characteristics of signaling traffic. For example:

time point 1 [ invite=120, register=90, bye=30 ]

Time point 2 [ invite=140, register=85, bye=25 ]

And (3) data normalization, namely carrying out M _in-M_ax normalization on the flow of each type of signaling, eliminating the numerical value difference between different signaling flows, and avoiding that certain types of signaling data are dominant in model training. The normalized time series is as follows, and y _t appearing subsequently is the data after normalization:

Illustratively, the normalized time series may be

Time sequence= [

[0.6,0.4,0.2],

[0.7,0.38,0.17],

...

]

(2.1.2) LSTM model design

(2.1.2.1) Define input and output.

The SIP signaling traffic time series of the past N time points is taken as input and output as the SIP signaling traffic predicting the future time point or points.

(2.1.2.2) Design a model structure.

The LSTM model is internally composed of a plurality of modules, including a forgetting gate, an input gate, a candidate memory unit, an updating memory unit, an output gate and a hidden state. The model structure design of the LSTM specifically comprises the following steps:

1) And designing a forgetting door.

Forgetting doorWhether the control model needs to forget information of past points in time, e.g. whether some signaling traffic in the history (like the outdated INVITE peak) is still meaningful for the current prediction. Based on the hidden state h _(t-1) at the previous point in time and the current input x _t, a ratio of a value range of 0,1 is calculated. A value close to 1 indicates retention history information, and a value close to 0 indicates forgetting history information. The calculation formula is as follows:

2) The input gate and the candidate memory cell are designed.

Input doorWhether new information at the current time point needs to be written into the memory unit or not is controlled. Candidate memory cellPotential memory values at the current point in time are generated for updating the memory cells. The specific formula is as follows:

3) The memory cell is updated.

Output of comprehensive forgetting gate and input gate, dynamic updating memory unitStatus of the device. The following formula is used for calculation. And combining the history memory with the current SIP signaling data, forgetting a part of history information, and adding a part of new information at the current time point. The specific formula is as follows:

4) Outputting the door and the hidden state.

Output doorAnd controlling which information in the memory unit needs to be output for predicting the SIP signaling flow of the next time point. Hidden stateIs a bridge for information transfer between LSTM units, and at each time step, the hidden state transfers the information of the current time step to the next time step. The specific formula is as follows:

(2.1.2.3) model training and optimization

Loss function: flow Mean Square Error (MSE) based on actual traffic and predicted traffic of SIP signaling:

Training environment base, namely completing model training by using historical flow data based on the deep learning framework PyTorch, and using an Adam optimizer to perform gradient update to set an initial learning rate alpha=0.001.

And (3) predicting in real time, namely deploying a trained model, and predicting the current flow at fixed time intervals (such as 5 seconds). QoS policies are adjusted in advance by predicting SIP traffic peaks, such as assigning a high priority label (e.g., setting DSCP value to EF 46) to predicted peak INVITE traffic.

(2.2) Configuration of differentiated services (DiffServ) mechanisms

DiffServ is a quality of service (QoS) management mechanism that prioritizes traffic using different labels. By marking corresponding QoS labels for different types of traffic, key traffic is preferentially processed, and quick forwarding of delay sensitive signaling is ensured.

The present application is directed to the SIP protocol by first classifying traffic into three levels, 1) high priority, delay sensitive signaling, such as INVITE, 2) medium priority, normal signaling, such as REGISTER, and 3) low priority, such as non-critical traffic. DSCP (DIFFERENTIATED SERVICES Code Point) is then configured, and the DSCP field of the IP header is used to assign priorities to the different flows, EF (Expedited Forwarding, value 46), AF31 (Assured Forwarding, value 26), medium priority traffic, BE (BestEffort, value 0), low priority traffic. QoS policies are then configured on the router or switch to mark traffic and apply policies to interfaces.

Finally, a queue scheduling mechanism based on priority is configured, the high-priority queue (EF) allocates more bandwidth, and the medium-low priority queues (AF 31, BE) allocate bandwidth as required.

(2.3) Dynamic flow adjustment strategy

The embodiment of the application provides a dynamic flow regulation strategy, which dynamically adjusts the priority and forwarding strategy of signaling by monitoring network flow in real time and predicting flow peaks by combining an LSTM model, so as to avoid network congestion. The system may prioritize delay sensitive signaling (e.g., SIP INVITE) when the predicted traffic exceeds a threshold, and may also reduce the forwarding rate of low priority traffic. By dynamically adjusting the transmission rate of the signaling, efficient traffic management can be realized, delay sensitive traffic is ensured to be forwarded preferentially, and the stability and reliability of the network are improved.

To facilitate an understanding of the dynamic flow regulation strategy provided by the present application, a description is provided below in conjunction with fig. 6.

When the LSTM predicts that the future flow value exceeds a set threshold (e.g., the bandwidth usage reaches 80%), the system triggers a flow regulation strategy. The flow regulation strategy is exemplified as follows:

The high priority signaling guarantee is to forward the high priority signaling (SIP INVITE for example) preferentially, and guarantee the real-time performance through a reserved bandwidth mechanism;

Low priority traffic rate limiting by applying a rate limit to low priority traffic (e.g., BE) or dropping a portion of the data packets;

and adjusting bandwidth allocation, namely dynamically adjusting the bandwidth allocation proportion of each priority flow according to the real-time flow prediction.

In the LSTM model training process, INVITE, REGISTER and BYE three SIP signaling are taken as examples for application, and the signaling covers common scenes such as session establishment, equipment registration, session termination and the like, and has higher representativeness. However, this is merely a reference example, and the present application is not limited to the above three types of signaling. Those skilled in the art can apply the LSTM model extension of the present application to other types of SIP signaling (e.g., OPTIONS, ACK, etc.) according to actual requirements, so as to meet the dynamic traffic management requirements of a specific service scenario.

Fig. 7 is a block diagram of a SIP signaling transmission and flow control device according to an embodiment of the present application, and for convenience of explanation, only the parts related to the embodiment of the present application are shown.

Referring to fig. 7, the apparatus includes:

The flow control module 701 is configured to obtain a flow prediction value of an SIP signaling in an SIP network through a flow prediction model, and trigger a flow adjustment policy when the flow prediction value of the SIP signaling exceeds a threshold value;

The signaling transmission module 702 is configured to control any SIP device to monitor its own status in real time, generate a differential packet according to status change information if status change information to be synchronized occurs, and transmit the differential packet to a corresponding SIP server, so that the SIP server updates the stored status information of the SIP device according to the differential packet, and otherwise, send a heartbeat signaling according to a preset time period to complete SIP periodic registration.

It should be noted that, because the content of information interaction and execution process between the modules and the embodiment of the method of the present application are based on the same concept, specific functions and technical effects thereof may be referred to in the method embodiment section, and details thereof are not repeated herein.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, the specific names of the functional units and modules are only for distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

The embodiment of the application also provides computer equipment, which comprises at least one processor, a memory and a computer program stored in the memory and capable of running on the at least one processor, wherein the steps in any of the method embodiments are realized when the processor executes the computer program.

Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps for implementing the various method embodiments described above.

Embodiments of the present application provide a computer program product which, when run on a mobile terminal, causes the mobile terminal to perform steps that enable the implementation of the method embodiments described above.

Fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 8, the computer device of this embodiment comprises at least one processor 80 (only one is shown in fig. 8), a memory 81 and a computer program 82 stored in the memory 81 and executable on the at least one processor 80, which processor 80 implements the steps of any of the various visual programming method embodiments described above when the computer program 82 is executed.

The computer device may include, but is not limited to, a processor 80, a memory 81. It will be appreciated by those skilled in the art that fig. 8 is merely an example of a computer device and is not intended to be limiting, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., may also include input-output devices, network access devices, etc.

The Processor 80 may be a central processing unit (Central Processing Unit, CPU), the Processor 80 may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), off-the-shelf Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 81 may in some embodiments be an internal storage unit of the computer device, such as a hard disk or a memory of the computer device. The memory 81 may in other embodiments also be an external storage device of the computer device, such as a plug-in hard disk provided on the computer device, a smart memory card (SMART MEDIA CARD, SMC), a Secure Digital (SD) card, a flash memory card (FLASH CARD), etc. Further, the memory 81 may also include both an internal storage unit and an external storage device of the computer device. The memory 81 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs etc., such as program codes of the computer program etc. The memory 81 may also be used to temporarily store data that has been output or is to be output.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium can include at least any entity or device capable of carrying computer program code to an apparatus/computer device, a recording medium, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, and a software distribution medium. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference may be made to related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/computer device and method may be implemented in other manners. For example, the apparatus/computer device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The foregoing embodiments are merely illustrative of the technical solutions of the present application, and not restrictive, and although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those skilled in the art that modifications may still be made to the technical solutions described in the foregoing embodiments or equivalent substitutions of some technical features thereof, and that such modifications or substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims (10)

1. A method for SIP signaling and flow control, comprising:

The method comprises the steps of obtaining a SIP signaling flow prediction value in an SIP network through a flow prediction model, and triggering a flow regulation strategy when the SIP signaling flow prediction value exceeds a threshold value, wherein the flow regulation strategy comprises the steps of distributing flow priority to SIP signaling according to the type of the SIP signaling and preferentially forwarding high-priority signaling;

Any SIP equipment monitors the state of the SIP equipment in real time, if state change information to be synchronized occurs, a difference data packet is generated according to the state change information, the difference data packet is transmitted to a corresponding SIP server, so that the SIP server updates the stored state information of the SIP equipment according to the difference data packet, and otherwise, heartbeat signaling is sent according to a preset time period to complete periodic registration of the SIP.

2. The method of claim 1, wherein the method further comprises:

Grouping the SIP devices in the SIP network according to the target characteristics of the SIP devices, wherein the characteristic values of the target characteristics of the SIP devices in each group are the same;

when the SIP equipment in the SIP network is started, each group of SIP equipment sends a registration request to the SIP server according to the allocated time for sending the registration request.

3. The method of claim 2, wherein the method further comprises:

the SIP server caches static parameters of any SIP device according to the first registration request of the SIP device;

After receiving the difference data packet of any SIP device, the SIP server performs parameter verification and status update according to the status change information in the difference data packet and the self-cached static parameters of the SIP device.

4. The method of claim 1, wherein the method further comprises:

Any SIP device generates an INVITE message by populating the required dynamic fields in a predefined INVITE template that includes the INVITE message structure and the required static fields of the INVITE message.

5. The method of claim 1, wherein the method further comprises:

And for any SIP equipment, predicting the probability of giving correct response by the opposite terminal equipment within preset response time according to the historical session data of the opposite terminal equipment, if the predicted probability is larger than a threshold value, sending an ACK message in advance, otherwise, waiting for the normal response of the opposite terminal equipment and then sending the ACK message.

6. The method of claim 5, wherein the sending the ACK message comprises:

the ACK message is generated by populating the required dynamic fields in a predefined ACK template that includes the ACK message architecture and the required static fields for the ACK message.

7. The method of claim 1, wherein the obtaining, by the traffic prediction model, a SIP signaling traffic prediction value in a SIP network comprises:

And taking the historical SIP signaling flow time sequence as a flow prediction model to input to obtain an SIP signaling flow prediction value output by the flow prediction model, wherein the flow prediction model is generated based on long-short-term memory network LSTM model training.

8. A SIP signaling and flow control apparatus, comprising:

The flow control module is used for acquiring an SIP signaling flow prediction value in an SIP network through a flow prediction model, and triggering a flow regulation strategy when the SIP signaling flow prediction value exceeds a threshold value, wherein the flow regulation strategy comprises the steps of distributing flow priority for the SIP signaling according to the type of the SIP signaling and preferentially forwarding the high-priority signaling;

The SIP device comprises a signaling transmission module, a SIP server and a heartbeat signaling module, wherein the signaling transmission module is used for controlling any SIP device to monitor the state of the SIP device in real time, generating a difference data packet according to state change information needing to be synchronized if the state change information appears, and transmitting the difference data packet to the corresponding SIP server so that the SIP server updates the stored state information of the SIP device according to the difference data packet, otherwise, sending a heartbeat signaling according to a preset time period to complete SIP periodic registration.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1 to 7 when executing the computer program.

10. A computer program product, characterized in that the computer program product, when run on a computer device, causes the computer device to perform the method of any of claims 1 to 7.