Chapter 1. Introduction

The Real-Time Streaming Protocol (RTSP) is a protocol for creating and managing time-synchronized streams for multimedia communications. (Liu et al., 2008) RTSP was designed to send low latency streams. It is important to know that RTSP itself doesn’t transport the data, but it uses RTP protocol with RTCP for the media streams. RTSP supports commands such as play, pause, options, describe, setup, teardown, get parameter, and set parameter. (Watequlis Syaifudin et al., 2018). There is another interesting detail about the real-time streaming protocol about its URL request which are completely like the hypertext transfer protocol (HTTP). To secure the video stream, RTSP can also use the SRTP protocol to encrypt the stream so that the video streaming is secured. When discussing the Real-Time Streaming Protocol (RTSP), (RTCP) and (RTP) are frequently mentioned (Abdulazeez et al., 2022a). At the application layer, these three protocols cooperate. RTSP serves as the controller that establishes the connection with a server, while RTP oversees providing video and audio data to the controller. Before HTTP streaming was adopted in the late 2000s, RTSP 1.0, which was first introduced in 1998, was the most widely used live streaming technology (Schulzrinne et al., 1998). The 2016 version of RTSP 2.0 sought to increase the older protocol`s speed (Liu et al., 2008) Although IP cameras are often utilized in surveillance and security applications, RTSP is not commonly supported for playback on current devices.

RTSP 2.0 is a two-way request-and-response protocol that controls how media resources are provided from the provider to the user after establishing a context for those resources. The three main parts of RTSP are session establishment, media delivery control, and an extensibility mechanism. The protocol provides a complete solution for client-controlled real-time media delivery and is based on a few assumptions regarding functionality that currently exists. RTSP uses text-based requests and responses, and the message bodies of these messages may include binary data. An RTSP request`s method line, which identifies the protocol, version, and resource to be used, comes first. An RTSP client uses the hostname element of the URI to get the IPv4 or IPv6 address of the RTSP server. A URI is used to identify the resource. Other RTSP headers come after the method line. Each of these lines ends with two consecutive carriages return line feed (CRLF) character pairs. If a message body is present, it is followed by two CRLF character pairs, and a message header indicates how long it should be. RTSP responses start with a response line that contains the protocol and version, followed by a status code and a reasonable sentence, much like HTTP responses. RTSP messages are sent between the client and server using a trustworthy transport protocol. According to RTSP 2.0, clients and servers must implement TCP and TLS over TCP as the needed transports for RTSP messages. RTSP playback is not supported by iOS or Android smartphones (Cmpe, 2009). The "last mile" distribution and playback on phones, desktops, and other devices are often handled via MPEG-DASH and HLS before using this technique to encode and transport live video streams to an intermediary server (Lanphier Westerlund Ericsson M Stiemerling, 2016). RTSP requires the deployment of additional protocols since it is not naturally bit-rate adaptable.

Within the next 3 years, monthly global data will surpass 26 exabytes, with the introduction of a 5g network and the expansion of the network rapidly it is predicted that half of the world network traffic will be focusing on multimedia communications such as video streaming (Sloman et al, 2015). According to the characteristic of the streaming protocol in multimedia communications, in this work, we will identify and address some of the security issues by running different proposed attacks against the RTSP. Many Challenges were identified such as high bit rate, delay requirements, latency, packet losses, network congestion, and good video quality, which are indeed critically important customer experience performance metrics nonetheless, without security, the video material is vulnerable to attackers when it contains sensitive or private data.(Santos-González et al., 2017)

Media stream encryption can keep personal or commercial information out of the hands of criminal actors. As RTSP protocol is designed same as HTTP Protocol thus bad implementation related to exploit vulnerabilities which can occur during streaming media. The vulnerabilities may be ­ mechanism. This article suggests a method for creating and implementing a security layer for RTSP-based Streaming Servers. We will also assess the protocol`s performance and accuracy both during the attack phase and during the security implementation phase.

1. Background:

In this section, we will define the background of the real-time streaming protocol. RFC 2326 contains information on RTSP, which was developed by the Internet Engineering Task Force (IETF) in April 1998. It quickly became popular because it allowed users to stream music and videos over the Internet without having to download anything to a client`s device. The amount of time and resources it saved thrilled everyone! Local area networks, where delivery delays and losses are modest and regular, are where RTSP originated. It also provides a numb­er of other solutions. When the server needed to control delivery to the client, RTSP was created and developed. Therefore, the server handled all logic, including the decision of what to send when and to whom. The client needed to be as simple and plain as possible, while the server needed to be as complex as possible. The situation drastically altered after we switched to the HLS and DASH protocols. The server was now more straightforward, but the client was suddenly more complex. However, it was discovered that the capabilities of intelligent monitoring of the RTSP server`s delivery had vanished into oblivion. Nowadays, most RTSP servers are IP cameras that are unaware of the RTSP capabilities that were developed decades ago. This suggests that customer input is mostly unimportant. Everything is OK if the client gets the data otherwise, there are problems. RTSP was created along with telephony. It was based on already on-the-market, extremely successful technologies, but we significantly updated them: SDP for content information transfer RTCP for signalling the quality of data delivery (QoS) and RTP for data delivery. RTP and RTCP were created about 25 years ago, but they have still been used the same way in the de facto standard for real-time communication, WebRTC.This should give you an idea of how successful these solutions are. They had all they needed to remain financially stable to this day, even back then! RTSP used to be the industry standard for streaming audio and video. However, adaptive bitrate HTTP-based technology eventually eclipsed RTSP and RTMP. Today, IP cameras are still utilized in video surveillance, and RTSP is still used for signal capture. It is crucial to understand that RTSP for television and RTSP for IP cameras are two different protocols. Only outdated systems that are still in use support RTSP for television. Real time streaming protocol (RTSP) was introduced in 1996-97 by Anup Rao of Netscape communications. (Aloman et al., 2016)RTSP was once the leading technology for multimedia communications, however, it requires a dedicated server for the last mile of content delivery. The benefits of RTSP protocol are low latency and ubiquitous in multimedia communications. (Seralathan et al., 2018) Previously, we have seen a lot of challenges that were identified in the multimedia communications such as latency, security, and performance of video streaming when using RTSP protocol. Although previous research has made numerous attempts to address the issue of performance security by using RTSP protocol. But not much progress is made to understand the factors and to identify the best practises from the Performance security areas of the RTSP protocol to derive a prototype that can help improve the video streaming experiences for the end users.

1.1 Aim Objectives:

The goal of the study is to use a streaming protocol on multi-media communication to improve the video quality and improve its security.

The above aim raises the following objectives:

· Conducting and analysing the RTSP protocol`s security measures in terms of performance in the multi-media Communications

· To improve the specific challenges such as high latencies, packet losses and trade-off between security and performance with respect to RTSP based multimedia communication

· Conducting Quantitative research with RTSP protocol in the labs to experiment data analysis and improve the security by carrying out attacks to test the security and performance of video streaming

1.2 Project Philosophy:

Project philosophy is connected to assumptions, the nature and knowledge of the research, and the method of knowledge production. The three-test driven phenomenon—interpretivism, positivism, and pragmatism—will be used in this study. As we will be focusing more on the performance and the security of the Real time streaming protocol for video streaming. The Research will be based on the data which will be taken from the manual steps that will be performed in the Initial phases of the project where different parameters such as latency, jitter, framerate etc will be analysed when using different network connections. This work will be related to positivism because it will be highly structured with medium to large data samples and will include the quantitative methodology.

Once the project is in the middle phase, we will be doing the result analysis and evaluation of the RTSP protocol that will include in-depth investigations. In the later stages where the transmission of the protocol will be made secured, we will be implementing security protocol using the best practices to achieve secure communication for the end-users.

1.3 Research Questions:

The below research questions will be addressed as a part of the project proposal:

1) How can we analyse and implement Real time streaming protocol RTSP with respect to security and the performance in video streaming?

2) What are the challenges and difficulties that can be faced during video streaming, keeping in mind parameters such as video quality, bitrate, framerate, and packet loss?

3) How can we secure the transmission of media when using the real-time streaming protocol RTSP?

1.4 Overview of Dissertation Our Results

This dissertation presents a systematic approach to utilize different methodologies to design, develop and evaluate a prototype which would support the enhancement of video streaming regarding the RTSP protocol. The Overview of the project is divided into difference chapters and then explained later in the respective chapters. The main message of this report is: RTSP Protocol, RTSP protocol secure transmission, Security layer and its performance metrics.

The dissertation is organized as follows:

Chapter 2 will be based on the methodology. That is going to include system development methodology and literature methodology and the benefits and limitations. Chapter 3 will be completely including the literature review which has been studied during our research phase. This will include all the past work done in the RTSP protocol and multimedia communications. This will describe our work and its relation to the literature of the research.

Chapter 4 will be related to experiment analysis this chapter will include the client and server-side setup. Configuration of client and server-side multimedia protocols. The data collection.

Chapter 5 demonstrates the results evaluations and the testing of the system during the attacks and during the implementation of the security protocols.

Chapter 6 will demonstrate the future work that can be done in the relative field and will demonstrate the results from chapter 5.

Chapter 7 presents conclusions and future work, and then followed by reference, appendix, and screenshots.

1.5 How to Read this Dissertation

The opening chapter summarises each topic succinctly and explains in detail how the findings of each chapter relate to one another. Since each chapter in this thesis is distinct from the others and may stand alone, they can all be read separately. The reader is also expected to have a foundational understanding of programming, machine learning, network communications, and cyber security.

Chapter 2. Methodology
This Chapter will contain the system development methodology, the literature review methodology and its background.

2.1 Quantitative Methodology:

Quantitative methodology refers to the process of collecting and analysing

data that is numerical (Base and Methods, 2022). In this work we will mostly depend on the quantitative methodology as we will be measuring the accuracy, latency, packet losses, bitrate, and other performance metrics. The following phases will be covered in the quantitative methodology these are:

a) Project Development methodology: We will be using an efficient project model called the iterative or incremental model to ensure flexibility for requirement and implementation changes which will help us to deliver the project on time with quality. The failure of the project can be reduced when using the incremental model as stated by (Nilsson and Wilson, 2012).

b) Types of attack: We will be testing out the security of the RTSP protocol on both the client side and server side by using different attacks such as DDoS, unauthorized access, man-in-the-middle attacks, brute force attacks, automated dictionary attacks, etc. once the tests are done, we will then take further steps to ensure that we can mitigate these risks associated with the video streaming.

c) Testbed development: Testbed Development is the process in which a particular element is tested in an isolated fashion (Fortier and Michel, 2022). Testbed development methodology will help us to test all the different phases in an incremental way.

d) Creating New Dataset: The dataset will be created based on the performance calculations of Real Time Streaming Protocol (RTSP) when using a different network such as Wi-Fi, 4g, and 5g connections.

e) Validation of the results using machine learning: During the project, we will also be using the Weka simulator and perform the tests to calculate and measure the performance, and accuracy of the protocol when implementing the security layer.

f) Evaluation and Result Findings: Findings from the result and evaluating the algorithms using accuracy matrix and identifying the extracted patterns using simulation techniques. This will include some of the performance metrics that will be used for the validation and evaluation. These are 1) Accuracy, Packet loss, Latency, bit rate, etc. In addition to the quantitative evaluation, functional testing and analysis will also be done to ensure that the experiments done, and the security layer implemented satisfies the requirement specification.

2.2 System Development Methodology:

We must consider what will happen for the remainder of the project while selecting the suitable and acceptable technique. As a result, we must adopt an approach that is required for bigger projects. To disperse the job for better purposes, the technique must be a step-by-step procedure. This project, which is a form of quantitative study, will include a significant amount of literature research on existing streaming standards and protocols as well as how scholars have identified and approached RTSP protocol performance metrics. Incremental model is the method chosen for this project. Since incremental model is a process where requirements are divided into standalone modules and is primarily designed for software development models, it offers the adaptability needed for this project. The incremental model is a more flexible strategy based on scientific research.

The incremental model, which is more focused on the facts, in this model, each phase goes through the requirements, design, development, implementation, and testing phases where every module would release and add function to the previous releases and this process flows until the outcome is achieved. This strategy enables the reconfiguration of certain project components during weekly or monthly meetings with the supervisor, allowing for subsequent re-planning based on an assessment of the product`s current state of execution. As stated in this paper, the primary objective of this project is to add a security layer to the RTSP protocol and evaluate its performance to utilize it to gauge latency and visual quality for multimedia communications.

The First phase of the incremental model will start with gathering the requirements. In this phase we will start and gather requirements from research databases such as IEEE, Google Scholar and go through the literature reviews. This will also include the flow to correctly setup the client and server side for the multimedia communications. In this phase, we will primarily identify and define our objectives and propose a prototype that is secured for transmission.

The second phase will start with the design and development. In the designing part we will be concentrating on the client-side architecture where we will have to establish a function to log the data from the stream and then store it in the database for further experiments. This will help us to determine and evaluate the results which will be performed on the client side. The server side will be setup using Open-CV python library with nginx server. This will help us to transmit the stream and therefore develop a secure layer for the transmission to avoid backdoor attacks or other emerging attacks.

In the third phase we will start working on the testing of both the client and server-side architectures. The testing will be done separately and the data from the experiments will be saved for future experiments. In this phase we will be testing the security and performance and log out the results to apply a machine learning model which can evaluate the different parameters and give us the result. The last phase will be for the implementation where the end product would be tested out. This will include the implementation of the security layer and the attacks that would be performed on the RTSP server. The result of this implementation will help us to understand the system and its vulnerabilities that can be exposed to the outer world. The feedback would be provided by the supervisor and necessary measure would be taken to secure and produce the best prototype for video streaming using different cameras and network connection such as 4g and possibly 5g network. For the purpose of doing a critical analysis of the data for this project, neither interviews nor questionnaires are needed. As a result, this project will accomplish a number of its goals. First, a significant amount of literature research will be conducted in the fields of network communication, RTSP security protocols, latency and performance metrics, the application layer of RTSP protocols, and specifically investigating how specific RTSP protocols can be used to support efficient and secure video streaming operation. The second and most important step is determining the security aspect that will allow us to develop a secure video streaming protocol capable of recording feeds from cameras via 4G, 5G, and WI-FI networks. The project`s most time-consuming section will be this one. A feasibility analysis for the deployment may be conducted once a security layer has been built. The only purpose of this feasibility study will be to simulate the performance metrics. Most likely, a Python and Javascri pt library will be used. In order to make sure the server is safe and figure out how well it works, it will be subjected to new attacks.

Descri ption automatically generated" v:shapes="Picture_x0020_3">

FIG 2.1 Incremental Model

2.2.1 Benefits Limitations:

The incremental model will be a great fit for larger and complex projects. We use the incremental model when the requirements are complex and clear. The benefits of using incremental model are:

1. When it comes to error finding and identifying errors, it’s easy to work on.

2. Incremental model is completely easy to test, and then debug.

3. Incremental model is flexible when it comes to handling things and projects

4. Its less costly to change

While on the other hand we can also see the incremental model has some drawbacks to which are discussed below:

1. Before starting it would need a good design and planning.

2. It needs a clear and complete requirement of the whole system before the system can be broken incrementally.

3. The total cost of the incremental model is more likely going to be increased if the definition of the actual system isn’t understood before.

2.2.2 Theoretical Background:

For the development of this project, we have used the Go language for the RTSP server. The RTSP server has been developed in the Go language, which runs the server for us. We chose Python and the OpenCV Python framework for the client side. The GO language, which is also mostly referred to as Golang, is an open-source computer programming language designed and developed by Google. It was initially built by Google because things in Google were getting more complex due to the codebase architecture within Google. The Golang was first introduced into the market by a renowned programming team known as Robert Grasmere, Rob Pike, and Ken Thompson. Because of the nature of C++, Golang was released to the public in 2009 as an open-source framework that was primarily used in server-side programming, data science, and cloud-based programming. As the market started to grow, many big giants, such as Twitch, Netflix, and Drobox, started using Golang.

Python and a Python library called OpenCV have been used for the client side of the project. OpenCV is an open-source platform that is used in computer vision and machine learning software. It was designed solely for the purpose of providing a common infrastructure for state-of-the-art computer vision and machine learning algorithms. This library has more than 2000+ algorithms that include camera movements, classifying human actions in videos, displaying streams, and much more. To store the data from the client side and to perform different experiments on the data, we have used a relational database language called MYSQL. MySQL is the query language that inserts, selects, deletes, and updates records in the database. With the help of a server-side language, we will store the data from the client side in the MYSQL database and then later perform different experiments on the data using a machine learning model. These experiments will enable us to check the data and evaluate the results after performing cyber-attacks during the live streaming. This will give us an accurate result of the performance parameters, such as latency, frame rate, average fps, delay, and other performance metrics, so we can see how the RTSP server is doing when using different network connections and different security protocols.

2.2.3 Security Aspects of the RTSP Server:

Once we are done with setting up the environment for the client and server side, we will then proceed with the cyber security aspects of the project. In this module, we will try to use different attacks on our RTSP server and then expose the vulnerabilities and flaws in the server. These attacks can be session hijacking, pass word sniffing, man-in-the-middle attacks, dos attacks, brute force attacks, and all the other emerging attacks. These attacks would then give us an overview of the RTSP server`s performance, and we could identify how the RTSP server works when it is attacked. In this module, we will also be focusing on the different security parameters and see how we can upgrade the security of the RTSP server. As mentioned by (Ohuchani et al. 2011), all devices running on the RTSP protocol can be extremely vulnerable to potential attacks since the RTSP service uses default usernames and pass words. As again mentioned by (Lohan et al., n.d.,) if an attack is carried out successfully, an attacker can control the intended system. Cyber-attacks on IP cameras or other cameras through RTSP usually represent a threat to the security of devices. With the increase of the Internet of Things, it is true that there will be more large-scale attacks on the RTSP servers in the future.

2.3 Literature Review Methodology:

The literature review methodology will involve the previous research papers to conduct a critical review and to identify the gaps in the performance security of the Real time streaming protocol. This will include the research questions, the sources that are going to be searched, strategy, action plan, and the criteria selection. This will include the papers taken from the databases such as IEEE, Google Scholar, Springer, Science Direct, ACM digital library, and sources in which other RTSP papers are published. The search terms will include the performance of RTSP protocol in video streaming, security applications of RTSP protocol in video streaming, RTSP Protocol Cyber security, Performance of RTSP protocol using 4g, 5g Wi-Fi network, etc.

Chapter 3. Literature Review

For this research proposal, several literature reviews were studied to understand the background, methodology, and research gaps in the Real Time Streaming Protocol (RTSP) performance and security in the field of video streaming.

(Hatem Mohammed et al., n.d. 2022) in the research paper “A study of islands Network performance for streaming protocols”, did a comparison between HTTP and RTSP protocol to broadcast the IP camera when using h264 and h265 encoders. The work was based on the security and performance of the protocols in which a network emulator was used to calculate the packet losses and latency. The results showed that http when using TCP had less packets compare to the real time streaming protocol.In the Paper “Evaluating 5G uplink performance in low latency video streaming” the authors (Uitto Heikkinen, 2022) analysed the efficiency of video streaming using the 5g network over the TCP and UDP protocols. The findings of a comprehensive set of evaluations with test cases suggest that 5G standalone with the optimal uplink to downlink duration ratio has the potential for low-latency streaming, and that delay variation remains at an acceptable level even in crowded network conditions. In the literature “Optimal Adaption of internet video Streaming the author (Abdulazeez et al., 2022b) described the main challenge to achieve optimal solution to stream video using the RTSP protocol. The author tested the videos over unicast and multicast networks. In addition to RTSP protocol, there were two other protocols called RTCP and RTP configured to achieve minimum packet losses, delay, jitter, and latency by incorporating an encoder on the network. The results were predicted to be

around 97% of performance when using the RTSP protocol with RTCP and RTP protocols together. (Arunachalam et al., 2022) proposed the idea of a secure 3-dimension video streaming using SRTP and RTSP protocols to transfer the audio and video content of the stream on the client side. (Veeramani Ganesan, 2022) primary objective is to find the system`s applications. This research paper provides a concept and implementation technique for efficient cloud-based video surveillance by using cloud computing characteristics such as parallel processing, large storage regions, scalability, and motion detection. The system`s video input processing, real-time picture analysis, storage, live streaming, and playback operations may be carried out using the RTSP protocol, the open-source Motion Service SDK, and Amazon cloud services. A mobile web application allows for remote viewing of the video stream data and the results of the image analysis. This system is low-cost, relatively portable, and easy to expand it enhances data security while requiring less maintenance.

(Yogesh et all, 2018) explains the security of the different protocols when it comes to video streaming applications. The author focuses mostly on internet-connected IP cameras that are accessible to everyone on the internet. Using the firmware images provided by the manufacturer on their own websites, he analyses the devices nonetheless, his 0-day vulnerabilities are proven on live devices. In addition, the author demonstrates how easy it is to find and exploit vulnerabilities in the chosen cameras using the available tools. The author selected ten D-Link Camera devices running a web server on a Light TPD server. The attackers discovered a series of vulnerabilities that exposed the devices` administrator pass words, allowed them to access a scri pt running as root, and contained a remote code execution flaw.

(Uitto Heikkinen, 2021) introduced a practical evaluation setup for the low latency streaming systems using the 5g network. In this paper the author states the importance of latency, in which he is gathering the results through optimized streaming solutions and accurate measurements. The experiment is essential in streaming scenarios because most of the industries have been moving towards the wireless technologies, and as stated by the authors one of the biggest concerns is the latency when it comes to live streaming.

(Rasanen et al., 2021) states that the information security is playing a key role in the streaming media applications that are increasingly vulnerable to wiretapping, message forgery, hacking and data tampering. In this paper the author has addressed the security extension for the RTP library. His proposed solution improves the content integrity and privacy through secure SRTP and ZRTP protocols.

(Prokofiev A.O. et all ,2017) developed a proactive intrusion detection system which was specifically used to find out the vulnerabilities in the RTSP devices widely used on the Internet of things. For the security of the RTSP devices the author has developed honeypot which is going to allow and investigate the cybercriminal behaviour or stop the unauthorized access. The main results of the developed IDS and the common queries sent by cybercriminals to interact with the system through RTSP were identified.

(Liu et al., 2010) in the paper, Design, and Implementation of Performance Testing Utility for RTSP Streaming Media Server reveals that the performance metrics of the video streaming and the author proposes an approach to tackle the different factors such as RTSP signals, RTSP packets, and counts the related performance metrics from the server. The experiment in the paper validates the efficiency and accuracy of the tool. A closer look into the other literature reveals that there are a wide variety of research studies and applications of RTSP protocol for different multimedia communications.

(Aloman et al., 2015) has proposed a comparative performance evaluation of the streaming protocol (RTSP) on 4g and Wi-Fi which has been done under different network conditions in terms of the QoE. The author however states that the RTSP protocol uses the non-standardized parametric process for comparative purposes in which RTSP performs better than most of the video streaming protocols in starting the video playback but at the expense of the QoE (Quality of user experience) due to packet losses.

Another literature review has been studied regarding the RTSP protocol security in which the author (Liu et al., 2019) has proposed an authorization model which can mitigate the risks of malicious monitoring, modification, and terminating of sessions as well server disguise, etc. People expect to speed, pause, and stop when watching video streams and videos online, and in cases like these the security is usually compromised which is becoming more and more prominent.

(Xin et al. 2008), the author proposed a framework for real-time streaming protocol-based applications to determine the performance. This was based on the four modules that include: an identification protocol module, an application layer management session module, an attack model module, and an attack analysis module. The performance measured is dependent on the time delay between the attack occurred and its detection.

In this project, we will work on the security aspects of establishing a secure RTSP protocol in video streaming and mitigate the risks associated with RTSP-based streams keeping in mind the performance metrics such as latency, packet losses, and network congestion.

Chapter 4. System Development Architecture

In this chapter we will cover the Server-side architecture, the client-side architecture, and the data analysis as well the data collection techniques.

4.1 RTSP Server Architecture:

As we know that RTSP is an application-level system that transmits data from devices by communicating directly with the server. (Posey, 2022) When a user or a program tries to stream video from a remote source, the client device sends an RTSP request to the server to get information on the choices that are available. These options include pausing the video, playing it, and recording it. The server will then deliver the request list in RTSP format. Once the client is aware of how to make any kind of request, it will submit a request for a media descri ption to the streaming server. The server will then respond with a descri ption of the media that the client has requested. After the client has sent a setup request, the server will respond with specific information about the transport mode. After the setup process is done, the client will start the streaming process by telling the server to send the bitstream, which is a sequence of binary digits, using the transport mode that was set up in the setup request. (Posey, 2022) Due to the fact that RTP is an application layer protocol, it is constructed on top of either TCP/IP or UDP. We use the lightweight UDP protocol and RTCP packets to handle congestion control because TCP often has a lot of extra overhead (because it has its own ways to handle congestion) and because UDP is simpler. An accumulator variable is declared inside the class and is increased by the length of each new packet that is received through UDP. This allows for the number of bytes that have been received to be calculated. The percentage of lost packets is calculated using two additional parameters: the total number of anticipated packets and the cumulative number of packets that have already been lost. Each time the actual sequence number of a packet is discovered to be different from the predicted sequence number, the value of the variable that tracks the cumulative number of lost packets is increased by one. The counting number is used to determine the anticipated number of packets. However, if part of the packets is lost and seqnum is larger than the counting number, the expected number of packets is determined by the maximum number of packets that were received. According to what was said previously, the total number of bytes received is used to calculate the video data rate. This pace is determined by the amount of time that the video is actively being played and does not consider the amount of time that the video is pausing. The client keeps track of the amount of time that has passed by measuring the amount of time that has passed between each packet that it has received and adding those times together. After then, this is used for the purpose of computing the total data rate statistic.

4.1.1 Workflow:

The RTSP server is running on nginx and has been created using the Golang programming language. The first step is to run the RTSP server, but before running RTSP server its quite important to download all the libraries and setup the path environment variables in the system. Once the RTSP server started running on the Port 8554 that’s the default port of RTSP to stream videos from camera or from other URL. The below screenshot shows that the RTSP server is running and with that we can also see the remaining ports which are open for other protocols.

FIG 4.1 RTSP server PORTs

As we can see that the RTSP listener is opened on the port 8554 (TCP) and port 8000 for UDP/RTP and 8001 for UDP/RTCP. Once the RTSP server is all set the next step was to stream the video. I used Visual Studio code to run the GoLang code and stream the video using the pythons OpenCV library. On a new terminal we ran the command ffmpeg -re -stream_loop -1 -i production.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream which started to stream the video from the producer.py file. The screenshot below confirms that the video can be seen executing from running the above command.

FIG 4.1.1 Server Running on FFMPEG

Upon success, I started to run the video using the VLC media player and the video started to run. VLC is a media player that can stream the Videos in the client side for us. The overall flow can be seen in the diagram below can show us how the stream from the server can be viewed in the client side. As RTSP itself cannot be tested our tried out in the browsers, to that we started to convert the stream from the RTSP to HLS, so that it can be seen in the browser and the metrics can be fetched and stored in database for further experiments.

FIG: 4.1.2 RTSP server architecture (Raj, 2019)

4.2 Client-Side Architecture

As explained above we are using the client-side architecture to make requests to the server which can take the stream by sending different commands such as play, pause, stop, describe etc. When a client submits packets in accordance with the RTCP protocol, the information about the quality of service may be sent back to the server. In addition to that there is also implementation for statistics and performance optimizations and to evaluate the latency, jitter, lost frames, packet losses, and the total seconds delay before and after an attack on the RTSP server. The development of the class FrameSynchronizer addresses the client-side problem of grouping frames that were sent using out-of-order sequence numbers. To address the issue, we use this class. This is achieved using a buffer, which keeps track of the difference between the expected and received sequence numbers. If there is a discrepancy, it will buffer the frame and insert several copies of the just-shown frame into the empty space. I have created a set of labels and performance metrics which are going to be stored in a MySQL database through an API. The labels and the parameters which we will be storing in database are the record type, duration, dropped frames, corrupted frames, latency, playback rate, avg latency, and the max processes. Integration of optimization and performance metrics has been integrated into the client. To do this, I came up with a whole new class that takes the place of an RTCP packet and is named RTCP packet. The RTCP protocol is built on top of the UDP transport protocol so that there will be as minimal overhead as is humanly achievable. When compared to RTP, the number of RTCP packets that are sent via UDP is much lower. This change was made to cut down on the amount of overall load. On the server side, the class known as Congestion Controller is the one that oversees managing congestion. This responsibility falls on the server. It does frequent checks of the statistics feedback from the client (through RTCP packets), and based on the findings of those checks, it adjusts the rate at which it sends RTP packets to the client. This is done so that the client receives the optimal amount of data. There are four different levels of congestion, ranging from one to four, and they are represented by the variable referred to as congestion Level. At level 0, there is no sign of any congestion in the system. The client is responsible for sending an RTCP packet, which contains a field called fraction Lost. This data is extensively used as the foundation for the computations that are used to determine the congestion level. The library and framework used for the client side is called HLS, the stream is first converted from RTSP to hls and then it runs on the browser which can give us the parameters.

Working Process of client side:

As we know to run rtsp stream in the browser we need to convert the stream into hls or other video streaming protocol that has native support in browsers for the stream, therefore in the case of RTSP, which doesn’t have any native support in the browsers, but we can use media players such as vlc to stream our videos from IP cameras through RTSP Protocol. The first thing is to install the FFMPEG tool.

i) FFMPEG:

The first step is to install ffmpeg. FFMPEG is a powerful tool that can handle different multimedia files. Once ffmpeg is installed and the environment variables are setup we then need to convert the rtsp URL to hls.

ii) Streaming the video on the browser:

As mentioned above for the client side we are using an hls plugin that can stream the video for us in the browser. Upon converting the rtsp link to hls we can see that the stream is running on HLS in the client side.

iii) Submitting the data from client to DB through a submit button:

A button labelled "Submit data" has been added to the client HLS to enable users to evaluate the functionality of the data which is sent to the MySQL database. When the submit button is clicked, the output of the server`s response should be sent to the database. When using the Session technique, it is important to keep in mind that the SETUP request must have been sent in the past for the server to be in the INIT state. This is a prerequisite for the method. Screenshot of the hls goes here.

Fig 4.2: client hls statistics

Fig 4.2.1: client hls main dashboard

Fig 4.2.2: client hls statistics submit data to db

4.3 Data Collection technique and analysis:

For collection of the data, we have simply used a query language called MySQL. The data is fetched from the client side hls and then when clicking on the submit button the data is sent to the database for further evaluation. As we are aware that sending data continuously to database in a matter on nano seconds can result in a complete crash of db., so we have used a quite traditional approach which can store the data for us in the MySQL database and later we can convert the data into .arf file and start our experiments and evaluation on the data. The database stores the values of duration type, latency, record type and frame rates, and the corrupted frames. The data can be exported manually to a csv file first and after that we can convert the data into an .arf file which we can use for the further experimental processes. This data will be taken in two phases, the first phase will have the data through a normal video stream and the second phase will involve the data during the cyber-attack stage i.e when an attack is performed on the real time streaming protocol server. We can see the screenshot below that contains the columns names and the data that has been stored in there.

Fig 4.3: Data collection and data records in php my admin

Chapter 5. Evaluation and Testing of the System

In this Chapter we will discuss the type of attack we have chosen, the security parameter we have implemented and, we will discuss the results of the system.

5.1 General Classification of Attack:

When it comes to choosing one of the emerging attacks, initially we were looking to go with 2 attacks that we knew is going to help us out in the penetration testing of the RTSP server were: 1) MITM which is the main in the middle attack and the second one was the DOS (Denial of service attack) to test out the RTSP server. So, for this Project I have gone with the http overflood or also know as dos attack to test out the RTSP server. It may be difficult to tell the difference between attack traffic and regular traffic, particularly in the case of an application layer assault, such as a botnet carrying out an HTTP Flood attack on a victim`s server. In this kind of attack, the traffic being sent is at the application layer. Because each bot in a botnet sends what seems to be valid network requests, the traffic generated by the botnet is not faked and may appear to have originated from a "regular" source. The application layer assaults the need for an adaptable approach that includes the capacity to block traffic based on specific rule sets, which may change on a frequent basis. Tools like a well-configured web application firewall (WAF) may reduce the quantity of fake traffic that is sent to the origin server, which in turn reduces the severity of the DDoS attack significantly. When dealing with various types of assaults, such as SYN floods or reflection attacks, such as NTP amplification, there are ways that may be utilised to drop the traffic reasonably effectively, if the network in question has enough capacity to take them in. Unfortunately, most networks are unable to handle an amplification assault of 300 Gbps, and even fewer networks are equipped to appropriately route and service the number of application layer requests that may be generated by an L7 attack.

5.1.1 DOS (DENIAL OF SERVICE):

The term “ Denial of Service” (or “DOS”) refers to an assault in which the resources of a server are depleted by overwhelming it with many requests. This sort of assault is almost never carried out by a single person but rather always with the assistance of networks of automated software programmes known as botnets. (Gonzalez et all,2017).

5.1.2 Layer Attacked:

The Layer we have attacked is the OSI Models Layer 7 called application layer. Because it is the OSI layer that is nearest to the end user, Layer 7 is the one that the user and the OSI application layer interface with directly while using a software program. Communication with this layer is open to any software applications that make use of a communicative component. Standard application layer duties include determining the availability of resources, locating potential communication partners, and organising communication between those partners. When finding communication partners for an application with data to communicate with, the application layer is responsible for determining their identity as well as whether they are accessible. When determining the availability of resources, the application layer is responsible for determining whether a sufficient network or the required communication is there. To get everything in sync, the application layer needs to coordinate and manage all the communication between applications. The method we have used is called the basic HTTP Flood, these attacks, which are also known as basic HTTP flooding attacks, are exactly what their name implies they are. In this case, we have made use of our IP location and assets within the same range (this kind of attack is considerably less severe than volumetric assaults) to repeatedly access the same server. In a normal situation, the server would end up crashing because it would be unable to cope with the sudden rise in the number of requests.

Fig 5.1.2: HTTP Get Flood Attack

5.2 Implementation of Attack:

As we know that, using Dos attacks or any attack is illegal but for this project purpose we are using in on our own server and using the IP address of my work internet. We have used a python scri pt which will send requests to the specific URL over and over again. In python, we have a library called sockets, when sending messages across a network, sockets and the socket APIs are used. They make possible a type of communication between different processes (IPC). The network might be a logical one that is local to the computer, or it could be one that is physically linked to a network that is external to the computer and has its own links to other networks. The libraries we will need to do a successfully http overflood attack we will need the following libraries:

Fig 5.2: HTTP Flood Attack Overload.py file

Once we are done with the installation of the libraries, we will then find the target IP-address and the port we want to attack which in this case will be 8554 that’s the port on which the real time streaming protocol server and stream is going to run. Because it is the function that launches the assault, this attack function will be the one that is carried out in each of our separate threads. It begins a loop that will never finish, and while it is operating, it will repeatedly send an HTTP request to the target, create a socket for that target, and connect to that target. All these actions are performed while the loop is active. If we are attempting to connect to a different port, it is only natural that we will also need to modify the sort of request that we send in order to do so successfully. After that we will open a terminal where our file overload.py resides and run the command python3 overload.py which will start our scri pt. As we are using Node js for our client-side streaming and to fetch data from the stream and store it in DB, during the http overflood attack we will send multiple threads and check the performance of the streaming. We can see the below screenshot where the attack is happening on the server:

Fig 5.2.1: Attack Started

The time we will have to put the duration of the attack, in threads I am going to send 500 threads in the 60 seconds and the url which is showing my ip address and the port will the base64 url of the rtsp stream. The moment attack is started we can send its starts to send the requests and payload size in the below screenshot:

Fig 5.2.2: HTTP Flood Attack Started

We can see the payload sizes in the above screen and if we look at our client side, it has started to overload the client side with large number of requests that has started to corrupt and drop the frames and latency can be seen and delay of the video stream too:

Fig 5.2.3: HTTP Flood Attack corrupted frames and latency

Fig 5.2.4: HTTP Flood Attack corrupted frames and latency

So now we can clearly confirm that the attack is happening, and the frames has started to drop.

5.3 Mitigation of the Layer 7 HTTP GET overload attack:

There are three ways to mitigate the layer 7 http overload attack and create a secure transmission between client and server-side streaming. These are implementation of captcha, using ai or machine learning for behaviour analytics, and web application firewall. During the video streaming using RTSP protocol, I have gone with the WAF, known as web application firewall.

WAF:

Utilizing a complex firewall that is purpose-built for the protection of online applications is one method for preventing unauthorised access to web applications from the outside world. An advanced WAF can manage, filter, and analyse the traffic coming from a variety of sources. The application firewalls are dependent on rules and policies that can be amended and updated in a quick and straightforward manner. It is possible that because of this, it will respond to assaults more quickly. A WAF is our best bet when it comes to protecting against DdoS assaults, particularly layer 7 attacks. This is especially true for layer 7 attacks. Managed WAFs perform an Inspection of layer 7 traffic and report any potentially malicious activity in the log file. Through the log files we may then choose to block the traffic to stop it from interfering with our services. As we know by default the rtsp streams doesn’t use any username or pass word for every RTSP stream which can also be vulnerable to attacks or when a username or pass word is inserted for a stream someone might capture the credentials and see the stream using tools such as Wireshark or fiddler therefore we have used hashing and encryption for the username and pass words and also we have use a WAF firewall from GitHub which can give us the extra security layer to protect the stream for any sort of bot attacks and overload attacks.

Chapter 6. Results and Machine Learning Algorithm

In this section I will perform the discussion of the results using machine learning algorithm and compare the results from normal stream and during the network attack stream.

6.1 Testing Results of Normal video Streaming VS During Attack:

As in the above chapters we have already discussed about how the stream works and the evaluation, during the results analysis, we started to stream a video on the RTSP server and then that was read in the client side. We streamed the video for at least 10 minutes so that we can fetch as much data as we can and then perform our machine learning algorithm to see what and how we are achieving the accuracy or performance metrics. The below figure indicates the normal stream evaluation results:

Fig6.1(A) Normal Stream test via 4g Network Fig 6.1(B) Normal Stream test via WIFI

Figure 6.1(A) indicates that during the testing with 4g network we can see that the latency was measure around 60 to 100 while the no of dropped frames and buffer size can be seen that they have been started from 25ms and going to above 100 which indicates that the rtsp server can be seen performing a little slower compared to using wife with a higher speed. The above figure 6.1(B) tells us that when using a fast internet or Wi-Fi the results can be seen normal and lag free, but only once the buffer size has been gone up where we increase the number of clients receiving the stream. In that duration the buffer size went directly from 50 to over 300 and then it started to become normal, and the delay was minimized too. So, in future if we use a 5g network the result can be greater and the stream can be streamed normally without any delays although if the clients are increased too. So, from this figure we can indicate and confirm that the RTSP stream on 4g, Wi-Fi and 5g devices will perform normally and lag free.

6.2 DDOS bandwidth flooding attacks on RTSP Server:

In this research paper “Uninterrupted Video Surveillance in the Face of an Attack” the authors have used a Blackbox approach on the standalone streaming server and client using vlc to analyse the dynamics of the network which therefore results in the exhausting of resources, such as network bandwidth, jitter, and delay. The authors (Jagannadh Vempati et all.. ,2018) has performed a Dos attack on the streaming server and then they have added a micro firewall rule that contains two parameters, rate and burst size, which regulate the operation of the streaming. These parameters are responsible for controlling the network traffic. The observed traffic volume serves as the basis for the selection of these parameters. If the traffic matches the profile that was provided, there are two different sorts of policy measures that may be carried out. They achieve this by (i) discarding the packet since it does not match the profile, and (ii) lowering the DSCP value of the packet to match one that has a lower priority. The results after implementing the firewall and during the attack stages shows that the latency and jitter and the results during when the network is under attack shows packet losses dropped frames, latency in delay in the video streaming.

Fig 6.2 Network under attack (Jagannadh Vempati et all.. ,2018)

The above figure shows that when the network is under attack, we can clearly see the effect of the attack on the server in seconds and therefore when it comes to video streaming services, its very important to have a normal video streaming quality for better user experiences. In comparison to that, when the attack was actually performed on the RTSP streaming server and we did a little different attack through using a get and post session overload attack, the quality of the video and also the effect of the user experiences in real time was affected too. We can see the results in the below charts that explains the analysis in chart form:

Fig 6.2.1 RTSP server during attack

By looking at the above chart we can confirm that the attack heavily effects the video streaming services and can result in delay jitter as well packet losses. In the paper as mentioned above the technique they used to mitigate or stop the attack and there feedback method only improves actual traffic conditions. Except for the parallel path, where there is a little latency, the network achieves a steady state in real time in all these situations. There might be a delay because of how long it takes to set up the link. Despite being a crucial QoS feature for video streaming, we did not account for RTP latency when using this method since we did not see a substantial change in the delay. We used a UDP flood to mimic a distributed denial-of-service (DDoS) assault. In our approach, the micro firewall rule monitors for certain types of traffic and, if it detects video data, it continues to do so without any delays. This approach is inappropriate for data transmission since the rate at which information is transferred may be hard to predict. Moreover, prioritising data transmission is not a good idea. By eliminating the low-profile traffic scenario, we were able to stabilise the network again, but we were unable to actively stop the attack.

6.3 Performance Evaluation using Machine Learning Algorithm:

In this research we have used certain machine learning algorithms, such as random tree, bayes, and random forest to determine the accuracy of these algorithms in to the normal and attack classes. We have used weka tool which is going to be used to perform the method best first search method on a correlation-based feature selection and we will use the precision, recall and f-measure parameters on our RTSP dataset which is divided into two main classes called normal and attack classes.

6.3.1 Experimental results for test dataset:

As I have mentioned above that I have used WEKA tool for my research which is an open-source ML scri pting software developed in JAVA by the University of Waikato New Zealand (Hall et al, 2009), the below table shows the different classes and the samples given to perform these experiments.

Classes	No of Samples
Normal	400
Attack (DOS)	400

CBFS (Using Best first Method)

Record type

Duration

Dropped Frames

Corrupted Frames

Latency

Target Latency

Table 1: Distribution for test dataset Table 2: Feature Selection of attributes

We did the experiment using the correlation-based feature selection (CFS) with best first search method in other to remove the features which are irrelevant. Our RTSP Video streaming dataset contains around 17 attributes and we have performed feature selection on the attributes using CFS, now we are left with 6 attributes which can be seen in the table 2. As mentioned above that the parameter we will target are going to be Accuracy(precision) = TP/TP+FP and detection rate or recall is considered as the number of attacks detected by the proposed algorithm and detection Rate is calculated as TP/TP+FN and F-Measure = 2*P*R/P+R. (Modi Jain, 2016). Our First detection technique was based on precision of classifiers in which we analysed j48 Random Forest, NaiveBayes algorithms to check the precision on the Normal and Attack class. The below table indicates the precision of different classifiers:

J48 %	Random Forest %	NaiveBayes%	Class
0.999	0.999	0.985	DOS(Attack)
0.979	0.984	0.993	Normal
0.989	0.9915	0.989	Weighted.Avg

Table3: Precision of classifiers

As we can see from the table 3 all the three techniques against the classes attack and normal shows that Random Forest performs the best and has the highest precision in classifying the record type attribute in the label named class. As far the detection rate (recall) of the classifiers algorithm is concerned we can confirm that j48 has the highest detection rate followed by random forest as shown in the below table:

J48 %	Random Forest %	NaiveBayes%	Class
0.994	0.997	0.999	DOS(Attack)
0.989	0.964	0.985	Normal
0.9915	0.9805	0.992	Weighted.Avg

Table4: Detection of classifiers

Now in the table no 5 we can see the F-Measure of classifiers in which we can see that the j48 outperforms the other two.

J48 %	Random Forest %	NaiveBayes%	Class
0.999	0.987	0.993	DOS(Attack)
1.000	0.964	0.992	Normal
0.999	0.9875	0.992	Weighted.Avg

So, from this we can confirm that the experiment which was done using the 3 classification techniques with the CFS for attribute selection using the BFS (Best first search) method alongside 10-fold cross validation.

Chapter 7. Conclusion and Future Work

If the defensive technologies against the rapidly growing cyber threat are not reviewed, researchers predict a catastrophic increase in the number of cyberattacks (Kotsiantis, Zaharakis Pintelas, 2007). As a result, there won`t be any place on the internet where users` sensitive information may be kept safe. To protect against several different types of attempts to breach a network`s security, this research focuses on the performance and security of the RTSP protocol, applying advanced machine learning algorithms. The accuracy of three distinct classification methods used in the RTSP dataset was compared, and the results are presented. We conducted an experiment on the performance of the multimedia communication protocol known as the Real-time Streaming Protocol (RTSP), in addition to the security of the protocol itself. A closed local network environment served as the setting for the experiment, which was carried out with the intention of determining the level of performance and security offered by an RTSP media stream. The performance of the stream was evaluated by using metrics such as latency, delay, and jitter in both the normal and DoS attack environments. After that, the dataset was logged in and exported into a CSV format to convert it into the ARFF format for further classification by making use of several different machine learning algorithms. The evaluation of the stream revealed the existence of a vulnerability in the real-time streaming protocol server. As a result, we carried out a DoS attack on the server to test its security controls. However, the attacks had a significant impact on both the latency and the server. As a result, latency increased to levels that were up to 30% higher than normal. In the end, the streaming was terminated because of the payload on the server. The research questions that were related to both performance and security were therefore solved by the fact that we need to implement standard security controls such as micro firewalls and assign encrypted usernames and pass words to the URL if we are running the stream through the IP address of the capturing devices. This was the solution to the research questions that were related to both performance and security. The implementation of the classification machine learning algorithm indicated that the results demonstrated that such an algorithm can identify an attack in the stream`s characteristics dataset. This was shown by the results of the implementation. Lastly, it was found that the detection rate, precision, and F-measure parameters of the classification algorithm were 98%, 99%, and 99%. We can conclude that j48 offers a greater degree of accuracy on the dataset that was taken based on the outcomes of the work that was done. This shows that a machine learning-based intrusion detection system can be successfully added to an RTSP server-based video stream without hurting the stream`s overall performance. For future we can test out the stream using 5g network and with that we can implement standard micro firewalls that can protect the stream It is necessary to do more research on the application of recommended security measures in order to assess the differences in the stream performance metrics values after deployment. In the future, we`ll include operations and development expenses, as well as the probability and associated costs of an attack`s impact.

References

Jagannadh Vempati, Ram Dantu, Mark Thompson, Uninterrupted Video Surveillance in the Face of an Attack. 2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Commmunications/ 12th IEEE International Conference On Big Data Science And Engineering

Abdulazeez, H. K., Khamiss, N. N., Ahmed, S. M. (2022a). OPTIMAL ADAPTATION OF INTERNET VIDEO STREAMING. In Journal of Engineering Science and Technology (Vol. 17, Issue 2).

Aloman, A., Ispas, A. I., Ciotirnae, P., Sanchez-Iborra, R., Cano, M. D. (2016). Performance Evaluation of Video Streaming Using MPEG DASH, RTSP, and RTMP in Mobile Networks. Proceedings - 2015 8th IFIP Wireless and Mobile Networking Conference, WMNC 2015, 144–151. https://doi.org/10.1109/WMNC.2015.12

Arunachalam, M., Patil, A. M., Uke, N., Lal, J. D., Sonawane, V. R., Rajagopal, R. (2022). A Real-Time 3D Video Streaming System Using SRTP AND RTSP Protocol. IJCSNS International Journal of Computer Science and Network Security, 22(6), 620. https://doi.org/10.22937/IJCSNS.2022.22.6.76

Cmpe. (2009). RTSP Protocol Focus on SECURITY 2009 Samuel MONY-Philippe SAWADOGO.

Effective IP Camera Video Surveillance With Motion Detection and Cloud Services. (n.d.). https://www.researchgate.net/publication/358749439

Hatem Mohammed, A., Kadir Mahamad, A., Saon, S. (n.d.). Evolution of Information, Communication and Computing Systems (EICCS) https A Study of Island Network Performance for Streaming Protocols.

IEEE Communications Magazine •. (2007).

Lanphier Westerlund Ericsson M Stiemerling, R. M. (2016). Real-Time Streaming Protocol Version 2.0. http://www.rfc-editor.org/info/rfc7826.

Liu, Y., Zhong, G. H., Liu, Y., He, H. Q., Wang, F. R. (2008). The research of streaming media mutual digest authentication model based on RTSP protocol. Proceedings of the 2008 International Conference on Wavelet Analysis and Pattern Recognition, ICWAPR, 2, 838–842. https://doi.org/10.1109/ICWAPR.2008.4635893

Lohan, F., Defée, I., Vlad, M. (n.d.). The Architecture of an Integrated RTSP, RTP and SDP Library.

Mutchima, P., Sanguansat, P. (2010). A novel approach for measuring video similarity without threshold and its application in sports video categorization. Proceedings - 2010 1st International Conference on Pervasive Computing, Signal Processing and Applications, PCSPA 2010, 868–872. https://doi.org/10.1109/PCSPA.2010.215

Rasanen, J., Altonen, A., Mercat, A., Vanne, J. (2021). Open-source RTP Library for End-To-End Encrypted Real-Time Video Streaming Applications. Proceedings - 23rd IEEE International Symposium on Multimedia, ISM 2021, 92–96. https://doi.org/10.1109/ISM52913.2021.00023

Santos-González, I., Rivero-García, A., Molina-Gil, J., Caballero-Gil, P. (2017). Implementation and analysis of real-time streaming protocols. Sensors (Switzerland), 17(4). https://doi.org/10.3390/s17040846

Schulzrinne, H., Rao, A., Lanphier, R. (1998). Rfc 2326 Title Real Time Streaming Protocol (RTSP) Author. https://www.hjp.at/doc/rfc/rfc2326.html

Seralathan, Y., Oh, T. T., Jadhav, S., Myers, J., Jeong, J. P., Kim, Y. H., Kim, J. N. (2018). IoT security vulnerability: A case study of a Web camera. International Conference on Advanced Communication Technology, ICACT, 2018-February, 172–177. https://doi.org/10.23919/ICACT.2018.8323686

Uitto, M., Heikkinen, A. (2021). Evaluation of live video streaming performance for low latency use cases in 5G. 2021 Joint European Conference on Networks and Communications and 6G Summit, EuCNC/6G Summit 2021, 431–436. https://doi.org/10.1109/EuCNC/6GSummit51104.2021.9482605

Uitto, M., Heikkinen, A. (2022). Evaluating 5G uplink performance in low latency video streaming. 2022 Joint European Conference on Networks and Communications 6G Summit (EuCNC/6G Summit), 393–398. https://doi.org/10.1109/EuCNC/6GSummit54941.2022.9815703

Watequlis Syaifudin, Y., Fahrur Rozi, I., Ariyanto, R., Rohadi4, E., Adhisuwignjo, S. (2018). Study of Performance of Real Time Streaming Protocol (RTSP) in Learning Systems. International Journal of Engineering Technology, 7(4.44), 216. https://doi.org/10.14419/ijet.v7i4.44.26994

Zhang, Y., Hong, Z., Lv, N. (2014). A High QS RTSP Server’s Architecture and Implementation Based On Android. http://www.ffmpeg.org/download.html,

C. Wan and C. Chen, "Research and Implementation of Low-Latency Streaming Media Transmission System," 2021 IEEE 21st International Conference on Communication Technology (ICCT), 2021, pp. 787-791, doi: 10.1109/ICCT52962.2021.9657994.

Esteve Brotons, M.J., Santiago Cabello, M.A. and García-Rodríguez, J., 2022. Live TV Streaming Latency Measurement Using YOLO. In International Work-Conference on the Interplay Between Natural and Artificial Computation (pp. 203-212). Springer, Cham.

. Shraddha, J. Rahul, S. Rishikesh, A. Poorvi, “DREAM: A Data Streaming Application Using RTP/RTSP in a Local Network”, International Journal of Engineering Science and Computing, vol. 6, issue no. 3, 2016

ZHU, S., YANG, J. and TANG, Z., 2009. Algorithm study of proxy integration method based on RTSP controlling of streaming media server. Journal of Computer Applications, 29(4), pp.1076-1078.

Fortier, P. and Michel, H., 2022. Testbed. [online] https://www.sciencedirect.com/topics/computer-science/testbed. Available at: [Accessed 24 June 2022].

Santos-González, I., Rivero-García, A., Molina-Gil, J. and Caballero-Gil, P., 2017. Implementation and Analysis of Real-Time Streaming Protocols. Sensors, 17(4), p.846.

Posey, B. (2022). What is Real Time Streaming Protocol (RTSP)? - Definition from WhatIs.com. [online] SearchVirtualDesktop. Available at: https://www.techtarget.com/searchvirtualdesktop/definition/Real-Time-Streaming-Protocol-RTSP.

Raj Kumar 2016 Available at https://docs.openrtsp.com/ [accessed 27^th July 2022]

Jazi, H.H., Gonzalez, H., Stakhanova, N. and Ghorbani, A.A. (2017). Detecting HTTP-based application layer DoS attacks on web servers in the presence of sampling. Computer Networks, 121, pp.25–36. doi:10.1016/j.comnet.2017.03.018.

A.N., Prof.Dr.B., Mehta, B., Modak, T. and Chaudhary, V. (2017). Protecting Web Servers from Distributed Denial of Service Attacks. IJARCCE, 6(3), pp.659–662. doi:10.17148/ijarcce.2017.63154.

www.wallarm.com. (n.d.). Layer 7 DDoS Attacks: ️ Methods and Ways of Mitigation. [online] Available at: https://www.wallarm.com/what/layer-7-ddos-attacks [Accessed 6 Sep. 2022].

Vempati, J., Dantu, R. Thompson, M., 2018. Uninterrupted video surveillance in the face of an attack. 2018 17th IEEE International Conference on Trust, Security And Privacy In Computing And Communications/ 12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE).

Chibuzor John Ugochukwu, E. O Bennett 2018. An Intrusion Detection System Using Machine Learning Algorithm. International Journal of Computer Science and Mathematical Theory ISSN 2545-5699 Vol. 4 No.1 2018

‌

Glossary

RTSP: Real-Time Streaming Protocol

SRTP: Secure Real-time Streaming Protocol

QoE: Quality of Experience

GDPR: General Data Protection Regulation
IEEE: Institute of electrical and electronics engineers
HTTP: Hypertext Transfer Protocol