For the past couple of months, I've been wrestling with a Voice-Over-IP system I've had to set up. Not only set up, but learn how to set up! From knowing almost nothing about VoIP technology, including Session Initiation Protocol (SIP, the protocol most VoIP phones use), to knowing a great deal more about how to set up a multi-user VoIP system, a few resources have helped me greatly.

First of all, the Voxilla forum is a great source of information and help from fellow users if you're working with any Linksys/Cisco or Sipura equipment. Like any popular forum, a quick search to check if your problem has already been discussed (or even solved) is recommended before diving in with your first post, but chances are even if you can't solve the problem in one go, the other people might help you narrow down the causes and make your life that bit easier.

Another forum should also be on your bookmarks: the Petri Forums, from Daniel Petri's tech discussion web site. This site's useful for more general networking problems and discussion, but quite often a problem with a VoIP network is due to a tricky network configuration (so by solving one problem, you remove the causes of the other!)

If you want to learn more about SIP and the often undocumented 'features' of the protocol and the technology, there are many guides and help documents on the web. However, I'm quite a visual person, and prefer a well laid out graph to reams and reams of text. The Tech-Invite site, "a Portal devoted to SIP and surrounding technologies" has loads of information, but what I'd like to point out is a series of 19 Really Useful Documents under the heading of "SIP Service Examples", with raelly well-written explanations accompanying large, easy to understand, coloured flow diagrams.

I was having problems with our phones establishing a call (they could see the incoming call, but for some reason they weren't reporting back to the remote SIP server that they were accepting the incoming call, so the actual call would never establish). The Call Pickup diagram greatly assisted me in understanding what was going wrong, and how to set about fixing it.

The InformIT web site also has a (text) article called "Session Initiation Protocol > Description of SIP" which explains - in a good amount of detail - both individual aspects of the SIP protocol, what various system status messages actually mean, and it even picks apart a selection of sample SIP messages, explaining what each part of it equates to in real world terms. If you want to expand your understanding of SIP, I suggest you browse through everything I've linked to during some spare time (with a few cups of tea and some biscuits!) and really clue up on SIP. I've been pulling my hair out at work for the past couple of months trying to establish a solid, problem-free VoIP setup and network, and I believe I've finally managed it.

Also, if you're thinking of setting up a VoIP network using Sipura or Linksys equipment, there are some network adapters you can buy which simplify the process - but which introduce problems of their own. For simplicity's sake, I suggest you run the phones directly attached to the network, with their appropriate SIP account details programmed directly into the phones, and with either DHCP IP addresses or static IPs configured via their (very 'comprehensive') web interface. Get rid of any adapters you might be considering (like SPA2000s or SPA9000s), because they introduce another layer of complexity.

Also, you wouldn't BELIEVE how many devices cause problems with SIP networks running more than one phone. For example, the Linksys WAG325N, one of their flagship pre-N wireless routers, sold specifically as having full VoIP compatibility, horribly fails when we hook up our kit through it. It just doesn't like the SIP traffic. To get a working network, here's how I configured our (separate) network:

Modem: ZyXEL P-660R-D1 ethernet modem (running in half bridge mode (Half Bridge Mode FAQ from the ZyXEL site), which is something only the D series modems can do, connecting to an ADSL Max Premium ISP for the higher upstream bandwidth)

Router: Linksys WRT54GL (or a WRT54G Version 4 will also do nicely), running the DD-WRT third-party firmware. It is crucial that you buy the correct, compatible version of the Linksys router to run DD-WRT on, many recent models are inadequately specced to run the firmware. Buy a WRT54GL if you can, avoid the WRT54GS or WRT54S or ANY of the Linksys routers which don't look like the classic blue and black routers with the two stub antennae at the back. I've linked to the Misco page for the router I purchased for work, and it works a treat (I also have one at home).

The Linksys router is set up to obtain a public IP via DHCP, and an appropriate subnet is configured (I used for the local area network). The router plugs into the ethernet socket on the ZyXEL modem, and the modem (in half bridge mode) passes through the public IP address to the router - and bam! No second layer of NAT required. This greatly simplifies setting up a working VoIP network, as you don't need to set up static routes on any of the devices or 'kludge' your network setup. The router behaves like it's got the modem integrated. (The modem itself is still accessible via

The reason you can't just put the modem into full bridge mode is that most ISPs in the UK only use PPPoA, which requires authentication whenever you connect. DD-WRT cannot deal with PPPoA connections natively, only direct PPPoE connections (which is why it works fine for cable modem connections), but with a router which can work in half bridge mode, this is trivial. In my setup, the ZyXEL modem handles the PPPoA authentication and silently passes all traffic through to the Linksys router to deal with - and the Linksys router handles NAT traversal, uPnP mapping and all the complex stuff. Indeed, when I plugged the phones in after configuring the modem and router appropriately, everything worked first time!

The reason I recommend DD-WRT for the router is that the firmware is vastly improved over the stock Linksys firmware; it turns the router from a capable to an excellent device, for no cost. Aside from that, it also provides you with a much greater deal of flexibility, compatibility and no-nonsense configuration and analysis (aside from the usual SSH, telnet and web interface for configuration, it will show you realtime bandwidth graphs via SVG with a compatible browser).

Some other tips I picked up... On your SIP phone, make sure your RTP Packet Size is 0.020 or less. (Most articles I've read don't suggest going lower than 0.010.) Linksys/Sipura phones ship with an RTP Packet Size of 0.030ms as their default, which can cause problems with the audio (stuttering / inaudible passages, distortion or even audio dropouts). Lowering the packet size lowers the latency, shortens the samplerate between packets and results in more reliable transmission of the audio from you to the other call (at the cost of marginally higher bandwidth usage). I noticed a marginal decrease in the latency between me speaking and the other party hearing my voice when I lowered the packet size, bringing it in line with a regular PSTN -> mobile phone call - much better! Before, audio was taking anything up to half a second to get to the other end, which really becomes noticeable in telephone conversations.

You can leave your subscription time to 3600 seconds for most SIP services, but ensure that NAT mapping and NAT keep-alive is turned on, and the NAT keep-alive interval is very short (I have our phones set to between 15 and 20 seconds, whereas the default on the Sipura devices is much longer). If you have multiple devices connecting through the same broadband connection, this helps remind the router to keep the phones' individual NAT maps alive, so that incoming calls (and outgoing calls) function correctly.

Six options on the Sipura phones I found useful to enable:

Handle VIA received
Handle VIA rport
Insert VIA received
Insert VIA rport
Substitute VIA Addr
Send Resp To Src Port

Set all of these to Yes (some of them default to No). These will aid the phones in handling with packets rewritten by NAT or proxy servers (which most networks will be using, unless you have a block of IPs with one dedicated to each one in a pass-through configuration, but that would be highly unusual). For more info on what each option means, see the VoIP-Info wiki article for Sipura devices, and this discussion thread on the Voxilla forum.

When testing and troubleshooting your phones, try making an outbound call to a regular number or mobile number - if it cuts off after 30 seconds (or a minute), you likely have a NAT problem. Check your settings and consult your provider for more info.

Be sure to check both incoming and outgoing calls work as expected both immediately after the phone successfully registers with the server - and after a while (30/40 minutes). If outgoing and incoming calls last more than 3 or 4 minutes, your network is most likely configured correctly, so if you have audio dropout or other problems (say, after half an hour in a call), something else is afoot.

In terms of codec choice, most phones will offer G.711 (I would recommend you choose G.711a instead of G.711u if you're outside of the United States, based on this discussion and this discussion), but as they are the highest quality (uncompressed) they use the most bandwidth. For more info on all the possible codecs used for VoIP platforms, see the VoIP-Info wiki article. If you can't use G.711a (or it's not feasible due to bandwidth constraints, then G.729 or G.726 - in that order - are the next best, and most commonly supported choices. If you're planning to use a fax device on a VoIP line, ensure that the service provider supports the T.38 protocol - and again, configuring the appropriate RTP Packet Size is crucial (setting a very low amount, like 0.010ms, will help with problematic devices that may receive a partially garbled transmission - or not connect at all). Some trial and error will be involved in finding the sweet spot - a discussion about 'Sipura tricks' for optimising your SIP call quality can be found on the DSLReports forum, which will also affect T.38 performance. NB: if you're sending data via T.38 to equipment which doesn't support T.38, results will be unpredictable (and you might as well not bother), so if fax over IP is important to you, ensure you check with your potential provider before you sign up, as it's not a standard offering.

Regarding RTP packet size, I've heard lowering it to reduce loss or uneven data transmission can also help with things like Sky Digiboxes and other devices which expect a regular PSTN line to 'phone home', although again, I've not checked this out, so YMMV. Check Google for more related reading.

Also, although I've detailed why a lower RTP packet size value is recommended, if you're in a situation where you find you have to use the (infrequently used) G.723.1 codec, your RTP packet size must be 0.30ms for the Sipura devices. This is something which I think is due to the constraints of the G.723.1 codec; its samplerate and packet size requiring the larger RTP packet size.

A final tip if you want to troubleshoot codecs - if you want to see what codec your Sipura phone is using to dial out or receive a call, make (or receive) a call, then go to its web interface while the call is in progress - and it's listed under the Line x Call y Status heading, a little way below the Phone Status and Extension statuses. The web interface can be accessed by going to its IP in a web browser (so for example, if your phone had an IP address of, just type that into a browser). To find your phone's IP address from the handset itself, press the button with the paper icon with the folded corner, just below the voicemail button (with the envelope icon) - this will go to the Setup screen. You can either page up or down with the cursor D-pad, or you can use the handset numbers to type in a number next to each menu entry to go straight to it. In this case, the Network setup is option 9 - tap 9, then you can see your current IP as entry 2 in the list. If you've plugged the phone in fresh out of the box, it will be configured for a DHCP-assigned IP, so this is the easiest way to get cracking. If you're feeling brave, you can even use the phone's interface to configure the IP address settings (but it's a little tricky to get right the first time, so I recommend you use the web interface, it's much handier). Once I have static IPs assigned for each handset, I always use the web interface.

To make your life a little easier when working out which codecs work and which don't, I always recommend first navigating to the advanced admin panel and enabling all codecs for use, even if you don't want to use them. There's some small links at the top of every web admin page, first of all you will see Admin Login - click that, then when the admin page reloads, click Advanced. This will become second nature after a while, and you can always bookmark the pages to go there direct if you like. You can't always modify all the phones' settings if the phones are locked to a provider, but if you buy them from Misco or BroadbandBuyer, they'll be sold as unlocked. Don't forget to flash to the latest firmware for each phone as soon as you get it, as this can sometimes unlock more extensions or fix problems in the older firmwares.

If you want any more help with configuring VoIP devices (particularly handsets or network configs similar to the one I've detailed here), you can get in touch with me via my company. Quite often I can direct people to existing information and support on the web which I've collated, but if you have a tricky problem I'll gladly provide my assistance on a commercial basis. This isn't a plug, but some people might just find it easier (or more cost-effective, if they're wasting time trying to sort it out themselves) to pay someone to get the job done! VoIP and SIP is a world of hurt if you're diving in for the first time, I'll readily admit that - some devices are far easier to set up, and play far more nicely with the wide variety of equipment and devices found in the office or home environment. The Sipura devices are far more picky, but they're not impossible to set up. I hope this article helps other people who feel they've hit a brick wall and can't figure out what their problems might be - and my final bit of advice is: don't give up! You'll feel very satisfied when your SIP system is fully operational, and as you'll most likely save a bit of cash too, it's all worth it in the end.

As I like to remind myself when I lose heart; being on the bleeding edge is often painful, but always rewarding!

1 Comment:

  1. Graham Francis said...
    Maybe people wanting to learn more about SIP could go to for training resources. they can also get their SSCA™ Certification to prove that they know their stuff when it comes to the protocol. There is more to come as well with a Forum and Wiki coming online this week and a News / Blog site @

Post a Comment


Copyright 2006 onwards Christopher Woods. Some Rights Reserved.
ITU uses a (highly) modified version of the K2 theme by GeckoandFly,
originally Bloggerised by Blogcrowds. Credit where credit's due. :)

Into The Unknown is licenced under a Creative Commons License.
(Attribution-Share Alike 2.0 UK: England & Wales, Some Rights Reserved).

Creative Commons License