Mitel Forums - The Unofficial Source
Mitel Forums => MiVoice Office 250/Mitel 5000 => Topic started by: thesavo on October 15, 2014, 02:04:57 PM
-
System Axxess (pre-mitel) 9.009
We just setup a single line polycom speaker phone in our conference room. It dials out fine and can take IC calls.
However I tried adding the extension, 162 as a Ring-in destination under call routing tables. It is set to ring in with the last 4 digit pattern. It set the same as the Keyset extensions that have working DIDs.
When I call the DID it rings to the Huntgroup 2001 for the mainline. We have another DID that forwards to a STAR app which allows dialing an extension. That too forwards extension 162 to the HG2001. If I call the STAR app, I can ring any other Keyset by dialing the extension number at the greeting.
I added mailbox per this thread. http://sundance-communications.com/forum/ubbthreads.php/topics/66970/CRA_Transfer_to_Collected_Exte
before adding a mailbox, calling the extension from the STAR app would fail to "the number dialed is not valid" now it also rings to the HG2001.
I also added a Single Line Extension list, and added 162 to that list.
Is there a way of seeing the call path on the SMDR like on a Mitel with Maintenance commands and LOGSYS?
Could this extension be set for DND or made busy? I thought against that since IC calls worked.
The guy that answers the main number is starting to get annoyed.
-
No step-by-step reporting in SMDR (but is available in CSM). Can you call it through auto att? I'd try changing DID destination to different ext, see if that works. That will tell you if problem is within cnf phone ext programming. Some possibilities: manual fwd, system fwd, duplicate entries in DID table. One more thing: look at SMDR to see what DID digits are received, maybe carrier sending wrong digits.
-
Thesavo,
So under Trunk Related Information > Call Routing Tables > {table used to route DID} > {digit pattern for SLC phone}, you have it set to ring x162 for both day and night based on the Call Routing Tables used CO Trunk Group that gets those DIDs?
Have you tried to change that DID to something else to see if it goes to that or if it continues to ring HG 2001? If that is the case maybe the DID that you are calling is sending in a different digit pattern that you are trying to route and it is going to the System Operator which may be forwarding to the HG 2001. You may have also added that DID pattern after a + or E which means those would match up first or that pattern may exist twice in the table and it is routing to the first one it matches with. Start at the top of your table and go down the list one pattern at a time and make sure that your pattern does not match up with any patterns with wild cards in them or the + or E.
As for the Call Path command there is nothing like that in the 5000.
Thanks,
TE
-
Thesavo,
So under Trunk Related Information > Call Routing Tables > {table used to route DID} > {digit pattern for SLC phone}, you have it set to ring x162 for both day and night based on the Call Routing Tables used CO Trunk Group that gets those DIDs?
Have you tried to change that DID to something else to see if it goes to that or if it continues to ring HG 2001? If that is the case maybe the DID that you are calling is sending in a different digit pattern that you are trying to route and it is going to the System Operator which may be forwarding to the HG 2001. You may have also added that DID pattern after a + or E which means those would match up first or that pattern may exist twice in the table and it is routing to the first one it matches with. Start at the top of your table and go down the list one pattern at a time and make sure that your pattern does not match up with any patterns with wild cards in them or the + or E.
As for the Call Path command there is nothing like that in the 5000.
Thanks,
TE
Yes, Day (table 1) is set to Single ring-in type. Destination is Extension 162.
Night is set to use routing table 1
I have used 3 different patterns in the table, setting the Ring-in to Extension 162. All experience the same issue.
As a test, I set a DID to ring-in to the Voice mail application. From there I can get to the Company Directory. I entered the surname of the single line and it tried to ring the line. It came back with {Directory Name} is not available. bad test, this is for leaving a message w/o calling the line.
I have scanned through all the patterns in the the #1 table there are no wild cards. Only 100 or numbers in sequence we have from our carrier. Should I call the carrier and ask if they are putting DNIS number on any of our DIDs?
Number 2 routing table has 1 pattern. + and rings to call routing table 1.
@dwayneg how do you view the SMDR in an Axxess?
Update: I downloaded a the DID lists from my carrier. There are no DNIS digits on these DIDs.
-
Thesavo,
Add the complete 10 digit and 7 digit number at the top of CRT 1 and route them to two different places and see if one of those work.
Thanks,
TE
-
Ok did that. I added a pattern for 7digits of the DID and 10 digits. I pointed them to a different STAR app. Nothing changed with routing. I also
left the original pattern as the last 4 digits of the DID in the list.
I then changed the pattern of the original (last 4 digit) DID, hopefully forcing it to use the other two patterns. I Called it and it went to the main line HG. IT didn't go to either of the star Apps for 7 and 10 digit patterns. I changed the Original pattern back to the last 4
It would appear that our system only reads the last 4 digits of the DID, not 7 or 10. Perhaps there is a block on the Single Line that doesn't allow external inbound calls.
-
Thesavo,
There is obviously something wrong if none of those patterns routes the call to the Single Line Port. We need to trace the call through the setup message, but that requires that you hook up to the T-1 card with Hyperterminal or similar software that can monitor an RS-232 connection through a serial port.
The only thing that would stop the Single Line Port from accepting the call is if it were forwarded either manually or through a System Forwarding Path. The only other thing would be if the ring generator for that port was bad, but all of the ports would have that issue since they all share one and that wouldn't explain why it ends up in a Hunt Group.
This is really an easy process to program and follow, usually. I wonder if the pattern you are calling is forwarded to another number. That would explain why you can never route it. Are there any DIDs that go to the place you are seeing the call ring at?
Thanks,
TE
-
It will route the call to a STAR app or a key set extension if the pattern is the last for digits of the DID.
I have changed the ring into 3 different STAR apps and voice mail 2500.
The problem is that it will let me get to a keyset from the STAR but not this SL.
How do I check for a single line call forward from dB programming?
Would it conditionally forward external but not IC calls?
Would the ring generator be bad if IC calls will make it?
Tomorrow I can take a working DID patten and change it to ring into this single line. Also as far as I know, there's no other wall jack connected to this SLC. There is also Noone capable in that office of doing so.
I'm staring to agree with a rouge forwarding rule. System forward path was empty in dB programming.
-
Thesavo,
OK maybe I am misunderstanding what is going on after reading your last post so let me clarify what the problem is before going any further.
A call comes in on a DID and for the sake of this explanation I am going to say that DID is this number, 212-465-0162. You are taking the last 4 digits of that DID, 0162, and sending it directly to a single line port with an extension of 162. At this point you are saying that it rings a Hunt Group 2001 instead of that single line port. Is that the correct problem?
I am also seeing that if you try to use a STAR that routes to CRA that allows you to dial extensions that you cannot get to that extension as it rings the Hunt a Group 2001 instead of the extension 162. Is that a correct statement as well?
You then added that extension 162 to the extension list of the Hunt Group 2001 and the phone still fails to ring. Is that a correct statement?
Thanks,
TE
-
Let me start by saying that you for helping me with this issue.
Yes, 212-646-0162 is going to hg 2001 when directed to extension 162. Yes, 162 does not ring. :-)
Yes to STAR statement. . It errors with "That number is not valid".
* I haven't added it to the extension list that is a member of hg2001.
That is a good test to see if it's capable. I could ask someone to sit in conference room and to note if rings, and ask the person monitoring hg2001 to not answer straight away.
Does it further confuse the situation if I say that the business number 212-646-0000 rings to app 2501. 2501 sends call to 2502 based on current time being with in business hours. AP2502 "times out" to hg 2001. ?
Person answering hg 2001 is the only
member.
I'm not sure why the integrator had set this up in that manner.
-
Updated previous post.
-
Thesavo,
Does it further confuse the situation if I say that the business number 212-646-0000 rings to app 2501. 2501 sends call to 2502 based on current time being with in business hours. AP2502 "times out" to hg 2001. ?
Person answering hg 2001 is the only
member.
No this does not confuse me at all since that is how a STAR application works. A STAR can only direct calls based on Time and Day to another Voice Processor Application. Those Applications would then have to direct the call based on either a users input, ie dial an extension, or if we want it to go directly to an answer point we just use the Time Out of a Call Routing Application (CRA) with no recordings in day or night of that application. In this case it is programmed to timeout to Hunt Group 2001 and most likely there are no recordings and if I had to guess it doesn't even say that the call is being transfered to 2001 as they probably turned that off in its Extension ID or possibly in the entire Voice Processor for extensions that do not have an Extension ID or Voice Mail Box.
Now, let's get down to business and figure out what is going on here. If the first statement is correct then the number you are dealing with is not working properly or the extension has some errant forwarding that you don't know about. We can check on the forwarding by just turning on Online Monitor and then go to that extension and look at the forwarding information section that now will show up. If you see that it is forwarded somewhere then you can remove that forwarding while Online Monitor is up or you can have someone on site use the feature code on the phone to turn it off.
Since you are not on site then looking at the setup message on the T1/E1 card is most likely not a solution to figure out what digits are being sent. We could look at SMDR since this is a 9.009 version it would have a CPC and therefore may be on the customers network and they could use a program like Procomm Plus to look at port 4000 of that cards IP Address to get the SMDR information once you tell it to send out SMDR in programming. I am not convinced that would give us enough good information to find a solution though, but you never know we can keep that in our back pocket for the hail mary if all else fails.
What would speed this process up is if I could actually see their database or screen shots of the CO Trunk Group, Call Routing Tables, Hunt Group, and the Extension along with the Primary Attendant or whatever is on port 1.1.1, which is what gets calls when the system doesn't know what to do with them.
If you want me to see the database you will need to email me through this site and I will reply back with an email you can use to send the database.
Thanks,
TE
-
So, telnet to the iprc card's IP on port 4000? I'll get putty on there tomorrow, if that is the case.
-
Thesavo,
That should work if their system is on the network, otherwise the default IP Address of the system is 192.168.200.201 /24 if you want to direct connect to it.
Thanks,
TE
-
That IP looks familiar. However, our company has three disparit axxess cabinets and a mitel 3300 all connected over T1s. It's everything is its own way.
-
Thesavo,
Well that doesn't sound good. Is this extension that you are trying to get to on the same node as where the DID enters?
Thanks,
TE
-
Er? Yes? I call the 10 digit number from the mitel 3300 using our T Provider. Oddly, no account code it is needed when I call their DIDs. I can reach any desk in that office by DID. To the best of my knowledge, calls enter on the trucks from my office just like they would for anyone.
The SL extension is on the same node as the hg, And the members. Each office, except mine has one axxess cabinet.
I'm in NY, they're in Illinois.
-
Thesavo,
Well that changes a few things then. So the DID you are calling is coming on the 3300 and then going across the T-1 to an Axxess system in order to ring the extensions?
Thanks,
TE
-
.. Is coming from a mitel 3300/SX2000 across the country over a set of Ts. Seeming like they would any other call, no? To the best of my knowledge, these systems aren't extensions of one another.
We have an MPLS linking our sites if it helps.
Is that a bad test?
-
Thesavo,
Well, not exactly the same as an incoming call directly to the Axxess since the 3300 sends the call to a T1 after it makes the changes it needs to in order to send the call. It also depends on how the T-1 is setup for the networking of those systems. My guess would be that the T-1 is set for OPX or DID on the Axxess so we would need to look at that to see how the calls actually come into the system.
Thanks,
TE
-
Resolved: There was some errant Forwarding. Turned off at the station with Feature Code 355 by an on-site user.
Thanks Tech Electronics for your help!
-
Thesavo,
Not a problem and I am sorry it took so long to figure out the answer, but in the end we got it.
Thanks,
TE