Research and implementation of network streaming media recognition algorithm based on Winpcap

0 Introduction

With the rapid development of key technologies such as computer networks and video compression, network streaming technology has become the main form of Internet information dissemination after text and pictures. Through network streaming technology, users can easily access, view and play streaming data on the network. How to quickly discover streaming data from massive network data is the premise and basis for network video service quality monitoring, network traffic statistics, network video user behavior analysis and video content supervision.

Network streaming media service is an application layer service, and its data transmission mainly adopts proprietary application layer protocol RTP/RTCP. Therefore, the discovery of network video data stream is first to identify the application layer protocol. For the identification of application layer protocol, the literature proposes a method to identify the protocol by using the most frequently appearing field in the protocol as a feature string, and uses a feature string to identify a protocol. The literature proposes a method based on signature strings to identify application layer protocols, which mainly targets the scope of P2P protocols and requires matching multiple feature strings for the entire message to identify a P2P protocol, which is time-efficient. The literature proposes a method to identify application layer protocols and traffic based on classification first and then grouping, but the essence of this method is still based on certain fixed ports. If the application layer protocol is implemented by randomly selecting ports, this method lacks accuracy and flexibility.

This paper analyzes the characteristics of the network streaming media interaction process and designs a network video stream recognition algorithm based on Winpcap based on the key feature strings corresponding to the application layer transmission protocol. It realizes the discovery of network streaming media and analyzes and verifies the performance of the algorithm designed in this paper through experiments.

1 Introduction to Winpeap

Winpcap is a packet capture library derived from the Berkeley packet capture library. It implements the interception and filtering of underlying packets on the Windows operating platform.

Winpcap is an architecture for network data packet capture and network status analysis under Windows platform based on BPF model and Libpcap function library. This architecture is composed of a core packet filter driver, a low-level dynamic link library Packet.dll and a high-level system-independent function library Libpcap. The low-level packet capture driver is actually a protocol network driver. It provides Windows 95/98/NT/2000 with the ability to capture and send original data packets similar to Berkeley Packet Filter under UNIX system by calling functions in NDIS. Packet.dll is the API interface for accessing this BPF driver. At the same time, it has a set of function libraries that conform to the Libpcap interface (capture function library under UNIX).

Winpcap consists of three parts: The first module NPF (Netgroup Packet Filter) is a virtual device driver file. Its function is to filter data packets and pass them to the user-mode module intact. This process includes some operating system-specific codes. The second module Packet.dll provides a common interface for the Win32 platform. Different versions of Windows systems have their own kernel modules and user-level modules. Packet.dll is used to resolve these differences. Programs that call Packet.dll can run on different versions of Windows platforms without recompiling. The third module wpcap.dll is independent of the operating system and provides more high-level, abstract functions.

Winpcap provides a set of standard programming interfaces that are compatible with libpcap, allowing many original network analysis tools on UNIX platforms to be quickly ported to facilitate the development of various network analysis tools. It fully considers various performance and efficiency optimizations, including support for NPF kernel-level filters, support for kernel-state statistical modes, and the ability to send data packets.

2 Application layer protocol RTP/RTCP

RTP/RFCP is an application-oriented transport layer protocol. It has no concept of connection and can be built on both connection-oriented and connectionless underlying protocols. Therefore, RTP is independent of the transport layer. Since the real-time transmission of network streaming media requires high transmission speed, UDP has a lower transmission delay than TCP and can be well matched with audio and video streams. Therefore, in practical applications, RFP/RTCP/UDP is the main protocol for streaming media transmission. Its structure is shown in Figure 1.

The Real-time Transport Protocol (RTP) is a protocol that provides end-to-end delivery services for real-time data. It can transmit time information and achieve stream synchronization. However, RTP itself cannot provide a reliable transmission mechanism for sequentially transmitting data packets, nor does it provide flow control or congestion control. It relies on the RTP control protocol (RTCP) to implement control services. During an RTP session, each participant periodically exchanges RTCP packets. The RFCP packet contains statistical information such as the number of packets sent and the number of packets lost. The session parties can use this information to dynamically change the transmission rate or even the validity type. The RTP packet structure is shown in Figure 2.

As can be seen from FIG. 2 , the RTP data packet is composed of a fixed RTP header of 12 bytes and continuous multimedia data of variable length, wherein the multimedia data may be compressed data.

The more important fields and their meanings are as follows:

Version (V): 2b. This field defines the version of RTP. The version defined by this protocol is 2.

Padding (P): 1b. Padding may be used for certain encryption algorithms with fixed length, or to transmit multiple RTP packets in the underlying data unit.

Extension (X): 1b, if the extension bit is set, indicates that the fixed header is (only) followed by a header extension.

CSRC Count (CC): 4b, the CSRC Count contains the number of CSRC identifiers following the fixed header.

Marker (M): 1b, markers are used to allow important events in the bitstream to be marked, such as frame ranges.

Payload Type (PT): 7b. This field defines the format of the payload. Its interpretation is determined by the specific application. The protocol can specify a default match between the payload type code and the payload format. Other payload type codes can be dynamically defined by non-RTP methods. An RTP transmitter sends a single RTP payload type at any given time.

Sequence number (SN): 16b, each time an RTP data packet is sent, the sequence number increases by one, and the receiver can detect packet loss and reconstruct packets based on this. The initial value of the sequence number is random.

Time stamp: 32 bits, the time stamp reflects the sampling moment of the first bit in the RTP data packet. The starting value of the time stamp is random.

SSRC: 32b, the SSRC field is used to identify the synchronization source. The identifier is randomly generated so that no two synchronization sources have the same SSRC identifier in the same RTP session.

CSRC list: 0 to 15 items, each 32 bits. The CSRC list identifies the contributing sources carried in this packet. The number of identifiers is given in the CC field.

Through the analysis of the RTP protocol, the following "stream characteristics" are summarized:

(1) The first two bits of the UDP payload are 0x10 (RTP version number is 2).

(2) The PT value of the RTP stream payload type remains unchanged. That is, the values ​​of bits 9 to 15 in the RTP header of the same streaming media data packet remain unchanged.

(3) The SN value of the RTP stream increases.

(4) The SSRC value of the RTP packet is a fixed value, and the SSRC values ​​of each packet of the same streaming media data remain unchanged.

3 Algorithm Implementation

First, the data packets are captured through the Winpcap filter, and the handshake data packets are identified. Then the content of the call signaling is analyzed to obtain the source, destination address and port number of the transmitted streaming media, and then the filter is notified to capture data based on the source, destination address and port number; the UDP data packets are identified and analyzed, and the RTP data stream to be captured is determined based on the "stream characteristics".

The above four items are used as necessary conditions for judging RTP traffic. For each UDP data stream, if four packets that meet the above strategy can be detected continuously, it is considered to meet the sufficient conditions for RTP data stream.

After testing with a large amount of actual data, the algorithm can effectively identify network streaming media.

4 Conclusion

Based on the analysis of network streaming media transmission protocol, a network streaming media identification algorithm is implemented using Winpcap. Experiments have proved that the algorithm can effectively identify streaming media and has a positive effect on the application of network streaming media.