Transcript Presentation

VoIP on a Wireless LAN
Orly Goren
Tomer Shiran
Lior Nir
The Topology




One server – Presence Server
Many clients – Voice Clients
Clients can connect via wireless
or wired LAN.
The server has the basic
functionality of a SIP server – it
provides location and presence
services to the clients.
Presence Server
Voice Client
Voice Conference
Voice Client
Voice Client
Communication Channels

There are two main communication channels:



Client-client communication
Client-server communication
There is no server-client communication.
Client-client communication
Client-server communication
Client-Client Communication


The voice conferences are managed in a P2P
architecture – the server is not involved.
TCP


An inviter sends an InviteToConference message to all
the invitees.
UDP – via Microsoft DirectPlay



The voice datagrams are sent via UDP.
DirectPlay provides an asynchronous callback API.
The client application must implement various event
handlers that handle network events as they occur.
Client-Client Comm. – TCP


A proprietary XML protocol is used over TCP.
The only client-client message is InviteToConference:
<command type="InviteToConference">
<user name="Ori"/>
<ipAddress>157.68.9.111</ipAddress>
<conferenceGuid>{3A7C05…}</conferenceGuid>
</command>
Inviter
157.68.9.111


<response type="Success"/>
Invitee
157.68.9.22
The XML message is terminated with a newline sequence (\r\n), so
no newline sequences are allowed in the message.
The inviter sends its current IP address – DirectPlay hosts the
conference on the inviter’s machine.
Client-Client Comm. – UDP



The voice stream is sent over multicast UDP if the clients
belong to a multicast network.
A client/server architecture would be better for nonmulticast networks, because if N clients are transmitting
voice data, we have N(N-1)=O(N2) distinct
Client 1
Client 3
transmissions.
Record
Record
Example:



Client 1 is transmitting
Client 2 is not transmitting
Client 3 is transmitting
Playback of voice
from Client 3
Client 2
Playback mix of voice from
Client 1 and Client 3
Playback of voice
from Client 1
Client-Server Communication


The same proprietary XML protocol (over TCP) is used.
Two types of messages:

Event-triggered messages:






Register
Connect
Disconnect
AddFriend
RemoveFriend
Periodic messages:


GetUserInfo (every 5 seconds – optimized for LANs)
Hello (every 60 seconds – graceful disconnection is expected)
The Connect Message



The server needs to know the IP address and port of each
connected user in order to answer GetUserInfo messages.
When a user logs in, the client sends its current IP address and port
in the Connect message.
The server sends back the user’s collection of friends.
<command type="Connect">
<user name="Ori"/>
<ipAddress>157.68.9.111</ipAddress>
<port>8080</port>
</command>
Voice Client
157.68.9.111
<response type="Success">
<friend name="Nir"/>
<friend name="Ari"/>
<friend name="Tomer"/>
<friend name="Maya"/>
<friend name="Lior"/>
</response>
Presence Server
The Disconnect Message

There are two types of disconnections:


Graceful disconnection
 The client sends a Disconnect message.
 The client stops sending the periodic
messages.
Forceful disconnection
 The client terminates abruptly without
sending a Disconnect message.
 The server will eventually find out that the
client has stopped sending Hello
messages.
The GetUserInfo Message



Every 5 seconds, the client sends a GetUserInfo message for each
friend of the currently connected user.
The short interval is optimized for low-latency networks such as
LANs – it provides high data accuracy.
The GetUserInfo messages are sent in a separate thread that is
allocated from the thread pool – if the message fails, the other
threads are immediately notified and a forceful disconnection takes
place.
<command type="GetUserInfo">
<user name="Ori"/>
</command>
Voice Client
<response type="Success">
<ipAddress>157.68.9.111</ipAddress>
<port>8080</port>
<status>Busy</status>
</response>
Presence Server
The Hello Message





Every 60 seconds, the client sends a simple “stay-alive”
message that indicates that the user is connected.
This feature is required in order to support forceful
disconnections.
Since most disconnections are graceful, a long interval (60
seconds) can reduce network load.
The server sweeps a local data structure every 90 seconds and
disconnects users that didn’t send a Hello message during the
last 90 seconds.
If the client fails to send a Hello message, the connection to the
server is assumed broken, and a forceful disconnection takes
place (similar to GetUserInfo failures).
Architecture



The server and the client are implemented in
separate Visual Studio .NET 2003 solutions.
Version 1.1 of the .NET Framework (Microsoft’s
“JRE” for .NET) is required in order to run the
applications.
Each solutions contains several projects:



One Windows Forms or Console project.
Several Class Library projects.
Each project represents an independent component
that is responsible for one layer of functionality:

For example, the NetworkController project is responsible
for all network communication.
The Voice Client

VoiceClient solution – 3000 lines of C# code



CentralController project (CentralController.exe)
NetworkController project (NetworkController.dll)
VoiceController project (VoiceController.dll)
Voice Controller
Central Controller

Network
Controller
The DirectX 9.0 SDK must be installed in order to build
the VoiceController project, but the DirectX 9.0 Runtime
(available from Windows Update) is enough to run the
client.
The Voice Client

The following parameters are read from a local XML
configuration file:




clientPort – the port on which the client waits for
InviteToConference messages from other clients (the
server doesn’t send any messages to the client).
serverPort (13579) – the well-known port on which the
server waits for event-triggered and periodic messages
from the clients.
serverAddress – the server’s IP address or hostname (the
DNS resolver of the OS is used to translate a hostname to
an IP address).
In order to support roaming users, no other data is
stored on the client – even the users’ friends are
stored on the server.
The Central Controller

Handles events from the client’s components:
 Network Controller



Voice Controller



When an InviteToConference message is received from another
client, the Network Controller passes the corresponding
XmlDocument object to the Central Controller.
The Central Controller processes the XmlDocument object and sends
the necessary response back to the Network Controller so it can be
sent to the other client.
The Voice Controller registers itself as the direct handler of DirectPlay
and DirectPlay Voice events.
The Voice Controller typically calls on the Central Controller to do the
real work because it doesn’t have the whole picture.
Central Controller

When the user clicks a button or opens a menu, the corresponding
event is handled by the Central Controller itself (the GUI belongs to
the Central Controller)
The Network Controller


Responsible for the client’s network communication.
Outbound:



Receives InviteToConference messages from the Central
Controller and sends them to the invitees.
Receives other messages from the Central Controller and sends
them to the server.
Inbound:

Receives InviteToConference messages from other clients
(inviters) and passes them to the Central Controller for
processing.
InviteToConference
Client-server
commands
The Voice Controller




Uses the DirectPlay API to capture, transmit, mix,
and play voice streams.
Each client is represented by in DirectPlay as a Peer
object.
The inviter is the initial host of the conference, but if
it leaves an ongoing conference, another participant
is selected to be the new host via a host migration
process.
A DirectPlay Voice session is created on top of an
existing DirectPlay session.
A Typical Workflow


In order to start working, a user must be registered (registration is
equivalent to opening an account).
A user that is already registered can immediately connect.
A Typical Workflow

Once connected, a user can manage his friends and start a
conference with any number of available (connected & not busy)
friends.
The Presence Server

PresenceServer solution – 2500 lines of C# code




CentralController project (CentralController.exe)
NetworkController project (NetworkController.dll)
StorageController project (StorageController.dll)
StatusController project (StatusController.dll)
Status Controller
Storage Controller
Central Controller
Network
Controller
The Presence Server

The server has several main functionalities:



It stores the information of each of the clients in
an XML file.
It holds a translation table that maps names of
connected users to their current network
endpoints (IP address and port).
It holds the current status of the connected users
– whether or not the user is currently participating
in a voice conference.
The Network Controller




Responsible for the server’s network communication.
The server does not initiate connections to clients – it
only responds to incoming messages.
The port is specified in the XML configuration file.
Implements a standard TCP server sequence:



Creates a new TcpListener object.
Accepts new connections in an infinite loop.
Each connection (TCP session) is handled in a separate
thread that is allocated from the global thread pool.
Client-server
commands
The Storage Controller

Responsible for the server’s interaction with
its persistent storage:




Each user in the system can maintain a list of
friends (friends must be registered users).
An XML file is used to store the information about
the users and their friends.
When a user connects, the server sends the
user’s list of friends as listed in the XML file.
The name of the XML file is read from the
configuration file.
The XML File
<?xml version="1.0" encoding="utf-8" ?>
<users>
<user name="orly">
<friend name="ori"/>
<friend name="tomer"/>
<friend name="ari"/>
</user>
<user name="tomer">
<friend name="maya"/>
<friend name="nir"/>
</user>
<user name="lior">
<friend name="oren"/>
<friend name="ari"/>
</user>
</users>
The Status Controller

Holds a table that contains an entry for each
connected user:






Network endpoint (IP address and port)
Status (Available/Busy)
Timestamp of the last Hello message
The timestamp is used in order to remove users that
did not disconnect gracefully.
A client retrieves information about the user’s friends
via GetUserInfo messages.
The client uses the network endpoints of its friends
in order to invite them to join a conference.
The Connected Users Table
When a user connects, the user’s
Name and IpEndPoint are added.
Indicates if the user
is participating a
conference.
Name
IpEndPoint
IsBusy
Timestamp
Orly
157.68.10.100:8080
True
3243244324
Tomer
157.68.10.70:8080
True
3243245555
Lior
157.68.9.70:9999
False
3243244455
Ari
157.68.9.69:8888
False
3243244323
Nir
157.68.9.77:8181
True
3243244423
Ori
157.68.9.111:17171
True
3243244523
When a user disconnects,
the user’s entry is
removed.
Updated
according to the
periodic Hello
messages.
The Central Controller


The glue between the other components.
The typical execution sequence:



Receives incoming messages from the Voice Clients via the Network
Controller.
Executes the necessary business logic for the received command via
the Status Controller and Storage Controller.
Sends a response message to the Voice Client (via the Network
Controller).
VoIP presentation

And now – to the real thing…