Manage Voice and Video Sessions

Instructions to manage the performance of Voice over IP or Video over IP streams.

Voice over IP and Video over IP can be managed with similar strategies, as both applications consist of long streaming data sessions accompanied by shorter initiation and control flows. Management recommendations for both Voice over IP and Video over IP are described here and are collectively referenced by the term V/VoIP.

PacketWise's recommendation for managing V/VoIP entails identifying the different types of V/VoIP traffic, reserving a portion of the network to support all of it, speeding the control traffic along quickly, giving each stream an appropriate amount of bandwidth, protecting individual V/VoIP users from each other, and protecting other applications if V/VoIP demand swells.

When instructions pertain to only voice or video, these terms are used. But when the instructions pertain to both traffic types, the all-encompassing term V/VoIP is used. Do not, however, manage voice and video streams together in the same classes with the same policies. Their bandwidth needs are quite different.

Note: See Prepare for VoIP for instructions to prepare an existing network for the addition of Voice over IP or Video over IP.

 Tutorial: Manage Voice over IP Traffic (requires Flash player)

Steps:

1. If you have not had active V/VoIP sessions, start and stop a few voice calls or video-conferences to generate some traffic. Leave one of the sessions running at least 10 minutes to collect a substantial amount of measurement data. Note the time interval that your session was running.
   
   PacketWise spots many types of V/VoIP traffic automatically, including Clarent, CU-SeeMe, Dialpad, H.323, I-Phone, Media Gateway Control Protocol, H.248/Megaco, Micom, Net2Phone, T.120, SIP, Skype, Vonage, RTP, and RTCP. MCK Communications, Skinny Client Control Protocol (Skinny), and VDOPhone are not auto-discovered but you can manually create classes for them.
   
   
2. Create a folder class to contain V/VoIP traffic under both Inbound and Outbound. If you have both voice and video, create two pairs of folders, one called Voice and one called Video. Do not combine voice and video traffic in one folder class.
   
   
3. Move each V/VoIP traffic class into its proper folder under the Inbound branch. Do the same for the Outbound branch.
   

   Voice and video clients typically use UDP streams. They have different flows and protocols for initiation, control, and data flows. For example, H.323 starts a conversation on one port (H.323), jumps to another port (Q.931), and eventually splits up into a data flow (RTP) and control flow (RTCP).

4. Consult the Monitor Traffic window to look at V/VoIP traffic data and get an idea of bandwidth trends. Observe the measurements for current rate, one-minute average, and peak rate. Create utilization graphs covering the time period you left the one session running for the large VoIP data flows (RTP, MiCOM VIP, MCK Voice, or others).
   
   PacketWise measures both data payload and header overhead, so requirements will be slightly higher than the nominal bandwidth rate of the protocol. In general, you should expect to see an increase ranging from 10 to 20 percent. Thus, a 768 Kbps stream might take 820 Kbps when headers are included.
   

5. Determine an appropriate minimum amount of bandwidth you want for your V/VoIP traffic, even during times of contention. In addition, determine the maximum amount of bandwidth you want all V/VoIP to be able to access, even during times of little or no contention. These numbers will be the minimum and maximum sizes for your V/VoIP partition.
   
   How many concurrent V/VoIP users do you want to support at a minimum? For a rough estimate of bandwidth needs, multiply that number by the amount of bandwidth you observed being used during your one prolonged test session.
   
   For voice, for example, you might want to support 10 concurrent sessions at 25 Kbps each, for a total of about 250 Kbps in each direction.
   
   For video, if you're using a 384 codec, for example, you might want to support two concurrent sessions of 420 Kbps each (remember those headers and control information are included).
   

6. The minimum and maximum sizes of your partitions depend on how restrictive you want to be and the relative importance of V/VoIP with other traffic. For general help determining correct minimum and maximum partition sizes, consult Sizing a Static Partition.
   

7. Create a partition for your V/VoIP class under both Inbound and Outbound using your numbers from the previous step.
   
   For background information, see Partition Overview.
   
   
8. Set a priority policy with a relatively high priority (5, 6, or 7) on each of your traffic classes for V/VoIP's setup or control flows (RTCP, SIP, Megaco, MGCP, Skinny, MCK-Signaling, et al).
   
   
9. Set a rate policy on each of your V/VoIP data classes (RTP or others) to accomplish several goals:
   
   - to indicate the relative importance of your streaming traffic so that PacketWise knows how to distribute excess bandwidth
   
   - to insulate streaming users from each other
   
   - to gain the benefits of rate control and in particular, to reduce retransmissions that waste bandwidth
   
   - to reserve the appropriate per-session bandwidth to ensure smooth streaming performance
   
   Use a guaranteed rate of the minimum bits per second that are required for acceptable session quality. Make your policy burstable with a relatively high priority.
   
   Typically, if a manufacturer claims that its voice flow requires 8 Kbps, it will actually need 17 to 21 Kbps due to additional overhead and forward error correction. In addition, it is best to overstate the bandwidth needs of UDP traffic by 15 to 20 percent. If in doubt, try 25 Kbps as your guaranteed rate for voice flows.
   
   As examples, rate policies for RTP:
   
   • Voice: Guaranteed: 25K, Burstable at priority 5
   • Video: Guaranteed: 420K, Burstable at Priority 5
     
     
10. If you are using an MPLS-based IP service to route V/VoIP and application traffic on different paths, you can assign appropriate Diffserv values to your V/VoIP and application classes. This assumes that the Label Edge Router will be doing MPLS tagging based on Diffserv or IP ToS tags. If you would like PacketShaper (instead of the LER) to assign the MPLS labels, see Classify Traffic with an MPLS Label.

See also:

Restrict Skype Traffic