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  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"></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 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 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!

Telecom Exchange Tour

By Steve Biddle, in , posted: 25-Feb-2010 09:07

I had the opportunity yesterday of attending a Telecom Exchange tour hosted by Chorus & Telecom Wholesale. This included a visit to the Courtenay Place exchange here in Wellington, a look at a current Fibre To The Home (FTTH) deployment in Grenada Village and a look at a Whisper Cabinet that are currently being deployed nationwide as part of the Fibre to the Node (FTTN) cabinetisation program. It was a very interesting day with plenty to see and talk about. Since it's something many people would never get the chance to experience I took a few photos to share with everybody.


Our first stop was the Courtenay Place exchange. This is one of the two major exchanges in the Wellington CBD (the other being on Featherston Street).



Phone cable entering the exchange from the outside world



Fibre optic cable entering the exchange 



A room full of batteries in case of a power cut



And backup generator. There are two of these required to power the exchange.


P1030159 P1030161

P1030164 P1030162


A view of the MDF (main distribution frame) in the exchange and some close up photos of the different types of connections - ranging from the old solder type to more modern punch down blocks. The frame contains a "D" side and an "E" side - one is from the outside world and the other is from the NEAX switch. A cable is patched between both sides of the frame to provide service.



The fibre section of the exchange. Fibre enters the exchange and has to be patched in much the same way copper is.



Inside of a cable trays where the fibre is joined.




The Alcatel Lucent 7302 ISAM that provides ADSL/ADSL2+ broadband services from this exchange. This is the same hardware that is deployed in the new roadside cabinets.


P1030154 P1030157

Orcon and TelstraClear equipment in the exchange. Both provide ULL (Unbundled Local Loop) internet and voice services from this exchange.



Next up was a visit to Grenada Village to visit the single FTTH deployment in Wellington. This deployment uses the GPON (Gigabit Passive Optical Network) standard. This deployment is in a new subdivision that currently only has a handful of active customers and there are approximately another dozen houses under construction at present. This cabinet is what is known as a "passive cabinet" - it does not require any power to operate. It is simply splitting the incoming fibre and acting as a simple patch panel. This cabinet has capacity for up to 288 houses.


In the photo above you can see the the yellow fibre that runs from each house back to the cabinet. The fibre at the top is currently unconnected.



The optical splitter (essentially just a glass prism) splits a single optical signal across 32 outputs. There is capacity in this cabinet for 9 splitters but only a single splitter is fitted at present due to the small number of customers.






The fibre then enters the tray where it is "patched in" and connected to liven up the connection to the house.



The underground pit where fibre from the exchange is connected to the cabinet. Spare fibre is available so the installation is future proofed.



There is no copper cabling deployed in this subdivision, every household requires a ONT (Optical Network Terminal) which turns the optical signal back to an electrical signal. The ONT provides a standard Ethernet output which connects to a router to provide internet access. The phone service is VoIP (Voice over Internet Protocol) and customers have the option of using VoIP handsets in their house or connecting regular analogue phones to an ATA (analogue telephone adapter) that converts the VoIP service to analogue. At present all internet and voice services are provided through WorldxChange Communications as Telecom Retail do not currently have a residential VoIP product in the marketplace.


The picture above shows a mock-up of the hardware that is typically being fitted in the home at present. This includes a Linksys router with built in ATA that allows you to connect analogue phones. It also includes a battery backup to ensure that phone service is still available in the case of a power cut.



Next up was a site visit to a working Chorus FTTN cabinet. These cabinets are brand new state of the art technology that are being deployed nationwide as part of the Chorus cabinetisation rollout. Approximately 1500 have currently been deployed nationwide out of a total of 3400, with the project due for completion towards the end of 2011. ADSL (and the forthcoming VDSL) deliver faster speeds the closer the customer is to the cabinet or exchange - because the customer can't be moved closer to the exchange the solution is to build these cabinets and move the hardware closer to the customer. These cabinets are connected back to a local exchange by fibre and copper, the fibre is used for backhaul for internet services and the copper is used to provide voice service from the existing NEAX switch in the exchange



Inside of the cabinet. On the left is the Alcatel Lucent 7302 ISAM that provides ADSL/ADSL2+ broadband. On the right is the MDF (main distribution frame) which contains copper cabling from the local exchange and from each nearby house or business. These are jumpered together to provide voice and broadband service to customers.



A close up look at the ISAM and cards


These cabinets were designed and built in New Zealand by Eaton in Christchurch and each cabinet is designed to serve to up approximately 300 customers. At present they only contain Telecom equipment but the space on the left is available for other telecommunications providers or ISP's to install their own equipment if required. As mentioned above all voice services are still provided by the existing phone exchange, however it is possible that in the future Telecom could install hardware in these cabinets to deliver voice services when the NEAX switches are retired. A voice card for the existing Alcatel Lucent ISAM could easily be installed and would connect to Telecom's core network using VoIP but would convert this to analogue so that existing phones in your home or business would continue to work as normal. The cabinets have a battery bank to ensure they work even during a power cut, and can be powered by a generator if need be during a prolonged outage.


A special thanks has to go to Chorus and Telecom Wholesale for organising such a great afternoon!

Permalink to Telecom Exchange Tour | Add a comment (13 comments) | Main Index

Is the MTR saga over?

By Steve Biddle, in , posted: 23-Feb-2010 10:48

Yesterday was an interesting day in the mobile world in New Zealand. Along with yet another outage affecting the XT network, the Commerce Commission submitted their findings to the Communications Minister in relation to Mobile Termination Rates (MTR). The Commission in a 2 to 1 majority recommended to Communications Minister Steven Joyce that an aligned undertaking from both Telecom and Vodafone be accepted rather than the Commission being forced to intervene in the market and force the regulation of wholesale interconnection pricing.


The response from those with opposing viewpoints was interesting

                2degrees said

Today is a very disappointing day for New Zealand mobile users. After much delay, the Commerce Commission appears to have squandered a golden opportunity to finally bring New Zealand mobile prices into line with the rest of the developed world. New Zealand consumers suffer with some of the highest mobile prices in the world. The Commission’s recommendation to leave the decision on access pricing up to the incumbents, Vodafone and Telecom, will mean this burden on New Zealanders continues for the foreseeable future.


The response from 2degrees was as expected. They are a company that has spent most of the last decade complaining about the regulatory environment in New Zealand rather than getting on with building a network. In August last year 2degrees finally launched their network and by their own admissions are doing amazingly well. Last week they announced that they had signed up 206,000 active customers, a figure that was well ahead of expectations, and also announced that for the first time people in New Zealand are now able to access prepaid calling rates at prices well below the OECD average. They are also claiming ARPU (average revenue per user) in excess of $10, a figure that is higher than many Telecom prepaid customers.

The question has to be asked as to why 2degrees seem to have significant issues with the Commerce Commission decision. Right now their business is booming and yet they see regulation of the industry as being essential to compete. One really has to wonder why this is the case.

The Drop the rate, mate! Lobby group (that is heavily backed by 2degrees and several unions) went even further accusing Commerce Commission members of doing “an about face”


Two members of the Commerce Commission have done an about-face, after repeated voluntary undertakings from the big telcos – while another, Anita Mazzoleni, has sided with consumers, the Drop the Rate, Mate! campaign said today.


The Drop the Rate, Mate! Campaign was formed to “to demand lower mobile termination rates in line with the costs of connecting calls and texts”. They have never explicitly explained exactly what they mean by this statement and where they see pricing in the market, but when a campaign is powered by nothing but hot air this isn’t surprising. One would presume they would be at least partly happy with the Commission’s announcement, SMS rates are potentially going to be cut to under cost and voice revenue cut to levels that are in line with costs based on some pricing models. Exactly what “about face” they are talking about is unknown, for months now the Commerce Commission have been actively encouraging a joint aligned undertaking from all three carriers that would deliver pricing that was acceptable to the Commission in preference to the Commission forcing regulation of pricing. To say that two members of the Commerce Commission have done an “about face” and no longer care about consumers is nothing but rubbish. The only “about face” I’m aware of in the whole MTR saga was the decision in December by 2degrees to throw their toys out of the cot and withdraw all previous undertakings that they had submitted to the Commerce Commission leaving them with no offer on the table.

I’ve been accused of working for both Vodafone and Telecom in past blog posts on the MTR issue but want to make it perfectly clear I no ties with either company. The telecommunications sector as a whole is of great interest to me and watching the MTR saga drag out over the past year has been fascinating. The rates charged by some carriers in New Zealand for fixed line to mobile and for mobile to mobile calls are expensive, what people need to remember however is that the MTR issue is a discussion of pricing of wholesale traffic interconnection, it isn’t a discussion on retail pricing. The Commerce Commission have no plans to regulate retail pricing and believe that pricing will fall due to competition in the marketplace due to lower termination rates. Whether this occurs is still to be seen as there is no evidence anywhere in the world that can draw any established relationships between wholesale interconnection rates and retail pricing. There are countries with high interconnection rates and low calling costs and countries with low interconnection rates and high calling costs.


What offer is on the table?

Both Telecom and Vodafone have said that from the 1st October 2010 they will drop SMS interconnection pricing to 0c and adopt a hybrid Bill and Keep pricing model. This hybrid pricing model means that Vodafone and Telecom will not charge each other for delivering SMS messages to the other network providing traffic levels remain even. If an imbalance in traffic occurs at a level between 7% and 12% then a charge of 2c per message will apply, and for an imbalance of greater than 12% a 4c per message charge will apply. The reason for the hybrid system and not a true bill and keep solution is primarily at attempt to stop the proliferation of unsolicited SMS messages, in a true BAK model with no restrictions it’s possible for a network to actively sign up users whose only intention is to deliver unsolicited SMS messages to users on other networks. It’s worth noting that current SMS traffic levels between networks are all reasonably even as SMS is a two way medium – if somebody sends you a SMS, move often than not you will send a reply.

Both networks will drop voice interconnection rates for mobile to mobile and fixed line to mobile to 12c per minute from the 1st October 2010, with theis rate following a glide path dropping on the 1st January every year until it reaches 6c per minute on the 1st January 2014. All interconnection costs will be billed per second.

So what did 2degrees want?

2degrees have been pushing for rates to go even lower. Their last undertaking was for a true BAK pricing model for SMS messages (ie no charge even if there was a traffic imbalance), and for voice interconnection rates to be approximately ½ of what both Vodafone and Telecom submitted in their undertakings. Many of their submissions did nothing but complain about the competition rather than offer reasonable solutions and from the outside it seemed like their purpose was to hijack the whole investigation solely for their own motives.

2degrees have a true motive – and that’s the introduction of a true BAK pricing model for mobile in New Zealand. As a newcomer to the market they have the most to gain from BAK – the majority of calls from 2degrees mobile users are off net, this results in 2degrees having to pay Vodafone or Telecom money to interconnect calls. Likewise because the number of inbound calls falls well short they end up in a situation where they are paying other operators more than they are receiving in termination costs. It’s easy to see why 2degrees want BAK, the problem here is that the Commerce Commission were not interested in looking at using BAK as a pricing model for New Zealand. No other country has moved from a CPP (calling party pays) to BAK pricing model for mobile, and such as a move was totally out of scope for the MTR investigation. Exactly what decision 2degrees make now is over to them – they presumably still have the option of joining Vodafone and Telecom and leveraging their agreement, continuing with their current interconnection agreements, or sitting on the sideline with their ratchet making lots of noise while contributing very little.


Right now you have a choice in New Zealand when it comes to mobile. With three networks and a myriad of pricing plans there is plenty to choose from. What is plainly clear is that the wholesale cost of interconnection plays a minor part in determining the retail cost of both fixed to mobile and mobile to mobile calling. It’s possible to pay 23c + GST per minute to call a mobile phone from a Telecom Business line however a Telecom homeline user with no calling plan will pay 63c incl GST for the same call. Up until several years ago the standard Telecom rate for fixed to mobile was 71c per minute, a rate that was set close to 20 years ago when the MTR rate was around 50c per minute. We’ve seen wholesale MTR costs fall by more than 60% in that time but the standard retail price fell by approximately 10%. Likewise a mobile user can currently be paying as low as 25c + GST per minute with per second rounding after the first minute for a voice call using a provider such as Compass Mobile (a MVNO on Vodafone’s network) or can be paying 89c incl GST with calls rounded up to the next minute if you’re on Vodafone Prepay.

It’s very clear that wholesale MTR costs are not the cause of high mobile pricing in New Zealand, the problem is one of retail pricing. As MTR costs have fallen over time retail costs have not necessarily followed due to a lack of true competition between the two mobile operators in New Zealand. The Commerce Commission investigation had good cause and the current offerings on the table from both Telecom and Vodafone will mean significant drops in inbound revenue for both operators. As to whether it will mean cheaper calling prices for New Zealand mobile users is another question entirely, something only time will answer.

Permalink to Is the MTR saga over? | Add a comment (5 comments) | Main Index

Mail For Exchange 3.0 for Nokia delivers HTML and folder support

By Steve Biddle, in , posted: 14-Feb-2010 20:35

If you are a Nokia phone user and use a Microsoft Exchange based email solution odds are you use MfE (Mail for Exchange) for your email. Newer Nokia handsets use Nokia Messaging, but for the large majority of users out there MfE is the only option as the standalone Nokia Messaging application does not support Microsoft Exchange.

For many years MfE has been severly limited with two major contraints - lack of folder support and no support for HTML, two features that were serious downfalls for devices such as the E71 that were targeted at email users.

The good news is that in recent days Nokia have released a brand new V3.0 release of Mail for Exchange. Included in the release is support for both HTML and support for folders in your inbox.

There is still no mention of this software of the official MfE website but it's available for download from Ovi Store.

I've been running this on my E71 for the last few hours and while it's still not a perfect solution it's finally great to be able to have access to features that should have been part of the software many years ago!

EDIT: There have been numerous people comment and also contact me saying that they can't find the HTML option. I can assure you that HTML viewing IS THERE!!!

If you have an HTML email click on options and there is a menu item saying view as HTML.

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.