sundance-communications.com/forum Forums TDM Business Telephone Systems Avaya - Lucent Telephones & Systems How can this be?

LegendR7 w/4 port Leg mail/2 - DS-1 mods(in sep.cabs)/Confer II 24 port analog conf bridge.
Facilities:13 analog(Pilot+hunt)- 8 analog DID's(separate ext range)- 2 supertrunks (outbound only)
Problem: Customer frequently complains that random calls to the pilot # automatically enter the conference bridge "rooms"
Issue: In order to do this you must dial a "room" code+ # AND a PIN# + #
What I found: None of the lines are assigned to any of the t/r ports used for the bridge or the DGCs used. Over 100 test calls were placed with no results...I did find the 5th line in hunt busy, was able to clear it, but then it returned to busy again. I'm guessing it's not related. SO...
How can a random call over an analog line automatically dial the DGC# for the bridge, then prepend 2 set of digits to enter the conf bridges?
Calling all you master "out of the box" thinkers - what is going on here?

The problem lies with the confer II. I dont know anything about those but thats the only thing that could cause that problem.

If what I'm thinking is true, then it's time for you to go play the Lotto as my theory relies on the probability of a communications miracle so remote, that I'm almost sharing this idea more for fun than anything else.

If you were able to slip in a digit grabber on an inbound call AFTER it passed through an Integrated VMI hunt group (a call that's going to voicemail), you would hear DTMF tones that would decode to something like #02##xxx#, where xxx is the called party's extension OR #01##yyy#, where yyy is the trunk number that the call arrived on.

These "mode codes" are part of an internal communication that happens between the PBX and voicemail side of the house. Am I going to play an Automated Attendant for an outsider or am I going to play the personal greeting of someone's mailbox? It's these codes that clue the 007MLM as to how it will handle the call.

Now let's further say that you have a failing or marginal TTR (the chip that decodes DTMF tones). Given a wild set of coincidences, it's possible that the digits on an inbound could be "misinterpreted" by the TTR and direct the call to the bridge DGC instead of the VM DGC. And IF said DGC is defined as a VMI of any kind AND the mode codes sent just happen to match both room code and PIN...well there you have it. Me and my wild theories.

On the off chance that I'm right, I would immediately prepare myself for a random alien abduction. But before that happens, change the room code and PIN to something that steers clear of "01" or "02" as a room code and/or a PIN that looks or smells anything close to your trunk numbers.

You might also want to test the TTRs in the switch.

I like where this is going. The Confer SE(NOT the Confer II - my mistake)setup requires the DGC it uses to be set as "Generic VMI" - I don't know why, since the mode codes don't seemingly have any function. The TTR's are responsible for carrying the information on "room" & PIN code entries from the caller depending on the DGC setup.

(A quick aside here - I 've noticed a 2 DGC limit on Integrated/Generic VMI settings)The last 4 bridge ports were assigned to DGC 772 w/771 overflowing after 20 calls - it still works even though I could only set it to Auto Login...(The V-mail being the other VMI group type)

Now the bad news - These calls ring straight to the bridge from the outside, circumventing any coverage which would prepend the mode codes that COULD conceivably dial the bridge.(BTW the DGC used is 771 and the customer made it more confusing by also numbering the "rooms" 771, 772 ect!!![I could not disuade her from this]the PIN codes as far as I know are a single digit)This will now be the necessary argument to renumber them. Maybe I can also try to change the group type to Auto Login and see if that changes things for the better. To be continued...

Bassbill,

The good news is you could not have a better outside the box thinker than Tim on the case. The bad news is, he's probably right about the aliens.

You kill me Shawn. Thanks for the compliment. "Out of the box thinking"? I don't even know what box it is that you're talking about. LOL.

So bassbill, you're in Los Angeles. How come we haven't bumped into each other already?

If the call truly "rings in directly" to the conference, then one of two things could be at play: either one of the hunting trunk members is assigned to that DGC or the "call from the outside" is actually a DID being directed there.

Get a printout of the Calling Groups and study it's membership as well as the PRI Info report (if applicable) to see what, if any, digit translations would cause calls to be sent toward that group.

We very well may have worked and/or run into each other. If you're an old AT&T guy, then you you probably know my old boss John Clemmer...

Anyway, Not only did I check the DGC's for line assignments, I checked all 24 T/R ports to make sure a stray line hadn't been assigned there - nothing of course. I've also verified (placing over 100 test calls!)that the number called comes strictly over the POTS lines ONLY...(Maintenance Monitor is a WONDERFUL THING!)

As I also posted, I've changed the DGC type from Intergrated VMI to Auto Login. I can't see any use for mode codes, as the calls are still answered with the prompting for the "room" & PIN codes. I have advised the customer to keep me posted regarding any more events. The only other thing to do would be to hang something on the SMDR port to try and catch the call to match it to the complaint...

TBC

I hope your customer will be good about reporting back to you on this. My curiosity is sky high as to whether changing the group type fixes it. If your trick works, then it becomes pretty apparent that the VMI setting somehow played a role, especially given the "room" numbering scheme matching that of our default DGC plan.

Which brings up another idea. Heh...and so obvious now. You could just renumber any DGCs that match "room numbers". Giddy up.

Being the old phone guy you are, I'm sure your 100+ test calls included those to specific phone numbers in the hunt (and not just to the pilot number)? And what about that 5th line? Was it busy from the telco or only busy once it was tied back into the switch? If you were able to ID the line, I wonder what would happen if you called it directly. The PBX line port could be broken in such a way that it *thinks* the trunk is busy, though an inbound call is possible. If that's the case, perhaps that line port plays a role in these bizarre calls.

I am certain I'll hear back. Production companies are funny that way - when there's a problem - the house is on fire! After you bandage their system and offer a permanent fix, you typically don't hear back from them until next time.

I have been pushing to renumber the "rooms" to something other than the DGC #s or the default #s 001-008. I am curious to first see if changing the DGC type is going to work.

In regards to the test calls - There was a 15 line hunt, so I loaded up my trusty 4412D+ with 10 SA btns. I called the Pilot #, got the auto attendant and set up a transfer to an unused QCC, so that the call would just ring continuously, and also allow me to put it on hold and call in again until I had all 10 SA btns full.

I then LV'd one of the lines further down the hunt sequence and started more calls, so as to completely cover the entire hunt.

That 5th line was tested by the CO and came back clean. No other line problems have been reported, although I am going to randomly check that line for trouble, so that should effectively kill 2 birds with one stone - testing the port as well as the line.

One other note on these Confer SE's that I'm not sure isn't playing a role in the bizarre. There seems to be a bug in the software regarding a call log it generates, that when not cleared on a regular basis, will cause the unit to answer the call but NOT play any prompts.

Luckily, after more than a year, I've been able to convince the IT guy to give me back my web access, which will allow me to not only monitor but do the maintenance the customer won't do.

TBC...