Sunday 27 November 2011

QoS for VoIP - How it works and when does it make a difference

Installers of VoIP (Voice over IP) often stress the importance of having QoS for the network. On a so-called 'experts' forum, I have even seen QoS put forward as the solution to one-way audio problems, even though it is of little or no relevance to such problems. QoS is undoubtedly a powerful and useful tool for VoIP engineers and can make a great difference in the right circumstances, but on the other hand is likely to make no difference at all to the handling of IP packets sent out to the Internet on a standard small-business broadband connection.

Want to know how QoS works in practice and understand where it makes a difference and how? Then read my article on the Smartvox Knowledgebase:
http://kb.smartvox.co.uk/index.php/ip-network-design/voip-qos-network-congestion/

Wednesday 5 October 2011

Why does NAT cause such a problem for SIP?

This question comes up time and again. Finding this week that I needed to brief a network consultant about the problems of SIP and NAT, it seemed like a good idea to write my summary here as a new blog article.

Why is NAT such a big deal for SIP communications:

  1. Although one SIP device is nominally the client device and another is nominally the server, all SIP end-points may need to act as a server or client at certain points in the dialogue – for example, the client device may initiate a call, but the server may end it.
  2. SIP requests may be relayed through a series of SIP Proxy servers (similar to email being relayed by SMTP servers)
  3. If Proxy servers want to be kept in the signalling path, they add a special “Record-Route” header containing their own address. They must respect any existing Record-Route headers.
  4. SIP requests always contain a “Request URI address” which describes the ultimate destination, but SIP devices and SIP Proxies may relay the request to an intermediate address which they know will relay it to the final destination.
  5. SIP requests contain IP addresses embedded in various headers and also in the SDP payload – see below for details
  6. The media path may not be the same as the SIP signalling path. The end points for the media are given in the SDP payload. The idea is that the media path needs to be as direct as possible, but the SIP signalling is less susceptible to latency so it is acceptable for it to go via a more convoluted path (e.g. via a billing server)
  7. SIP requests contain a Via header to tell the destination which IP address (and port) to send their replies. The source device that constructs the SIP request may not be aware of NAT traversal further downstream so is likely to specify its own local IP in the Via. To alleviate this known problem, many SIP devices have features (e.g. STUN) to allow them to examine their own networking environment and determine if they are behind NAT. It is also quite common to be able to manually program the device with an “external” IP address.
  8. The port specified in the Via address does not have to be the same as the port that the request was sent from.
  9. SIP requests contain a Contact header which specifies the address where the sending device can be reached by the remote end-point when the remote end-point wants to initiate a new request (as opposed to responding to the existing request, which is handled by the Via)
If you want some further reading on this topic, please take a look at the following articles on the Smartvox knowledgebase:


Wednesday 17 August 2011

VoIP QoS Settings

If you're confused by the QoS settings on VoIP equipment or just want to know what value you should assign to the DiffServ/TOS field on a Linksys IP phone, then you need to read the 2-part article on the Smartvox Knowledgebase:

VoIP QoS Settings - Part 1: Overview and Layer 2 settings


VoIP QoS Settings - part 2: Layer 3 settings, DSCP/TOS