I came across another strange one today. It is definitely not acting the way I would expect and I'm wondering if anyone else has seen this or has some input.
It has to do with ARS that has a list of routes.
System type is MXe II, MCD 4.2, Embedded PRI, Protocol NI-1
- A phone has rights to dial route 1 which is choice 1 in an ARS list.
- A call is made that encounters "unknown signal" from the telco
- The Mitel responds by trying to dial the secondary route.
CCS trace was used to identify the calling pattern.
When ARS Digits Dialled Termination was changed to route 1 (Instead of list) the call responded with "Busy"
When the trunk was manually dialled with the direct trunk select the call was "Busy"
When the same number was dialled using a cell phone the responce was fast busy (what I would call re-order tone)
When ARS was returned to a list, the behaviour returned to it dialling first on the primary route and then attempting the secondary route.
I would never have thought that a signal from the Telco could cause the Mitel to choose a secondary route after failing on a primary. I would only have thought that internal programming would govern the route selection.
Has anyone ever seen anything like this?
**********************************************
What's most important is that you realise ... There is no spoon.
It has to do with ARS that has a list of routes.
System type is MXe II, MCD 4.2, Embedded PRI, Protocol NI-1
- A phone has rights to dial route 1 which is choice 1 in an ARS list.
- A call is made that encounters "unknown signal" from the telco
- The Mitel responds by trying to dial the secondary route.
CCS trace was used to identify the calling pattern.
When ARS Digits Dialled Termination was changed to route 1 (Instead of list) the call responded with "Busy"
When the trunk was manually dialled with the direct trunk select the call was "Busy"
When the same number was dialled using a cell phone the responce was fast busy (what I would call re-order tone)
When ARS was returned to a list, the behaviour returned to it dialling first on the primary route and then attempting the secondary route.
I would never have thought that a signal from the Telco could cause the Mitel to choose a secondary route after failing on a primary. I would only have thought that internal programming would govern the route selection.
Has anyone ever seen anything like this?
**********************************************
What's most important is that you realise ... There is no spoon.
