Multiplexing scheme updates for QUIC

RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket

Real-time Audio-Visual Media Transport over QUIC

We consider the problem of how to transport low-latency, interactive, real-time traffic over QUIC. This is needed to support applications like WebRTC, but difficult to support due to the reliable, unframed, nature of QUIC streams. We review the needs of low-latency real-time applications and how they have been supported in previous protocols, then propose a minimal set of extensions to QUIC to provide such support. Compared to a raw datagram service, our extensions provide meaningful support for partially reliable and real-time flows, in a backwards compatible manner

Guidelines for using the multiplexing features of RTP to support multiple media streams

The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams

Managing Network Delay for Browser Multiplayer Games

Latency is one of the key performance elements affecting the quality of experience (QoE) in computer games. Latency in the context of games can be defined as the time between the user input and the result on the screen. In order for the QoE to be satisfactory the game needs to be able to react fast enough to player input. In networked multiplayer games, latency is composed of network delay and local delays. Some major sources of network delay are queuing delay and head-of-line (HOL) blocking delay. Network delay in the Internet can be even in the order of seconds. In this thesis we discuss what feasible networking solutions exist for browser multiplayer games. We conduct a literature study to analyze the Differentiated Services architecture, some salient Active Queue Management (AQM) algorithms (RED, PIE, CoDel and FQ-CoDel), the Explicit Congestion Notification (ECN) concept and network protocols for web browser (WebSocket, QUIC and WebRTC). RED, PIE and CoDel as single-queue implementations would be sub-optimal for providing low latency to game traffic. FQ-CoDel is a multi-queue AQM and provides flow separation that is able to prevent queue-building bulk transfers from notably hampering latency-sensitive flows. WebRTC Data-Channel seems promising for games since it can be used for sending arbitrary application data and it can avoid HOL blocking. None of the network protocols, however, provide completely satisfactory support for the transport needs of multiplayer games: WebRTC is not designed for client-server connections, QUIC is not designed for traffic patterns typical for multiplayer games and WebSocket would require parallel connections to mitigate the effects of HOL blocking

ADAPTIVE UNMANNED VEHICLE AUTOPILOTING USING WEBRTC VIDEO ANALYSIS

Εκμεταλλευόμαστε τις νέες δυνατότητες που παρέχονται από το WebRTC, υπό την έννοια της διαλειτουργικότητας και των τελευταίας γενιάς επικοινωνιών σε πραγματικό χρόνο, προκειμένου να αναπτύξουμε ένα σύστημα για το πιλοτάρισμα μη επανδρωμένων οχημάτων χρησιμοποιώντας ανάλυση βίντεο. Συγκεκριμένα, ορίζουμε μια τοπολογία όπου ένα ROS όχημα μεταδίδει βίντεο μέσω WebRTC προς έναν ενδιάμεσο εξυπηρετητή, ο οποίος με τη σειρά του το μεταβιβάζει σε έναν πελάτη. Ο εξυπηρετητής εκμεταλλεύεται τη βιβλιοθήκη OpenCV και εφαρμόζει ανάλυση βίντεο, με τέτοιο τρόπο ώστε να εξυπηρετήσει ένα επιλεγμένο από τον πελάτη σενάριο. Οι αντίστοιχες εντολές μεταδίδονται στο όχημα, με αποτέλεσμα να έχουμε ένα αυτόματα οδηγούμενο όχημα. Ο πελάτης παρακολουθεί την πορεία του οχήματος και μπορεί να αλλάξει δυναμικά το επιλεγμένο σενάριο – αυτό σημαίνει είτε να αλλάξει ελαφρώς τη λειτουργία του (π.χ. από παρακολούθηση ανθρώπων σε παρακολούθηση παιδιών) είτε να ενεργοποιήσει μια εντελώς διαφορετική φιλοσοφία λειτουργίας – στέλνοντας τα κατάλληλα αιτήματα στον εξυπηρετητή. Μόλις ο εξυπηρετητής λάβει αυτά τα αιτήματα, χρησιμοποιεί τις αντίστοιχες λειτουργίες το OpenCV για να εξυπηρετήσει το νέο σενάριο, και στέλνει τις νέες εντολές οδήγησης στο όχημα, αναγκάζοντας το σύστημα να υιοθετήσει μια νέα λειτουργία αυτόματου πιλότου. Η επικοινωνία μεταξύ του οχήματος, του εξυπηρετητή και του πελάτη εδραιώνεται μέσω των SIP/SDP και ενορχηστρώνεται μέσω ενός Web-Socket εξυπηρετητή που επιτελεί το ρόλο του Signaling Server, ενώ οι εντολές μεταφέρονται μέσω του WebRTC Data Channel πάνω από το SCTP. Περιγράφουμε και αναλύουμε το πώς όλα αυτά τα ετερογενή συστατικά (WebRTC – OpenCV – ROS) συνδυάζονται για τη δημιουργία μιας δικτυακής υποδομής, για το αυτόματο πιλοτάρισμα ROS οχημάτων σύμφωνα με ένα συγκεκριμένο σενάριο χρήσης. Τέλος, τα αποτελέσματα αποδεικνύουν την ιδέα μας, δηλαδή μια οριζόντια υποδομή που (α) αποτελείται από μια ευέλικτη/αρθρωτή αρχιτεκτονική, (β) παρέχει τα απαραίτητα στοιχεία για την μηχανή-σε-μηχανή επικοινωνία, (γ) χρησιμοποιεί τελευταίας γενιάς τεχνολογίες, (δ) επιτρέπει σε έναν προγραμματιστή να εφαρμόσει τη δική του λογική κατακόρυφα σε βάθος και (ε) παρέχει στον τομέα του IoT μια λύση που μπορεί εύκολα να αξιοποιηθεί με πολλούς τρόπους.We exploit the new features provided by WebRTC in terms of interoperability and state-of-the-art real-time communications, in order to develop a system for piloting unmanned vehicles using video analysis. Specifically, we define a topology where a ROS-based vehicle transmits its video using WebRTC to an intermediate server, who in turn relays it to a client. The server takes advantage of the OpenCV library and applies video analysis, with respect to a selected task (i.e. face detection) defined by the client. The corresponding commands are transmitted to the vehicle, resulting in an automatically driven unmanned vehicle. The client monitors the vehicle’s movement and can dynamically change the selected use case; that is, either change slightly its operation (i.e. from human tracking to children tracking) or enable an entirely new core philosophy (i.e. to fire detection) by sending the appropriate requests to the server. Upon reception of these requests, the server utilizes the corresponding OpenCV functionalities to serve the new task, and sends the new piloting commands to the vehicle, forcing the system to adopt a new autopiloting mode. This communication between the vehicle, the server and the client is established using SIP/SDP and orchestrated via a WebSocket server that serves as a Signaling Server, the media are transferred through SRTP/UDP, and the commands are carried via the WebRTC Data Channel over SCTP. We explain and describe how to combine all of these heterogeneous components (WebRTC – OpenCV – ROS), in order to compose a web-based infrastructure for autopiloting ROS-based vehicles upon a specific use case. Finally, the results prove our concept, meaning a horizontal infrastructure that (a) consists of a modular architecture, (b) provides the necessary components for machine-to-machine communication, (c) uses state-of-the-art technologies, (d) allows a developer to implement her own logic vertically, and (e) provides IoT with a solution that can be easily exploited in numerous ways

A comparative study of RTC applications

Real-Time Communication (RTC) applications have become ubiquitous and are nowadays fundamental for people to communicate with friends and relatives, as well as for enterprises to allow remote working and save travel costs. Countless competing platforms differ in the ease of use, features they implement, supported user equipment and targeted audience (consumer of business). However, there is no standard protocol or interoperability mechanism. This picture complicates the traffic management, making it hard to isolate RTC traffic for prioritization or obstruction. Moreover, undocumented operation could result in the traffic being blocked at firewalls or middleboxes. In this paper, we analyze 13 popular RTC applications, from widespread consumer apps, like Skype and Whatsapp, to business platforms dedicated to enterprises - Microsoft Teams and Webex Teams. We collect packet traces under different conditions and illustrate similarities and differences in their use of the network. We find that most applications employ the well-known RTP protocol, but we observe a few cases of different (and even undocumented) approaches. The majority of applications allow peer-to-peer communication during calls with only two participants. Six of them send redundant data for Forward Error Correction or encode the user video at different bitrates. In addition, we notice that many of them are easy to identify by looking at the destination servers or the domain names resolved via DNS. The packet traces we collected, along with the metadata we extract, are made available to the community

Designing and prototyping WebRTC and IMS integration using open source tools

WebRTC, or Web Real-time Communications, is a collection of web standards that detail the mechanisms, architectures and protocols that work together to deliver real-time multimedia services to the web browser. It represents a significant shift from the historical approach of using browser plugins, which over time, have proven cumbersome and problematic. Furthermore, it adopts various Internet standards in areas such as identity management, peer-to-peer connectivity, data exchange and media encoding, to provide a system that is truly open and interoperable. Given that WebRTC enables the delivery of multimedia content to any Internet Protocol (IP)-enabled device capable of hosting a web browser, this technology could potentially be used and deployed over millions of smartphones, tablets and personal computers worldwide. This service and device convergence remains an important goal of telecommunication network operators who seek to enable it through a converged network that is based on the IP Multimedia Subsystem (IMS). IMS is an IP-based subsystem that sits at the core of a modern telecommunication network and acts as the main routing substrate for media services and applications such as those that WebRTC realises. The combination of WebRTC and IMS represents an attractive coupling, and as such, a protracted investigation could help to answer important questions around the technical challenges that are involved in their integration, and the merits of various design alternatives that present themselves. This thesis is the result of such an investigation and culminates in the presentation of a detailed architectural model that is validated with a prototypical implementation in an open source testbed. The model is built on six requirements which emerge from an analysis of the literature, including previous interventions in IMS networks and a key technical report on design alternatives. Furthermore, this thesis argues that the client architecture requires support for web-oriented signalling, identity and call handling techniques leading to a potential for IMS networks to natively support these techniques as operator networks continue to grow and develop. The proposed model advocates the use of SIP over WebSockets for signalling and DTLS-SRTP for media to enable one-to-one communication and can be extended through additional functions resulting in a modular architecture. The model was implemented using open source tools which were assembled to create an experimental network testbed, and tests were conducted demonstrating successful cross domain communications under various conditions. The thesis has a strong focus on enabling ordinary software developers to assemble a prototypical network such as the one that was assembled and aims to enable experimentation in application use cases for integrated environments

Considerations around transport header confidentiality, network operations, and the evolution of Internet transport protocols

To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted. This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features

A network analysis on cloud gaming: Stadia, GeForce Now and PSNow

Cloud gaming is a new class of services that promises to revolutionize the videogame market. It allows the user to play a videogame with basic equipment while using a remote server for the actual execution. The multimedia content is streamed through the network from the server to the user. This service requires low latency and a large bandwidth to work properly with low response time and high-definition video. Three of the leading tech companies, (Google, Sony and NVIDIA) entered this market with their own products, and others, like Microsoft and Amazon, are planning to launch their own platforms in the near future. However, these companies released so far little information about their cloud gaming operation and how they utilize the network. In this work, we study these new cloud gaming services from the network point of view. We collect more than 200 packet traces under different application settings and network conditions for 3 cloud gaming services, namely Stadia from Google, GeForce Now from NVIDIA and PS Now from Sony. We analyze the employed protocols and the workload they impose on the network. We find that GeForce Now and Stadia use the RTP protocol to stream the multimedia content, with the latter relying on the standard WebRTC APIs. They result in bandwidth-hungry and consume up to 45 Mbit/s, depending on the network and video quality. PS Now instead uses only undocumented protocols and never exceeds 13 Mbit/s

Analysis and testing of voip-subsystems of Ip Brick

Technology in which communication done using IP(Internet Protocol) alternative for the traditional analog systems is voip (voice over internet protocol) .One of the emerging or attractive communication systems in this era is voip. Several technologies within the voip are emerging and more come to near future, services offered by this technology needs internet connections and/or telephone connections. It offers services such as making audio and video calls. VoIP is a medium that converts the analog signal to digital signals[1]. In this dissertation mainly focused on ipbrick voip-subsystems such as webrtc ,asterisk13.8 pbx server and kamilio sip proxy. These are free and open-source technologies available in the marketplace. Integration of these technologies provides real-time communication between the systems such as voice,video and text. Webrtc enables web browsers to have native support for real-time voice, video and data capabilities. As such, end-users do not require additional add-ons or plug-ins to utilize real-time voice and video communication. To allow webrtc to make calls to non-webrtc voip applications, A initiation protocol is needed and one such protocol is session initiation protocol (SIP),which is the standard protocol used for initializing, changing and terminating sessions for multimedia today. It is particularly known for its use in voip applications. Asterisk13.8pbx supports webrtc and it acts as media gateway. In this thesis, we are evaluating and comparing previous and current versions of the ipbrick voip-subsystem which is previously having lab environment of ipbrick OS v6.1 with Asterisk v1.8 as a pbx server and webrtc application such as webrtc2sip and SIP Proxy software called Kamailio which connects two endpoints. In this thesis we are testing ipbrick voip-subsystem with current version of ipbrick OS v6.2 with Asterisk v13.8 as a new pbx server and Webrtc application (SIPML5) on the browser side and a phone on the server side (softphone) establish a phone call between them. The SIP Proxy server Kamailio will act as a intermediary connection, connecting the two endpoints using websockets