Q: I have been getting some random complaints that when people are trying to transfer out of the Intuity to someone’s extension they hear a recording that says, “All circuits are busy.” Every time I’ve made some test calls they all seem to go through without any problems. I don’t think we’re running into a situation where all of the Intuity ports are busy at the same time. I’ve looked at the hunt group measurement reports and never seen any “Calls Queued” to the Intuity hunt group. What do I look at next?
A: I seem to hear about this problem every year or two. It’s usually just long enough in between so I can’t remember off the top of my head what causes it. I took a look in your Intuity and agree that isn’t a situation where all the ports are busy. After looking through some of the complaints you forwarded to me, I noticed an interesting pattern. All of them seemed to be from people trying to transfer to stations that are located in your remote office rather than the main one where the Intuity is located. This led me to look at the Class of Restriction (COR) for the Intuity ports. The FRL associated with that COR was 1. When I looked at the route pattern that was used for 4-digit dialing to your remote switch, I noticed it required a minimum FRL level of 2. So what was happening was the caller would dial the extension number, and because the Intuity port FRL was not high enough to make the call across the tie trunks it was rejected. The Intuity was interpreting this as a busy condition and that’s why it was playing the “All circuits are busy” recording.
My guess is the Intuity was set up before the remote office existed, and it looks like whoever set it up wanted to be sure to prevent any chance of toll fraud. You have a couple options for fixing the problem. You could either assign the Intuity ports a higher FRL by creating a new COR, or modify the existing COR if nothing else uses it. The other option would be to lower the FRL in the route pattern to the remote office. Make sure not to allow other phones to call across the tie line that shouldn’t have that ability.
Q: I work for a small interconnect company. One of our customers has a Definity V8 that was upgraded from a System 75 many years ago. About three years ago we replaced their copper trunks with a couple of T-1s. Both of them are in the same trunk group and are used for both inbound and outbound, local and long-distance. They have not had any problems until a few days ago when they suddenly couldn’t make any long-distance calls. I tried to look through the ARS Analysis to see if I could figure out what was wrong but it is a confusing jumble of hnpa, fnpa, rhnpa, partitions, toll lists, etc. Is there a way this can be simplified so a normal human can understand it?
A: As far as the reason why they suddenly couldn’t make long-distance calls, my guess would be the T-1 provider made a change to their system without notifying the customer that it might affect the dialing pattern. After looking through the ARS Analysis, I agree it’s a big mess. My guess is this was partially a carry-over from the System 75 upgrade, and this customer is in an area that had its area code changed a few years ago.
I completely agree that it would be much easier to understand and maintain the ARS if it was simplified from its current partitioned mess. Unfortunately it’s not just as easy as adding a line in to match any call that’s eleven digits long and starts with a 1. The ARS Analysis tries to find the most significant match from the table. For example, if the customer wanted to call our main number the ARS would match the entry for an eleven digit call starting with “1503.” What would have to be done is somewhat time-consuming, but not difficult by any means. Basically all of the entries that are meant to match long-distance calls would have to be removed. There would most likely be some exceptions such as an entry to block calls to the 809 area code, entries for toll-free 800/888 calls, etc. I would also strongly recommend cleaning up or completely removing most of the route patterns.
Considering that all of the calls are being routed out over the same trunk group, I would say there really isn’t any need to use the hnpa, fnpa or rhnpa tables. Also, I noticed during testing that this customer has the long-distance provider require an account code to complete any call. I would set up a simple match for eleven digit calls that start with a “1” and use the call type “natl.” Using this type bypasses any of the Prefix Mark instructions in the route patterns. This should help narrow down the sixteen-page mess that your customer has now. He would probably be left with an ARS Analysis that’s only a page or two long at the most.
ARS can be a tricky subject to master, so if you have any questions about it or anything else related to the Definity, please give me a call.
More at medak.com.
© 2008 Telecom Reseller. All Rights Reserved.