voip on a wireless lan orly goren tomer shiran lior nir
Post on 20-Dec-2015
229 Views
Preview:
TRANSCRIPT
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…
top related