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.

Communication Channels There are two main communication channels: Client-client communication Client-server communication There is no server-client 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.

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(N 2 ) distinct transmissions. Example: Client 1 is transmitting Client 2 is not transmitting Client 3 is transmitting

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.

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.

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.

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.

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)

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.

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

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