See discussions, stats, and author profiles for this publication at: [Link]

net/publication/300727546

Performance analysis of the Janus WebRTC gateway

Conference Paper · April 2015

DOI: 10.1145/2749215.2749223

CITATIONS READS
20 12,231

4 authors, including:

Lorenzo Miniero Simon Pietro Romano

University of Naples Federico II University of Naples Federico II
26 PUBLICATIONS   127 CITATIONS    158 PUBLICATIONS   962 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

OT Cyber Security Frameworks Comparison Tool (CSFCTool) View project

VIBES - IMPLEMENTATION OF VIRTUALISED NETWORK FUNCTIONS (VNFS) FOR BROADBAND SATELLITE NETWORKS View project

All content following this page was uploaded by Simon Pietro Romano on 23 November 2016.

The user has requested enhancement of the downloaded file.

 Jattack: a WebRTC load testing tool
A. Amirante∗ , T. Castaldi∗ , L. Miniero∗ , S. P. Romano†∗
∗ Meetecho S.r.l., Via C. Poerio 89/a, 80121 Napoli, Italy
{alex, lorenzo, tobia}@[Link]
† University of Napoli Federico II, Computer Science Department, Via Claudio 21, 80125 Napoli, Italy

spromano@[Link]

Abstract—We present Jattack, an automated stressing tool for We hence decided to work on a suitable load generator
the analysis of the performance of WebRTC-enabled server-side which might be leveraged in a programmatic fashion in order
components. Jattack has been initially conceived with the primary to rapidly prototype customized testing scenarios involving a
objective of performing a thorough scalability analysis of the
well-known Janus WebRTC gateway. As such, it re-uses most of significant number of WebRTC client instances capable to re-
the Janus core stack components in order to reliably emulate the produce the typical behavioral profile of the users of a specific
behavior of a dynamically adjustable number of WebRTC clients. Janus-enabled framework. The idea was to become able to
The specific testing scenario can indeed be programmatically keep the load on the client-side as low as possible, hence
reproduced by writing a small “controller” component, which moving the bottleneck to the server-side of the integrated
takes on the responsibility of properly orchestrating the scenario
itself. The general-purpose nature of the tool, together with system and allowing us to easily assess the scalability of the
its flexibility deriving from the controller-based programmable Janus servers residing in the backend.
approach, makes Jattack also suitable for stress-testing other The tool we devised has been conceived at the outset as
WebRTC-enabled servers. a general purpose one. As it will be explained in the next
sections of the paper, it is made of two main components: (i)
I. I NTRODUCTION a core implementing the fundamental WebRTC functionality
and related stack; (ii) a programmable controller allowing to
The motivation behind this paper stems from the concrete easily build and drive a specific testing scenario. The adoption
need for a flexible, lightweight and reliable testing tool for of the principle of separation of concerns, with special regard
the assessment of the scalability of WebRTC-enabled servers. to the availability of the programmable orchestrating part,
These components definitely represent strategic assets of a indeed allows to use our stress-testing tool for the assessment
number of Web-based real-time multimedia systems that are of server-side WebRTC components other than Janus.
starting to be used at very large scales. The authors of this
paper are the developers of the JanusTM WebRTC gateway [1], II. R ELATED W ORK
a well-known open source component that is currently lever- The automated testing of WebRTC applications and services
aged by a number of small and medium size enterprises having definitely represents a challenging issue. Being able to design
in common the need for WebRTC-enabled interaction among and execute a stress test campaign can be of paramount
their clients, as well as interoperability with “legacy” real-time importance when evaluating a new service, a new WebRTC
communication frameworks based, e.g., on SIP (Session Ini- endpoint or any kind of WebRTC component. Stress testing,
tiation Protocol) [2]. Just to cite a very well-known example, in fact, allows to assess the scalability and the performance of
SlackTM is currently using Janus for the implementation of the the target. Lately, there have been several efforts devoted to
audio call functionality of their application [3]. this area of research.
Given the increasing level of deployment of Janus as a The most popular means for testing WebRTC applications
key backend component of the aforementioned systems, the in an automated fashion is by using the well known Selenium
need has arisen to properly assess its scalability properties Framework [4], which allows for a complete simulation of a
in a reliable way. When we started to tackle such an issue, browser’s behavior. This framework, in fact, allows developers
we had to confront ourselves with a number of challenges, to remotely control and drive browser instances through soft-
especially when trying to automatically generate a suitable ware modules called “webdrivers”. A controller application,
stress testing load capable to properly mimic the behavior of then, can be written by leveraging different language bindings
real-world WebRTC clients. Indeed, more often than not we (e.g., Java or Python) to decide things like which page to
found ourselves struggling with the issue of properly scaling open, what user input to simulate, and so on. As such, it is
the client-side of the integrated WebRTC system under test usually fairly easy to deploy headless instances of browsers
before being capable of arriving at a load which might be (e.g., Chrome, Firefox) on dedicated servers and have them
deemed suitable in order to assess the scalability of even a open and “navigate” properly crafted web pages that allow
single Janus instance. The testing campaigns, most of the times for a partial, if not full, automation of a user’s interaction.
deployed in the cloud, took us a lot of effort, in terms of both When these interactions involve the creation of WebRTC
platform configuration and cost. PeerConnections, this allows for the automated creation of
multiple WebRTC resources that can be used for the purpose. used, for instance, as a stress testing tool to interact with
The advantage of this solution is that it allows users to re- different applications, possibly based on different backends.
use most of the resources already available when designing Finally, there are some commercial solutions for testing
a test campaign: in fact, most of the times you can run WebRTC services [12], [13]; unfortunately, to the best of our
tests on the very same pages that would actually be accessed knowledge, there is no public documentation on the tools they
by users themselves, taking advantage of the scripting and leverage to do performance evaluation.
programmable features of both JavaScript and the language These were the considerations that eventually led us to
used in the controlling application. We ourselves have used this work on such a tool ourselves. While the main aim was, at
approach repeatedly in our tests, and have shared our results first, an efficient tool we could use to test Janus instances
in a recently published paper [5]. The same approach has been while managing resources more efficiently, we soon found out
adopted in [6], where the authors evaluated the performance of that it could actually be generalized, and used to assess the
Kurento Media Server [7] in various scenarios. To the best of performance of any WebRTC application, provided that the
our knowledge, Selenium is also the foundation of a popular test campaign is designed properly.
WebRTC testing service as well, TestRTC [8]. That said,
while easy and effective, this approach is nonetheless quite III. A GENERAL - PURPOSE LOAD TESTING TOOL
demanding in terms of resources. In fact, this requires actual
Jattack (which stands for “Janus Attack”, or the French
browser instances to be deployed on server machines that can
“J’attaque”) is a tool we conceived to quickly generate mul-
be used for the testing. Since browsers are typically not very
tiple WebRTC connections, for the purpose of stress testing
lightweight applications, and given the fact that there is a lot
WebRTC applications. We took the Janus WebRTC Gateway’s
of overhead in terms of what such browser instances actually
open source core and slightly modified it for the purpose. As
do when opening a target web page, the number of concurrent
such, it is mainly composed of the same WebRTC stack of
PeerConnections that can be established and maintained on a
Janus, with a few differences.
single machine is limited. This makes it hard to effectively
Jattack is supposed to be a generic WebRTC stressing client
assess the scalability of a component without an adequate
tool, thus it is not strictly limited to Janus itself. Given its
number of client machines available for testing.
programmable nature, with a few customizations it can be
For this reason, when either the availability of resources
easily fit to interact with different server-side components.
is constrained or there is a need for more efficiency, it is
By itself, Jattack does no signaling at all: it only works
in general advisable to rely on some kind of application
when used with a controller that handles that part for it, and
that allows for a better management of resources (e.g., to
which orchestrates its actions. This means that, in general,
only implement the WebRTC communication), while leaving
users will have their own application talking to Janus (or their
the rest of the interactions (e.g., authentication, signaling,
Janus-based service) and handling the signaling (JSEP [14],
automated input, and so on) to other tools. Unfortunately, just
SDP [15], trickle ICE candidates [16]), and then bridging this
a few tools can satisfy this requirement. In fact, most of the
info between Janus and Jattack. This allows for the realization
available automated web tools are specifically targeted at stress
of heterogeneous scenarios: for instance, the controller can or-
testing the web-based behavior of an application, e.g., in terms
chestrate the creation of multiple PeerConnections of different
of HTTP and/or WebSocket [9] requests.
types to simulate real scenarios (e.g., a multi-party conference,
One notable exception is Jitsi Hammer[10], a tool devised
or a large webinar). Multiple Jattack instances can be used by
and implemented by Jitsi as a traffic generator for their
the same controller for larger scale scenarios. Furthermore,
Videobridge application. This tool is a Java application that
multiple PeerConnections can share the same media source in
can be configured to connect to a Jitsi-Meet conference, create
Jattack, thus allowing for a very lightweight setup of active
fake users, and generate/receive RTP traffic on behalf of the
sources. It is worth noting that, with this approach, Jattack is
simulated users within the room [11]. This is a very good
completely relieved of any encoding/decoding burden, which
example of how resources can be better managed for the
is known to be the most resource-intensive task a WebRTC
purpose of assessing the performance of a component. In
client has to perform.
fact, while it is true that the same results might be achieved
The Jattack architecture is depicted in Fig. 1.
through the Selenium Framework (e.g., by having multiple
browser instances all access the same web page and provide
IV. C ONTROLLER : THE BRAIN
credentials in an automated way to join a meeting room), it is
fairly obvious that a dedicated application allows for a much Jattack uses WebSockets to connect to the controller, receive
more optimized management of resources. In this case, the Jitsi commands, and send responses/events. This means that a
Hammer tool takes care of the interaction with the backend on wannabe controller needs to implement the server-side of the
its own and, through configurable parameters, can be instructed jattack-protocol we conceived.
to behave in different ways, all using less resources than a full While we will not delve into the details of the protocol
browser would require. While a very effective tool, though, itself for the sake of brevity, it may be worth summarizing
to the best of our knowledge Jitsi Hammer is specifically its syntax, with special regard to the inner workings of the
tailored to the Jitsi Videobridge, which means it cannot be request/response mechanism, as well as to how asynchronous
 Streaming and VideoRoom plugins for this paper, as they
are the most commonly used by developers for their Janus-
based applications. As to the controller implementation, we
chose [Link] as the runtime environment, and talked to Janus
through its WebSocket transport module.
V. JATTACK : THE ARM
The actions to undertake in order to create and manage a
Jattack-based testing campaign are briefly listed below:
1) Jattack connects to, and registers at, the controller;
2) the controller properly handles Jattack’s registration re-
quest;
3) one or more media sources are created, if needed (more
on that later);
4) as many sessions as needed get created in a dynamic
fashion (each session will be associated with a Peer-
Connection);
Fig. 1: Jattack architecture 5) one or more Janus instances get contacted and instructed
to create as many PeerConnections as needed with the
available Jattack instances;
notifications can be delivered within the context of an exist-
6) if Jattack instances need to generate media, a media
ing session. Jattack commands (requests) have the following
source is attached to them;
syntax:
7) optionally, Jattack instances can be instructed to record
{
jattack: ’<command>’, // Command name, mandatory the incoming frames (not mandatory, you can receive
transaction: ’<unique ID>’, // Transaction ID, mandatory
id: <session ID>, // Media session ID, optional without recording).
body: { // Command specific payload, optional

}
[..] The following subsections dig further into the details of the
} above mentioned procedures.
A command, when handled, always results in a response A. Registration
from Jattack to the controller. Responses are formatted like
Upon connection, Jattack sends a register message to
this:
the controller. This is the only time that Jattack sends an active
{
jattack: ’success|error’, // Command result command. In general it will always just receive commands,
transaction: ’<unique ID>’, // Transaction ID, same as request
id: <session ID>, // Media session ID, optional while sending back responses and/or events.
body: { // Command specific response, optional
[..]
} B. Commands
}
Jattack can receive the following commands:
As anticipated, though, not all the communication between
• add-media-source: add a new source for active
Jattack and a controller is synchronous. Commands sent to
RTP sessions (e.g., an external GStreamer/FFmpeg script
Jattack can subsequently result in asynchronous events gener-
sending media); such a source can be shared across
ated by the tool (e.g., to notify new candidates or ICE state
multiple sessions at the same time; without a source, a
changes). Events are formatted like this:
Jattack session is receive-only;
{
jattack: ’<event>’, // Event name • remove-media-source: destroy an existing media
id: <session ID>, // Media session ID, optional
body: { // Event specific payload, optional source;
[..]
} • create-session: create a new media session; this is
}
basically the same as a session+handle in Janus, meaning
We notice that events do not have a “transaction” field, that a session is associated with a single PeerConnection;
as they are, again, asynchronous, and hence never explicitly • destroy-session: destroy an existing media session
related to any command. These events can be quite helpful (destroys PeerConnection too, if it existed);
to track the “life” of a PeerConnection, and at the same time • generate-offer: have Jattack generate an offer in a
collect statistics that can provide valuable information. session to create a new PeerConnection;
For the testing campaign we conducted, we wrote differ- • generate-answer: have Jattack generate an answer
ent controller logics, all implementing, on the Jattack side, in a session to create a new PeerConnection;
the above mentioned protocol. Such controller logics han- • handle-offer: pass a remote offer to Jattack in a
dled signaling toward different Janus plugins, e.g., the Janus session to create a new PeerConnection;
Streaming, AudioBridge, VideoRoom and EchoTest plugins. • handle-answer: pass a remote answer to Jattack in a
For the sake of simplicity, we chose to focus on the Janus session to create a new PeerConnection;
 • hangup: hangup an existing PeerConnection; must forward those trickle candidates to the peer, or the
• get-state: get the internals of an existing session WebRTC connectivity will most likely fail.
(very similar to Janus admin API info). A PeerConnection stays alive until we destroy the session
A media source, in Jattack, is whatever can be used to or simply hangup. Destroying the session means we would
have Jattack actively generate RTP data. Jattack does not have to create a new one if we wanted to create a new
capture/generate media by itself, meaning it does not access PeerConnection, while only hanging it up allows us to re-use
your microphone, your webcam, a file or anything like that. the existing session for a new PeerConnection. Tearing down
The only way to have a Jattack PeerConnection send media a PeerConnection results in events sent to the controller.
is by creating a media source and attaching it to the session. In order to check the internal state of a Jattack session,
A media source listens on a couple of ports, and everything including the state of the associated WebRTC PeerConnection,
it receives on them (normally valid RTP) is sent over the we introduced an ad-hoc request called get-state, which
session’s PeerConnection by Jattack. Sending media to such acts like the Janus admin API and returns similar info.
ports can be achieved through external tools like GStreamer or
FFmpeg. As already anticipated, multiple sessions can share C. Events
the same media source in Jattack, which is completely relieved
Jattack can generate several different events towards the
of any encoding/decoding task.
A Jattack session is the main purpose of Jattack itself. This controller at any time. These include events related to any
is where a media session is created, that is something that will change in the state of the PeerConnection, the health of the
be strictly associated with a PeerConnection in Jattack itself. media session, etc.. No action is needed from the controller
In Janus terms, it can be seen as a condensed session+handle, when an event is received: it just needs to be prepared to
i.e., a session that only contains a single handle. receive and optionally handle them.
When a session is created, there is no PeerConnection yet. The events Jattack can generate are the following:
A PeerConnection becomes only available after a successful • source-done: a previously created source is over;
WebRTC negotiation. This involves SDP offers and answers, • trickle: Jattack gathered a new candidate in a session
trickle ICE candidates, ICE connectivity checks, DTLS hand- (the controller must forward it);
shakes, and so on. • ice-state: the ICE state of a Jattack session PeerCon-
In order to create a PeerConnection in Jattack, and more nection changed;
specifically within a specific session that has been created, • selected-pair: an ICE pair was selected in a Jattack
we need to first decide who will send the offer and who session PeerConnection;
will instead provide the answer. This typically depends on the • webrtcup: a PeerConnection in Jattack has just become
scenario we want to achieve and, in case Janus is involved, on active;
the plugin that will be used for the purpose. To use either • media: Jattack started/stopped receiving media from the
the Janus EchoTest, or the AudioBridge or even to create peer;
a VideoRoom publisher, for instance, the client is supposed • recording: a Jattack recording state changed
to send the offer and the target plugin module on the Janus (started/completed);
side to answer back. To create a VideoRoom subscriber or a • hangup: a PeerConnection in Jattack was just closed;
Streaming viewer, instead, the offer always has to come from • destroyed: a Jattack session was just destroyed.
the Janus plugin, and the client has to answer back. For this All these events can be very helpful to follow the evolution
reason, when Jattack acts as the offerer, a generate-offer of an existing PeerConnection, and controllers may choose to
command is always followed by a handle-answer; when save/store them in a structured way for offline evaluations.
the peer is the offerer, instead, a handle-offer is followed
by a generate-answer. In both cases, the result is an VI. J’ ATTAQUE ! A CAMPAIGN AGAINST THE JANUS
attempted setup of a PeerConnection. This means that Jattack W EB RTC G ATEWAY
starts gathering and trickling ICE candidates, tries to send
connectivity checks when it has enough information, starts a In this section we show the results of the testing campaign
DTLS handshake when ICE is done and exchanges RTP/RTCP we conducted against Janus. Our objective was to assess the
packets when WebRTC is ready. During the negotiation pro- performance of both Janus and Jattack itself. The primary pa-
cess, handle-offer, handle-answer, and responses to rameters we took into account are the CPU and memory loads
generate-offer and generate-answer have to carry on both ends. We also leveraged the information provided by
an SDP body. As anticipated, this negotiation process starts Jattack’s get-state command in order to roughly estimate
a chain of activities and events that eventually lead to the the quality perceived by the simulated users, more specifi-
setup of a WebRTC PeerConnection. All these activities will cally by analyzing the number of negative acknowledgments
be notified to the controller via events so that the controller can (NACKs) sent/received on each PeerConnection. NACKs, in
use them as appropriate. A notable example of an important fact, are used to inform a sender of the loss of particular RTP
event to handle is trickle, as it is the event used to report packets, and thus represent a quality indicator of the media
ICE candidates Jattack has gathered for itself: the controller streams flowing across a PeerConnection.
A. The testbed
The testbed we set up uses Docker containers [17] in
order to isolate the single functions described in the previous
sections. Namely, we made use of docker-compose to
build a microservices-oriented architecture. The testbed was
deployed on a machine equipped with 8 Intel Core i7-4770S
CPUs @ 3.10GHz and 16 GB of RAM. All containers
are based upon the Ubuntu 16.04 OS. We also leveraged
the Docker’s cpuset option to dedicate different CPUs to
different containers, so that the performance statistics of Janus
were not impacted by Jattack, and vice-versa. Specifically, we
assigned 4 cores to Janus, 3 cores to Jattack and 1 core to the
controller.
We note that Janus, Jattack and the controller all ran on the
same physical host, so all network communication happened
in localhost. We did this on purpose, as we did not want Fig. 2: VideoRoom CPU with 10 publishers and 90 viewers.
network performance and congestion to affect the results of our
analysis. Our aim was twofold: (i) evaluate the performance
of the Jattack tool itself; (ii) spot any performance issue that
strictly depends on the Janus source code, which can then be
fixed/optimized.
B. Stressing the VideoRoom plugin
Fig. 2 shows the CPU evolution of both Janus and Jattack
in the presence of 10 publishers and 90 subscribers. In this
experiment we had Jattack generate clients with a frequency
of 10 per second, starting with the publishers and then al-
locating viewers. As the VideoRoom plugin implements the
Selective Forwarding Unit (SFU) logic, we had a total number
of 1000 PeerConnnections maintained by Janus and Jattack;
furthermore, as each client has to establish 10 PeerConnections
when it connects to Janus, we were approximatively generating
one PeerConnection per second. We observe the CPU levels
are very similar to each other, as we expected since Jattack Fig. 3: VideoRoom RAM with 10 publishers and 90 viewers.
has been built upon the Janus core. Such a scenario took up
to 200% of CPU on the Janus’ side, and slightly more on
the Jattack’s side. We recall that Janus was running on four
dedicated cores, while Jattack on three. Hence, Janus could
take up to a value of 400% and Jattack up to 300%.
Fig. 3 shows the memory load, which proved to be very
low in both cases.
Fig. 4 depicts the CPU load when there was only one
publisher and 1000 viewers, i.e., 1000 PeerConnections main-
tained by Janus and Jattack. It is very similar to the one
attained in the scenario envisaging 10 publishers and 90
viewers, as the overall number of PeerConnections is the same.
During the campaign described above, we periodically
issued get-state requests to Jattack in order to retrieve
information about the health state of each PeerConnection.
Fig. 5 shows a client’s perspective with respect to negative ac-
knowledgments (NACKs) sent. We notice that no NACKs were
sent/received until the overall number of PeerConnections
approached 800. Then, NACKs started flowing, indicating a
degradation of the quality perceived by the simulated users. Fig. 4: VideoRoom CPU with 1 publisher and 1000 viewers.
One of the possible causes might be the inability for the
media router to enqueue, on that specific instance, 800 packets
 Jattack, instead, and it was not even the maximum number of
sessions it could create on the server we hosted it on. This
whole order of magnitude can prove extremely helpful when
it is time to scale up the number of tests and start simulating
hundreds of thousands of users, as in this case you can leverage
multiple Jattack instances, each of which can support a very
high number of sessions.
That said, there is room for improvement. In fact, as
anticipated, we currently only tested Jattack to test the Janus
server. Considering they share most of the same code-base in
terms of WebRTC stack, it might be actually more interesting
to start using it in different contexts as well. This includes
Fig. 5: Number of NACKs sent over a PeerConnection
using it both in purely peer-to-peer scenarios (i.e., to browsers
directly) and to interact with third-party components, as a tool
for delivery to different recipients in the short time between to help assess the performance of those as well.
two packets. Another possible cause might be ascribed to the Another interesting use case for Jattack is actually not
significant number of CPU context switches: at the time of this related to stress testing, but to WebRTC clients implementation
writing, in fact, Janus spawns a dedicated thread to transmit in general. In fact, the configurable nature of Jattack and the
packets to each receiver. We have already started investigating fact that it can relay plain RTP media via WebRTC on behalf
solutions to this problem. One possible approach, which we are of a programmable controller means it can also be used as a
working on in a development branch of Janus, is to delegate simple, while effective, client-side WebRTC gateway.
the one-to-many routing job within the Janus plugin to helper R EFERENCES
threads, which can then alleviate the burden a single thread
[1] A. Amirante, T. Castaldi, L. Miniero and S.P. Romano, Janus, a general
has to bear right now. An alternative approach might be to purpose WebRTC gateway, Proceedings of the Conference on Principles,
leverage a pool of sender threads handling multiple recipients Systems and Applications of IP Telecommunications, IPTComm ’14,
each. 2014
[2] J. Rosenberg, H. Schulzrinne, G. Camarillo et al. SIP: Session Initiation
Protocol. RFC 3261, RFC Editor, June 2002. URL [Link]
C. Stressing the Streaming plugin html/rfc3261.
When we addressed our testing campaign towards the [3] Faraz Khan, Calls: Is it you or is it me?. URL [Link]
calls-is-it-you-or-is-it-me-f5d36749e8ed.
Streaming plugin, we obtained the very same results discussed [4] SeleniumHQ web site, [Link]
in the previous subsection about the VideoRoom plugin when [5] A. Amirante, T. Castaldi, L. Miniero and S.P. Romano, Performance
a single publisher was envisaged. So, we do not present any Analysis of the Janus WebRTC Gateway, Proceedings of the 1st Workshop
on All-Web Real-Time Systems, AWeS ’15, 2015
new chart regarding these specific experiments. [6] C. C. Spoiala, A. Calinciuc, C. O. Turcu and C. Filote, Performance
comparison of a WebRTC server on Docker versus virtual machine,
VII. C ONSIDERATIONS AND F UTURE W ORK 2016 International Conference on Development and Application Systems
We introduced a general-purpose WebRTC stressing tool (DAS), Suceava, Romania, 2016, pp. 295-298.
[7] Kurento Media Server web site, [Link]
called Jattack. We explained the motivations that led us to [8] TestRTC web site, [Link]
design and implement such a tool, and also described some [9] Alexey Melnikov and Ian Fette, The WebSocket Protocol, RFC 6455,
sample test campaigns, aimed at assessing the performance RFC Editor, Oct. 2015. URL [Link]
[10] Jitsi Hammer project page, [Link]
of our Janus WebRTC server. In this context, we focused our [11] Grozev, Boris and Marinov, Lyubomir and Singh, Varun and Ivov, Emil,
attention on both the performance of the target (Janus) and the Last N: Relevance-based Selectivity for Forwarding Video in Multimedia
stressing tool (Jattack), in order to evaluate the effectiveness Conferences, Proceedings of the 25th ACM Workshop on Network and
Operating Systems Support for Digital Audio and Video, NOSSDAV ’15,
of Jattack as a tool for performance assessment purposes. 2015.
We were delighted to find out that Jattack behaved exactly [12] Valid8 WebRTC load tester web site, [Link] Load
as we hoped it would, and that it was actually able to [Link]
[13] Load Multiplier web site, [Link]
simulate the activities of multiple (both passive and active) [14] Justin Uberti and Cullen Jennings and Eric Rescorla, Javascript Session
WebRTC sessions. The greatest result was probably in terms Establishment Protocol, draft-ietf-rtcweb-jsep-15, July 2016 (work in
of resources needed on the client side to implement the test progress). URL [Link]
[15] J. Rosenberg and H. Schulzrinne. An Offer/Answer Model with the
campaign. While implementing a Jattack controller required Session Description Protocol (SDP). RFC 3264, RFC Editor, June 2002.
some more complexity in terms of managing signaling and URL [Link]
out-of-band communication with the target, when compared [16] E. Ivov, E. Rescorla,J. Uberti, P. Saint-Andre. Trickle ICE: Incremental
Provisioning of Candidates for the Interactive Connectivity Establishment
to implementing a Selenium controller (where, as anticipated, (ICE) Protocol draft-ietf-ice-trickle-03, July 2016 (work in progress).
you typically can re-use existing web pages and JavaScript URL [Link]
code), in order to set up 1000 PeerConnections we needed [17] Docker web site, [Link]
more than 10 servers when using Selenium. We only needed
a single one to setup the same number of PeerConnections on

View publication stats