Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: pakman on September 26, 2013, 02:05:52 PM
-
Hello,
I have a main line go to vm and this vm has options setup to transfer out to other places specifically 800 numbers. This has always worked and I got a ticket saying it's broke. I don't know when maybe after the upgrade from 5 to 6.0. I can still dial the speed call number that is programmed under the voicemail box so I know the speed call number works and the outside 800 numbers are not down. When you push option x to get transferred to this place you end up just coming back to the original voicemessage. The intresting thing is the other outside line a customer can get transferred to is down as well but the other internal numbers one can transfer to is fine. Nothing has changed with the setup or mailbox just the software upgrade as far as I know. any suggestions?
Thanks
-
Verify the the system speed dial number has "Override Toll Control" set to 'yes'.
Ralph
-
yes. I did change some items in the COR so maybe I blocked the vm ports from dialing out this is probably the case now that I think about it more.
-
Does anyone know how the following would work:
I checked COR there is none setup. I did however, find under VM Options there is a restrict numbers that begin with X and in my case it's 9. So my question is when you dial our 800 number hit option 3 this is really a voicemail box set to transfer only and this transfer only is pointed at a speed call number which has the actual number being 91800.....I did simply remove the 9 but when I called and tested by pushing option 3 I do hit the voicemail box behind option 3 as it Say's your are being transferred to X then it tells me that extension is not valid. Not sure what the deal is at this point.
Thanks
-
When using system speed calls the VM wouldn't know it's an outside call.
Is there a noticeable delay when you dial the speed call before the call goes out?
Are the VM ports in a different tenant than the trunks or using a different interconnect restriction?
Ralph
-
Ralph,
There is a delay if I just dial the speed call number #5600. To answer your other questions when I go to VM ports the interconnect number is 1 and the Tenant number is 1. If I look under IP/Xnet Trunk Profiles there is only one profile in there and the interconnect number is also a 1. I am not sure what else to cross reference for the interconnect number.
Thanks,
-
Ralph,
There is a delay if I just dial the speed call number #5600. To answer your other questions when I go to VM ports the interconnect number is 1 and the Tenant number is 1. If I look under IP/Xnet Trunk Profiles there is only one profile in there and the interconnect number is also a 1. I am not sure what else to cross reference for the interconnect number.
Thanks,
Just to confirm, your speed dials start with a #? If so, check your System Options. What is "Disable End of Dial Character (#)" set to?
-
It's set to NO.
-
Do your speed dials start with #?
-
yes, it does. I just tested two scenarios one I replaced the 800 number and put an internal extension in it's place and the system did transfer me to my co-worker. Then I put my cell in it's place I used 9 1 plus area code and my number and it worked just fine.
-
Does the delay go away if you dial #5600#?
I'm starting to think the VM is releasing the call prior to the call setup being finished.
Can you try a speed dial that doesn't have a # in it?
Ralph
-
Ralph,
No, it doesn't. I finally broke down and called our phone vendor he spent almost tow hours on it and came up with nothing. We were able to create a work around by going into ARS and putting in the following stmt. digits dialed 9180..... sent it out Route 8 which is our local trunks instead of Route 1 which is our PRI. Now one would think this would mean the PRI has the issue but that doesn't make sense since I could alway's dial #5600 and it dial out to the 800 number.
-
I wouldn't think this would be the case since you can make the speed call your mobile number, but try looking in Trunks->Digital->ISDN->ISDN Protocol and changing "Replace External CLID" to true. This option tells the system to send your BTN instead of the caller's CLID. I have seen where providers would shut the call down when calls were placed from your circuit with CLID that wasn't native to them.
Caution - this will drop all active calls so choose a time carefully.
Another thought, these 800 numbers are outside your system aren't they? The reason I ask is that I have seen people try to loop calls out to the PSTN and back to themselves. This may be blocked as well.
-
Hi Mattmayn,
Thanks for the reply, the 800 numbers are out of our system and they don't route back to us there third party vendors. I did take a look at "replace external CLID" it's currently set to False. I will change this after hours and test....I just find it strange that this always worked and the only major thing I have done lately is upgrade software from 5 to 6. The tech from our vendor really wasn't much help as he couldn't figure it out and he spent two hours so I had to cut if off. I don't think your suggestion will work because I can dial the speed call #5602 and get to the 800 number just fine. However, when I call our main system and hit option 3 which is a voicemail box that is transferr only and it points to an extension number "#5602" then in system speed calls #5602 points to the actual 800 number. When I press option 3 it does tell me I am being transferred then it sends me back to the original queue like I just called the main line.
-
Here is what I am thinking if somoene could confirm or deny.
If I take the speed call number of #5602 and edit it and put in my cell phone which is long distance the call goes through. Now this LD call goes out a different PRI then the 800. I can dial #5602 directly from my set and it will go to the 800 just fine. There has to be some sort of blocking issue with voicemail ports or mailboxes transferring calls to an 800 number. I have no idea how to track this down if anyone has any suggestions? There is no COR on the path of this 800 number.
-
I think that Mattymayn is on to something.
I think that when the voicemail tries to transfer the call to the 800 number its trying to also pass the caller id of the inbound call, back out, to the 800 number. The PRI that 800 calls are routed out, is rejecting the use of a non-native CLID, and then because the transfer was cancelled, the voicemail drops the call back at the top most level.
Try this. From your cell phone, call your desk phone. Answer on your deskphone, and then transfer the call to the speed dial. Does the transfer complete?
-
Thanks for the reply bluewhite4
when I go into " Trunks->Digital->ISDN->ISDN Protocol and changing "Replace External CLID" to true" there are two modules protocol NI2 and DMS 250 not sure which one I should change this on both perhaps? Also, for your suggestion maybe I am missing something but If I take my cell and call my desk the only way I know how to transfer folks is to hit the Trans/conf key the "arrorw|3 heads" then dial the number. I can complete the call and hang up my deskphone and have it carry over to me cell. Not sure if there's another way to transfer calls?
-
The two modules you're seeing are two different trunks. You'd have to get into ARS, and trace back which trunk group, and therefore which circuit, your outbound 800 call is being routed out of. That would tell you which one to enable the "Replace External CLID" on.
You've got the right process, but rather than supervise the transfer I'd like you press the conf/transfer key, dial the #5600, and immediately hang-up your desk phones handset.
-
Ok, when I call my desk and hit the transfer key and dial #5601 and hang up immediately it just hangs up on the transfer and my cell and desk are still connected. But If I try that same test with an internal ext. it does the same thing. Don't I have to wait for the other person or line to pickup before I can press the trans key then hang up? If not something must not be setup correct. Also, I do know which trunk the 800 numbers are going out but in the ISDN Protocol form there's no way I can tell how to identify which one PRI uses which Protocol. I will just change one then both and see what happens.
-
Thought I would update this. I called our telco vendor last week before I started all of this and they said no issues on their end. After, exhausting what I felt was all options I called telco back spoke to another tech. Wouldn't you know it they've had DTMF issues now for awhile.......I created my work around and hopefully they will resolve this soon on their end. They went from switched to dedicated in terms of how they handle 800 number calls which started all of this mess.
-
Is this a cluster or a stand-alone system? In other words are the voicemail ports on the same controller as the PRI's that the call comes in on and the call to the 1-800 will go out on?
If you have an incoming PRI call that the voicemail then will transfer to an external number does the COS of the PRI's have the options for forwarding external and public to public enabled?
-
Yes, this is a cluser and all our voicemail is embedded on the same controller as the PRI. Now when a customer calls the 800 number it first comes in on one PRI it gets sent over the WAN to the other PBX that has the voicemail and the other PRI that they system transfers customers out to those 800 numbers that are giving us a problem. I looked in the COS for that PRI trunk and yes public to public is enabled and forward external. Not sure if you had a chance to read the my last post but the issue is on the Vendors side.
Thanks though.
-
Don't forget to check the COS of the IP trunks.
Have you played with the ISDN protocol yet?
I'm thinking you may have to adjust the "Replace External CLID" to be "true".
It may also be possible to route the calls to a system speed dial where the actual number looks like this: <network element>91-xxx-xxx-xxxx.
The network element would be the system where the originating PRI exist.
Ralph