G.722 HD Audio. What’s the big deal?

By Steve Biddle, in , posted: 5-May-2010 11:00

G.722, HD Voice and HD Audio have become the latest buzzwords in the VoIP (Voice Over Internet Protocol) market in the last year. They are all words to describe the same thing - wideband audio that delivers voice calls using VoIP with audio quality that is greatly superior that of a regular landline or mobile phone call.

Since the late 1970's G.711 has been the defacto standard in the telephony world for voice encoding as we moved into the digital world with fully digital phone switches, and moved away from analogue phone exchanges. G.711 sampled audio at 8kHz and created a 64kbps audio stream using two slightly different methods depending on where in the world you were located. u-law was used in Japan and North America, and a-law was used in the remainder of the world. u-law and a-law were also used as the audio codec for both T1 and E1 circuits as well as ISDN, hence the reason that channels are all 64kbps. Since the mid 90's as VoIP has rapidly taken over in the telephony world G.711 has still remained as the codec of choice.

Things are now slowly changing however, since computers now have far more processing power than they did in the 1970's the ability to process, compress, and decompress audio in real time is now far easier. This has lead to the creation of new audio codecs in recent years that can sample voice with greater frequency ranges, and also compress audio to use less bandwidth without any noticeable loss of quality.

G.729 delivers call quality that is only marginally less than that of G.711 but uses approximately half the bandwidth. This offers very significant benefits as we move to fully IP based networks as it allows greater volumes of voice traffic to be carried. G.722 on the other hand uses a similar amount of bandwidth as G.711, but samples audio at 16kHz which is double that of G.711 and delivers what many regard as far more natural sounding audio. Newer codecs such as Siren22 that was created by Polycom take things a step further and sample audio at 22 kHz, resulting in audio that sounds even better but with the downside of using significantly more bandwidth. G722-2 or AMR-WB is also slowly making it's presence felt in the mobile market with a number of mobile carriers having recently deployed this codec which offers superior 16 kHz voice quality over a mobile connection when the end users both have handsets that support this codec.

Many modern IP PBX's support the G.722 audio codec and with most new IP phones supporting G.722 it's certainly a feature that many people are rapidly discovering. The enhanced audio quality also makes audio conferencing a vastly superior experience. While G.722 is currently supported by a growing number of VoIP providers around the world, the one "limitation" of G.722 is that there is no benefit when calling a landline, mobile phone, or another VoIP user who doesn't have G.722 hardware as the call will only be as good as the audio quality from the remote party. Here in New Zealand WorldxChange fully support G.722 on their VFX and DVX platforms for calling between other DVX and VFX users, and G.722 calls between users on different VoIP providers who peer IP calls and support G.722 are also possible. Telecom New Zealand's new VoIP platform and newly released SIP trunking product does not support G.722 at this stage and I see this being a fundamental downside for them as they move towards launching this product publically in the coming months.

I'm presently reviewing a number of mid range and high end VoIP handsets for Geekzone. I have a Snom 820, Cisco SPA509G, Aastra 6755i, Yealink T28P and Polycom IP450, all of which support the G.722 codec. As part of this review I've recorded some audio samples and have them available below for you to listen and compare for yourself.


  • Sample 1: Asterisk recording "Your extension number is two two two". This file uses the GSM codec for "Your extension number is" and uses the G.722 codec for the "two two two"

  • Sample 2: Asterisk recording "At the sound of the tone the time will be exactly twenty fourty nine". This file uses the GSM codec for "At the sound of the tone the time will be exactly" and uses the G.722 codec for the "twenty fourty nine" CLICK HERE FOR SAMPLE 2

  • Sample 3: Asterisk Voicemail recording using G.729. This is a sample of the Asterisk voicemail prompts using recordings in the native G.729 format.

  • Sample 4: Asterisk Voicemail recording using G.711. This is a sample of the Asterisk voicemail prompts using recordings in the native G.711 format.

  • Sample 5: Asterisk Voicemail recording using G.722. This is a sample of the Asterisk voicemail prompts using recordings in the native G.722 format.

  • Sample 6: Asterisk voice call using G.729. This is a sample of  a phone call using the G.729 codec.

  • Sample 7: Asterisk voice call using G.711 a-law. This is a sample of  a phone call using the G.711 a-law codec.

  • Sample 8: Asterisk voice call using G.722. This is a sample of a phone call using the G.722 codec.


The differences between the various codecs should be readily apparent!





Some research notes for Steven Joyce & the NZ Commerce Commission

By Steve Biddle, in , posted: 27-Apr-2010 17:00

This morning Communications Minister Steven Joyce announced that he had asked the Commerce Commission to reconsider it's recommendation on mobile termination rates. In February the Commission recommended to the Minister that voluntary undertakings from both Vodafone and Telecom be accepted rather than Government regulation.
"In a letter to me dated 19 April 2010, the Commerce Commission indicated that a new retail offer launched by Vodafone on 13 April 2010 may be material and may have the potential to affect the basis for the Commission's recommendation," says Mr Joyce."
The plan in question is Vodafone's Talk Plan - a $12 addon for Prepay users that allows calls to other Vodafone customers or any landline in New Zealand any time of the day or night, at an effective rate of 6c per minute. The Commission appears to believe there could be an issue with with this plan and that it is is "anti-competitive" by offering on-net termination rates at a price less than Vodafone's offering that had been submitted to the Commission. This view can be argued against in many ways, including the fact many customers do not use all included minutes and that a large number of these calls will presumably be to landline phones where Vodafone are in fact paying approximately 2c exl GST per minute to terminate calls.
If Vodafone's plan was enough to trigger a serious rethink on MTR rates, questions serious questions need to be raised about the knowledge the Commerce Commission of the mobile market with New Zealand, and ultimately whether they are competent enough to be offering advice to the Minister.
As of the 1st April 2010 the MTR costs for Telecom are 14c + GST for voice and 14.4c + GST for Vodafone. SMS rates on both networks are 9.5c + GST per message. Current interconnection costs for mobile to landline traffic is approximately 2c + GST per minute.
Telecom offer a plan called Telecom Talk & TXT 300 for  $29.95 per month that offers
  • 300 Nights and Weekends minutes to any mobile or network
  • 300 TXT messages to any network
  • 20 Daytime minutes to any network
Telecom claim this offers $344.80 worth of monthly value (based on normal calling & SMS rates) for $29.95 per month.
If all of those 320 minutes were used to call another Telecom customer it represents a cost of 9.36c per minute, under Telecom's current MTR of 14c excl GST per minute. This rate calculation is based on no SMS messages being sent -  if a modest cost of 4c (excl GST) [1] was used to model this equation it would result in a cost of  cost of 5.14c per minute, which is lower that Vodafone's Talk offering!
If Vodafone's Talk is so bad why is Talk & TXT not being targeted also? What's even more interesting is that based upon current MTR costs if all included TXT message and voice minutes were used to call a Vodafone customer it would result in inbound revenue to Vodafone (based on whole minutes) of $83.90
ZOMG!!!!111!!! Telecom are actually losing $53.95 per month on that customer. How can that be? Quick, somebody launch a Ministerial enquiry!! It should be illegal for a company to sell a product under cost!!
Telecom also offer a capped rate of $1 + GST for calls of up to 60 minutes from a Telecom business landline to a Telecom mobile. Once again this is below current (and proposed) MTR rates.
Vodafone also offer You Choose addons that have been in place for a number of years that also give calls both on and off net for less than current (and in some cases proposed) MTR rates.
  • Your Time 100 - 100 mins to any network or landline for $14.95 = 15c per minute
  • Your Time 300 - 300 mins to any network or landline for $29.95 = 10c per minute
  • Your Time 200 - 200 mins to another Vodafone mobile for $11.95 = 6c per minute
The Commerce Commissions' "smoking gun" is in fact nothing new as Vodafone have already been offering on-net calls for 6c per minute for a number of years.
There is a myth in this world that mobile calling rates are related directly to retail call pricing. These prices should make it clear to people that no such link exists.
So my advice to the Commission and Minister is quite clear - pull your head out of the sand and do your research. Right now you look like nothing but a pack of idiots after bragging about finding the "smoking gun" - except you haven't told us anything new. Networks have offered calling rates for both on-net and off-net that have been below MTR costs for many, many years.
What exactly is so significant about Vodafone's offering that has lead to the action you have taken? If on-net termination is your "smoking gun" why have Telecom or their Talk and Text 300 Plan not been mentioned when this plan can offer effective on-net termination rates that are even lower that what Vodafone's Talk offering has?
Every single person in NZ is relying on  you to deliver us competition in the marketplace. It seems highly unlikely that you are actually capable of doing this when you're not even aware of current offerings and pricing that exist in the marketplace today.
It should be pointed out as that I have no links with Vodafone or Telecom other than being a Vodafone customers. I think calling prices in NZ are too high and want to see them come down.
[1] 4c + GST is the maximum rate that would be charged per SMS under the Hybrid Bill and Keep system proposed by Vodafone and Telecom.

Will the Minister regulate MTRs?

By Steve Biddle, in , posted: 21-Apr-2010 09:06

In November 2008 the Commerce Commission began an investigation into Mobile Termination Access Services (MTAS), also known as Mobile Termination Rates (MTR) - the wholesale prices mobile providers charge each other to terminate calls on their networks. The goal was to assess "whether the mobile termination access services should be regulated, due to concerns that a combination of mobile termination rates that are significantly above cost, with significant on-net discounting, creates a barrier to competition in the mobile market"

I've had a great interest in the MTAS investigation and have blogged about it on numerous occasions. Last week I wrote a slightly tongue in cheek blog post on Vodafone's newly released Talk plan suggesting that Vodafone now welcomed regulation of rates and it is with some irony that on Monday both the Commerce Commission and Minister for Communications and Information Technology, Steven Joyce, announced that they were investigating this new plan to see whether this should be factor in determining the outcome of his decision to either accept a voluntary industry agreed pricing model, or force Government regulation upon the industry.

Despite my tongue in cheek comments last week my stance on the matter is one of impartiality. I agree that mobile calling costs in New Zealand are too high, however I realise that MTR costs are not the cause of high costs in New Zealand. A lack of competition in the marketplace is the sole cause of high rates, competition from 2degrees and virtual network operators such as Slingshot, TelstraClear and Compass has forced retail prices down. The exception has been regular calling prices for Prepaid users on Vodafone and Telecom which are stick stuck in the last decade at 89c per minute.

Revenue for mobile operators is a two way system. Revenue is gained from mobile users who make calls, send text messages, use data or access STK (SIM toolkit) based network services. Revenue is also gained from inbound termination rates that are in essence "earned" by that user, and the network as a whole, when inbound calls and text messages are sent to a user of the network. The common argument is that if revenue is lost from one part of the business it will simply have to be recovered from another part of the business, an economic principle known as the "waterbed effect".

The real world reality is that terminating traffic on any telecommunications network, whether it be a mobile network or a fixed line network has an inherent cost, whether this figure is small or large becomes a moot point, the key point is that a cost is incurred. Carriers have two ways of recovering this revenue, by charging the carrier who is terminating traffic on their network using the Calling Party Pays (CPP) billing model or the Receiving Party Pays (RPP) model, also known as Mobile Party Pays (MPP) in some countries. CPP means that the network charges the network terminating the traffic their negotiated MTR cost to terminate traffic and is the common model used by mobile carriers in most parts of the world. RPP/MPP means that the network terminating the traffic pays no cost but the receiving party is charged by the carrier when they answer the call. This is how an 0800 number works in New Zealand and is also how mobile users are typically charged in North America where they normally pay a flat fee per month for incoming calls or have these incoming calls deducted from their included minutes.

In recent years the MTR debate has become a hot topic for regulators around the world as they have had to try and tighten their grip on what they see as a stranglehold on customers that is artificially keeping the prices of calling mobile phones from landlines and mobile calls between networks much higher than they should be. What is clear is that while many see MTRs as the smoking gun, and that by cutting MTRS they will cut the price of calls and text messages, nobody is able to agree on exactly what constitutes a fair price for termination, or even how much terminating a call on a mobile network really does cost. What is clear is that as MTRs have been forced down by European Regulators prices have not necessarily followed suit , and in many cases have increased as operators try to recover lost revenue [1].

If McBiddle's (a global fast food chain focussing on burgers) were regulated forced by a Government body to slash the price of their McBiddle Deluxe burger by 50% it's inevitable that these costs would have to be reclaimed from elsewhere, whether by cost cutting, charging a fee to dine in, cutting free drink refills or making the McBiddle burger only available as part of a combo meal. The mobile market is no different.

In 2005 the New Zealand Commerce Commission took the opinion that the waterbed existed when in it's final report into regulation of MTAS it wrote:

A regulated fall in mobile termination rates is likely to lead to some rise in the price of mobile
services (mobile subscription and mobile-to-mobile calls), relative to the scenario of no
regulation, or alternatively, lesser price reductions than otherwise. To the extent that
regulation leads to a relative increase in mobile prices, and a reduction in mobile
subscription levels, a range of determinants may be generated. Accordingly, this effect has
been factored into the cost-benefit analysis


So what annoyed the the Minister and the Commission yesterday?

  • 200 minutes of calling to any other Vodafone mobile or to any landline phone in New Zealand (on any network) for $12 per month

So what's wrong with that you might ask? Well I raised the issue last week that if those whole 200 minutes were used to call between Vodafone mobiles then it would represent an on-net net MTR rate that is less than Vodafone are willing to offer other carriers to terminate voice traffic. As many people have pointed out not everybody will use all of these minutes or even use them all to call another on-net mobile phone. It is expected that calls to landline phones will make up a significant percentage of these 200 minutes, and Vodafone will be paying approximately 2c per minute to terminate these calls with a fixed line provider. If these 200 minutes were split evenly between mobiles and landlines the net cost of calling another Vodafone mobile would be 12c per minute which is around the same rate that Vodafone and Telecom have proposed to the Minister.

It's worth remembering that deals like this are nothing new. Vodafone have already offered a Your Time 200 You Choose addon for a number of years that offers 200 mins of on-net only calling for $11.95 per month. Telecom offer business customers the ability to make calls to any Telecom mobile phone and speak for up to an hour for $1 + GST. Telecom Favourites also offers the ability to nominate mobile and landline numbers that can be called as much as you want for a flat rate of $6 per number, and likewise Vodafone also offer Best Mate which allows unlimited calling to another on-net Vodafone mobile. Both networks have also had SMS plans that deliver messages both on and off net for significantly less than their current MTR rates.

Cheap on-net calls have become a feature in recent times everywhere in the world. In Australia Vodafone, Virgin and Three all now offer free on net calling and text messaging as a standard feature of many new plans. Vodafone, Optus and Three also offer unlimited plans for $99 offering unlimited calling to landlines and mobile phones on any network in Australia for $99 per month with MTR costs of approximately 9c per minute for mobile calls and fixed price termination rates for calls to landlines.

So the question has to be asked : What issues can the Commission and Minister have with Vodafone's new plan? it does not represent a significant move away from anything that already exists in the marketplace.

And the tougher question: Should the Minister accept voluntary undertakings from the industry or should he regulate?

Those pushing for regulation have to realise that the Minister sending the discussion back to the Commerce Commission could easily face another 18 months worth of delays before any regulation occurs. Are we better to accept the offer that is on the table that will take effect from this October and deliver instant MTR reductions and regular drops down to 6c per minute (billed per second) in 2014 or should we start the entire 18 month long MTAS process again, with no clearcut agenda that will force the Commissioners to accept regulation, while MTR rates stay at at their present levels?

Nobody can say it's not a challenging time ahead for Steven Joyce!



[1] Mobile Regulation and the "waterbed effect" Genakos & Valletti Jan 2010 http://www.voxeu.org/index.php?q=node/4448

Linksys SPA New Zealand Configuration

By Steve Biddle, in , posted: 20-Apr-2010 12:00





If you're using a VoIP provider there is a good chance you may well have a Linksys IP phone or Analogue Telephone Adapter (ATA). The Linksys 92x/94x series of IP phone, SPA2102 and 3102, and older SPA3000 and PAP2 ATA's are a very popular choice due to their great performance and reasonable pricing.

If you live in New Zealand and are using one of these are a handful of configuration changes that need to be made to configure the device to New Zealand telephone standards and to ensure that the tones heard match those from PSTN providers such as Telecom, TelstraClear, Orcon and Vodafone who all use the same tones which are specified in Telecom's Telepermit specifications. If you fail to correctly set some other settings such as the FXS impedance on your device you risk echo on your calls due to an impedance mismatch with your analogue phone, likewise if you set the incorrect impedance on the FXO port on a SPA3102 or SPA3000 you will also risk echo due an impedance mismatch with the PSTN line. Ideally you'll also want a correct dialplan that allows calls to connect immediately after you dial the number, and not have to wait several seconds for this to happen.

At present WorldxChange are the only VoIP provider in New Zealand to offer a full autoprovisiong service for their customers. If you sign up to their VFX or DVX service you can enter a URL into your device which will connect to their servers and correctly configure your device with the optimal settings and user settings.


If you're using another provider such as 2talk, iTalk, or a Linksys device on your own IP PBX, you're on your own when it comes to configuring your device. These providers and others provide a list of settings, however many of these are either not correct or not optimal for New Zealand. This leaves people who know nothing about VoIP left to configure their own device, and in many cases making mistakes or using incorrect settings that may result in an inferior quality call, and left blaming VoIP as being an inferior technology when the reality is it's not.

I've been working for several weeks on a New Zealand specific configuration file for Linksys devices, and also hosting this file so that anybody who wants to quickly and easily configure their device can enter a web URL into their device which will download all the correct settings. The only thing required by the end user is to configure their SIP user account details, network settings, and a couple of other optional setting that I'll leave to the end user such as the preferred voice codec. By default your device will check once per week for a new configuration file however this can be easily disabled if you do not want to do this. Instructions on how to change this are at the bottom.

To enable this provisioning file log into your device and click on the Provisioning tab. Into the Profile Rule field enter the following http://voipzone.co.nz/spaconfig.cfg  Also check that the Provision Enable is set to Yes and Resync On Reset is also set to Yes



Your device will now reset and download the provisioning file. This can take approximately 30 seconds or so to occur and once it is complete the device will reset again. If you look in the menu options listed below you should now see these updated to reflect the new settings.

A list of all settings in my file is listed here. This file could change in the future if any updates are needed and because it's a XML file rather than a LInksys compiled configuration file you can view the contents of the file at any time from a web browser by entering the URL above.



<!-- Linksys SPAxxx Config File with NZ specific indications and setup (C)2010 Steven Biddle [email protected] ->

  <Resync_Periodic ua="na">604800</Resync_Periodic>
  <Primary_NTP_Server ua="na">nz.pool.ntp.org</Primary_NTP_Server>
  <Dial_Plan_1_ ua="na">(#|*xx|*0xx.|[2-9]xxxxxx|xxxS1|0210xxxxxxx|0212xxxxxx|021[3-9]xxxxx|02[0279]xxxxxxx|0240xxxxxx|024[1-9]xxxxxxx|028[0134567]xxxxxx|028[289]xxxxxxx|026[1-3]xxxxx|0264xxxxxx|0[34679][0-9]xxxxxx|0508xxxxxx|070xxxxxxx|080[0-8]xxxxxx|1xxx|08[2-3]xxx|01681x.|083201234|014xx|015xxx|017[02]|00x.)</Dial_Plan_1_>
  <Time_Zone  ua="na">GMT+13:00</Time_Zone>
  <Daylight_Saving_Time_Rule ua="na">start=4/1/7/3;end=9/-1/7/2;save=-1</Daylight_Saving_Time_Rule>
  <Time_Format ua="na">24hr</Time_Format>
  <Date_Format ua="na">day/month</Date_Format>

  <Call_Return_Code ua="na"> </Call_Return_Code>
  <Blind_Transfer_Code ua="na"> </Blind_Transfer_Code>
  <Call_Back_Act_Code ua="na"> </Call_Back_Act_Code>
  <Call_Redial_Code ua="na"> </Call_Redial_Code>
  <Call_Back_Busy_Act_Code ua="na"> </Call_Back_Busy_Act_Code>
  <Cfwd_All_Act_Code ua="na"> </Cfwd_All_Act_Code>
  <Cfwd_All_Deact_Code ua="na"> </Cfwd_All_Deact_Code>
  <Cfwd_Busy_Act_Code ua="na"> </Cfwd_Busy_Act_Code>
  <Cfwd_Busy_Deact_Code ua="na"> </Cfwd_Busy_Deact_Code>
  <Cfwd_No_Ans_Act_Code ua="na"> </Cfwd_No_Ans_Act_Code>
  <Cfwd_No_Ans_Deact_Code ua="na"> </Cfwd_No_Ans_Deact_Code>
  <Cfwd_Last_Act_Code ua="na"> </Cfwd_Last_Act_Code>
  <Cfwd_Last_Deact_Code ua="na"> </Cfwd_Last_Deact_Code>
  <Accept_Last_Act_Code ua="na"> </Accept_Last_Act_Code>
  <Accept_Last_Deact_Code ua="na"> </Accept_Last_Deact_Code>
  <Block_Last_Act_Code ua="na"> </Block_Last_Act_Code>
  <Block_Last_Deact_Code ua="na"> </Block_Last_Deact_Code>
  <CW_Act_Code ua="na"> </CW_Act_Code>
  <CW_Deact_Code ua="na"> </CW_Deact_Code>
  <CW_Per_Call_Act_Code ua="na"> </CW_Per_Call_Act_Code>
  <CW_Per_Call_Deact_Code ua="na"> </CW_Per_Call_Deact_Code>
  <Block_CID_Act_Code ua="na"> </Block_CID_Act_Code>
  <Block_CID_Deact_Code ua="na"> </Block_CID_Deact_Code>
  <Block_CID_Per_Call_Act_Code ua="na"> </Block_CID_Per_Call_Act_Code>
  <Block_CID_Per_Call_Deact_Code ua="na"> </Block_CID_Per_Call_Deact_Code>
  <Block_ANC_Act_Code ua="na"> </Block_ANC_Act_Code>
  <Block_ANC_Deact_Code ua="na"> </Block_ANC_Deact_Code>
  <DND_Act_Code ua="na"> </DND_Act_Code>
  <DND_Deact_Code ua="na"> </DND_Deact_Code>
  <Secure_All_Call_Act_Code ua="na"> </Secure_All_Call_Act_Code>
  <Secure_No_Call_Act_Code ua="na"> </Secure_No_Call_Act_Code>
  <Secure_One_Call_Act_Code ua="na"> </Secure_One_Call_Act_Code>
  <Secure_One_Call_Deact_Code ua="na"> </Secure_One_Call_Deact_Code>
  <Paging_Code ua="na"> </Paging_Code>
  <Call_Park_Code ua="na"> </Call_Park_Code>
  <Call_Pickup_Code ua="na"> </Call_Pickup_Code>
  <Call_UnPark_Code ua="na"> </Call_UnPark_Code>
  <Group_Call_Pickup_Code ua="na"> </Group_Call_Pickup_Code>
  <Media_Loopback_Code ua="na"> </Media_Loopback_Code>
  <Referral_Services_Codes ua="na"> </Referral_Services_Codes>
  <CID_Act_Code ua="na"> </CID_Act_Code>
  <CID_Deact_Code ua="na"> </CID_Deact_Code>
  <CWCID_Act_Code ua="na"> </CWCID_Act_Code>
  <CWCID_Deact_Code ua="na"> </CWCID_Deact_Code>
  <Dist_Ring_Act_Code ua="na"> </Dist_Ring_Act_Code>
  <Dist_Ring_Deact_Code ua="na"> </Dist_Ring_Deact_Code>
  <Speed_Dial_Act_Code ua="na"> </Speed_Dial_Act_Code>
  <Modem_Line_Toggle_Code ua="na"> </Modem_Line_Toggle_Code>

  <Dial_Tone ua="na">400@-15;30(*/0/1)</Dial_Tone>
  <Second_Dial_Tone ua="na">400@-15;30(*/0/1)</Second_Dial_Tone>
  <Outside_Dial_Tone ua="na">400@-15;30(*/0/1)</Outside_Dial_Tone>
  <Busy_Tone ua="na">400@-15;*(.5/.5/1)</Busy_Tone>

  <Reorder_Tone ua="na">400@-15;*(.25/.25/1+2))</Reorder_Tone>
  <Call_Waiting_Tone ua="na">400@-15;9(.2/3/1,.2/3/1,.2/3/1,.2/0/1)</Call_Waiting_Tone>
  <Off_Hook_Warning_Tone ua="na">400@-15;*(.25/.25/1+2)</Off_Hook_Warning_Tone>
  <Ring_Back_Tone ua="na">400@-15,450@-15;*(.4/.2/1+2,.4/.2/1+2,2,2/0/0)</Ring_Back_Tone>
  <MWI_Dial_Tone ua="na">400@-15;2.5(.1/.1/1);27.5(*/0/1)</MWI_Dial_Tone>
  <Confirm_Tone ua="na">400@-15,450@-15;10(0.2/0.4/1+2,2/0.4/1+2)</Confirm_Tone>
  <Cfwd_Dial_Tone ua="na">400@-15,450@-15;10(0.2/0.4/1+2,2/0.4/1+2)</Cfwd_Dial_Tone>
  <Holding_Tone ua="na">400@-15,450@-15;*(.5/.5/1),(.5/2.5/1+2)</Holding_Tone>

  <Reorder_Delay ua="na">1</Reorder_Delay>
  <Ring_Frequency ua="na">25</Ring_Frequency>
  <CWT_Frequency ua="na">400@-15</CWT_Frequency>

  <Interdigit_Short_Timer ua="na">3</Interdigit_Short_Timer>

  <Ring1_Cadence ua="na">60(.4/.2,.4/2)</Ring1_Cadence>
  <Ring2_Cadence ua="na">60(.4/2.6)</Ring2_Cadence>
  <Ring3_Cadence ua="na">60(.4/.2,.4/.2,.4/1.4)</Ring3_Cadence>
  <Ring4_Cadence ua="na">60(.4/.8,.4/1.4)</Ring4_Cadence>
  <Ring5_Cadence ua="na"> </Ring5_Cadence>
  <Ring6_Cadence ua="na"> </Ring6_Cadence>
  <Ring7_Cadence ua="na"> </Ring7_Cadence>
  <Ring8_Cadence ua="na"> </Ring8_Cadence>
  <Ring_Waveform ua="na">Sinusoid</Ring_Waveform>

  <CWT1_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT1_Cadence>
  <CWT2_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT2_Cadence>
  <CWT3_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT3_Cadence>
  <CWT4_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT4_Cadence>
  <CWT5_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT5_Cadence>
  <CWT6_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT6_Cadence>
  <CWT7_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT7_Cadence>
  <CWT8_Cadence ua="na">10(.2/3,.2/3,.2/3)</CWT8_Cadence>

  <RTP_Packet_Size ua="na">0.020</RTP_Packet_Size>
  <FXS_Port_Impedance ua="na">370+620||310nF</FXS_Port_Impedance>
  <Disconnect_Tone ua="na">400@-15;*5(.25/.25/1+2)</Disconnect_Tone>
  <FXO_Port_Impedance ua="na">370+620||310nF</FXO_Port_Impedance>



RESYNC PERIODIC = time of 604800 which is 7 days. The device will check every 7 days (or on reset) for a new configuration.

NTP/Time settings = Use nz.pool.ntp.org as a time server. Also correctly configure NZ DST settings. Because of a bug in earlier Linksys firmware not being able to handle DST in the Southern Hemisphere starting in a different year to the end date we reverse things and use GMT+13 as the normal time during DST and deduct 1hr from April to September.

All service activation codes have been disabled to stop them clashing with codes your VoIP provider or PBX may use. Depending on your setup you may wish to set some of these again. For example if you use an ATA you will not get the correct Call Forward dialtone with DND/CallFwd enabled if you do not map these to your VoIP provider or PBX as the ATA has no idea about these codes. This is not needed with an IP phone as the DND/Cfwd is managed via SIP messages. 

All tones have been set to the NZ standard as defined by Telecom's TNA102 specifications. The only exception to this is the Reorder tone which is technically incorrect but these devices use this tone differently to normal POTS phones. All tones have been set to -15dB which is slightly louder than the -19dB Linksys default settings (I'm open to discussion as to whether this is too loud or too quiet, I personally think it's about right). Distinctive Ring cadences have also been set to the Telepermit specifications.

RTP packet size has been set to 20ms and both FXO and FXS line impedance has been set to the correct 370+620||310nF that is used here in NZ (and is clearly documented in the Telepermit specifications).


Some new firmware releases from Linksys do not support this setting. If this option is not available the safest option to use is 600 Ohm.

And now to look at the dialplan. This will pattern match virtually every number that the normal person will need to call. I've detailed the number ranges below and how they are matched. While I've put a lot of effort into this there is a chance that some errors may exist or there could be service numbers or calling card access numbers that I have missed. Any feedback on these is appreciated.

# = Asterisk/FreePBX directory
*xx = Asterisk/FreePBX shortcodes
*0xx.= Linksys codec selection. Also pattern matches *0 for Epygi Quadro Voicemail access
[2-9]xxxxxx = local calls
xxxS1 = local 3 digit PBX extns with short timeout as well as 3 digit emergency and service codes 111, 123 etc
0210xxxxxxx = 0210 + 8 digits
0212xxxxxx = 0212 + 7 digits
021[3-9]xxxxx = 0213 - 0219 + 6 digits
02[0279]xxxxxxx = 020 + 022 + 027 + 029 + 7 digits
0240xxxxxx = 0240 + 6 digits
024[1-9]xxxxxxx = 0241 - 0249 + 7 digits
028[0134567]xxxxxx = 0280 + 0281 + 0283 + 0284 + 0285 + 0286 + 0287 + 7 digits
028[289]xxxxxxx = 0282 + 0288 + 0289 + 8 digits
026[1-3]xxxxx = 0261 + 0262 + 0263 + 6 digits
0264xxxxxx = 0264 + 7 digits
0[34679][0-9]xxxxxx = all 03 + 04 + 06 + 07 + 09 toll calls as well as 0900
0508xxxxxx = 0508
070xxxxxxx = 070 personal numbers. Allocated for use but not currently in use. Possible that shortly they may be available.
080[1-8]xxxxxx = 0800 + 0800 - 0808 as defined by NAD guidelines but not currently used
1xxx = service codes mainly Telecom
08[2-3]xxx = 082210 and 083210 for voicemail on WxC and Telecom and Telecom's 083030, 083032 and 083033 conferencing
01681x. = Telecom's USA toll free service for calling North American toll free 800 numbers
083201234 = recorded message number you are calling from
014xx = calling card platform
015xxx = calling card platform
017[02] = 0170 and 0172 for international directories
00x. = international calls

In trying to create a dialplan that can be used across both standalone phones and phones connected to a PBX there is one small issue I am aware of that is not possible (at least that I can work out!) to resolve. To try and pattern match local 3 digit PBX extensions as well as local 7 digit numbers means using a small delay (S1) after the phone detects 3 digits. If you are dialling a 7 digit local number and pause for too long after the 3rd digit you will find that the call is pattern matched as a 3 digit local number.


VoIP "hacking" is becoming a real risk these days and if you have an insecure VoIP device you are leaving yourself wide open to possible fraud. Do not under any circumstances port forward the web interface for your IP phone or ATA so it's accessible from the web. This is about as secure to leaving your front door wide open!

From VoIP security perspective inbound URI calling also poses security risks that end users need to be aware of. URI calling is the ability to call another SIP device directly over the internet without the call going via a VoIP provider or PSTN. If you have a Linksys ATA at home on your internet connection somebody else using a VoIP device can call you directly by dialling the SIP URI [email protected], ie [email protected]

There have been numerous cases lately of SIP trojans actively scanning devices looking for valid user accounts. Once it detects a SIP device on port 5060 it repeatedly tries usernames until it finds the correct one. I recommend that you set "'AUTH INVITE" to 'YES' in your Linksys device configuration. This will only allow a SIP invite message from an authorised SIP peer (ie your VoIP provider). This setting will disable the ability to accept inbound SIP URI calls so if you need this ability do not change this setting.


EDIT: It seems this setting may disable inbound calls on iTalk and 2talk. If you are using iTalk or 2talk leave this setting set to 'no'. Another option which exists only in the ATA devices called 'Restrict Source IP' that will lock down inbound SIP traffic to the IP of your SIP proxy server. Setting this to 'yes' will perform a similar job.


As mentioned above entering this provisioning URL this file will cause the device to attempt to reprovision itself once every 7 days to get an updated configuration file. If you want to disable this feature set the "Provision Enable" setting show in the web interface menu above to "NO". If you are going to change any of the settings listed above such as the Service Activation Codes it's important that you change this setting to "NO". If you fail to do this your changes will be deleted every week when the device checks for a new configuration file.

If you are uncertain about proceeding with this URL I recommend taking a snapshot of your current settings, in particular  your dialplan before proceeding. This file will only change the settings listed above, it will not change any other settings in your device such as network or SIP user settings. If you are unhappy with the results you can return to your existing configuration by disabling the Provision Enable setting as detailed in the paragraph above, removing the provisioning URL, and manually entering your settings again.


I've been using Linksys devices for many years but only recently decided to publish this information because the number of poorly configured devices and misinformation about NZ configurations got the better of me! I'm open to any feedback or comments about this project and am very interested in comment about the dialplan settings. It is possible this setting may stop you being able to dial some numbers and some PBX's may use different codes that I have not included. Please let me know about any issues so I can attempt to resolve them.

I have also developed a modified trixbox Linksys autoprovisioning tool that will help those who are using Asterisk, trixbox or Elastix and want to correctly configure their Linksys devices with their PBX. For help with this or to suggest improvements my contact details are listed in the right.

PS: Thanks also has to go to Mike Beattie who helped test the dialplan settings.

PPS: If you are going to include these settings on your site some link love to my post and acknowledgement would be appreciated.

Vodafone welcomes MTAS regulation*

By Steve Biddle, in , posted: 13-Apr-2010 20:45

Vodafone today launched a new mobile add-on plan into the marketplace. Offering 200 minutes of calls to other Vodafone mobiles or landlines in New Zealand at any time of the day or night for $12 it is arguably the best value mobile add-on in New Zealand. The catch is that it's only available to Prepay users - if you're a On Account user helping prop up Vodafone's ARPU you've just been given the big finger. Vodafone do assure us this plan is coming "soon" to On Account plans, but right now we're all stuck paying more than a pimply teenager who had absolutely no brand loyalty.

$12 for 200 minutes equates to 6c per minute for a call to any other on net Vodafone mobile or landline. That's fantastic value in anybody's terms and is the cheapest available calling rate available on any mobile network in NZ for calling another mobile or landline (excluding deals such as Best Mate, TalkZone or Favorites that only allow calling to nominated numbers. The launch of 2degrees in New Zealand has finally broken the mobile duopoly that existed in New Zealand and finally lead to some significant competition for the customers hard earned dollar.

I've blogged on numerous occasions about the Commerce Commission led MTAS (Mobile Termination Access Services) investigation that has been in place for approximately 18 months. This purpose of this investigation was to look at mobile termination rates (MTRs) - the rates that mobile operators charge each other for terminating voice calls and SMS messages on their network. These rates have been falling consistently for the last 10 or so years from approximately 45c per minute down to approximately 18c per minute now. Many people believe that high MTR costs cause inflated retail mobile calling rates, a conclusion that I neither agree with or have seen compelling evidence to agree with. What is clear however is that rate should be set to reflect the cost of terminating an inbound voice call on the network, it should not be used as a revenue source for operators. International benchmarking shows that our current MTR costs are not excessive but  globally pressure is being put on mobile operators by regulators to force these MTR costs down, primarily because they believe current charges are inflated and do not reflect the true cost of terminating a call in this day in age.

In early 2009 the Commerce Commission welcomed dialogue from all interested parties and in June 2009 issued a draft recommendation that recommended prices should be cut significantly. Needless to say this didn't go down well with either Telecom or Vodafone who were intent on maintaining the status quo. Because only two mobile operators existed in the marketplace the charge became almost irrelevant for calls and SMS messages between Vodafone and Telecom - while they paid the other provider money when a call made off network, they received money when a call was terminated on their network. While there was a marginal imbalance in voice termination rates, SMS termination rates were very equal for both networks which meant very little money actually changed hands at the end of the day. This cosy duopoly upset new entrant 2degrees, who aggressively campaigned for MTR costs to be lowered significantly and also pushed for a move away from the Calling Party Pays (CPP) pricing model to Bill and Keep (BAK) as a replacement pricing model. BAK would mean no money would ever be paid from one operator to another, and that mobile operators would in effect receive no money for terminating a call on their network. This model is used in the USA and typically means that a mobile user pays for incoming calls (normally out of included minutes) as a way of the mobile provider recovering call termination revenue. 2degrees funded what I consider to be a dirty tricks campaign known as Drop The Rate, Mate! that mislead people into thinking that MTR costs were the root cause of high mobile calling costs and the lack of competition in NZ, however the hugely successful launch of 2degrees into the marketplace with aggressive pricing shows that the existing regulatory environment was not broken - we were being ripped off as mobile users because of a lack of competition in the marketplace. Despite MTR costs having fallen by well over 50% in recent years, retail pricing has not followed suit with a Vodafone or Telecom prepaid mobile user still paying similar rates now to what they were three years ago.

In the following months plenty of debate took place and numerous submissions were made by all three networks putting forward their cases. The Commission indicated it would prefer an industry lead solution rather than being forced to regulate the market and in December 2009 both Vodafone and Telecom submitted final submissions to the Commerce Commission pledging to reduce MTR costs for voice calls to 12c per minute (billed per second) from October 2010 and gradually reducing to 6c per minute (billed per second) by 2014. 2degrees threw all of their toys out of the cot believing the Commerce Commission were ignoring them, and withdrew all offers they had previously put on the table.

In February 2010 the Commission delivered it's final report to the Minister for Communications and Information Technology, Steven Joyce. This report recommended that the Minister should accept the submissions from both Telecom and Vodafone rather than regulating the market, but the decision was not without controversy, only two of the three Commissioners involved in the investigation agreed with this approach, with Commissioner Anita Mazzoleni recommending that regulation of the market take place.

So now back to todays news..Vodafone have now told us loud and clear that  6c per minute is now sufficient revenue for an on net call from one Vodafone customer to another Vodafone customer. One has to now ask the question - why do Vodafone believe that the rate for any other mobile network operator to terminate a call on the Vodafone network should exceed 6c per minute from today? If that 6c was split 50/50 between the revenue cost of the A party making the call and B party answering the call then that MTR cost should not exceed 3c per minute. What possible argument could Vodafone have for charging another network operator more to terminate a call on the Vodafone network than they "charge" themselves?

The decision  to either accept the proposals from Vodafone and Telecom currently sits with Minister Joyce, who has the decision as to whether he should accept voluntary proposals from both networks or with the full force of the law regulate MTR pricing. Vodafone have now very openly come out and made a mockery of many of their claims that MTR costs can't drop to 6c until 2014. I'm no fan of regulation but if I were Minister Joyce I'd calling Vodafone's bluff and  recommending regulation. Thumbing your nose at both the Commission and Minister like Vodafone have done is not smart business.


*= my opinion of what Vodafone's new plan represents

Configuring inbound SIP URI calls with trixbox

By Steve Biddle, in , posted: 2-Apr-2010 21:34

One of the great things about VoIP is the ability to make calls directly between VoIP phones, over the internet, without having to pay anything for the cost of the call.

Most IP phones on the market allow IP dialling direct to another phone. Many VoIP providers allow outbound SIP calling from phones to any SIP device on the internet. Some, but not all will allow inbound SIP URI calls. If you are running an IP PBX such as trixbox (or any Asterisk variant) you have the ability to accept inbound URI calls but this feature may not configured.

A SIP URI (Uniform Resource Locater) is essentially a form of  internet phone number, except it follows a SIP:name@domain or SIP:number@domain format and looks much like a cross between an email address and a website (but should not be confused with either). If you have a trixbox PBX with multiple extensions, IVR, or ringgroups, these can be called directly over the internet by another VoIP user, direct to your PBX, without having to go via the regular PSTN network or your VoIP provider. To implement this feature you need to have a static IP address for your internet connection, or be using a dynamic hostname provider such as DDNS.

Lets say your company is called Acme Phone Systems and you have the domain name of www.acmepbxphonesystems.com. You have 3 telephone extensions and a main incoming IVR welcoming callers, and want to allow people the ability to call you via SIP URI as well as your existing PSTN phone numbers.

You could allocate the main IVR it's own SIP URI which will allow callers to connect directly over the internet without having to call your PSTN phone number. They could simply call [email protected] from their IP phone and be connected directly you IP PBX. Likewise you could also allow individual extensions to be called, for example [email protected] or [email protected]. If you wanted you could also use your existing PSTN phone number and use [email protected] - the choice is up to you.

By default trixbox will not allow anonymous inbound SIP calls for security reasons. This feature is controlled by a setting "Allow Anonymous Inbound SIP Calls" which is in the General Settings menu.



Changing this to YES will automatically allow SIP URI's to work, but it's an extremely bad move. Unless you fully understand the significant security implications of enabling this it should always be set to off. Enabling this has the ability to allow unauthorised users to have access to your system and make free outbound calls if you have your system poorly configured or an insecure dialplan. When this is set to NO most inbound SIP URI calls will not be authenticated (ie they are anonymous) and will be blocked. A message saying "the number you have dialled is not in service" will be heard by the caller trying to call a SIP URI on your trixbox system.

A few simple changes need to be made to the trixbox configuration to allow inbound URI calls.

Log into your trixbox PBX and go to the PBX menu and select Config File Editor. This allows manual editing of all the Asterisk and trixbox configuration files.

  1. Click on /etc/asterisk
  2. Click on extensions.conf
  3. Click on from-sip-external
  4. Select and copy this text to your clipboard with Crtl-C

This text is the context settings called [from-sip-external] that processes all inbound SIP calls into your PBX. We can't edit this file because it's self generated by FreePBX, so we need to insert it into the extensions_override_freepbx.conf file.

As of March 2010 the content of this context is as follows, but is subject to change in future which is why it's best to use your own local copy.

;give external sip users congestion and hangup
; Yes. This is _really_ meant to be _. - I know asterisk whines about it, but
; I do know what I'm doing. This is correct.
exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
exten => _.,n,Goto(s,1)
exten => s,1,GotoIf($["${ALLOW_SIP_ANON}"="yes"]?from-trunk,${DID},1)
exten => s,n,Set(TIMEOUT(absolute)=15)
exten => s,n,Answer
exten => s,n,Wait(2)
exten => s,n,Playback(ss-noservice)
exten => s,n,Playtones(congestion)
exten => s,n,Congestion(5)
exten => h,1,NoOp(Hangup)
exten => i,1,NoOp(Invalid)
exten => t,1,NoOp(Timeout)


  1. Click on /etc/asterisk
  2. Click of extensions_override_freepbx.conf
  3. Paste the contents of your clipboard into the editor using Ctrl-V

The [from-sip-external] context will now be used from the extensions_override_freepbx.conf file instead of the extensions.conf file. You can now manually edit this file to allow certain inbound SIP URI destinations to pass to your Inbound Routes in the PBX menu. These can be added in the area show below ====>>>>

    ;give external sip users congestion and hangup
    ; Yes. This is _really_ meant to be _. - I know asterisk whines about it, but
    ; I do know what I'm doing. This is correct.
    exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
    exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
    exten => _.,n,Goto(s,1)
    exten => s,1,GotoIf($["${ALLOW_SIP_ANON}"="yes"]?from-trunk,${DID},1)


    exten => s,n,Set(TIMEOUT(absolute)=15)
    exten => s,n,Answer
    exten => s,n,Wait(2)
    exten => s,n,Playback(ss-noservice)
    exten => s,n,Playtones(congestion)
    exten => s,n,Congestion(5)
    exten => h,1,NoOp(Hangup)
    exten => i,1,NoOp(Invalid)
    exten => t,1,NoOp(Timeout)


    A few examples:

    exten => 202,1,Goto(from-trunk,202,1)

    exten => 205,1,Goto(from-trunk,205,1)

    exten => office,1,Goto(from-trunk,office,1)


    The file will now look like this:


    ;give external sip users congestion and hangup
    ; Yes. This is _really_ meant to be _. - I know asterisk whines about it, but
    ; I do know what I'm doing. This is correct.
    exten => _.,1,NoOp(Received incoming SIP connection from unknown peer to ${EXTEN})
    exten => _.,n,Set(DID=${IF($["${EXTEN:1:2}"=""]?s:${EXTEN})})
    exten => _.,n,Goto(s,1)
    exten => s,1,GotoIf($["${ALLOW_SIP_ANON}"="yes"]?from-trunk,${DID},1)
    exten => office,1,Goto(from-trunk,office,1)
    exten => 202,1,Goto(from-trunk,202,1)
    exten => s,n,Set(TIMEOUT(absolute)=15)
    exten => s,n,Answer
    exten => s,n,Wait(2)
    exten => s,n,Playback(ss-noservice)
    exten => s,n,Playtones(congestion)
    exten => s,n,Congestion(5)
    exten => h,1,NoOp(Hangup)
    exten => i,1,NoOp(Invalid)
    exten => t,1,NoOp(Timeout)


    We now need to set up some inbound routes in the PBX, Inbound Routes menu. An inbound route needs to be created for each SIP URI that you created above. Give the Incoming route a name and in the DID field enter the number or name that you used above for the URI and set the destination. For extension 202 you would like this to go to your local extension 202. For the office you may want to set this to a ring group or IVR menu.


    image image


    Once you have these set up you're all up and running. Any inbound SIP calls to the SIP addresses you specified will now be passed through to the selected destinations!



Configuring DDI’s on WxC DVX trunks with Asterisk / trixbox

By Steve Biddle, in , posted: 25-Mar-2010 10:18

I've been a user of WxC's VFX VoIP service for a number of years now and believe they offer New Zealand's best VoIP platform for both residential and business users.

WxC offer two VoIP products in the marketplace - a residential VoIP offering called VFX and a business offering called DVX. DVX is a true SIP trunking service and offers features such as multiple inbound DDI numbers that are not available using the VFX service. I've configured VFX on numerous Asterisk systems and DVX on numerous Epygi Quadro PBX's but had never configured a DVX trunk on an Asterisk based system until I sat down last week to test a configuration.

If you're configuring multiple phone numbers with a SIP based system the easiest way is to create an individual SIP registration for each line. This defeats the purpose of a SIP trunk however and doesn't deliver a truly scalable solution - if you had 200 DDI numbers for example you would require 200 SIP registrations which is a lot of unnecessary SIP traffic. A true SIP trunking product such as the Broadsoft solution WxC offer can handle all these DDI's through a single parent registration however Asterisk needs a few tweaks to be able to handle these DDI numbers correctly.

My understanding is that people who have deployed DVX in the past have manually added additional registration lines to their sip.conf or sip_custom.conf files to forward these DDI numbers to the correct inbound route. I decided to look at a much easier way to do this that avoids requiring multiple SIP registrations and after a few minutes work came up with a new custom context that can be used as your inbound trunk in your DVX settings.


By default Asterisk can't see the DDI number - it processes it's inbound route thinking the originating number is the parent registration


Executing [91234560@from-trunk-dvx:1]


This context looks at the inbound SIP URI and extracts the DDI from the To: header and then passes this through to the regular from-trunk context that is used for inbound calls.


SIP/SPgtXt7P1OlxZDN9ao-b7c33798", "DVXDDI="User1 3bitdemo" <sip:[email protected];rinstance=4baa739e26af491b


It can now pass this to the from-trunk context using the number 91234561 rather than 91234560


To configure this you you need to manually edit extensions_custom.conf and add the following

exten => _.,1,Noop(Extract DVX DDI/DID info from SIP URI header. By Steve Biddle [email protected])
exten => _.,n,Noop(NoOp(SIP_HEADER : ${SIP_HEADER})
exten => _.,n,Set(DVXDDI=${SIP_HEADER(To)})
exten => _.,n,Set(DVXDDI=${CUT(DVXDDI,@,1)})
exten => _.,n,Set(DVXDDINAME=${CUT(DVXDDI,",1)})
exten => _.,n,Set(DVXDDI=${CUT(DVXDDI,:,2)})
exten => _.,n,Goto(from-trunk,${DVXDDI},1)


In your sip.conf or FreePBX web interface change the context=from-trunk to context=from-trunk-dvx

You can now configure these inbound routes using the DDI number and set the extension you require these to go to. This now results in a single SIP parent registration rather than multiple registrations for each DDI number.


And now a plug from me..If anybody is interested in assistance or support with Asterisk based systems or wanting help in deploying an Asterisk based PBX feel free to contact me!

I’m after a job!

By Steve Biddle, in , posted: 16-Mar-2010 10:14

If you've followed my forum posts and blog here on Geekzone over the last few months you're probably aware of the fact I've been unemployed since November after being made redundant. I decided to have a few months off over Summer relaxing (partially ruined by the fact Summer never seemed to make it to Wellington this year!) and working on a few other projects. Spending my days at the gym, socialising and catching up for coffee and lunch is a great lifestyle, but unfortunately isn't so great from a financial point of view!

To cut a long story short I'm on the lookout for another job or some more casual work in the Wellington region. Right now I have some part time projects I'm working on but I need some more challenges in life and am open to offers. . . .If you've followed me over the years you'll probably have a good idea of what interests me and where my skills lie!

I like to think I'm a bit of a guru when it comes to VoIP stuff - I've been playing with VoIP for over 5 years now have a fantastic knowledge of design and installation of IP PBX's and associated hardware. I've spent a huge amount of time playing with Asterisk and am a fan of both trixbox and Elastix. I've also worked on Epygi Quadro and 3CX PBX's and have a good knowledge of handsets and adapters from Polycom, Linksys, Snom, Aastra, Grandstream and Patton. I have a basic knowledge of Microsoft OCS and have successfully integrated my OCS setup with trixbox for external connectivity. I've also spent a lot of time playing with traditional analogue phones and PBX's and have a good knowledge of these.

I'm pretty handy when it comes to cabling work and have done numerous structured network cabling installations for phones and data in both homes and businesses. I've also installed a fair few TV aerials over the years and have a good knowledge of cabling requirements and setup of home theatre systems. I've  installed numerous CCTV and alarm systems and love electronics. Having spent time in retail I'm also pretty handy when it comes to the installation, support and best practice guidelines for EAS tagging systems.

I've been building PC's for many years and have a good knowledge of PC hardware and both Microsoft desktop and server operating systems. I'm no Linux expert but know the basics.

I'm an engineer who likes to build things, fix things, or develop innovative ideas into solutions that work. I'm not big on selling stuff but am more than capable of doing this. Cold calling is out - there is nothing that annoys me more.

I like to think I've got a pretty good understanding of the telecommunications industry in New Zealand and have a good knowledge of the various fixed line and mobile technologies used in New Zealand. I have a good understanding of both GSM and WCDMA networks and also enjoy writing about telecommunications, something you would have noticed if you've followed my blog.

I would really love to find more work in the telecommunications sector, particularly in the VoIP space as it's something I'm very passionate about. The realities however are that the market in NZ is still very much in the growing stage with plenty of cowboys who think they know their stuff trying to sell inferior solutions to gullible customers which is hurting the market. This isn't good.

If you've read my posts over the years and think I could be a good match for your company then feel free to get in touch. My contact details are listed on the right.



Permalink to I’m after a job! | Add a comment (6 comments) | Main Index

Telecom mobile history and Rod Deane's failing memory

By Steve Biddle, in , posted: 2-Mar-2010 14:04

In The Herald on Sunday last weekend journalist Matt Nippert wrote an article entited "Can Telecom survive" which gave a background into Telecom's mobile history and included comments from former Chief Executives Theresa Gattung and Rod Deane. Deane also also served as the board chairman of Telecom until 2006. Both have made very little comment about Telecom in recent years so it was certainly a coup to get comments from both of them. While reading this article I was interested in a comment from Deane over Telecom's choice of mobile technology:


Telecom also persisted with an older, CDMA technology for its mobile phone network and only recently upgraded to the newer industry-standard with XT.

Deane says that this, again, was the fault of Government. "We bought the GSM spectrum in an auction, and the Commerce Commission forced us to sell that back to Vodafone and Bell South. I still remember pleading with the Government that we should have that technology, but officials - in their infinite wisdom - decided against it."

Nonetheless, Deane concedes that history proved CDMA wasn't the technology of choice. "It was a bit like VHS versus Beta," he says. "And Telecom has effectively moved to VHS with XT."


These comments are completely and utterly wrong. Matt Nippert has either misquoted Deane, or Deane has a failing memory and should have probably checked his facts first before giving an interview.

Many people wonder why Telecom chose the CDMA path and didn't deploy GSM in the 1990's - the answer is quite simply that they did not own any spectrum that enabled them to deploy a GSM network.

In 1987 Telecom launched New Zealand's first mobile network using the AMPS (Advanced Mobile Phone System) technology. The AMPS standard used spectrum in the 800MHz band and consisted of two blocks of radio spectrum known as the AMPS A and AMPS B bands. These blocks consisted of an equal number of channels and were created so two networks could happily co-exist side by side. Telecom was granted usage right for the AMPS B band to deploy their network and over the next few years successfully rolled out a nationwide analogue mobile phone network. At this stage ownership of the AMPS A band was still retained by the Crown.

By 1990 network growth meant they required additional spectrum to expand their network, Telecom were already using some AMPS A frequencies under agreement with the Crown and were excited at the potential of upgrading the network to the DAMPS (Digital AMPS) standard that was ratified in March 1990. It was clear to analogue network operators already that the limited number of frequencies available would seriously hamper the grown of analogue networks and that a move to digital was essential. At this time the GSM standard was also being finalised but had still not been publically demonstrated.

In May 1990 the NZ Government announced that it was calling for public tenders for usage rights to the AMPS A band, and also the TACS A and TACS B bands. The TACS bands were European frequency blocks in the 900MHz band that were used for deployment of analogue TACS (Total Access Communication System) mobile networks in Europe, however they were now expected to be used for the GSM standard that were expected to launch in Europe in 1991. A 3rd block of TACS spectrum known as TACS C was not sold off as it was still currently in use by existing licence holders for non mobile services.

The New Zealand Government auctioned off these blocks of spectrum using the Vickrey auction process where the price paid by the successful bidder was that of the 2nd place bidder. At this auction Telecom New Zealand bid $101,200,000 for the AMPS A band but had a pay price of $11,500,000 which was the price bid by the 2nd place getter, First City (a Canadian investment bank). BellSouth won the usage rights to the TACS A network bidding $85,522,101 with a pay price of $25,200,000 that was bid by Telecom. Telecom Mobile Radio Ltd were the successful bidder for the TACS B spectrum bidding $7,000,000 but with a pay price of a mere $5000 from the 2nd place bidder, Broadcast Communications Ltd. Telecom bid for this TACS B spectrum through a subsidiary known as Telecom Mobile Radio Ltd who were at the time primarily providing land mobile radio services. They claimed this spectrum would be used for  "expanding demand for land mobile services, future mobile data services, and point to point linking services", however it was finally acknowledged that this spectrum was being acquired for future mobile services.

A condition of the auction was that any spectrum purchases by Telecom New Zealand had to be cleared by the Commerce Commission before the acquisition was finalised and submissions to the Commerce Commission were made on the 29th May 1990 seeking approval for the AMPS A and TACS B bands.

Immediately after this auction issues were raised over the fairness of Telecom New Zealand owning two new blocks of spectrum and appeals were lodged by several unsuccessful bidders. The Commerce Commission also began reviewing the case to test whether Telecom's purchase would be preventing competition in the mobile market. The Commerce Commission issued a draft determination on the 24th August 1990 saying that it believed Telecom's purchase of the AMPS A band was anti competitive and would result in it having a dominant position in the market as it would control 3 out of 4 available spectrum blocks for mobile services, as well as full control over the existing PSTN and interconnection with the PSTN. On the 17th October 1990 the Commerce Commission issued a final decision blocking Telecom from acquiring the management rights to the AMPS A band.

On the 31st October 1990 Telecom lodged an appeal against this ruling. Telecom had made it plainly clear that it's submissions that it's preference was for the AMPS A band over TACS B and that in it's view BellSouth would be competitive in the marketplace which placed even greater pressures on Telecom to acquire AMPS A. Telecom argued acquiring AMPS A "as the essential means by which it could at least achieve, first, greater efficiencies with its existing network notwithstanding its basic inferiority compared with digital technology and, secondly, the ultimate capacity to upgrade to digital technology without incurring inordinate expense and disruption of its existing analogue subscribers".

On November 30th 1990 the Commerce Commission cleared Telecom to acquire the management rights to the TACS B band, however Telecom were still so keen to acquire the AMPS A band that they reached a deal with the Commerce Commission and pledged to give up their rights to the TACS B band if they were successful on appeal for the AMPS A band, hoping that this compromise would avoid any competition issues.

Telecom's appeal was heard during a 12 day case before the Administrative Division in June and July 1991, and in December 1991 the High Court delivered a judgement dismissing the appeal. Leave was granted to appeal to the Court of Appeal which was Telecom's next step. It's also worth noting that Broadcast Communications had also filed legal action against the Commerce Commission which is part of the reason both cases took so long. In June 1992 the Court of Appeal ruled that subsequent to Section 97 of the Commerce Act 1986 Telecom should be allowed to purchase management rights for the AMPS A band. The court noted " it was not demonstrated that the grant of the AMPS-A frequency to Telecom would, or would be likely to, result in it acquiring or strengthening a dominant position in the cellular telephone market such that Telecom was entitled to clearance under s 66(7) Commerce Act 1986".

Telecom now had access to both AMPS A and AMPS B bands and BellSouth had access to TACS A. The TACS B band was subsequently sold to Telecom Australia (who later became Telstra) and remained unused. Throughout the 1990's Telecom proceeded to upgrade their mobile network to the DAMPS standard and ran their digital and analogue networks side by side.

What had become very clear to Telecom by the late 90's was the fact that GSM was vastly superior in many aspects to the DAMPS standard and had grown to become the defacto standard for mobile networks around the world. With the purchase of BellSouth by Vodafone Group and aggressive marketing that resulted, Telecom gradually began to lose market share and was faced with a network that was simply unable to offer the same capabilities as it's competitor.

Around 1999 it because clear to Telecom that they were going to need to look at options for replacing their AMPS/DAMPS network. At this stage Telecom still didn't own any 900MHz spectrum that enable it to deploy a GSM network, however 1800MHz spectrum was available that would enable Telecom to build an entirely new nationwide GSM network. The downside of the 1800MHz frequency was that it required significantly more cellsites to create a nationwide network than the lower 800MHz and 900MHz frequencies, and would also mean building a brand new network from scratch. Also being considered was the CDMA (Code Division Multiple Access) standard which was being sold as a solution for existing AMPS/DAMPS networks allowing a much simpler upgrade to something bigger and better. The base of installed AMPS and DAMPS networks in the USA was huge and this technology allowed an upgrade without having to entirely rebuild the network which would have been required with a 1800Mhz GSM network.

Telecom proceed with the CDMA network upgrade, rumours have it in part because of the much cheaper price, but also because of the influence put on the company by part owner Verizon who had already upgraded their AMPS/DAMPS network in the USA to CDMA. In 2001 Telecom launched it's CDMA network to much fanfare and the rest of the story is now well known. CDMA while technically superior to GSM in many aspects, suffered badly in the marketplace. GSM had become the dominant global cellular standard, and handset selection began to suffer as large players such as Nokia and Ericsson pulled the plug on CDMA handsets. Despite hurting Vodafone, Telecom never managed to reverse the rot that had already set it, and it became clear by around 2005 that Telecom seriously had to look at options to replace CDMA as their share of the mobile market was in decline.

Telecom's options right now were fairly straight forward, the GSM 850MHz standard had been around since 2002 and finally Telecom owned spectrum that allowed them to deploy a GSM network. Telecom also won a 3G 2100MHz licence at auction and would make use of it to build a dual mode GSM/WCDMA network that would be identical to that of Vodafone with 2100MHz 3G services in the cities and major towns and GSM coverage across the remainder of the country. The stage was set, but unfortunately things didn't run to plan.  Delays then occurred in the planning, delays which turned out to be a blessing in disguise for Telecom - the 850MHz 3G WCMDA standard had matured and Ericsson had deployed a huge 850MHz WCDMA network in Australia for Telstra. Ericsson now wanted to do the same thing for Telecom, and the decision was made to dump the GSM component and go with a nationwide 850MHz WCDMA network that would ultimately be built by Alcatel Lucent. XT was born.

What is clear is that at no time did the Government force Telecom to sell spectrum suitable for a GSM network to BellSouth/Vodafone as Deane claims. BellSouth had won management rights to the TACS A band. Telecom had won management rights to the TACS B band. Telecom simply picked the wrong horse, opting for the AMPS A band rather than the TACS B band when it was given a choice by the Government. Nobody knew at the time GSM would turn into a global standard and dominate over DAMPS - there wasn't even a single GSM network in the world in 1990 when the decision was made (the first GSM network was launched in Finland in 1991). Allowing Telecom to own 75% of the available mobile spectrum was frowned upon by the Commerce Commission in 1990 and it was a decision that was would certainly not be any different today.

So in a nutshell that's the history of Telecom mobile. A history that is unknown to many people, including the former Chief Executive and Chairman of the company!

Slingshot offer NZ's best ever mobile plan?

By Steve Biddle, in , posted: 27-Feb-2010 09:24

If you're an XT user and looked in the media today you'll see the competition are out to get your business!

Vodafone are offering to pay your early termination charges if you cancel your XT contract and are stuck with a bill for terminating this contract early. They will give you a free Nokia 6121 handset when you sign up with them.

Slingshot have also in on the act. Slingshot are MVNO (Mobile Virtual Network Operator) who piggyback on Vodafone's network. They are offering what is quite possibly NZ's best ever mobile deal.

A free Nokia 2730 handset
Free monthly access for 12 months (normally $20)
20 free calling minutes and 100 free TXT messages every month
25c calling to mobiles and landlines
12 month minimum contract

Slingshot also have a form letter quoting the CGA that you can send to Telecom explaining you would like to break your term contract and pay no fee.

If you're an XT user who is unhappy you certainly have plenty of options open to you if you do want to leave!

sbiddle's profile

Steve Biddle
New Zealand

I'm an engineer who loves building solutions to solve problems.

My interests and skillset include:

*VoIP (Voice over IP). I work with various brands of hardware and PBX's on a daily basis
  -Asterisk (incl trixbox, PiaF, FreePBX, Elastix and AsteriskNOW)

  -xDSL deployments

*Structured cabling
  -Home/office cabling
  -Phone & Data

*Computer networking
  -Mikrotik hardware
  -WAN/LAN solutions

*Wireless solutions
  -Motel/Hotel hotspot deployments
  -Outdoor wireless deployments, both small and large scale
  -Temporary wireless deployments
*CCTV solutions
  -Analogue and IP

I'm an #avgeek who loves to travel the world (preferably in seat 1A) and stay in nice hotels.

+My views do no represent my employer. I'm sure they'll be happy to give their own if you ask them.

You can contact me here or by email at [email protected]


Located in NZ and after a cheap way to call friends or family in Australia?

Faktortel VoIP offers plans from $0 per month that offer you the convenience of being able to call landline numbers anywhere in Australia from A$ 10c per call (yes *per call*, not per minute!). An optional Australian DDI number also lets friends and family call you and they will only pay the cost of a local call. Interested? Check out Faktortel for more details.