Server media stress testing method, system, electronic device, and storage medium

Abstract

The application relates to the technical field of communication performance testing, and provides a server media stress testing method and system, electronic equipment and a storage medium. An implementation scheme is as follows: a calling SIPp and a called SIPp send a start testing request to a sending party testing media server and a receiving party testing media server by calling an external interaction interface, the start testing request carries respective local media parameters, opposite media parameters and a session identifier; the sending party testing media server generates testing information in response to the start testing request, encodes the testing information and media data, obtains a media data packet, and enables the SIP server to send the media data packet to the receiving party testing media server in the form of an RTP stream; the receiving party testing media server receives and analyzes the media data packet, obtains analysis data, tests the RTP stream based on the analysis data, and generates a media stress testing result. The application can improve testing granularity and testing quality.

Description

Technical Field

[0001] This invention relates to the field of communication performance testing technology, and in particular to a server media stress testing method, system, electronic device, and storage medium. Background Technology

[0002] Among existing stress testing tools for Session Initiation Protocol (SIP) servers, tools such as the SIP stress testing tool (SIPp) are widely used for signaling layer performance testing. These tools are primarily designed to simulate a large number of SIP user terminals concurrently sending and receiving signaling messages such as INVITE requests, ACK requests, and BYE requests, in order to evaluate the signaling processing capabilities of the SIP server.

[0003] However, existing testing methods can usually only count the success rate or simple packet loss rate at the overall call level, making it difficult to finely characterize the media transmission process of a single media data packet or a single call. Their test granularity is too coarse and cannot accurately reflect the forwarding quality of audio and video media streams by SIP servers in real business scenarios. Summary of the Invention

[0004] This invention provides a server media stress testing method, system, electronic device, and storage medium, which can solve at least one of the above-mentioned technical problems.

[0005] In a first aspect, embodiments of the present invention provide a server media stress testing method, applied to a server media stress testing system in a distributed system. The server media stress testing system includes a sending test media server and a receiving test media server. The distributed system further includes a calling SIPp, a called SIPp, and a SIP server. The calling SIPp is communicatively connected to the sending test media server, the called SIPp is communicatively connected to the receiving test media server, and the sending test media server and the receiving test media server are communicatively connected through the SIP server. The method includes: The calling SIPp and the called SIPp send start test requests to the sending test media server and the receiving test media server respectively by calling the external interaction interface. The start test request carries their respective local media parameters, peer media parameters and session identifier. In response to the start test request, the sending test media server generates test information and encodes the test information and media data to obtain media data packets, so that the SIP server sends the media data packets to the receiving test media server in the form of a Real-time Transport Protocol (RTP) stream. The receiving test media server receives and parses the media data packets to obtain parsed data, and tests the RTP stream based on the parsed data to generate media stress test results.

[0006] Secondly, embodiments of the present invention provide a server media stress testing system configured in a distributed system. The server media stress testing system includes a sending test media server and a receiving test media server. The distributed system also includes a calling SIPp, a called SIPp, and a SIP server. The calling SIPp is communicatively connected to the sending test media server, the called SIPp is communicatively connected to the receiving test media server, and the sending test media server and the receiving test media server are communicatively connected through the SIP server. The calling SIPp and the called SIPp are used to send start test requests to the sending test media server and the receiving test media server respectively by calling an external interaction interface. The start test request carries their respective local media parameters, peer media parameters and session identifier. The sending test media server is configured to respond to the start test request, generate test information, and encode the test information and media data to obtain media data packets, so that the SIP server can send the media data packets to the receiving test media server in the form of an RTP stream. The receiving test media server is used to receive and parse the media data packets to obtain parsed data, and to test the RTP stream based on the parsed data to generate media stress test results.

[0007] Thirdly, embodiments of the present invention also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described in any one of the embodiments of the present invention.

[0008] Fourthly, embodiments of the present invention also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method described in any one of the embodiments of the present invention.

[0009] By employing the technical solution of this invention, the calling SIPp and the called SIPp send start test requests to the sending test media server and the receiving test media server through an external interaction interface, thereby decoupling media transmission from SIP signaling processing. This ensures that the generation, transmission, and parsing of media data no longer depend on the media capabilities of SIPp itself. The sending test media server generates test information containing time and sequence information based on the local media parameters, peer media parameters, and session identifier carried in the start test request. This test information is then uniformly encoded with the actual media data to form media data packets, which are then forwarded to the receiving test media server as an RTP stream via the SIP server. The receiving test media server parses the received media data packets, recovers the test information, and analyzes the RTP stream based on the test information, thereby performing fine-grained detection of the media transmission process at the individual media data packet level. Thus, the embodiments of the present invention can not only statistically analyze indicators such as packet loss, latency, and jitter at the media data packet level, but also avoid resource competition between media processing and signaling processing, so that the test results more realistically reflect the processing capabilities of the SIP server in the media forwarding scenario, thereby achieving fine-grained evaluation of the server's media forwarding performance and improving test granularity and test quality.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of the invention. Wherein: Figure 1 This is a schematic diagram of an application scenario of the server media stress testing method provided in an embodiment of the present invention; Figure 2 This is a schematic flowchart of a server media stress testing method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the process of parsing and verifying audio data packets in a server media stress testing method according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the process of verifying the memory parsing of video data packets in a server media stress testing method according to an embodiment of the present invention; Figure 5This is a structural block diagram of a distributed system and server media stress testing system according to an embodiment of the present invention; Figure 6 This is a schematic block diagram of an electronic device used to implement the methods of embodiments of the present invention. Detailed Implementation

[0012] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] This invention provides a server media stress testing method, system, electronic device, and storage medium. The execution entity of this server media stress testing method can be the server media stress testing system provided in this invention, or a computer device integrating the server media stress testing system. The server media stress testing system can be implemented in hardware or software, and the computer device can be a terminal or a server.

[0014] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the server media stress testing method provided in an embodiment of the present invention. In one embodiment, the application scenario includes a calling SIPp, a called SIPp, a SIP server, a sending test media server, and a receiving test media server. Specifically, the calling SIPp is the call initiator simulated using the SIPp tool; the sending test media server is an independent server dedicated to processing media streams, serving the calling party; the SIP server is the core SIP network device responsible for routing SIP signaling, such as a proxy server or SBC; and the receiving test media server is another independent media server serving the called party.

[0015] The arrows in the diagram represent the flow of messages. According to the legend, they can be divided into three categories: thin black solid arrows (SIP signaling): standard SIP protocol messages used to establish, maintain, and terminate calls; black dashed arrows (media information and control): the core innovation of this invention is the private control signaling between each SIPp and each test media server; and thick black arrows (RTP stream): the actual audio and video media data streams transmitted between the two test media servers.

[0016] like Figure 1As shown in the diagram, the application scenario flowchart completely describes the entire process from call setup to call termination, which can be broken down into the following key stages: Phase 1: Standard SIP call setup process.

[0017] INVITE (SDP): The calling SIPp initiates a call request (INVITE) to the SIP server. The message contains the Session Description Protocol (SDP), which describes the media type, encoding format, and receiving address / port that the calling party expects.

[0018] Signaling routing: The SIP server routes the INVITE request to the called SIPp.

[0019] Temporary response: The called party and the SIP server return 100 Trying and 180 Ringing respectively, informing the caller that "processing" and "the other party is ringing".

[0020] Final response (200 OK (SDP)): The called party's SIPp answers the call and returns a 200 OK response, which also includes the called party's SDP information, informing the caller of their media receiving address / port.

[0021] Acknowledgment (ACK): After the 200 OK message is sent back to the calling party via the SIP server, the calling party replies with an ACK message to acknowledge receipt. At this point, a successful SIP session negotiation is completed.

[0022] Phase Two: Media Control and Transmission Process.

[0023] The biggest difference between this invention and traditional SIPp testing is that the media control initiation method starts the Real-time Transport Protocol (StartRTP): After the SIP session is successfully established (the calling party sends an ACK, and the called party receives the ACK), the calling and called party's SIPp scripts do not process the media themselves. Instead, they each send a private control command, StartRTP (implemented via the exec command), to their respective designated test media servers (the sending test media server and the receiving test media server). This command contains all the parameters required to establish the media stream, such as the local media IP / port and the remote media IP / port resolved from the other party's SDP.

[0024] Media transmission RTP stream (RTP): After receiving the StartRTP command, the two independent test media servers begin sending and receiving RTP media streams to each other. The green arrows represent media streams sent from the sending test media server to the receiving test media server; the yellow arrows represent media streams sent from the receiving test media server back to the sending test media server.

[0025] Throughout the call, the actual audio and video data was transmitted between two professional test media servers, without passing through SIPp itself, thus freeing SIPp from heavy media processing.

[0026] Phase 3: Standard SIP call removal process.

[0027] Hang up (BYE): After the call ends (for example, after a pause of time), the calling SIPp sends a BYE request to the called SIPp.

[0028] Hang-up confirmation (200): The called SIPp replies with 200 OK, confirming the hang-up. The SIP signaling session ends.

[0029] Phase 4: Termination of Media Session and Collection of Results.

[0030] Media Control Stop (StopRTP): After the SIP session ends, both the calling and called SIPp scripts send a private control command, StopRTP, to their respective test media servers. This command instructs the media servers to stop sending and receiving media streams and to release related resources.

[0031] Collect test status: The SIPp script sends a TestStatus command. Upon receiving this command, the media server returns the media quality data it collected during the call (such as packet loss, jitter, latency, etc.) to SIPp. The SIPp script then records these returned results in its own log file, combining them with signaling statistics.

[0032] It should be noted that the application scenarios of the above-described server media stress testing method are only used to illustrate the technical solution of the present invention and are not intended to limit the technical solution of the present invention. The above-described connection relationship may also take other forms.

[0033] Figure 2 This is a flowchart of a server media stress testing method according to an embodiment of the present invention.

[0034] like Figure 2As shown, this server media stress testing method is applied to a server media stress testing system in a distributed system. The server media stress testing system includes a sending test media server and a receiving test media server. The distributed system also includes a calling SIPp, a called SIPp, and a SIP server. The calling SIPp communication connection is to the sending test media server, and the called SIPp communication connection is to the receiving test media server. The sending test media server and the receiving test media server are connected via a SIP server. The method includes: S110, the calling SIPp and the called SIPp send start test requests to the sending test media server and the receiving test media server respectively by calling the external interaction interface. The start test requests carry their respective local media parameters, peer media parameters and session identifier. S120, the sending test media server responds to the start test request, generates test information, and encodes the test information and media data to obtain media data packets, so that the SIP server sends the media data packets to the receiving test media server in the form of an RTP stream; S130, the receiver test media server receives and parses the media data packets, obtains the parsed data, and tests the RTP stream based on the parsed data to generate media stress test results.

[0035] For example, the calling SIPp and the sending test media server establish a control channel via inter-process communication or socket communication within a local area network. For instance, using TCP sockets (Transmission Control Protocol Socket, TCP Socket), the calling SIPp communicates via... <exec>The command invokes an external interactive program / interface and sends a start test request to the sending test media server. The called SIPp and the receiving test media server establish a control channel using the same communication method as the calling side.

[0036] For example, the sending test media server and the receiving test media server do not establish a direct control connection. Instead, they communicate through an RTP media stream relayed by a SIP server. That is, the sending test media server sends the encoded media data packets to the SIP server in the form of an RTP stream according to the peer's media parameters, and the SIP server forwards them to the receiving test media server.

[0037] For example, the external interaction interface refers to the program interface or communication interface used by the calling SIPp or the called SIPp to call the test media server, and to send control commands and parameter information to the corresponding test media server.

[0038] For example, the calling SIPp executes <exec>The instruction calls the Test RTP Program (TestRTP) program and sends control messages to the sender test media server through the Transmission Control Protocol (TCP) socket, thus constituting an external interaction interface implementation method.

[0039] For example, a Start Test Request is a start control message sent by the calling or called SIPp via an external interface to the corresponding test media server, used to trigger the test media server to create a media test task. For instance, the Start Test Request carries the string "StartRTP" and corresponding parameter fields, instructing the test media server to begin executing an RTP media transmission or reception task.

[0040] For example, local media parameters refer to the media communication parameters corresponding to the side that initiates the start test request, used to characterize its own media receiving or sending capabilities. For example, local media parameters include the local Internet Protocol (IP) address, the local port number, and the audio codec type as G.711.

[0041] For example, peer media parameters refer to the media communication parameters of the media node communicating with this end, used to indicate the destination address and port of the media data packet. For example, peer media parameters include the peer IP address and the peer port number.

[0042] In this example, after the calling SIPp completes the SIP signaling call establishment, it parses the peer media IP address and port number from the received SDP to form the peer media parameters. At the same time, it reads its own configuration to obtain the local media port number, constructs a start test request containing the local media parameters, peer media parameters, and session identifier, and sends it to the sender's test media server through an external interaction interface. The called SIPp constructs a start test request in the same way and sends it to the receiver's test media server, where the session identifier is the call identifier (Call Identifier, Call-ID) corresponding to the current call.

[0043] For example, if the calling SIPp resolves the peer's media port to 5004, the local media port to 4000, and the session identifier to "call12345", then the start test request sent to the sending test media server will carry the parameters local_port=4000, remote_port=5004, and call_id=call12345. Here, local_port is the local port; remote_port is the remote port; and call_id is the call ID. The called SIPp will correspondingly generate local_port=5004, remote_port=4000, and call_id=call12345 and send it to the receiving test media server.

[0044] For example, test information refers to the identifying and timing information generated by the sender's test media server and embedded in the media data, used for verification and performance calculation at the receiving end. For instance, test information in JSON format might be represented as {"local_port": 4000, "remote_port": 5000, "call-id": "abc123", "send-time": "2026-02-27 10:00:00", "send-interval": 20, "send-seqno": 15}. Here, send-time is the sending time; send-interval is the sending time interval; and send-seqno is the sending sequence number.

[0045] For example, a media data packet refers to a data unit formed by encoding and encapsulating test information with audio or video media data, used for transmission via the RTP protocol. For instance, the test information can be encoded as a Dual-Tone Multi-Frequency (DTMF) signal and combined with audio sampling data before being encapsulated into an RTP data packet, or the test information can be encoded as a QR code and superimposed onto a video frame before being encapsulated into an RTP data packet.

[0046] In this example, after receiving the start test request, the sending test media server initializes the media test task according to the session identifier in the request and creates a socket for sending RTP data based on its own media parameters. Then, it generates test information, which includes at least the local port number, the peer port number, the session identifier, the sending time, the sending time interval, and the sending sequence number. When the media data is audio data, the test information is converted into a hexadecimal character sequence and further encoded into a DTMF audio signal, which is then combined with the audio media data to form an audio media data packet. When the media data is video data, the test information is encapsulated as a JavaScript Object Notation (JSON) string and a QR code image is generated. This QR code image is then overlaid onto the video frame to be sent to obtain a video frame carrying the test information. Finally, the audio media data packet or video frame is encapsulated into an RTP data packet and sent to the SIP server according to the peer media parameters.

[0047] For example, the sending test media server generates test information {local_port: 4000, remote_port: 5004, call_id: "call12345", send_time: "2026-03-02 10:00:00", send_interval: 20, send_seqno: 1} for the test task with session identifier "call12345". When it is an audio test, the test information is mapped to DTMF tone and formed into an RTP audio packet and sent to the SIP server; when it is a video test, the test information is generated into a QR code and superimposed on the upper left corner of the current video frame, and then encapsulated into an RTP video packet and sent to the SIP server.

[0048] For example, parsed data refers to the data content obtained by the receiving test media server after decoding the media data packets, including the test information restored from the media and the corresponding timestamp and sequence number. For instance, the test information JSON string is decoded from the received RTP audio stream, and the send-time (send time) and send-seqno (send sequence number) fields are extracted as parsed data.

[0049] For example, media stress test results refer to a set of media performance indicators obtained by statistically analyzing and calculating RTP streams based on parsed data, used to characterize media transmission quality. For instance, media stress test results might include a total packet loss of 5, an average end-to-end latency of 120 milliseconds, a maximum jitter of 30 milliseconds, and an effective packet reception rate of 98% during a single call.

[0050] In this example, the receiving test media server listens on the corresponding port according to the local media parameters in the start test request, receives RTP media data packets forwarded by the SIP server, and decapsulates the RTP media data packets. When the media data is audio data, it performs DTMF decoding on the audio data to recover the test information string. When the media data is video data, it identifies the QR code from the decoded video frame and parses it to obtain the test information. Then, it performs integrity and continuity checks on the parsed test information, calculates the delay value based on the sending time and local receiving time in the test information, calculates the jitter value based on the time difference of adjacent data packets, and determines whether there is packet loss based on the sending sequence number. Finally, the statistical results such as delay, jitter, and number of packet losses are stored or reported as the media stress test results.

[0051] For example, the receiving test media server parses the test information {send_seqno: 1, send_time: "2026-03-02 10:00:00"} from the RTP video packet, and the local reception time is "2026-03-02 10:00:30". Then, the end-to-end latency of the packet is calculated to be 30 milliseconds (ms). When the subsequent test information with sequence number 2 is received, the jitter is calculated based on the difference between the two latency values. When a packet loss event is found when the sequence number is not continuous, the media stress test result of the session is formed.

[0052] According to the above implementation method, firstly, the calling SIPp and the called SIPp respectively send a start test request carrying local media parameters, peer media parameters, and session identifier to the corresponding test media server, realizing unified triggering and precise binding of media test tasks. Subsequently, the sending test media server generates test information containing timing and identification information based on the start test request, and encodes it together with audio or video media data to form a media data packet, which is then sent to the receiving test media server via the SIP server in RTP stream mode. Finally, the receiving test media server parses the received media data packet and performs integrity, continuity, and latency tests on the RTP stream based on the parsed test information, generating corresponding media stress test results. In this way, refined, quantifiable, and traceable testing of media streams can be achieved without relying on the media processing capabilities of the SIPp itself, effectively avoiding resource competition between signaling processing and media processing, and improving test granularity and test quality.

[0053] In one implementation, the sending test media server responds to a start test request by generating test information and encoding the test information and media data to obtain media data packets, enabling the SIP server to send the media data packets to the receiving test media server in the form of an RTP stream. This includes: the sending test media server obtaining the current timestamp and current sequence number, and determining a transmission time interval based on the difference between the current timestamp and the timestamp of the last packet transmission; the sending test media server generating test information based on the current timestamp, current sequence number, transmission time interval, local media parameters, peer media parameters, and session identifier; and encoding the test information and media data to obtain media data packets, including: if the media data is audio data, the sending test media server converting the test information to hexadecimal data; the sending test media server encoding the hexadecimal data based on a preset mapping relationship between dual-tone multi-frequency (DTMF) signals and hexadecimal characters to obtain a DTMF audio signal; and the sending test media server encapsulating the DTMF audio signal and audio data to obtain media data packets.

[0054] For example, each time the sending test media server prepares to generate test information, it reads the current time from the local system clock as the current timestamp and reads the current sequence number from an internally maintained counter. Simultaneously, it reads the timestamp recorded when the test information was last generated from the buffer, calculates the difference between the current timestamp and the previous timestamp to obtain the transmission time interval, and writes the current timestamp into the buffer for use in the next calculation.

[0055] For example, if the timestamp of the last packet transmission was 10:00:00.000 and the current timestamp obtained this time is 10:00:00.020, then the transmission interval is determined to be 20 milliseconds, and the current sequence number is incremented from 5 in the previous packet to 6.

[0056] For example, the above parameters are organized into structured data according to the preset field order and encapsulated in JSON format to form a test information data object containing the local port number, the remote port number, the call identifier, the sending time, the sending time interval, and the sending sequence number.

[0057] For example, if the local port is 4000, the remote port is 5000, the session identifier is call123, the current time is 2026-02-27 10:00:00.020, the sending interval is 20 milliseconds, and the sending sequence number is 6, then the generated test information can be represented as {"local_port": 4000, "remote_port": 5000, "call-id": "call123", "send-time": "2026-02-27 10:00:00.020", "send-interval": 20, "send-seqno": 6}.

[0058] For example, the test information is converted into a hexadecimal data sequence according to a preset rule; then, based on the preset mapping relationship between dual-tone multi-frequency signals and hexadecimal characters, the hexadecimal data is mapped character by character to the corresponding DTMF audio signal; then, the generated DTMF audio signal and the audio data to be sent are encapsulated to form a media data packet conforming to the RTP protocol format.

[0059] For example, the test information string "6A" is converted into the hexadecimal character "3641". Then, according to the mapping relationship, "3" is mapped to 697Hz+1477Hz, "6" is mapped to 770Hz+1477Hz, "4" is mapped to 770Hz+1209Hz, and "1" is mapped to 697Hz+1209Hz, thus forming the corresponding DTMF audio signal sequence. This DTMF signal is then combined with the original audio sampling data and encapsulated into an RTP audio data packet for subsequent transmission.

[0060] For example, the mapping relationship between the preset dual-tone multi-frequency signal and hexadecimal characters is shown in Table 1: Table 1 It should be noted that the entire sending process is executed in a loop, rather than ending after one execution.

[0061] According to the above implementation method, the sending test media server generates test information containing time, sequence number, and session-related parameters before each media data transmission, and embeds this test information in DTMF format into the audio media data. This ensures that each media data packet carries resolvable test identification information, allowing the receiver to accurately obtain the transmission order and time after decoding. This enables refined statistics and analysis of packet loss, out-of-order delivery, latency, and jitter. This not only avoids the insufficient accuracy problems caused by relying solely on external statistical tools, but also allows for in-band testing and real-time evaluation of the media stream without altering the existing SIP signaling process, significantly improving the granularity and quality of media stress testing.

[0062] In one implementation, encoding test information and media data to obtain a media data packet includes: if the data type of the media data is video data, the sending test media server extracts a video frame from the video data and determines whether test information needs to be superimposed on the video frame according to configuration requirements; if no test information needs to be superimposed, the video frame is packaged to obtain a media data packet; if test information needs to be superimposed, the test information is encoded to obtain a QR code image; the QR code image is superimposed on the video frame and the superimposed video frame is packaged to obtain media data.

[0063] For example, the sending test media server reads the currently transmitted video data from a local video file or video capture buffer at a preset frame rate (e.g., 25 frames / second or 30 frames / second), and extracts a complete frame from the video data as the current video frame, while recording the frame number and timestamp corresponding to the video frame. For example, when the video stream frame rate is 25 frames / second, the server extracts the 10th frame image as the current video frame on the 10th read operation.

[0064] For example, the sending test media server reads preset test strategy parameters or user configuration parameters to determine whether the current test scenario enables in-band video testing mode. If the configuration parameters indicate that in-band testing is enabled, it is determined that test information needs to be superimposed; otherwise, it is determined that no test information needs to be superimposed. For instance, when video_test_mode is set to true in the configuration file, it is determined that test information needs to be superimposed on the video frames; when the parameter is false, it is determined that no test information needs to be superimposed.

[0065] For example, test strategy parameters or user configuration parameters can be stored in a configuration file or database. For instance, setting the parameter "video_test_mode=true" in the configuration file indicates that in-band test information overlay is enabled for the current test scenario. Alternatively, setting the parameter "overlay_interval=5" indicates that test information is overlaid every 5 video frames sent. The parameter "overlay_position=bottom_right" can also be set to indicate that the QR code is overlaid in the lower right corner of the video frame.

[0066] For example, the video frame is encoded or its original encoding format is kept unchanged, and the video frame data is encapsulated into RTP data packets according to the encapsulation rules of the RTP protocol to form a media data packet to be sent. For example, when the video frame is in H.264 encoding format, the server directly writes the H.264 video frame as the payload into the RTP packet header, generates a complete RTP video data packet, and sends it.

[0067] For example, the test information, including the local port number, the remote port number, the session identifier, the sending time, the sending interval, and the sending sequence number, is serialized in JSON format, and then a QR code generation algorithm is called to convert the JSON string into QR code image data. For instance, the test information {"local_port":4000, "remote_port":5000, "call-id":"call123", "send-time":"2026-02-27 10:00:01.000", "send-interval":40, "send-seqno":12} is converted into a QR code image with a size of 128×128 pixels.

[0068] In this example, the QR code generation algorithm can employ a standard QR code encoding algorithm, such as an encoding algorithm based on the Quick Response Code (QRCode) standard. It takes a JSON-formatted test information string as input and generates a QR code image using a QR code generation algorithm with an error correction level of M. Alternatively, it can use the ZXing (ZebraCrossing) algorithm library to encode the string "{local_port:4000, remote_port:5000, call-id:call123, send-seqno:10}" to generate a 128×128 pixel QR code image.

[0069] For example, according to a preset overlay position rule, the QR code image is embedded into a designated area of ​​the video frame, such as the lower right or upper left corner. The overlaid image then undergoes necessary color space conversion and re-encoding, and is finally encapsulated into a media data packet according to the RTP protocol. For instance, the QR code image is overlaid into the 100×100 pixel area in the lower right corner of the original video frame, re-encoded into H.264 format, and then encapsulated into an RTP video data packet for transmission.

[0070] In this example, the overlay position rule can predefine a fixed position for the QR code within the video frame. For example, the overlay position could be specified as the lower right corner of the video frame, specifically 10 pixels from the right edge and 10 pixels from the bottom edge. Alternatively, the overlay position could be specified as the upper left corner, starting the QR code image from coordinates (10, 10). A dynamic position rule can also be defined, such as rotating the overlay position according to the frame number, placing it in the lower left corner when the frame number is odd and in the upper right corner when the frame number is even, to avoid long-term obscuring of the same video content area.

[0071] According to the above implementation method, by introducing a configurable test information overlay mechanism during the generation of video media data, the sending test media server can selectively embed test information into video frames according to test requirements without changing the original video transmission process. This ensures that each video frame carries identification information related to session state, transmission sequence, and time characteristics when necessary. After parsing the video frame and decoding the QR code, the receiving party can accurately obtain the corresponding test data, enabling fine-grained measurement of performance indicators such as packet loss, latency, and jitter in the video stream. This ensures video transmission efficiency when test mode is not enabled, while significantly improving the observability and accuracy of video media stress testing when test mode is enabled, thereby effectively improving test granularity and test quality.

[0072] In one implementation, the receiving test media server receives and parses media data packets to obtain parsed data, and tests the RTP stream based on the parsed data to generate media stress test results. This includes: the receiving test media server receiving and parsing media data packets to obtain parsed data, wherein the parsed data includes a first Internet Protocol address and a first port; the receiving test media server matching the first Internet Protocol address and the first port with a second Internet Protocol address and a second port in the peer's media parameters to obtain a matching result; if the matching result is a mismatch, the parsed data is discarded and the number of discards is counted; if the matching result is a match, the type of media data packet is determined; if the type of media data packet is an audio data packet, the RTP stream is tested. The process involves decoding to obtain the DTMF audio signal, and then restoring it to a hexadecimal string based on a pre-defined mapping between DTMF signals and hexadecimal characters. This hexadecimal string includes the audio transmission time, audio transmission time interval, and audio transmission sequence number. Continuity checks are performed on adjacent received hexadecimal strings based on the audio transmission sequence number to determine if packet loss exists, yielding the audio continuity check result. Audio delay parameters for media transmission are calculated based on the audio transmission time and the current audio reception time, and audio jitter parameters are calculated based on the audio transmission time interval and adjacent audio reception time intervals. Finally, media stress test results for the audio data packets are generated based on the audio continuity check result, audio delay parameters, and audio jitter parameters.

[0073] For example, the receiving test media server continuously receives RTP packets sent by the remote end (the sending test media server) on its local audio port being monitored, and extracts the source Internet Protocol address (first Internet Protocol address) and source port number (first port) from the network layer header of each packet; then, the system strictly compares the extracted source address and source port with the second Internet Protocol address and second port in the peer media parameters passed through the start test request to generate a matching result.

[0074] For example, if the source address of the received data packet is 192.168.1.20:6000, and the preset peer media parameters are also 192.168.1.20:6000, then the matching result is determined to be a match; if the matching result is a mismatch, the system will immediately discard the data packet, internally count the discard events, and then continue to listen for the next data packet.

[0075] For example, if the matching result in the aforementioned example is a match, and the system determines that the media data packet type is an audio data packet, the system will perform a decoding operation on the RTP payload of the data packet to extract the DTMF audio signal contained therein. Then, based on a preset mapping relationship between DTMF signals and hexadecimal characters that is identical to that of the sender, the system will restore the decoded continuous DTMF tone sequence one by one to the corresponding hexadecimal characters, ultimately concatenating them into a hexadecimal string containing complete test information. For example, a DTMF signal representing hexadecimal "4142" will be accurately restored to the string "4142" after this step.

[0076] For example, after successfully reconstructing the hexadecimal string, the system parses the audio transmission sequence number contained in the string from a specified position; then, it compares the current audio transmission sequence number with the transmission sequence number of the last successfully parsed audio data packet stored internally to perform a continuity check.

[0077] For example, if the sequence number of the previous packet is 100 and the sequence number of the current packet is 102, the system determines that the two are not consecutive. This means that the data packet with sequence number 101 was lost during transmission. The system then records a packet loss event, and this determination result is the audio continuity check result.

[0078] For example, the system also parses the audio transmission timestamp and audio transmission time interval contained in the hexadecimal string from a specified position. Then, the system subtracts the parsed audio transmission timestamp from the current audio reception timestamp to calculate the audio delay parameter for the one-way transmission of the data packet.

[0079] Simultaneously, the system will also calculate the difference between the current audio reception time interval and the parsed audio transmission time interval. This difference is the audio jitter parameter of the data packet. For example, if the transmission time is 05:123 and the reception time is 05:153, the calculated audio delay parameter is 30 milliseconds.

[0080] For example, the system will summarize and update the audio continuity verification results (i.e., specific packet loss information), calculated audio latency parameters, and audio jitter parameters obtained in the previous steps. This structured data, which includes key performance indicators such as packet loss, latency, and jitter, together constitutes a quantified media stress test result for the current audio data packet, and is prepared for subsequent querying and feedback.

[0081] Please see Figure 3 , Figure 3 This is a schematic diagram of the process of parsing and verifying audio data packets in a server media stress testing method according to an embodiment of the present invention.

[0082] In a specific example, firstly, listening and data reception are initiated: The receiving test media server continuously listens for and receives data sent by the sending test media server on the specified local audio port (local_audio_port in the local media parameters) according to the parameters passed down from the called party's SIPp. Data packet source verification: Whenever a data packet is received, the receiving test media server immediately performs source verification. It checks whether the source IP address and port number of the data packet match the remote media address specified in the called party's SIPp parameters (remote_media_ip / remote_audio_port in the peer media parameters).

[0083] If there is no match (N): The receiver test media server will discard this packet, internally count the number of discards, and then return to the listening state to wait for the next packet.

[0084] If a match (Y) is found: This confirms that the data packet originated from the correct sender, the test media server, and the packet proceeds to the next step of processing.

[0085] Second, DTMF information extraction and stream concatenation: The receiver's test media server uses an algorithm to decode the verified RTP stream and extract DTMF information (i.e., tone sequences representing hexadecimal characters). Then, the newly extracted DTMF information is concatenated with the previously received but not yet processed DTMF information in the internal buffer to form a longer, continuous DTMF information stream.

[0086] Third, frame synchronization search header: The receiver test media server searches for a specific header (e.g., hexadecimal A5A5) in the spliced ​​DTMF information stream according to predefined rules to determine the starting position of a valid test information packet.

[0087] If the header (N) is not found: the system will execute the synchronization recovery logic. It will check if the end of the current cache is an incomplete header fragment (e.g., only an A5). If so, the fragment is retained, and all previous data is cleared; otherwise, the entire cache is cleared. Then, the process returns to the data receiving step, waiting for new data to be concatenated.

[0088] If the header (Y) is found: the system will use this header as the starting point to continue to the next step of judgment.

[0089] Fourth, data packet integrity judgment: After finding the header, the receiving test media server will determine whether there is enough data to form a complete test data packet (e.g., a fixed length of 44 characters) starting from this header.

[0090] If the length is less than N: it means that the data packet has not been completely received. The process will return directly to the data receiving step and wait for subsequent data packets to be concatenated.

[0091] If the length is sufficient (Y): the system will treat these 44 characters as a candidate test information packet and proceed to the next step of deep verification.

[0092] Fifth, content integrity verification (Hash verification): The receiving media server extracts these 44 characters and calculates a 16-bit hash value from the first 40 characters. Then, this calculated hash value is compared with the original hash value recorded in these 44 characters (located in bytes 40-43).

[0093] If it does not meet the condition (N): This indicates that the data has been corrupted during transmission or that there is a frame synchronization error. The receiver's test media server will shift two characters backward from the current header position and then return to the "Search Header" step to attempt to find a valid header again from the new position.

[0094] If it meets the condition (Y): It is confirmed that the content of the data packet has not been corrupted during transmission, and the next step of verification is performed.

[0095] Sixth, Session Attribution Verification: After the hash verification passes, the receiving test media server will parse the test information from these 44 characters, including the sequence number, timestamp, bidirectional port, and the hash value of the Call-ID (session identifier). For the first successfully verified packet: the system will save the "bidirectional port + Call-ID hash value" as an "expected value" as a unique identifier for this call session. For subsequent packets: the receiving test media server will verify whether the hash value (bidirectional port + Call-ID) it carries matches the previously saved "expected value".

[0096] If it does not meet the condition (N): This indicates that although the data packet is complete, it may not belong to the current call session. The receiving party's test media server will count and record this error information, and then discard the packet.

[0097] If it meets (Y): At this point, the system fully confirms that this is a valid, complete test message packet belonging to the current session.

[0098] Seventh, Media Quality Index Analysis and Statistics: For valid test packets that pass all checks, the receiving test media server performs a final performance calculation. Packet Loss Analysis: The system analyzes the sequence number of the current packet and compares it with the sequence number of the previous valid packet. If they are not consecutive, packet loss is determined, and detailed information about the loss is recorded. Latency and Jitter Analysis: The system analyzes the timestamp information carried in the packet to calculate the end-to-end latency from when the data packet is sent by the sending test media server to when it is received by the receiving test media server. Simultaneously, jitter is calculated by comparing the difference between the current latency and the previous latency. All these latency and jitter data are accumulated and statistically analyzed.

[0099] Eighth, cache cleanup and loop: After processing and counting a valid 44-character test packet, the receiving test media server removes these 44 characters from its internal cache. Then, the entire process returns to the "DTMF information extraction and stream concatenation" or "header search" step to continue processing the remaining DTMF stream in the cache, forming a never-ending receiving and verification loop until the entire call ends.

[0100] According to the above implementation method, by performing source matching and type discrimination on the media data packets at the receiving end test media server side, it is ensured that only RTP streams from legitimate peer media parameters are parsed and processed, thereby avoiding interference from irrelevant data on the test results. After confirming the match, audio media data packets are decoded packet by packet, restoring the DTMF signals carried within them into hexadecimal strings containing the transmission time, transmission time interval, and transmission sequence number. Based on this, continuity checks and timestamp-based delay and jitter calculations are performed, thereby simultaneously obtaining packet loss, end-to-end delay, and delay fluctuation information at the packet level. By combining the check results with delay parameters to generate media stress test results for audio data packets, it is possible not only to accurately characterize the real-time performance status of the audio RTP stream during transmission, but also to improve the reliability and granularity of the test results while filtering out abnormal source data. This elevates media stress testing from traditional coarse-grained statistics to precise quantitative analysis based on real media load and in-band test information.

[0101] In one implementation, if the matching result is a match, after determining the type of the media data packet, the method further includes: if the media data packet type is a video data packet, decoding the RTP stream to obtain video frames; performing QR code image recognition on the video frames to obtain video test information, wherein the video test information includes video transmission sequence number, video transmission time, and video transmission time interval; performing continuity verification on adjacent received video test information based on the video transmission sequence number to determine whether there is frame loss or packet loss, and obtaining a video continuity verification result; calculating the video delay number of media transmission based on the video transmission time and the current received video time, and calculating the video jitter parameter based on the video transmission time interval and the time interval of adjacent received videos; and generating a media stress test result for the video data packet based on the video continuity verification result, the video delay parameter, and the video jitter parameter.

[0102] For example, after receiving a video-type media data packet, the receiving test media server extracts the RTP payload from the data packet and decodes it into a single-frame video image according to a preset encoding and decoding algorithm for subsequent processing.

[0103] For example, if the received RTP payload is in H.264 encoding format, the system decodes it into a 1920×1080 resolution video frame using a decoder.

[0104] For example, the receiving test media server inputs the decoded video frame into the image recognition engine to detect and decode the QR code in the video frame, and extracts the JSON format test information carried in the QR code, including the video transmission sequence number, video transmission time, and video transmission time interval.

[0105] For example, the receiving test media server compares the extracted video transmission sequence number with the transmission sequence number of the previous frame's valid video test information to determine whether there are any dropped frames or packets in adjacent received frames, and records the continuity check result. For example, if the previous frame sequence number is 1023 and the current frame sequence number is 1024, the sequence numbers are consecutive, so the continuity check passes; if the sequence number is 1026, then it is determined that there are dropped frames.

[0106] For example, the receiving test media server calculates the end-to-end transmission delay based on the video sending time and the current receiving video time, and at the same time calculates the jitter parameter by comparing the video sending time interval with the actual adjacent receiving video frame interval. All delay and jitter data are accumulated and statistically analyzed.

[0107] For example, if the video transmission time is 1677721600 milliseconds and the local reception time is 1677721610 milliseconds, then the delay is 10 milliseconds. If the transmission interval of the previous frame is 40 milliseconds and the actual reception interval of the current frame is 42 milliseconds, then the jitter is 2 milliseconds.

[0108] For example, the receiving media server integrates the video continuity verification result, the calculated latency parameters, and the jitter parameters to form a complete media stress test result for this video data packet, and stores it in a statistics table or sends it to a SIP server for aggregation. For instance, the test result for this video frame is recorded as sequence number 1024, with a latency of 10 milliseconds, jitter of 2 milliseconds, and a continuity status of passing, and is stored in a statistics table for subsequent analysis.

[0109] Please see Figure 4 , Figure 4 This is a schematic diagram of the process for verifying the memory parsing of video data packets in a server media stress testing method according to an embodiment of the present invention.

[0110] In a specific example, firstly, listening and data reception are initiated: the process begins in a listening state. The receiving test media server continuously listens for and receives media data packets sent by the sending test media server on the specified local video port (local_video_port in the local media parameters) according to the parameters passed down by the called SIPp. These data packets are then reassembled into a complete video frame at the network layer.

[0111] Second, data packet source verification: Whenever a complete frame of image data is received, the receiving test media server immediately performs source verification. This includes checking whether the source IP address and port number of the data packet match the remote media address specified in the called SIPp parameters (remote_media_ip / remote_video_port in the peer media parameters).

[0112] If there is no match (N): The receiver test media server will discard this frame, internally count the number of discards, and then return to the listening state to wait for the next frame.

[0113] If a match (Y) is found: This confirms that the image came from the correct sender, the test media server, and the frame proceeds to the next step of processing.

[0114] Third, QR code recognition and test information extraction: The receiver's test media server reconstructs this frame of image data from the verified media data packet, and then an image recognition engine attempts to recognize and decode the QR code on this frame of image.

[0115] If the QR code (N) is not found: This indicates that the current frame is a regular video content frame and does not carry test information. The system will proceed directly to the end of the process, count and record an error message (e.g., "Test information frame not found"), and then return to the data receiving step to wait for the next frame.

[0116] If a QR code (Y) is found: the image recognition engine will decode the QR code and extract a test information string in JSON format.

[0117] Fourth, JSON information parsing: The receiving test media server parses the JSON string extracted in the previous step to obtain all the key test information fields, including: sequence number, sender timestamp, time interval, bidirectional port, call-ID, etc.

[0118] Fifth, session attribution verification: The receiving test media server verifies whether this test packet truly belongs to the current call session. Specifically, for the first successfully decoded packet, the system saves the "bidirectional port + Call-ID" information (or its hash value) as an "expected value," serving as a unique identifier for this call session. For subsequent packets, the receiving test media server verifies whether the "bidirectional port + Call-ID" information they carry matches the previously saved "expected value."

[0119] If it does not meet the condition (N): This indicates that although the test packet carries test information, it may not belong to the current call session. The receiving party's test media server will count and record this error information, and then discard the packet.

[0120] If it meets (Y): At this point, the system fully confirms that this is a valid test packet belonging to the current session.

[0121] Sixth, Media Quality Index Analysis and Statistics: For valid test packets that pass all checks, the receiving test media server will perform a final performance calculation. Packet Loss Analysis: The system analyzes the sequence number of the current packet and compares it with the sequence number of the previous valid packet. If they are not consecutive, packet loss is determined, and detailed information about the loss is recorded. Latency and Jitter Analysis: The system analyzes the time interval information carried in the packet and calculates the time interval between the current packet received by the local machine and the previous packet. By comparing the difference between these two time intervals, reference information for calculating latency and jitter is obtained. The system will use this to calculate the current latency and jitter data and perform cumulative statistics.

[0122] It should be noted that after completing all processing and statistics of a video image carrying test information, the entire process returns to the step of "receiving remote media data packets" and continues to execute the same logic on the next frame, forming a never-ending receiving and verification loop until the entire call ends.

[0123] According to the above implementation method, by parsing the received video media data packets packet by packet, the RTP stream is decoded into video frames, and the QR code images embedded in the video frames are further identified to extract video test information containing the transmission sequence number, transmission time, and transmission time interval. Based on this, the continuity of adjacent received video test information is checked according to the transmission sequence number to accurately determine whether frame or packet loss exists. Simultaneously, the video transmission delay is calculated by comparing the transmission time and the reception time, and the video jitter parameter is calculated by the difference between the transmission time interval and the reception time interval. Finally, the continuity check result, delay parameter, and jitter parameter are combined to generate the media stress test result of the video data packets. By carrying and parsing in-band test information within the video frames, frame loss, latency, and jitter can be accurately quantified under real video load conditions. This not only improves the resolution and reliability of video media stress testing but also avoids errors caused by relying solely on external statistics, making the test results closer to the actual business operation state, thereby significantly improving the test granularity and test quality.

[0124] In one implementation, the receiving test media server receives and parses media data packets to obtain parsed data, and then tests the RTP stream based on the parsed data to generate media stress test results. The method further includes: the calling SIPp and the called SIPp sending stop test requests to the sending test media server and the receiving test media server respectively by calling an external interaction interface; the sending test media server responds to the stop test request and stops sending media data packets; the receiving test media server responds to the stop test request and stops receiving media data packets.

[0125] For example, the sending test media server receives a status query request from the sender, which includes a test session identifier, request time, and request type. The sending test media server retrieves corresponding statistical data from its internal statistics table based on the session identifier, including the number of media packets sent, packet loss rate, latency, and bandwidth usage. Subsequently, the sending test media server formats and encapsulates the retrieved statistical data to generate a statistical data message conforming to the SIP server interface specification. Next, the sending test media server sends the statistical data message to the SIP server via the SIP interface and waits for server confirmation of receipt. Finally, the sending test media server logs this query and sending operation for subsequent auditing and analysis.

[0126] For example, if the test session ID is "TEST56789", after receiving the query request, the sender test media server retrieves the data of 10,000 RTP packets sent from the statistics table, with a packet loss rate of 0.5% and an average latency of 50 milliseconds, and encapsulates it into a SIP INFO Method (SIP INFO) message and sends it to the SIP server.

[0127] For example, the receiving test media server receives a status query request from the receiving party, which includes a session ID, request time, and request type. The receiving test media server identifies the corresponding media stress test task based on the session ID and retrieves the media stress test results from its internal cache or logs, including the number of received data packets, packet loss rate, end-to-end latency, and received bandwidth usage. Subsequently, the receiving test media server formats and encapsulates the obtained media stress test results to generate a data message conforming to the SIP server interface specification. Next, the receiving test media server sends the encapsulated test results to the SIP server via the SIP interface and receives a confirmation response from the server. Finally, the receiving test media server records this query and sending operation in the system log for performance analysis and troubleshooting.

[0128] For example, in the test with session ID "TEST56789", the receiver's test media server found that it had received 10,000 RTP packets with a packet loss rate of 0.8% and an average end-to-end latency of 55 milliseconds. It then encapsulated this data into a SIP INFO message and sent it to the SIP server.

[0129] In one implementation, after the receiving test media server stops receiving media data packets in response to a stop test request, the method further includes: the sending test media server responding to a test status query request issued by the calling SIPp, obtaining statistical data by querying a statistical data table, and sending the statistical data to the SIP server; and the receiving test media server responding to a test status query request issued by the called SIPp, and sending the media stress test results to the SIP server.

[0130] For example, first, the calling SIPp constructs a stop test request message, which includes a session ID, request type, and timestamp. The calling SIPp sends this request to the sending test media server via Hypertext Transfer Protocol (HTTP) or the SIP interface. Upon receiving the request, the sending test media server parses and verifies the request content, confirming that the session ID matches the currently running test session. Subsequently, the sending test media server triggers a stop operation to send media data packets, terminating the continuously transmitted audio / video or analog stream. Finally, the sending test media server generates a stop confirmation response and sends it back to the calling SIPp via the interface, indicating that the test has been successfully terminated.

[0131] For example, if the session ID is "TEST12345", after the calling SIPp sends a stop test request to the sending server, the sending server immediately stops sending RTP packets to the receiver and returns a status code 200 to indicate that the stop was successful.

[0132] For example, firstly, the called SIPp generates a stop test request message based on the current test session information. This message includes the session ID, request type, and initiation time. The called SIPp sends this message to the receiving test media server via HTTP or SIP interface. Upon receiving the request, the receiving test media server parses the message and verifies the session ID, confirming that the request matches the currently executing test session. Subsequently, the receiving test media server stops receiving media data packets and clears the cache or buffer associated with the test session. Finally, the receiving test media server generates a stop confirmation response and sends it back to the called SIPp, indicating that the receiving test has been completed and terminated.

[0133] For example, in the test with session ID "TEST12345", after the called SIPp sends a stop request to the receiving server, the receiving server immediately stops receiving the RTP stream from the sender and returns an acknowledgment response indicating that the operation is complete.

[0134] Figure 5 This is a structural block diagram of a server media stress testing system according to an embodiment of the present invention.

[0135] like Figure 5 As shown, the server media stress testing system 100 is configured in a distributed system 10. The server media stress testing system 100 includes a sending test media server 110 and a receiving test media server 120. The distributed system 10 also includes a calling SIPp11, a called SIPp13, and a SIP server 12. The calling SIPp11 is communicatively connected to the sending test media server 110, and the called SIPp13 is communicatively connected to the receiving test media server 120. The sending test media server 110 and the receiving test media server 120 are communicatively connected through the SIP server 12. The calling SIPp and the called SIPp are used to send start test requests to the sending test media server and the receiving test media server respectively by calling an external interaction interface. The start test request carries their respective local media parameters, peer media parameters and session identifier. The sending test media server is configured to respond to the start test request, generate test information, and encode the test information and media data to obtain media data packets, so that the SIP server can send the media data packets to the receiving test media server in the form of an RTP stream. The receiving test media server is used to receive and parse the media data packets to obtain parsed data, and to test the RTP stream based on the parsed data to generate media stress test results.

[0136] In this example, 1 indicates establishing a SIP call using SIPp; 2 indicates transmitting media information, such as port, IP, and session ID; 3 indicates that the corresponding test media server pushes the media stream to the corresponding calling or called SIPp based on the received information, while receiving the media stream, recording the reception status, and parsing the information in the media for information identification; 4 indicates that after the call ends, the media stream test results are fed back to the SIPp for recording.

[0137] In one implementation, the sender tests the media server, specifically for: The sender's test media server obtains the current timestamp and the current sequence number, and determines the transmission time interval based on the difference between the current timestamp and the timestamp of the last packet transmission; The sender's test media server generates the test information based on the current timestamp, the current sequence number, the transmission time interval, the local media parameters, the peer media parameters, and the session identifier; The process of encoding the test information and media data to obtain a media data packet includes: If the data type of the media data is audio data, then the sending test media server converts the test information to obtain hexadecimal data; The sending test media server encodes the hexadecimal data based on a preset mapping relationship between dual-tone multi-frequency signals and hexadecimal characters to obtain a DTMF audio signal. The sending test media server encapsulates the DTMF audio signal and the audio data to obtain the media data packet.

[0138] In one implementation, the sender testing the media server is further specifically used for: If the data type of the media data is video data, the sender's test media server extracts a video frame from the video data and determines whether test information needs to be superimposed on the video frame according to the configuration requirements. If there is no need to overlay test information, the video frames are packaged to obtain the media data packet; If test information needs to be superimposed, the test information is encoded to obtain a QR code image; The QR code image is superimposed onto the video frame, and the superimposed video frame is packaged to obtain the media data.

[0139] In one implementation, the receiver tests the media server, specifically for: The receiving test media server receives and parses the media data packet to obtain parsed data, wherein the parsed data includes a first Internet Protocol address and a first port; The receiving test media server matches the first Internet Protocol address and the first port with the second Internet Protocol address and the second port in the peer media parameters to obtain the matching result; If the matching result is a non-match, the parsed data is discarded and the number of times it is discarded is counted; If the matching result is a match, the type of the media data packet is determined; if the type of the media data packet is an audio data packet, the RTP stream is decoded to obtain a DTMF audio signal, and the DTMF audio signal is restored to a hexadecimal string based on a preset mapping relationship between dual-tone multi-frequency signals and hexadecimal characters, wherein the hexadecimal string includes the audio transmission time, the audio transmission time interval, and the audio transmission sequence number; Based on the audio transmission sequence number, the continuity of adjacent received hexadecimal strings is checked to determine whether there is packet loss, and the audio continuity check result is obtained. The audio delay parameter for media transmission is calculated based on the audio transmission time and the current audio reception time, and the audio jitter parameter is calculated based on the audio transmission time interval and the adjacent audio reception time interval. Based on the audio continuity verification result, the audio delay parameter, and the audio jitter parameter, the media stress test result of the audio data packet is generated.

[0140] In one implementation, the receiver testing the media server is further specifically used for: If the media data packet is a video data packet, then the RTP stream is decoded to obtain video frames; The video frame is subjected to QR code image recognition to obtain video test information, wherein the video test information includes video transmission sequence number, video transmission time, and video transmission time interval; Based on the video transmission sequence number, the continuity of adjacent received video test information is checked to determine whether there is frame loss or packet loss, and the video continuity check result is obtained. The video delay number of media transmission is calculated based on the video transmission time and the current video reception time, and the video jitter parameter is calculated based on the video transmission time interval and the time interval of adjacent received videos. Based on the video continuity verification results, video latency parameters, and video jitter parameters, the media stress test results of the video data packets are generated.

[0141] In one implementation, after the receiving test media server receives and parses the media data packets to obtain parsed data, and tests the RTP stream based on the parsed data to generate media stress test results, the system further includes: The calling SIPp and the called SIPp are used to send stop test requests to the sending test media server and the receiving test media server respectively by calling external interaction interfaces; The sender testing media server is configured to respond to the stop test request and stop sending the media data packets; The receiving test media server is configured to respond to the stop test request and stop receiving the media data packets.

[0142] In one implementation, after the receiving test media server stops receiving the media data packets in response to the stop test request, the system further includes: The sending test media server is used to respond to the test status query request issued by the calling SIPp, obtain statistical data by querying the statistical data table, and send the statistical data to the SIP server; The receiving test media server is used to respond to the test status query request issued by the called SIPp and send the media stress test results to the SIP server.

[0143] The specific functions and examples of each module and submodule of the system in this embodiment of the invention can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0144] The acquisition, storage, and application of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0145] This invention also provides an electronic device, comprising: At least one processor; and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in any one of the embodiments of the present invention.

[0146] The beneficial effects of the electronic device in this embodiment of the invention are equivalent to the beneficial effects of the above-described server media stress testing method, and will not be repeated here.

[0147] This invention also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method described in any one of the embodiments of this invention.

[0148] The beneficial effects of the storage medium of the present invention are equivalent to the beneficial effects of the above-described server media stress testing method, and will not be repeated here.

[0149] Figure 6 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present invention is shown. Electronic device 800 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 800 may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0150] like Figure 6 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0151] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0152] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as a server media stress testing method. For example, in some embodiments, the server media stress testing method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the server media stress testing method described above can be performed. Alternatively, in other embodiments, the computing unit 801 can be configured to perform the server media stress testing method by any other suitable means (e.g., by means of firmware).

[0153] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0154] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0155] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0156] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0157] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0158] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0159] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0160] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this invention should be included within the scope of protection of this invention.< / exec> < / exec>

Claims

1. A server media stress testing method, applied to a server media stress testing system in a distributed system, characterized in that, The server media stress testing system includes a sending test media server and a receiving test media server. The distributed system also includes a calling SIPp, a called SIPp, and a SIP server. The calling SIPp is connected to the sending test media server, the called SIPp is connected to the receiving test media server, and the sending test media server and the receiving test media server are connected via the SIP server. The method includes: The calling SIPp and the called SIPp send start test requests to the sending test media server and the receiving test media server respectively by calling the external interaction interface. The start test request carries their respective local media parameters, peer media parameters and session identifier. In response to the start test request, the sending test media server generates test information and encodes the test information and media data to obtain media data packets, so that the SIP server sends the media data packets to the receiving test media server in the form of an RTP stream. The receiving test media server receives and parses the media data packets to obtain parsed data, and tests the RTP stream based on the parsed data to generate media stress test results.

2. The method according to claim 1, characterized in that, In response to the start test request, the sending test media server generates test information and encodes the test information and media data to obtain media data packets, so that the SIP server can send the media data packets to the receiving test media server in the form of an RTP stream, including: The sender's test media server obtains the current timestamp and the current sequence number, and determines the transmission time interval based on the difference between the current timestamp and the timestamp of the last packet transmission; The sender's test media server generates the test information based on the current timestamp, the current sequence number, the transmission time interval, the local media parameters, the peer media parameters, and the session identifier; The process of encoding the test information and media data to obtain a media data packet includes: If the data type of the media data is audio data, then the sending test media server converts the test information to obtain hexadecimal data; The sending test media server encodes the hexadecimal data based on a preset mapping relationship between dual-tone multi-frequency signals and hexadecimal characters to obtain a DTMF audio signal. The sending test media server encapsulates the DTMF audio signal and the audio data to obtain the media data packet.

3. The method according to claim 2, characterized in that, The process of encoding the test information and media data to obtain a media data packet includes: If the data type of the media data is video data, the sender's test media server extracts a video frame from the video data and determines whether test information needs to be superimposed on the video frame according to the configuration requirements. If there is no need to overlay test information, the video frames are packaged to obtain the media data packet; If test information needs to be superimposed, the test information is encoded to obtain a QR code image; The QR code image is superimposed onto the video frame, and the superimposed video frame is packaged to obtain the media data.

4. The method according to claim 1, characterized in that, The receiving media server receives and parses the media data packets to obtain parsed data, and tests the RTP stream based on the parsed data to generate media stress test results, including: The receiving test media server receives and parses the media data packet to obtain parsed data, wherein the parsed data includes a first Internet Protocol address and a first port; The receiving test media server matches the first Internet Protocol address and the first port with the second Internet Protocol address and the second port in the peer media parameters to obtain the matching result; If the matching result is a non-match, the parsed data is discarded and the number of times it is discarded is counted; If the matching result is a match, the type of the media data packet is determined; if the type of the media data packet is an audio data packet, the RTP stream is decoded to obtain a DTMF audio signal, and the DTMF audio signal is restored to a hexadecimal string based on a preset mapping relationship between dual-tone multi-frequency signals and hexadecimal characters, wherein the hexadecimal string includes the audio transmission time, the audio transmission time interval, and the audio transmission sequence number; Based on the audio transmission sequence number, the continuity of adjacent received hexadecimal strings is checked to determine whether there is packet loss, and the audio continuity check result is obtained. The audio delay parameter for media transmission is calculated based on the audio transmission time and the current audio reception time, and the audio jitter parameter is calculated based on the audio transmission time interval and the adjacent audio reception time interval. Based on the audio continuity verification result, the audio delay parameter, and the audio jitter parameter, the media stress test result of the audio data packet is generated.

5. The method according to claim 4, characterized in that, If the matching result is a match, then after determining the type of the media data packet, the method further includes: If the media data packet is a video data packet, then the RTP stream is decoded to obtain video frames; The video frame is subjected to QR code image recognition to obtain video test information, wherein the video test information includes video transmission sequence number, video transmission time, and video transmission time interval; Based on the video transmission sequence number, the continuity of adjacent received video test information is checked to determine whether there is frame loss or packet loss, and the video continuity check result is obtained. The video delay number of media transmission is calculated based on the video transmission time and the current video reception time, and the video jitter parameter is calculated based on the video transmission time interval and the time interval of adjacent received videos. Based on the video continuity verification results, video latency parameters, and video jitter parameters, the media stress test results of the video data packets are generated.

6. The method according to claim 1, characterized in that, The receiving media server receives and parses the media data packets to obtain parsed data, and then tests the RTP stream based on the parsed data to generate media stress test results. The method further includes: The calling SIPp and the called SIPp send stop test requests to the sending test media server and the receiving test media server respectively by calling the external interaction interface; The sending test media server responds to the stop test request and stops sending the media data packets; The receiving test media server responds to the stop test request and stops receiving the media data packets.

7. The method according to claim 6, characterized in that, After the receiving test media server responds to the stop test request and stops receiving the media data packets, the method further includes: The sending test media server responds to the test status query request issued by the calling SIPp by querying the statistical data table, obtaining the statistical data, and sending the statistical data to the SIP server. The receiving test media server responds to the test status query request issued by the called SIPp and sends the media stress test results to the SIP server.

8. A server media stress testing system, configured in a distributed system, characterized in that, The server media stress testing system includes a sender test media server and a receiver test media server. The distributed system also includes a calling SIPp, a called SIPp, and a SIP server. The calling SIPp is connected to the sender test media server, the called SIPp is connected to the receiver test media server, and the sender test media server and the receiver test media server are connected through the SIP server. The calling SIPp and the called SIPp are used to send start test requests to the sending test media server and the receiving test media server respectively by calling an external interaction interface. The start test request carries their respective local media parameters, peer media parameters and session identifier. The sending test media server is configured to respond to the start test request, generate test information, and encode the test information and media data to obtain media data packets, so that the SIP server can send the media data packets to the receiving test media server in the form of an RTP stream. The receiving test media server is used to receive and parse the media data packets to obtain parsed data, and to test the RTP stream based on the parsed data to generate media stress test results.

9. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images