Search results for query: *

A hunt group won't go from one station to the next to the next if the call isn't answered. The hunt group picks the station to send the call to based on the type of hunting, in this case "circ". That means the first call will attempt to hit phone one if it's available. If it's not available...

Special Application has been turned on. However, the customer is still not able to use the TAAS code to pickup calls. They can make enough calls to see the attd-qcalls button flash on the backup phone but when they pickup and dial the TAAS code they get waved off. I just noticed yesterday...

Up to 5 G650 gateways could be connected together to form one port network that basically duplicated the old Definity Multi Carrier Cabinet. It shows up in the config as one PN with up to 5 carriers which would be A through E. One IPSI in carrier A could control the entire stack.

I am able to log in as init. The problem is when I do a "ch sys spec" command, I don't know what the passwords and key are that it asks for on that screen.

Of course as soon as I post that I get a response from the customer. He said it works just like it should. Thanks.

I am working with a customer with an old Definity 9.5 (I know, very old). I am trying to set up attendant backup alerting. I have everything done but the backup phone can't enter the TAAS code to pick up the calls. Just by chance, I ran across an old post that mentioned a Special Application...

Still waiting to hear back from customer if the attd xfer calls work or not.

My concern is still being able to have the front desk transfer room to room. Sounds like it's time to give it a test. Thanks.

I am working on a Definity/early CM R013i.01.2.632.1 in a hotel. The manager wants to block guest room to guest room calling without going through the attendant. I don't know what PMS they are using, but controlled restriction appears to change User Cntrl Restr: from none to toll, although I...

It is. Actually just figured out the problem about an hour ago. The customer had given us an invalid number for the cell phone. Once I had the correct cell number in the remote coverage table it worked fine. Go figure. Then, they actually figured out that's not what they wanted to do...

Definity 9.5 (yes, I know this is very old). A customer of mine is trying to set up a number for a "call in sick" line. They want it to ring out to a cell phone and then come back to Audix if not answered. No problem. Set up a station with a coverage path that covers to "r1" first, and then...

Well, finally got an answer from the PRI provider. They weren't actually sending any called number information, so no digits for the PBX to use to route calls. I knew there should have been more data following the calling number.

If you changed the dial string 9 because they dial 9 to make the calls, then that's the problem. The initial '9' that you dial to make an outbound call is a feature access code and activates the ARS feature. It is not considered part of the dialed string. i.e. if the user picks up the phone...

I set up MST to capture d-channel data on that particular PRI. I enabled mst and had the tech make one test call. After the call completed, I did a "list mst" and all that showed up on the screen was what I pasted above. I cleared the mst and had him do another test call. The same...

Look in your existing ARS analysis plan and see how the 7 digit dialing is set up now. Usually you would have a matching pattern of a single digit (2, 3, 4, etc...) with 7 digit minimum and maximum followed by the route pattern and call type of hnpa, locl, etc... You could simply add one line...

Trying to figure out why calls coming across this "tie" PRI from one Definity to another are not being directed to the correct extension. This is the trace from the D-Channel of the PRI in PBX 2 capturing the test call. The caller called into PBX 1 from the outside to the remote access number...

Old system, I know.... Customer has two locations tied together with a PRI. The testing that was done was: Call from 713-459-XXXX into switch 1 at 512-430-XXXX and then dial 6101 to go across PRI to switch 2. Switch 2 is not getting, or recognizing, 6101. Switch 2 uses 3 digit extensions...

What software version on the PBX? Try setting your network switch port to 10M/full or even 10M/half duplex. Older software did not have a place to set speed to 100M.

V6 systems needed to have a communication link and communication processor channel programmed to run the D-channel.

Incoming routing is completely different based on the type of trunk. CO/POTS trunks go to the extension you have programmed as the "Incoming Destination" on the first page of the trunk group form. T1/ISDN etc... use the digits the provider sends over the trunk to determine where the call goes...