![](bg2.png)
and NAT (TURN). Both these Interactive Connectiv-
ity Establishment (ICE) techniques, namely STUN
and TURN, make communication possible when the
communicating endpoints are behind a firewall.
The motivation for this work is that applica-
tion developers will soon begin to create innovative
WebRTC-supported applications with little or no con-
sideration on the total cost of usage of their applica-
tions. An application with a high signalling overhead
would incur more cost with poorer quality of experi-
ence for users having low Internet bandwidth and pay-
ing high cost for Internet access. This work examined
the additional signalling overhead introduced by We-
bRTC applications. The contribution of this research
is therefore the development of a three-user WebRTC
video chat application with a report on the signalling
overheads introduced by the two common methods of
doing WebRTC.
The remainder of this paper is arranged as fol-
lows: Section II discusses the common methods of
doing WebRTC within compliant Web browsers and
the current ways of implementing video streaming us-
ing WebSocket. Section III presents the three-user
WebRTC vide chat prototype which was used to eval-
uate the resultant signalling overhead. Section IV
then presents and discusses the resultant signalling
overhead of the two commond methods of doing We-
bRTC. In Section V the paper is concluded.
2 WEB REAL-TIME
COMMUNICATION (WebRTC)
METHODS AND ISSUES
The two prominient ways of doing WebRTC are
using pure SIP via websocket (WebRTC-SIP/WS)
and JavaScript Object Notation via XMLHttpRe-
quest (WebRTC-JSON/XHR). While the former uses
a WebRTC-SIP proxy/gateway as its application en-
gine and SIP over websocket for signalling, the latter
uses a custom engine (e.g. the Google App. Engine)
as its application engine and JSON over XHR for sig-
nalling. For the Google App. Engine, the JSON/XHR
signalling is done via its Channel API. However, both
approaches are based on JSEP, which mimics the SIP
Offer and Answer signalling.
There are however other implementations devel-
oped to meet specific requirements. An example is
the Ericsson WebRTC implementation (Ericsson We-
bRTC, 2012), which uses ROAR. In this example,
some changes were made to the webkit libraries in
the Epiphany web browser in order to support We-
bRTC. There are other kinds of implementation in the
form of an extension to a browser. An example is
the IEWebRTC extension (which uses ChromeFrame)
for Internet Explorer (webrtcie ext, 2012). As web
browsers are being extended, the number of WebRTC
applications and frameworks, such as SIPML5 (which
uses SIP over websocket) (sipml5, 2012) and SIP-
JS (with support for Flash-network) (SIP-JS, 2012),
are rapidly increasing. At the time of this research,
Google Chrome is taking the lead in the WebRTC im-
plementation. Mozilla Firefox is yet to have a version
that has the PeerConnection or getUserMedia API. A
SIP stack (called SIPCC) is now being integrated into
it (Ikran - FF as SIP endpoint, 2012). Hence, it does
not currently support WebRTC. Other browser mak-
ers, such as Microsoft and Opera, are also contribut-
ing to the WebRTC standadization.
Figure 1 shows the signalling between two UAs
(User Agents) or devices; the sequence of events
starts from top to bottom. Some of the processes (such
as PeerConnectionFactory, ProcessSignalingMessage
and OnSignalingMessage) are peculiar to Google
Chrome, which uses the libjingle. A caller first cre-
ates a new peerconnection and adds stream using the
PeerConnection API as shown in Figure 1. In ad-
dition, a local session description (for audio and/or
video) is applied. ICE is then started in order to get
available IP (Internet Protocol) address and port num-
ber for media transfer (these additional processes are
not shown for simplicity). A peerconnection and re-
mote session description (for the callee) are later cre-
ated. When a callback at the callee’s notifies that a
stream is added (via a channel), an offer is created.
It is sent and processed by the caller. An answer is
then sent back and a local session description (for the
callee) is created. The answer, which contains the re-
mote session description and some hints, is sent to the
callee. A local session description (for audio or/and
video) is then set and applied in the callee’s browser.
Lastly, ICE is also started in order to get available IP
(Internet Protocol) address and port number for media
transfer. The caller later applies the remote session
description in order to present video/audio from the
callee. Encryption of WebRTC media in Google Ap-
pEng is achieved by sending the UDP (User Datagram
Protocol) data via SCTP (Stream Control Transmis-
sion Protocol) and DTLS (Datagram Transport Layer
Security).
On the other hand, there are still NAT and fire-
wall issues in the WebRTC. In addition, SBCs (Ses-
sion Border Controllers) could be required to handle
connections between two or more domains. ICE tech-
niques (STUN and TURN) are likely to increase du-
ration to set-up a call. Security of media and per-
missions are also hot issues in the WebRTC, though
WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies
120