Optimizing Voice Over IP

Transmitting voice over IP (VoIP) connections is, in most senses, like any other network application. Packets are transmitted and received from one IP address to another. The voice data is encoded into binary data at one end and decoded at the other end. In some sense, voice is just another form of data. However, there are a few special problems.

The requirements for quality voice traffic are not exactly the same as the requirements for most data traffic:

• If a data packet arrives a second late, it is usually of no consequence. The data can be buffered until the late packet is received. If a voice packet arrives a second late, it is useless and might as well be thrown away.
• If a data packet takes a third of second to arrive at the destination, that is usually fast enough. If voice packets routinely take a third of a second to arrive, the users will begin to take long pauses between sentences to make sure that they don’t interfere with the other person’s speech.

Optimizing Voice Over IP

Quality VoIP calls need data to be delivered consistently and quickly. Meeting the requirements of VoIP data requires either a connection with plenty of bandwidth all along the data route or a means of ensuring a certain quality of service (QoS) for the duration of the call.

Even if the bandwidth is available, setting up the phone call can be a non-trivial task. When a phone call is initiated, the destination of the call might be a standard telephone on the public switched network (PSTN) or an IP-to- device at a particular IP number, or one of several computers (for example, a computer at home or office). If the destination device is a phone on the public network, the initiation protocol must locate a gateway between the Internet and the telephone network. If the destination device is in the local network, the initiation protocol must determine which computer or device to call.

After the destination device has been found, the initiating and the destination devices must negotiate the means of coding and decoding the data. This process of finding a destination device and establishing the means of communication is called session initiation.

The two main standards for initiating sessions are:

• Session Initiation Protocol, or SIP, used for most VoIP telephone calls.
• 323, used for multimedia communication, for example by Microsoft NetMeeting.

In both cases, the initiating device queries a server, which then finds the destination device and establishes the communications method.

After the two devices have been matched and the communication standards chosen, the call is established. The VoIP server may remain in the communication loop or it may step out of the loop depending on the server configuration.

Using QoS Rules for VoIP

The Wireless LAN System is designed to automatically provision voice traffic with a level of QoS appropriate for voice calls. Incoming traffic are matched against the pre-defined QoS rules and depending on the match, the traffic is assigned with appropriate prioritization.

The port numbers monitored for incoming traffic are:

• 5060 for SIP service (UDP or TCP)
• 1720 for H.323 service (TCP)
• 5200 for Vocera (UDP)

If your VoIP devices and servers are configured to use different ports, modify the QoS rules on the controller to match the ports your system uses. Change QoS rules with either the Web UI or the CLI.

Optimizing Voice Over IP

Modifying QoS Rules for Nonstandard Ports

The controller is pre-configured to detect the bandwidth requirements for a SIP or H.323 call and make a bandwidth reservation. Change QoS rules with either the Web UI or the CLI. The following default QoS rules are configured at the factory:

default(15)# show qosrule

ID    Dst IP          Dst Mask        DPort Src IP          Src Mask        SPort Prot Firewall Filter Qos   Action

• 0.0.0 0.0.0.0         1720  0.0.0.0         0.0.0.0         0     6                    h323  capture
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         1720  6                    h323  capture
• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0    

17                   sip   capture

• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0    
• sip capture
• 0.0.0 0.0.0.0         5200  0.0.0.0         0.0.0.0         0     17                   other forward
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5200  17                   other forward
• 0.0.0 0.0.0.0         80    0.0.0.0         0.0.0.0         0     17                   other capture
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5060  6                    other capture

        QoS and Firewall Rules(8 entries)

The first two pre-configured QoS rules give priority to H.323 traffic sent to and from TCP port 1720 respectively. The next two QoS rules give priority to SIP traffic sent to and from UDP/ TCP port 5060 respectively. Rules 7 and 8 are for Vocera badges and use port 5200 with UDP.

You normally do not need to configure QoS rules in the controller, unless you have special requirements in your configuration. For example:

• You want to drop packets coming from certain ports or IP addresses.
• You want to configure the controller to give priority to traffic other than H.323 and SIP traffic.

You can configure rules to provide priority-based or reserved QoS. QoS is applied with reserved traffic being allocated the first portion of total bandwidth, followed by fixed priority levels, and finally by the best-effort (default) traffic class. You can configure reserved QoS for new applications using the average packet rate and token bucket rate parameters together as the traffic specification (also called TSpec in IETF IntServ RFCs).

Optimizing Voice Over IP