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 Client

Voice Client

Voice Conference

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:

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.

<command type="InviteToConference"><user name="Ori"/><ipAddress>157.68.9.111</ipAddress><conferenceGuid>{3A7C05…}</conferenceGuid>

</command>

<response type="Success"/>Inviter157.68.9.111

Invitee157.68.9.22

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 non-multicast networks, because if N clients are transmitting voice data, we have N(N-1)=O(N2) distinct transmissions.

Example: Client 1 is transmitting Client 2 is not transmitting Client 3 is transmitting

Record Record

Client 3Client 1

Client 2

Playback mix of voice from Client 1 and Client 3

Playback of voice from Client 1

Playback of voice from Client 3

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>

Presence Server<response type="Success">

<friend name="Nir"/><friend name="Ari"/><friend name="Tomer"/><friend name="Maya"/><friend name="Lior"/>

</response>

Voice Client157.68.9.111

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>

Presence Server<response type="Success">

<ipAddress>157.68.9.111</ipAddress><port>8080</port><status>Busy</status>

</response>

Voice Client

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)

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.

Network Controller

Voice Controller

Central Controller

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 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.

Voice Controller 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.

Client-server commands

InviteToConference

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)

Network Controller

Storage ControllerStatus Controller

Central 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

Orly 157.68.10.100:8080

Tomer 157.68.10.70:8080

Lior 157.68.9.70:9999

True

True

False

Ari 157.68.9.69:8888 False

Nir 157.68.9.77:8181 True

Ori 157.68.9.111:17171 True

Name IpEndPoint IsBusy Timestamp3243244324

3243245555

3243244455

3243244323

3243244423

3243244523

When a user connects, the user’s Name and IpEndPoint are added.

Indicates if the user is participating a

conference.

Updated according to the periodic Hello

messages.

When a user disconnects, the user’s

entry is removed.

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…