Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Digits lost on E & M trunks 1

Status
Not open for further replies.

miteldude

Technical User
Sep 18, 2006
20
GB
I have a problem on a mitel 3300MXe which is linked to a third party voicemail system via E&M trunks. Ocassionally when a user(eg extn 6109) dials 88(to access their mailbox) the 3rd party voicemail doesnt give the correct mailbox options. The reason for this is that the voicemail system is not receiving all of the extn's digits, instead of receiving the extn no 6109, the voicemail system only
gets 109. Hence the 3rd party voicemail doesnt recognise 109 and gives the call to a default mail option('please enter your room number'). This is an intermittant fault and doesnt have a pattern in which it occurs. Are their any timers on the system which i could manipulate to make sure all the digits go across the E&M trunks to the voicemail system to get rid of this fault ?

Or any other fixes for this would be most welcome!
 
Timers? Well yes, in a manner of speaking.

In the ARS tables you can build a Call Progress Tone Plan and set it to detect some tone that it will not ever see, i.e., Specialized Carrier Dial Tone. Set the time to wait for this tone at some initial value such as 2 seconds. Then set the action of timeout to outpulse DTMF. Now associate this tone plan with the route.

 
Sorry, I meant to also explain that the net result of this is that the trunk will get seized outgoing (toward the VM system) and then the PBX will pause (for the wait time specified in the tone plan). Finally upon not seeing the tone, the tone plan will time out, allowing the digits to go to the VM system.

By choosing something like NA Specialized Carrier Dial Tone we deliberately chose an oddball tone that should not ever be there, hence rather than detecting the tone and immediately sending out our digits, the system instead waits.... Then after waiting for 2 secs (the time specified) and not seeing the tone it is waiting for, it gives up and sends the digits anyway.

Kind of a kludge method of making a timer, but it works.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top