LIST OF ABBREVIATIONS

NETML Network Modelling Language

XML Extensible Markup Language

XSLT Extensible Stylesheet Language Transformations

JSON JavaScript Object Notation

API Application Programming Interface

WebRTC Web browsers with Real-Time Communications

Abstract:

Most of the network planning tools available today use their own format to describe network data.
Since these tools use different formats, network planners have to convert network description from one
tool to another. This project aims to create a standard language (Netml) for describing networks for
network designing and analysis.

Netml was developed using eXtensible Markup Language (XML). To develop Netml an XML Schema was
developed which defines the grammer for Netml. Being an XML application eXtensible Stylesheet
Language Transformations (XSLT) can be applied to Netml networks to translate them to other formats
such as to ns2 script.

The Netml schema defines the grammar of the Netml root element and of the Nodes, Links and Traffic
Streams which are specified within the Netml root element. Also within the root element, the grammar
for an element containing display settings of the network has been specified.

The Netml Schema can be found in downloads section.

Four tools are available via the netml web site:

a traffic analysis tool, which calculates the shortest paths, routing tables for each node, and
deduces the mean and variance of traffic on each link;
an availability analysis tool;
A tool which converts netml documents to postscript documents (printable diagrams). From
these postscript documents many other types of diagram can be generated by off-the-shelf
tools; this tool requires that the netml document is saved without the xml declaration;
A tool which converts diagrams generated using dia, to netml. This tool requires that the dia
document is saved as uncompressed xml without the xml declaration at the start.
The popularity of mobile devices makes it possible to promote communication and
collaboration among different devices. In this paper, we propose a video conferencing
system with enhanced screen sharing feature. In order to make the screen sharing across
platforms, we proposed a scheme based on the WebRTC technology under the
Browser/Server framework. Both the system architecture and its components are described
in detail in the paper. Compared with the traditional screen sharing systems, this proposed
WebRTC-based scheme not only brings a cross-platform, cross-device and multifunctional
user experience, but also insures good quality even in the low bitrate communication
networks.

Introduction
Screen sharing aims at sending the compressed screen images from one computer to
another one through networks, which could support a lot of applications such as wireless
display and remote assistance. In particular, this feature plays an essential role in the video
conferencing applications for multi-party remote collaborations [1]. When developing an
end-to-end solution for interactive screen sharing, we need to make sure that the system
has high visual quality, low delay and bandwidth cost, as well as supporting various clients
[2].

References:
Kim Hazelwood, Michael D. Smith, "Generational cache management of code traces in
dynamic optimization systems", Proceedings of the 36th annual IEEE/ACM International
Symposium on Microarchitecture, 2003.

Guo Dai, Yan Jian, Wang Wenjiang, "Design and implementation of new screen sharing
system", Application Research of Computers, vol. 24, no. 6, pp. 299-301, 2007.

Yan Lu, Shipeng Li, Huifeng Shen, "Virtualized Screen: A Third Element for CloudMobile
Convergence", MultiMedia IEEE, vol. 18, no. 2, pp. 4-11, 2011.
Implementing screen sharing through WebRTC:
Last couple of years web browsers extremely extended their functions from being viewers for
web pages to all-in-one web application frameworks. Modern web browser provides local
storage, database, multi-threading, peer to peer connection and dozens of other possibilities,
that give developers a chance to bring user experience from native apps to web.

Definitely the hero of last year was WebRTC framework that provides direct data and
media stream transfer between two browsers without external server involved. Its
breakthrough for online video communication apps, since developers dont need to
support hundreds of servers that act as a bridge for user media streams. Now they only
need to exchange participants webrtc addresses and let them use p2p connection for
data transfer.

And WebRTC is production ready! We use it as one of connection channels

in Videolink2.me to provide our users with high quality video calls service in web
browsers.

But what will we see with WebRTC in 2014? Maybe screen sharing?

The current version of Chrome already supports plugin-free screen sharing. While there
are thoughts on moving that into a mandatory Chrome extension, the implementation
will probably stay the same. Why not prepare for it by implementing screen sharing?

Lets take a look at how screen sharing works and how difficult is it to implement it in a
web app.

As I mentioned above, WebRTC enables video calling between two browsers. The next
step for true collaboration is to enable screen sharing as well which is exactly what
Chromes developers decided to do.

Chrome screen sharing doesnt allow you to manipulate the shared screen, but only
view it as a video stream. And as a developer, you work with the screens stream the
same way as you work with the web camera or microphone. And use WebRTC to
transmit screen sharing the same way as usual media streams.

Interested? Lets take a closer look.

Before developing you need to enable screen sharing: open chrome://flags/#enable-
usermedia-screen-capture and enable Enable screen capture support in
getUserMedia().

To get access to user media streams we use getUserMedia function, that takes object
with description of desired stream and returns it back into callback.

Thats how it looks if you want to get user web camera with audio:

navigator.getUserMedia({audio: true, video: true}, function(stream) {

//Weve got media stream
}, function() {
//Error, no stream provided
}
)

We use the same way to get user screen but with different stream description:

navigator.getUserMedia({
audio: false,
video: {
mandatory: {
chromeMediaSource: 'screen',
maxWidth: 1280,
maxHeight: 720
},
optional: []
}
}, function(stream) {
 //We've got media stream
}, function() {
//Error, no stream provided
}
)

We asked browser to provide screen media stream with maximum size 1280720
without audio. After executing the code above, Chrome will ask our permission to share
the screen and if we agree pass our screen capture as a media stream to the
callback.

As soon as we got it we can add to WebRTC connection as any usual video stream:

navigator.getUserMedia({

audio: false,

video: {

mandatory: {

chromeMediaSource: 'screen',

maxWidth: 1280,

maxHeight: 720
 },

optional: []

}, function(stream) {

pc.addStream(stream);

}, function() {

//Error, no stream provided

So the received stream can be transmitted via WebRTC the same way as web camera
and easily played in <video> component on the other side.

One restriction that should be taken into consideration screen sharing works only
with SSL enabled (https://) domains.

To see it in action, lets make a simple example that will capture she creen and play it in
the video player.

Our html page will contain button to start screen sharing and video to show shared
screen:

<html>

<head>

<title>Screen sharing example</title>

<script src="https://code.jquery.com/jquery-1.10.1.min.js"></script>

</head>

<body>

<p align="center"><input type="button" id="share_screen" value="Share screen"/></p>

<p align="center"><video id="video"/></p>

</body>

</html>
Now we can add handler for click on share button, that will request screen media
stream (using the code above) and play it in our video element:

<script language="javascript>

navigator.getUserMedia = navigator.webkitGetUserMedia || navigator.getUserMedia;

$('#share_screen').click(function() {

navigator.getUserMedia({

audio: false,

video: {

mandatory: {

chromeMediaSource: 'screen',

maxWidth: 1280,

maxHeight: 720

},

optional: []

}, function(stream) {

document.getElementById(video).src = window.URL.createObjectURL(stream);

$('#share_screen').hide();

}, function() {

alert('Error, my friend. Screen stream is not available. Try in latest Chrome with Screen sharing
enabled in about:flags.');

})

</script>

So instead of adding a stream to peer connection, were setting it as video surce.

AndThats it! Heres a page that weve made:

<html>

<head>

<title>Screen sharing example</title>

<script src="https://code.jquery.com/jquery-1.10.1.min.js "></script>

</head>

<body>

<p align="center"><input type="button" id="share_screen" value="Share screen"/></p>

<p align="center"><video id="video" autoplay/></p>

<script language="javascript">

navigator.getUserMedia = navigator.webkitGetUserMedia || navigator.getUserMedia;

$('#share_screen').click(function() {

navigator.getUserMedia({

audio: false,

video: {

mandatory: {

chromeMediaSource: 'screen',

maxWidth: 1280,

maxHeight: 720

},

optional: []

}, function(stream) {

document.getElementById('video').src = window.URL.createObjectURL(stream);;

$('#share_screen').hide();

}, function() {

alert('Error, my friend. Screen stream is not available. Try in latest Chrome with Screen
sharing enabled in about:flags.');

)
 })

</script>

</body>

</html>

When the user clicks on the Share screen button, click handler will request media
stream and display it in video player if the permission is granted.

WebRTC architecture

Servers and Protocols

Peer to peer

Abstract Signaling
Need to exchange 'session description' objects:
- What formats I support, what I want to send
- Network information for peer-to-peer setup
Can use any messaging mechanism
Can use any messaging protocol

Signaling diagram

STUN and TURN

P2P in the age of firewalls and NATs
STUN
Tell me what my public IP address is
Simple server, cheap to run
Data flows peer-to-peer

TURN
Provide a cloud fallback if peer-to-peer communication fails
Data is sent through server, uses server bandwidth
 Ensures the call works in almost all environments

Security throughout WebRTC

 Mandatory encryption for media and data
Secure UI, explicit opt-in
Sandboxed, no plugins
Secure pathways