Extending call forwarding time

Here's a little tip for those of you frustrated that the system forwarding timer on the Mitel / Inter-tel Axxess / 5000 is global.
If you have a user who has a system forward to voicemail, but wants a longer timer than all the other users, do this.
Create them their own system forwarding path. Put their own extension in as forwarding point 1 and the voicemail application as forwarding point 2.  This has the effect of ringing their phone for the global system forwarding time + the no answer advance time before going to voicemail.  Simple really.

www.telecomcare.net

Outsourced engineering

Are you a telecoms dealer who is finding it more and more difficult to train engineers to the required standard of a particular manufacturer. Are the scenarios below familiar to you?

• We won't sell you this solution until you have got an engineer (or two) through this two week training course at a cost of £3000 + Wages + Hotel + loss of productivity.

• We know this bolt on piece of software is dead simple and only has 10 settings, but we won't take a support call on it when it appears to have bugs, because your engineer hasn't done the 30 minute online course at a cost of £150.

• I did put my engineer through a course, but since it then took me another year to actually sell the widget in question, he no longer has any idea how it works.

If the above sounds familiar, then head over to our website and take a look. Because we offer white label engineering services on behalf of a number of dealers, we see the products on a more regular basis than may be the case within a single dealership. So this makes it worth our while to both keep up with training and to train more engineers.

Telecom Care Ltd

We are currently fitting

Mitel HX 5000

Mitel Call Director (3300)

Mitel Customer Service Manager

Xarios Phone Manager

Mitel Border Gateway

Mitel Unified Communicator

NEC SVM

We have experience on older systems such as

Ericsson (Aastra) Businessphone

Siemens HiPath

Samsung DCS, IDCS

Toshiba

Obit SIP trunks on Mitel 5000

We recently ran some testing on an Obit SIP trunk to see if it worked OK with the Mitel 5000 pbx. Mitel have a range of suppliers who have tested with them, but a supplier of ours asked us to test Obit for them.  Below is the detail of the test setup and the programming done to get it all working. Hopefully it will help someone else.

Obit Trunk Testing.

Test equipment was :-

Mitel CS5000 software version 5.0

Netgear Prosafe FVS338 firewall, provided with a static public IP address. (Note this firewall runs completely different software to the cheaper FVS318’s). SIP ALG was turned off. The phone system was NAT’ed

The router was set with no port forwarding relating to SIP, rather the Ping option of the phone system to the obit server opens the port at a regular interval, allowing traffic to be sent inbound from the obit server to the phone system.

System was provided with SIP trunk license for each obit trunk.

A Sip Peer / Sip Trunk group was created.

Registration – Off           

Authentication – Not used

Keep Alive – Yes

                Ping Interval – 60

                Ping Failure threshold – 5

NAT settings – Non Sip Aware NAT

Alternate IP - Empty

Route Set – Empty

IP address – obit server ip xxx.xxx.xxx.xxx

Port number – 5060

FQDN – blank

Call Configuration – (Select a call config with G711 and 20msec playback delay buffer)

Operating State – (Set ‘In Service’ when config is finished)

Maximum Number of Calls – (To match amount of trunks purchased)

Use ITU-T E.164 – No

Static Binding – Yes

Use Peer Address in from Header – No

Trunk Group Configuration

Create a SIP trunk for each trunk purchased.

Call Routing table entries.

Should be in the format such that an inbound call to 01159610400 presents as

441159610400 in the left most column.

Extension Calling Party Number

Set in the format 01159610400 for each extension set to go outbound on SIP.

IP Settings

Set the ‘System NAT address’ to be the public IP address of the firewall.

IP Connections

P6xxx (the default is usually P6000) set the NAT address as the public IP of the firewall.

You can contact us via our website www.telecomcare.net

Mitel HX 5000 SIP and VoIP ports

I am just setting this down as a resource for those trying to get Mitel IP Phones, SIP trunks or SIP devices working on a 5000.

Mitel Handsets.
The following ports need forwarding on your router to the internal IP of the phone system.

69/UDP - FTP port for downloading firmware to phone
20001/UDP - Alternative FTP port if 69 is not available or you want it closed for security
6800-6802/TCP - Call Control
3998-3999/TCP - Call Control
6004-7039/UDP - Voice transmission to 5000

You need to remember to set the IP Extensions Network properties to NAT and make sure that the IP Connections NAT address is the public IP of the router.

This appears to work the majority of the time. We have found BT Homehubs to be particularly likely to fail to work at the remote end and they are so locked down in recent releases you may not be able to get a phone to work with them.

Inter-tel Handsets
5566 TCP - Control
5567 UDP - Control
6004-7039 UDP - Audio

SIP Trunks
We seem to find that it differs from router to router whether it will work at all, and we have found most success when the routers own SIP algorithm is turned off and the system allows for this.

The problem with SIP and NAT is that if the phone system is set in default the the SIP packets go out with the internal IP address of the phone system in them. Then the responding party doesn't know which public IP  address to send them back to.  The 5000 can be told the public IP and insert it in the SIP packets. That way the SIP packet wrapper and the payload both have the same IP address in them.

Dependant on the provider and the router used you may not need any port forwarding. I prefer on our Netgear FVS338 to leave port 5060 closed. 'But how will a sip call get in?' I hear you cry.  If SIP Pinging is turned on in the system, the phone system will send an OPTIONS message every minute to the SIP server on the internet, thus opening port 5060 but only for packets returning from the sip server, thus protecting you from continual SIP hacker attacks.

However with some routers/firewalls you will have to do port forwarding.


5060/UDP & TCP - SIP signalling.
Set Sytem NAT public IP address in both IP Connection and in System IP Settings to match the public IP of the router.

In the SIP Peer Group set the NAT type to 'Non SIP aware NAT' if the router SIP alg is off.

EDIT - SIP ALG - Usually when behind NAT you would set the phone system to NAT, however if the router has a SIP ALG then this attempts to sort out the NAT issue and can cause conflict.  Either set the phone system to NO NAT OR SIP AWARE NAT or turn off the SIP ALG.
On a Draytek (my favoured router) issue the below commands from SSH to turn off SIP ALG
sys sip_alg ?  (this will offer help and tell the sip alg status.)
sys sip_alg 0  (to turn off)
sys commit
sys reboot

----------------------------

SIP Devices
These are the really tricky ones and you may need to get a border controller installed for security and for devices to work at all. The SIP port has to be open for access from any IP address, as you don't know where your mobile SIP user may end up. This could therefore defeat protection put in place for SIP trunks. As the RTP stream may be initiated from the device.
You will need to open


5060/UDP & TCP - SIP signalling.
You may need to forward RTP ports for voice transmission, dependant on device.
The SIP Phone group has a NAT setting which will need to be set for NAT
Set Sytem NAT public IP address in both IP Connection and in System IP Settings to match the public IP of the router.


While the above is my experience I am open to suggestions and additional information, so please post a response if you have anything to add.

John Rogers
Telecom Care Ltd

Recording Audiotext Greetings on Inter-tel Axxess and Mitel CS and HX 5000 Phone Systems

Recording Audiotext Greetings on Inter-tel Axxess and Mitel CS and HX 5000 Phone Systems.

This is one we are constantly explaining to our clients, so here it is for reference. 

Your telephone system may be set to use Automated Attendant functions or queuing announcements. Where these are not system prompts but have been customised for your company the engineer has probably used what are called Audiotext Greetings.  Should you need to record new greetings or rerecord old greetings you will need to follow the procedure below.  First note down greeting numbers, your Voicemail number (default 2500), Admin mailbox number (check with your installer) and Admin mailbox password (default same as mailbox number).  If during the procedure below you find the the password is incorrect, try without a password before contacting support.

Dial 2500 for Voicemail

On hearing the prompt press *

Enter the Admin mailbox number and password followed by #

The system greets you to the admin mailbox by saying “The hard disk is x% full.” During the greeting press 9

Choose option 3

Choose option 1

The system asks for a prompt number, enter the number followed by #

Follow the recording instructions. At the end of recording press #.  Do not put the phone down. You must listen to the recording and then accept it for it to be saved.

After you have recorded all the prompts needed you may hang up.

Telecom Care Ltd are based in England and provide phone system maintenance and installation services in Nottingham, Derby, Leicester and beyond.

SIP Tracing on the Mitel HX5000

I hate SIP. Absolutely hate it.  While SIP trunks are advertised as a cheap replacement for ISDN, and advertised as standards based, SIP is implemented differently by each carrier, implemented differently by each manufacturer, and will work differently with different routers employed by different customers. At least with ISDN you know that when you plug in the RJ45 to the telco's box you have a 95% chance it will work straight away. If the internet connection goes down, at least you still have phones, but with SIP you risk it all on one connection.

This means I have spent a fair bit of time having to get traces out of systems to try and find out why SIP is not working.  I will come back to identifying the problems in later posts, but first of all you need to retrieve the SIP trace.

On a v4 or v5 5000 you can do the following.

1. In Mitel DB Programming, go to 'View' and turn on Online Monitor.
2. Navigate in the left hand pane to System \ Devices and feature codes \ Sip Peers
3. In the General Configuration set the SIP Message output format to 'Full'
4. Set the SIP log level to 'Information'

The effect of this will be to output the SIP signalling to the systems SIP logs.

To View the logs 

1. Go to the Mitel System Administration & Diagnostics front end.  
2. At the top right click on 'Connect'
3. In the panel below that, when the play button appears click on it.
4. On the Favourites tab, or on the System Information tab find the 'View system logs' button in the 'System Information' box and click on it.
5. The system retrieves a full list of system logs. There is a refresh button that reloads the list at any time. find the SIP section.
6. The logs are quickly overwritten so check the timestamp on the logs before saving or opening the log to see if it will contain your test call. 

More on SIP in another post, but this may get you started. If you see both send and receive messages you at least know port 5060 is open!

Have Fun

John Rogers

Telecom Care Ltd

VPN and Remote Desktop Issue

Hi All,
1st post and already off topic!  Well, I am sure you all agree, the life of the PBX Engineer rapidly became the life of network and server engineer some years ago.
As a business we all work from home or work while on the road and can be called on at any time to make a connection onto someone's phone system and make changes.  Of course a dial up connection using a modem onto an older system when you are in a car park on the motorway is not possible, so we came up with a solution.
Each principle engineer has a Virtual XP machine hosted on a VMWare server in our office, and we all have a Hamachi software VPN into the office. So long as we can get onto the internet we can remote desktop to the XP machine and do all we need to do.
However I have found the Hamachi VPN to be painfully slow at times, especially if you want to transfer files from home to the office. - My solution?  Since I had just fitted a VPN router at home, I decided to put in a tunnel between home and the office. this should at least speed things up when I am at home.

So that's what I did. Found some instructions and created a tunnel. I could ping fine, I could open files on the server and browse to the internal database.  What I couldn't do was remote desktop to my hosted machine!

I searched the internet and checked if others had the same problem, and after an hour came up with nothing. If I disabled the tunnel and enabled Hamachi, remote desktop worked. If I went back to the tunnel, no remote desktop.  The mad thing was that the XP machine could control my windows 7 laptop at my house, so it was only in 1 direction that RDP didn't work.

I finally checked to see if the XP machines firewall was on. It was and could not be turned off due to group policy. I checked if I could remote desktop from another machine in the office to the XP machine and I could.  Then I had the lightbulb moment.

Hamachi uses the DHCP server on your network to give your machine a LAN IP address. however the tunnel I had setup was LAN to LAN so my machine at home was on a different network to the XP machine. The firewall policy allowed connections from the local LAN but not from a foreign LAN.

Having figured this out, and not having seen the solution online, I thought I would post it to assist others who may come across the same.

John Rogers
Telecom Care Ltd

Introduction

Hi.
My name is John Rogers and I and my colleagues run a telecoms maintenance business in the UK called Telecom Care. We look after a range of different business types and act on behalf of a number of telecoms dealers and in doing so we have gained a large amount of experience in the field.  The purpose of this blog is to share our experiences, knowledge and hints and tips with the community. Please feel free to comment back and add your own experience to ours.
While our main experience is in the Mitel arena, we also have knowledge of Samsung, Ericsson, Siemens, Nortel and NEC systems within the business.

Regards

John