seeing 000-000-0000 on display for calls xfrd from MM

[mmagen]

We have a new MM 5.2 integrated to our CM 4.0 via SIP trunks with SES 5.2.1.0. We are getting reports that the display on a telephone shows "call from 000-000-0000" when the user receives a call transferred from MM. Even though the system is brand new, and we never had the issue with out Intuity, Avaya says it will be billable to investigate and correct the issue. My guess is they don't have a clue what's wrong, and want to charge us so they can learn. Anyone have any idea what might be wrong? It is an intermittant issue, it doesn't happen all the time. See log:

14:34:32 Calling Number & Name 0000000000 AT&T SDN
14:34:32 active trunk-group 11 member 32 cid 0x349c
14:34:32 G711MU ssff ps:20 rn:242/1 192.168.37.92:7046 192.168.37.71:3328


Mike

Why does the light always have to be at the end of the tunnel?

 

[mikeydidit]

Mike I have been getting hammered with calls from 000-000-0000. I think its a fax server randomly sending out junk from XYZ company. That would make since that MM is sending out what it was send by way of CID.

I am going to try to route those calls to my fax and see if i start getting faxed junk from them. If not I am going to send those calls someplace really nice..

When is the last time you helped someone, just because you were able to?

For the best response to a question, read faq690-6594

 

[wellco9530]

Friend of mine getting the same thing for a couple of day's now....he looked up the number of the local FBI office..he's thinking for doing a CFW to their fax and see what happens....;-) Might be good for laugh or two...I told him he might not want to do that though.......

 

[mmagen]

I appreciate the feedback (and the good laugh) you both provided. However, my case is a little different. Only calls passed from the MM to the CM get tagged with all 0's, the incoming call registers in the CM with a correct 10-digit ANI. But if the call goes to a caller application in MM for example, it comes back in to the CM with all 0's. Could the configuration of the SIP trunks be the problem? And how do I check to see? I didn't set up the SIP trunks between the CM and MM, the Avaya project team did, but since we've "signed off" on the project, they won't look at it, they want "professional services" to look at it, and that is big $$$.

Mike

Why does the light always have to be at the end of the tunnel?

 

[PBXTech]

unplug the INADS line and threaten to not pay the maintenance bill and/or go to a (different) business partner. raise holy hell. they will fix it for free.

 

[mikeydidit]

Mike have you checked the public unknown numbering? I had this same setup installed a couple of months ago and that was one of the things that had to be done for our SIP trunk group. You should be able to run this command to find the entries.

"li public" Look for entries pointing back to the SIP trunks. If you need me to, I'll post our SIP configuration also.

When is the last time you helped someone, just because you were able to?

For the best response to a question, read faq690-6594

 

[mmagen]

Yes, the public/unknown numbering table is populated with information on trunk group 11:

NUMBERING - PUBLIC/UNKNOWN FORMAT
Total
Ext Ext Trk CPN CPN
Len Code Grp(s) Prefix Len
4 2 11 4
4 3 11 4
4 4 11 4

Does this look right?

I am leaning toward the SIP config at this point because I have a warning on the SIP signalling group (11) that I can't resolve:

Port Mtce Alt Err Aux First/Last Err
Name Name Type Data Occurrence Cnt

11 SIP-SGRP 257 04/07/03:15 88
04/15/19:54
11 SIP-SGRP 513 0 04/11/14:10 7
04/14/11:55
11 SIP-SGRP 1 04/13/23:00 6


Mike

Why does the light always have to be at the end of the tunnel?

 

[mikeydidit]

d. Error Type 257: Tracks failures of the SIP signaling-group PING test. See Signaling Group
Ping Test (#1387) for test failure information.

Signaling Group Ping Test (#1387)(Same test for error 513)
This test checks the circuitry involved in the data path of a peer-to-peer IP layer connection. It is
only run for those signaling groups that have an administered far-end IP address. If the H.323 or
SIP signaling group does not have an administered far-end IP address, the test will abort.
The test determines the local C-LAN through which the signaling originates, and the far-end
terminating IP address. It then requests the local C-LAN to execute a PING on the far-end
address. If the PING is successful, the test passes. If the ping is not successful, the test fails.
Note:
Note: Multiple failures of this test will cause this signaling group’s associated H.323 or
SIP B-Chels to be taken out of service (OOSFE). This will allow incoming calls to
be made when the far-end comes up before the near end has detected it. The
signaling group will be left in service, but in the far end bypass state.
If the PING is successful, the test looks at the PING round-trip delay. If a round-trip delay of
greater than 4 seconds is reported, a separate error is logged. Excessive round-trip delays
within the signaling group will not take the signaling group out of service.
The standard PING command can be executed using the C-LAN board’s address and far-end
IP address from the signaling group screen to see the actual round-trip delay.
This test runs on H323-SGR (H.323 Signaling Group) and SIP-SGRP (SIP Signaling Group).

b. Error Type 1: Failure of the C-LAN hardware (IP-PROCR in S8300 systems) carrying the
signaling group chel.
To determine which C-LAN had been administered for this signaling group, find the
near-end node name on the signaling group form, then find the C-LAN or IP-PROCR
with the same node name on the ip-interfaces form.
Check for errors against the CLAN-BD MO.





When is the last time you helped someone, just because you were able to?

For the best response to a question, read faq690-6594