Voice over IP through System in the

loopSimulation using the OPNET SITL module to analyze

QoS in a VoIP call

-Akash Puthraya-Sreenivas Ravi

AbstractSystem-in-the-loop module in OPNET allows

real systems to connect to simulations. A VoIP call is made from one real computer to another through a simulated system. The call quality, before and after simulating various load effects on the simulation, is observed.

SITL - what? why?OPNET does not restrict analysis to networks

that are completely simulated from end to end.

It allows its simulations to be part of a bigger, real, live network.

As this simulated network, and all its attributes are under the control of the user, the user is able to test and observe various conditions on a network or service.

What the module adds:SITL gateway: allows simulation to connect to a

real network through a Network adapter.

SITL virtual ethernet link: is used to connect two SITL components together and also to connect a SITL component with another.

SITL GatewaysSITL gateways are virtual gateways to the real

world.

Real world devices (our laptops) are connected to these gateways on the simulation through the ethernet cards of the machine running OPNET.

These are not real nodes.

SITL Gateways

Voice over IPThe delivery of a real time voice data stream

over an IP network, is Voice over IP. Voice is captured on the ends of communication, converted to data packets and transmitted over the IP network, rather than PSTN as in the case of normal calls.

MicroSipMost VoIP services require connection to a

central server through which authentication info and call initiation must pass through, e.g. Skype uses Microsoft servers.

This is not useful for our setup, as we need all transactions to pass through only the network in our control. MicroSip is used for this.

It is an open-source VoIP application that allows for IP-IP calls in the same subnetwork.

The SIP in MicrosipMicroSip utilizes the SIP and RTP protocols for a

Voice call.

When a user makes a call, the invite to start a data transfer session is sent as a SIP packet.

After the invite has been accepted and a session has begun, subsequent data transfers are made using RTP packets. All voice data from both ends are sent using RTP.

Hence, our SITL gateways must be defined to catch SIP and RTP packets.

SITL - The compiler needs to be run differentlySITL does not run using the <stdmod> library

repository like standard simulations. In order to have a unified runtime environment for the real and the simulated packets, SITL uses Microsoft Visual Studio by running vcvarsall.bat from the OPNET console.

SITL - The compiler needs to be run differently

Packet of reality to simulationWhen a packet of data is sent from the real setup

to the SITL gateway, it needs to be caught, filtered, and converted to a format that is used by the simulation. For this, the SITL module calls on the WinPCap. Using filter syntaxes, the exact specification of the packet that we wish to be analyzed by the simulation can be specified.

Eg: (arp or icmp) and ether src 30:85:a9:05:2c:a7

SITL- three scenariosThere are three types of scenarios in which

SITL is used:

1. Real-Sim simulations

2. Real-Real simulations

3. Real-Sim-Real simulations

Real-SimThe first step in our project was to test a Real-

Sim project. Here, we got one of our laptops to ping a simulated workstation in OPNET (SITL) using SITL virtual ethernet links.

Real-Sim

Real-Real

The next step in our project was to test a Real-Real setup. Here, we got one of our laptops to ping another laptop. This project was especially invigorating because this was Proof of Concept that SITL could make two laptops talk to each other directly.

Real-real

Real-sim-RealNow that a direct real-real setup was

established, the next step was to establish communication through a switch. The switch does not need to be configured, as its interfaces do not have IP addresses.

A switch was inserted and a VoIP connection was established.

Real-switch-real

Real-router-RealReplacing the switch with a router is the first

step at increasing the complexity of the network. Adding a router involves configuring the router to allow packets to be routed from one subnet to another.

Real-router-Real

Router configuration

The router runs RIP, and hence accepts RIP config commands. It is given static routing entries to ensure transmission of packets.

We had to add the various subnets involved to our laptops' routing tables through the route add command.

Eg.: route add <destination network> mask 255.255.255.0 <default gateway>

Router configuration

Real-sim-realThe next step in our project was to test a Real-

sim-Real project. Here, we got one of our laptops to ping another laptop through two simulated routers. The routers needed to be configured just like real world devices and we needed to add the routes of the router interfaces to our laptops' routing tables.

Real-sim-real

Real-sim-real setup without any load

Real-sim-real loaded

Real-sim-real setup with added load:ip_traffic_flow starts 1 minute after

simulation begins

Results

Terminal A to Terminal B

Delay conditions

Terminal B to Terminal A

No-Load conditions

Terminal A to Terminal B

Terminal B to Terminal A

Load conditions

1 Gbps Traffic

1 kbps Traffic

Results

Terminal A to Terminal B

Delay conditions

Terminal B to Terminal A

No-Load conditions

Terminal A to Terminal B

Terminal B to Terminal A

Load conditions

1 Gbps Traffic

1 kbps Traffic

Results

More packets destroyed with 1 Gbps load

Less packets destroyed with 1 kbps load

THANK YOU