The Four Enemies of Voice and Video Traffic

What do you think of this post?
  • Useful 
  • Sucks 
  • Boring 
  • Awesome 
  • Interesting 

VoIP bandwidth delay jitterIt is the never ending battle of real time voice and video traffic against the following evil foursome.  Here is a quick reference of who/what they are and the metrics required to keep them in check:

Delay:

According to Cisco and IEEE recommendations the end to end one-way delay should be kept between 150 ms to 200 ms for voice traffic.  In reality any greater than 250ms of consistent one-way delay will degrade voice quality and is not acceptable for production deployments.

Symptom:  Unnatural delay in conversation

Jitter:

This is the measure of the variation of delay.  In other words the inconsistency of voice packet arrival times at the receiving end.  As an example, a few voice packets may arrive every 100 ms then the next (few) packets may arrive 120 to 130 ms apart.  To smooth out this inconsistency so that the listener receives a consistent flow of voice a jitter buffer is commonly implemented at the receiving end to collect/buffer a large enough number of packets before playing the stream to the listener.

The recommended value to constrain one-way  jitter should be less than 30 ms.   Jitter buffers are typically designed to handle this amount.

Symptom:  A robotic sounding voice from the other end.

Packet Loss:

A symptom of a number of possible causes which could include faulty hardware, over subscription of WAN links, corrupted packets etc.

Packet loss needs to be kept less than 1% in networks handling voice and video traffic.

Symptom:  Clipping of voice and choppiness.

Lack of Bandwidth:

The bandwidth normally requires engineering based on the CODECs being implemented and the calculated expectation of the VoIP and/or video traffic flow.

The above four are the most common and major causes of disruption to the real-time nature of VoIP and Video traffic however there are other issues which can and should be considered when engineering the network.  For example, serialization delay should be considered if the WAN link speed is below 768 Kbps (Cisco considers link speeds <= 768 Kbps a ‘slow speed WAN link’).

QoS mechanisms, adequate bandwidth provisioning along with mechanisms such as LFI (fragmentation) for slower WAN links can go a long way in curtailing these villains of real-time traffic.

Overall as long as the voice engineer pays attention to these major areas of contention when pre-assessing the network there is high chance for a successful VoIP deployment.

SIP Response Codes

What do you think of this post?
  • Awesome 
  • Sucks 
  • Boring 
  • Useful 
  • Interesting 

SIP Response codes are a means of communication for the Session Initiation Protocol.  They are pre-defined responses to SIP Requests which have been organized in relevant groups.

1xx—Informational Responses

100 Trying
Extended search being performed may take a significant time so a forking proxy must send a 100 Trying response
180 Ringing
Destination user agent received INVITE, and is alerting user of call.
181 Call is Being Forwarded
Servers can optionally send this response to indicate a call is being forwarded.
182 Queued
Indicates that the destination was temporarily unavailable, so the server has queued the call until the destination is available. A server may send multiple 182 responses to update progress of the queue.
183 Session in Progress
This response may be used to send extra information for a call which is still being setup.

2xx—Successful Responses

  • 200 OK
  • 202 accepted: It Indicates that the request has been understood but actually can’t be processed
  • 204 No Notification [RFC5839]

3xx—Redirection Responses

  • 300 Multiple Choices
  • 301 Moved Permanently
  • 302 Moved Temporarily
  • 305 Use Proxy
  • 380 Alternative Service

4xx—Client Failure Responses

  • 400 Bad Request
  • 401 Unauthorized (Used only by registrars or user agents. Proxies should use proxy authorization 407)
  • 402 Payment Required (Reserved for future use)
  • 403 Forbidden
  • 404 Not Found (User not found)
  • 405 Method Not Allowed
  • 406 Not Acceptable
  • 407 Proxy Authentication Required
  • 408 Request Timeout (Couldn’t find the user in time)
  • 409 Conflict
  • 410 Gone (The user existed once, but is not available here any more.)
  • 412 Conditional Request Failed
  • 413 Request Entity Too Large
  • 414 Request-URI Too Long
  • 415 Unsupported Media Type
  • 416 Unsupported URI Scheme
  • 417 Unknown Resource-Priority
  • 420 Bad Extension (Bad SIP Protocol Extension used, not understood by the server)
  • 421 Extension Required
  • 422 Session Interval Too Small
  • 423 Interval Too Brief
  • 424 Bad Location Information
  • 428 Use Identity Header
  • 429 Provide Referrer Identity
  • 433 Anonymity Disallowed
  • 436 Bad Identity-Info
  • 437 Unsupported Certificate
  • 438 Invalid Identity Header
  • 479 Regretfully, we were not able to process the URI (479/SL)
  • 480 Temporarily Unavailable
  • 481 Call/Transaction Does Not Exist
  • 482 Loop Detected
  • 483 Too Many Hops
  • 484 Address Incomplete
  • 485 Ambiguous
  • 486 Busy Here
  • 487 Request Terminated
  • 488 Not Acceptable Here
  • 489 Bad Event
  • 491 Request Pending
  • 493 Undecipherable (Could not decrypt S/MIME body part)
  • 494 Security Agreement Required

5xx—Server Failure Responses

  • 500 Server Internal Error
  • 501 Not Implemented: The SIP request method is not implemented here
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Server Time-out
  • 505 Version Not Supported: The server does not support this version of the SIP protocol
  • 513 Message Too Large
  • 580 Precondition Failure

6xx—Global Failure Responses

  • 600 Busy Everywhere
  • 603 Decline
  • 604 Does Not Exist Anywhere
  • 606 Not Acceptable

 

References:

  1. Wikipedia.org
  2. Rosenberg, J.; Schulzrinne, H.; Camarillo, G.; Johnston, A.; Peterson, F.; Sparks, R.; Handley, M.; Schooler, E. (June 2002). SIP: Session Initiation ProtocolIETF. RFC 3261. Retrieved January 20, 2012.

What is GARP (Gratuitous ARP Protection)?

What do you think of this post?
  • Awesome 
  • Useful 
  • Sucks 
  • Boring 
  • Interesting 

Gratuitous ARP (protection)

This is an example of a typical standards based (beneficial) LAN feature which can be used in some cases by the bad guys for malicious purposes.  Therefore the following is a brief description on the feature and why most IP phones normally have the capability/feature to disable cooperation with this common LAN function.

Enabling GARP protection prevents the IP phone from replying to GARP requests.    Normally when an IP device wants to know the MAC address (layer 2) of another device it sends an ARP request (with the IP address it wants mapped) and receives an ARP response from the device which has that particular IP address assigned.

However if the IP device/phone receives a ‘gratuitous’ (unsolicited) ARP response providing a different MAC address to IP address mapping the end-device will go ahead and update its ARP table.  This can be a beneficial feature for example if a secondary HSRP (or VRRP) router detects failure of the primary router and wants to update all end-devices to use IT as the new default gateway; it will send out a GARP request to all the devices to update their tables.  However it can also be used for malicious purposes for man-in-the middle attacks to divert traffic from unsuspecting end-devices (namely IP phone voice traffic).

Therefore enabling GARP protection configures the IP phone to stop responding / acting upon unsolicited GARP requests and provides an additional level of security to the voice infrastructure.

VoIP Packet Overhead

What do you think of this post?
  • Sucks 
  • Boring 
  • Useful 
  • Interesting 
  • Awesome 

The world of packet overhead, the envelopes which ensure our information reaches our destination.

It is easy to forget these specific values however they can be necessary to engineer WAN links for client VoIP deployments.

The following is a summary of common overhead values for your ease of reference.

I will attempt to update this page with pertinent ‘overhead’ related information over time.

Comment below with any suggestions you may have and I will try my best to add them.  Thanks.

 

Standard Layer 2 Voice Packet Overhead

Ethernet II:
18 Bytes

Ethernet (with 802.1Q) VLAN Tag:  22 Bytes

Frame Relay Forum Standard 12 (FRF.12):  6 Bytes

HDLC:  7 Bytes

MPLS: 4 Bytes

PPP: 12 Bytes

MLP:  6 Bytes

ATM:  5 Bytes

IPSec:  50 – 57 Bytes

L2TP / GRE:  24 Bytes

 

Standard Layer 3+ Voice Packet Overhead

RTP: 12 Bytes

UDP: 8 Bytes

IP: 20 Bytes

Total:  40 bytes

Note:  Compressing the above header using cRTP can bring the 40 bytes down to 2-bytes of overhead (4-bytes if UDP checksum is being used).

Common CODEC Types and their Associated Payload and Packet Sizes

CODEC Payload Size and Type

Standard Voice CODEC Payload Sizes and Types