Getting several complaints that transfer disconnects call

[ippsp]

Hello,

This is my first post. I am absolutely desperate for help at this point in figuring out the trouble we've been having with our PBX.

I work for a company that recently upgraded from an InterTel system to a Mitel MiVoice Office 250. We've got several single line, digital and a handful of IP phones (all Inter-Tel branded). We chose to keep our existing phones to save some money up front. Our system seemed to be working fine after the upgrade until we moved from a PRI over to SIP trunks. The SIP provider has given us 23 call paths to use, however, our system only has 11 SIP licenses.

Ever since we moved off the PRI and over to the SIP trunks (different provider from where we had the PRI) I've started getting complaints from the front office personnel (reception) that they occasionally get calls from upset customers that could not dial in. They say they either get a busy signal or receive a call cannot be completed as dialed message. More often however, they tell me that when they attempt to transfer a caller to an inside extension, sometimes it will just disconnect the call. I haven't gotten very many complaints at all about dialing out.

These problems have been going on for over half a year now. I have no idea what is going on and have reached out to our vendor a few times to 'take a look at the system', in which every time the same support guy gets in remotely and tells me there are no errors going on. I was also told that the phones could be getting old (happens across at least 5 different front office phones) or the buttons could be going bad. He of course pointed out that we may need more SIP licenses, but told me there is no way to tell for certain without getting third party call accounting software.

I've attached a snippet of the hourly trunk stats from the Mitel Admin program, in case it helps to give an indication of how many calls we've gotten so far this week. The vendor actually reset it on Tuesday while he was working with me.

Could these issues be with the provider or our SIP licensing, or possibly even my SIP configuration (probably not typical)? If it was configuration though, I don't see why it would work most of the time.

Thanks,
Sam

[acejavelin]

This literally sounds like your don't have sufficient SIP Trunks/Licenses... Your 11 are being used and the Mitel is rejecting any further calls.

If you can get a specific call example, pass it on to your carrier and they should be able to track down exactly why the call failed.

These are difficult for you to troubleshoot as you can't duplicate it consistently, but if you can get specific call examples which include time (roughly, but as close as possible), date, calling number, number they dialed, and what the issue was, your carrier should be able to pin that specific call down without too much trouble.

That said, SIP Trunk licenses are a relatively inexpensive 1-time expense... add 4 licenses and associated trunk programming and see what happens, it might be cheaper than paying for several ours of your vendor troubleshooting the issue.

[ippsp]

I am going to let the SMDR tool run in the admin tool all week and log to a file. I am hoping to see that if/when this occurs, that it will show all of my trunk IDs on the list somewhere.

For example, the tool has been running since Friday, and out of all 11 trunks, I only see IDs for 8 of them ever show on the list:

94000, 94001, 94002, 94003, 94007, 94008, 94009 and 94010.

If all the trunks eventually go busy, wouldn't I see 94004, 94005 and 94006 join the list?

[Tech Electronics]

Sam,

Your system should be making calls out from 94010 up to 94000 and calls should be coming in on 94000 to 94010 respectively. If you don't see 94004-94006 then you haven't been having any issues with call volume; apparently.

The only way to figure out this problem is to have someone looking at the OAI stream and SIP Messages for when any of your issues happen. If it is an intermittent issue, mean it doesn't happen every time, then it may take an entire day or two to capture an incident before they can dig through all of the information to find the problem.

This method will always find the problem, although not necessarily fix it, but it is very expensive to have someone on site waiting for things to happen. That is where working with your vendor to figure out the issue is the best way. I would have them come out and setup a laptop to do the work and then show you how to start and stop each of the captures and then you can wait for the issue to happen and record as much information about the call as possible [Date, Time, Extension, Number of Caller, Transferred to, etc..]. Personally, I would start and stop the captures on each work day to reduce the amount of information that you have to dig through.

Thanks,

TE

[Travis]

Sam,

I agree with TE. Additionally you should get those SIP Licenses, You currently are paying for SIP trunks you aren't using. Either cut the SIP Trunks from your provider down to 11 and stop paying for those extra 12, or buy 12 more SIP trunk licenses for the pbx. If people are complaining about calling in and getting busy its very likely during times of high volume and they cant get through to the pbx. Have you noticed any system alarms?

-Travis

[ZuluAlpha]

That "call cannot be completed as dialed" bothers me. It would seem that they'd send a busy signal if all your trunks were occupied otherwise. To me (like everyone else) this points to a discrepancy to having 23 paths but only 11 licenses.

[Tech Electronics]

Sam,

I think it is likely there is more than one thing going on here and it is just blurring the lines to a solution.

Work with your vendor and try to look at each problem as an individual issue and see what can be done to fix each one.

Thanks,

TE

[magnus]

I will echo the same solutions as above.

But this part stood out to me
More often however, they tell me that when they attempt to transfer a caller to an inside extension, sometimes it will just disconnect the call.

Do a few test calls with the reception people and see what there process actually is. Are they doing a transfer to a DID?
If so then you are compounding the call path uses. 1 for the inbound, then one for the outbound reception to the inbound DID, so 3 per call.

And you will need to actually stand beside them while they do this or they will lie to you about the transfer process.

[Tech Electronics]

Sam,

Expanding on what Magnus stated about the transfer process got me to thinking about that a bit. This may just be an issue where the Transfer to Connect Allowed is set differently than what it was in your old Inter-Tell Axxess system.

By default this flag is set to No which requires the user to hang up from the Attendant/Operator and press a Call Key to answer the Transferred call. If the person hangs up prior to the Attendant/Operator then the Transfer is Rejected and when the Attendant/Operator hangs up the call is disconnected.

Thanks,

TE