Hello?.. Hello? You called me, no YOU called me! 1

[Toni269]

I get this about 3 times per month, reports from end users saying they are getting calls from somewhere a business or residence saying that we called them and we think they called us. Sometimes callers end up in Audix saying: Hello?....Hellooo? Last night we had repeat calls from the same number claiming that we were the ones calling them. I check in the Call Detail reports and in fact they were all Incoming calls not outgoing. We don't have a predictive dialer or call return features. What's happening on the other end to cause this to happen?

 

[nknook]

Your best bet is to contact your pstn-operator, and have them look into it. Could be wrong administration in the public switch, or some app somewhere (anywhere) misperforming, or auto-callback through a PBX that fails (due to incorrect callback number, so someone behind a PBX with ext 444 calls you, you're busy, they press callback, but they have a CLIP of 400. Auto-callback (in public switch) gets activated, calls ext 400 and you. The person answering the call to ext 400 doesn't have a clue why they get you on the phone, and neither have you. This normally shouldn't happen, but it is possible, especially if the other party has some "El Cheapo" PBX...)

Nice puzzle

Good luck,
Nico

 

[WHCARon]

Toni269,

It's possible that this is an old operator trick. Someone in the middle calls two parties and listens to both ends argue about who called whom. Look for some link between the parties (I know of an incident where someone harassed a neighbor doing this) and have the LEC trap your calls. They would be able to see the detail on both end points.

Good Luck, WHCARon

 

[netcon1]

I find it hard to believe that those calls were classified as inbound calls, however, every situation is different.

I do suspect that a voice mail box has notification set to outcall to the wrong number perhaps. (I base this on knowing the customer (or complainer) is always correct.

Question time...

Are the lines on your system loop start?

Do all the trunk groups have CDR "yes" set to show you all the outbound calls.

Do you have the voice mail ports included in your call accounting software. (perhaps do a report on the ports and what they are calling out to..)

Do those hello hello calls reside in only one particular mailbox? or are they in many mailboxes?

If they are in one mailbox, have you used the disp activity subscriber option to see what is happening on an activity basis in that mailbox?

What does the caller here when the system calls?

Are those inbound CDR records the result of the customer calling back in after the fact to see what is calling them?

These answers might help diagnose the problem further.

Some some more ideas for you to look at...

netcon1

 

[randyb19]

netcon1 - it is possible for those calls to be inbound. As WHCARon stated, it is an old trick. At my last job, we had someone in our office that would dial a number, hit conference, and then dial a second number. He would then connect the two and listen to them argue over who called who. Toni's situation sounds almost identical. The only thing is I'm not sure how to help since it does not sound like it is being initiated within the PBX.

 

[Toni269]

CDR is set to Yes on all trunk groups, not sure about the loop start but I believe they are. Yes our voice mail ports show up on CDR reports. We do not use outcalling. The calls that we are receiving, the majority of them end up in the call center, hunting with each call to a new agent, none of these agents have voice mailboxes. When looking at the CDR, I can see for example, 15 inbound calls from the exact same number, one outbound call to that number (us calling them to ask them to stop calling), or a number with the same prefix calling us to ask us to stop calling. The callers hear eachother and they can have a conversation, usually about who is calling who. They usually come from Hospitals or Hotels, but can also come from a residence, however the residence calls do not repeat over and over.

 

[netcon1]

I'm still not convinced. (however, I have been wrong before..!!)

Are any of these set below different in your trunk group?

I am suspicious of the Queue length if the trunk group is a loop start trunk group for inbound/outbound traffic.
Glare or call collisions can occur frequently when a loop start trunk group is used for both inbound and outbound traffic at the same time. If that is how your trunk group is set up then any one of the below setting might be causing the trunk lines in the group to hookflash or cause glare which may result in what you are seeing. (CDR would not pick this up.)

Definition:
Queue Length — Don’t create a queue for two-way loop-start trunks, or you may have a problem with glare (the interference that happens when a two-way trunk is seized simultaneously at both ends).

The following settings are pulled from a working trunk group with both in and outbound trunking.

Queue Length: 0
Trunk Flash? n
Trunk Type: loop-start
Outgoing Dial Type: tone
Cut-Through? n
Trunk Termination: rc
Disconnect Timing(msec): 500
Auto Guard? n
Call Still Held? n
Disconnect Supervision - In? y Out? n
Answer Supervision Timeout: 30
Receive Answer Supervision? n

Does your trunk group have any of these settings set differently?

netcon1

 

[Toni269]

This is a 2-Way trunk, here is how it's programmed:

Group Number: 1 Group Type:isdn CDR Reports: y
Group Name: Local PacBell ISDN DID Call COR: 95 TN:1 TAC: 601
Direction: two-way Outgoing Display? n
Dial Access? n Busy Threshold: 99 Night Service:
Queue Length: 0
Service Type: public-ntwrk Auth Code? n TestCall ITC: rest
Far End Test Line No:
TestCall BCC: 0
TRUNK PARAMETERS
Codeset to Send Display: 6 Codeset to Send National IEs: 6
Max Message Size to Send: 260 Charge Advice: none
Supplementary Service Protocol: a Digit Handling (in/out): enbloc/enbloc
Trunk Hunt: descend
Digital Loss Group: 15
Calling Number - Delete: Insert: Numbering Format: pub-unk
Bit Rate: 1200 Synchronization: async Duplex: full
Disconnect Supervision - In? y Out? n
Answer Supervision Timeout: 0 TRUNK FEATURES
ACA Assignment? n Measured: internal Wideband Support? n
Maintenance Tests? y
Data Restriction? n NCA-TSC Trunk Member:
Send Name: n Send Calling Number: y
Used for DCS? n
Suppress # Outpulsing? n Numbering Format: public
Outgoing Channel ID Encoding: preferred UUI IE Treatment: service-provider
Replace Restricted Numbers? n
Replace Unavailable Numbers? n
Send Connected Number: y
Send UCID? n
Send Codeset 6/7 LAI IE? n Ds1 Echo Cancellation? n
US NI Delayed Calling Name Update? n
Network (Japan) Needs Connect Before Disconnect? n

 

[netcon1]

I stand corrected.....

carrier problem!!!!

netcon1

 

[netcon1]

One more shot at it!!!

Do you have a second or backup trunk group?

Do you have PRI overflow or alternate routing on the PRI to copper backup lines or a different telephone number?

If so, where is that trunk group pointing to and how is it programmed?

If you list measurements DS1 log SS/PP today, do you see any PRI problems over the last 24 hours, that may show the PRI having problems when the complaints are called in?

Just grasping now!!

Netcon1

 

[netcon1]

Is this the same switch that you stated problems with in the
"ISDN-SGR & SYS-LINK Errors, T1's Bouncing?" thread?

Netcon1

 

[Toni269]

Yes I have a second trunk group for long distance, and yes there is alternate routing setup on the long distance to the local pri and from the local pri to copper lines.
I did the list measurements, and for the local trunk, (2 ds1's) no errors, on the long distance trunk two on two boards, (total of 3 ds1's) on 01c15, ES 4 17:56, on 01c16 ES 4 and BES 4 17:56. Here is the programming on the long distance trunk group.

Group Number: 3 Group Type: isdn CDR Reports: y
Group Name: Global Crossing - Long Dist COR: 93 TN: 1 TAC: 603
Direction: two-way Outgoing Display? n
Dial Access? n Busy Threshold: 99 Night Service:
Queue Length: 0
Service Type: public-ntwrk Auth Code? n TestCall ITC: rest
Far End Test Line No:
TestCall BCC: 0
TRUNK PARAMETERS
Codeset to Send Display: 6 Codeset to Send National IEs: 6
Max Message Size to Send: 260 Charge Advice: none
Supplementary Service Protocol: a Digit Handling (in/out): enbloc/enbloc
Trunk Hunt: descend
Digital Loss Group: 13
Calling Number - Delete: Insert: Numbering Format: pub-unk
Bit Rate: 1200 Synchronization: async Duplex: full
Disconnect Supervision - In? y Out? n
Answer Supervision Timeout: 0
TRUNK FEATURES
ACA Assignment? n Measured: internal Wideband Support? n
Maintenance Tests? y
Data Restriction? n NCA-TSC Trunk Member:
Send Name: n Send Calling Number: y
Used for DCS? n
Suppress # Outpulsing? n Numbering Format: public
Outgoing Channel ID Encoding: preferred UUI IE Treatment: service-provider
Replace Restricted Numbers? n
Replace Unavailable Numbers? n
Send Connected Number: y
Send UCID? n
Send Codeset 6/7 LAI IE? y Ds1 Echo Cancellation? n
US NI Delayed Calling Name Update? n
Network (Japan) Needs Connect Before Disconnect? n

 

[Toni269]

Yes it's the same switch. I also have problems with the Voice over IP. The entire connection keeps dropping. I have another thread called: C-LAN Intermittantly Dropping All Connections.

 

[netcon1]

Crap...this is getting messy.

Does you IP conections still drop after you upgraded the firmware on the clan card?

Did you upgrade the firmware on the medpro as well?

Where are all your ip, medpro and DS1 cards located in the switch?

Do you have any packet interface alarms in the alarm log?

Do you have a service contract with AVAYA or a business partner?

The C-lan card, if set up in a ppp connection enviroment, does insert the signaling data on the TDM bus for subsequent inclusion (via the switching fabric) in the same DS1 bit stream as the voice transmissions. This could be causing the problems with the signaling if set up this way.

Are you using IP trunking on your switch?

Display the system maintenance form. Is the dial out number for the switch set correctly, or is it calling the person complaining. Same on the voice mail. Is the voice mail calling the complainer?

My theory is pointing to time slot problems... List measurements <port network> and see what percentage usage the port network is under.

Also, if the IP phones are not fully operational, busy out the c-lan and medpro cards and run the switch for a day without them. See if the ISDN problem goes away.

Buss problems, could also be a factor if you are using an older port network and have shoved all the DS1 and lan cards in the first cabinet. Also problems could exist if all the DS1 cards and lan cards are not in the first cabinet.

There is a complete engineering design that should have gone into this box before this was upgraded to ensure that the signalling across the TDM bus is proportional and distributed properly.

Insert your credit card here...

I cannot go any farther with the three posts you have without directing you to AVAYA TAC Centre or the Business partner you had install it.

These items are what I would investigate over the next few days, as I think they are all related.

cheers!!! let me know if I was close!!!

Netcon1

 

[Toni269]

Yes IP connections still drop after C-LAN firmware upgrade. I didn't even think of upgrading Med-Pro.. All IP, Medpro and DS1 cards are located in the switch, (most of them in the same cabinet.) It has been suggested to move the MedPro board into another cabinet, and I will probably do that next week. I have maintenance with Avaya and I have had a 6 trouble tickets over 2 months regarding the C-LAN issue and I am currently working wiht Tier 3. Your question about the PPP connection was way over my head. We are not using IP Trunking. System maintenance dial out is set correctly. Under list measurements, these are my choices: aca coverage-path occupancy
announcements ds1 outage-trunk
attendant hunt-group principal
blockage ip route-pattern
call-rate lar-route-pattern security-violations
call-summary lightly-used-trunk summary
cbc-trunk-group load-balance tone-receiver
clan modem-pool trunk-group
communications-links

I am not aware of any engineering designes in place before our upgrade in May 02.

I thank you very much for your help and for your time, you've given me tons of ideas. I will post after this is corrected to let you know what the final culpret was!