NEC SV9100 Intermittent one way audio on ISDN-PRI

[meyer1y2k]

Have a real, at least for me, headscratcher. Site recently installed SV9100 with PRI. Migrated from hosted. Everything seemed to work well until they mentioned that callers calling in will report that they hear ringing even after the call is answered. The party on the PBX says they can hear the caller but cannot be heard. This happens to analog or digital users. I tried replacing the PRI card and it seemed to solve the trouble but it has been reported to come back. The service provider says not them. I have run D-Channel traces and both tech support and I can see nothing wrong there. I am trying to avoid visiting the site with a PRI tester as it is very remote. If I go, I will be prepared to replace the cabinet and CPU if I cannot prove to myself it is the SP.

I am writing in the hope someone out there may have run across this or can offer some meaningful troubleshooting. I have remote access to the system.

Of course, I have made about 100 test calls to this thing and can't duplicate it.

Thank You ~ Mike

 

[belevedere]

The big question is, the SP bringing the link in as SIP converting to digital PRI? If so, possibly their issue. Can you determine if it's a specific port?

 

[PFD45]

When we were experiencing intermittent talk path failure on our 9100's the System Alarms were showing 2 "IP Collisions" per minute.
They weren't actual IP collisions but were caused by a Cisco device doing some sort of probing that involved an IP address of 0.0.0.0.
The 9100 does NOT like dealing with quad zero IP addresses.
If this is happening at your site, I can tell you what we did to correct it.

 

[meyer1y2k]

@Belvedere - As far as we know, it is a straight PRI but, who knows, when it gets to the POP? We have not been able to drill down to a specific port. Trouble only seems to occur on incoming calls.

@PFD45 - Thank you. I checked the system alarms and there was nothing like that occurring.

Mike

 

[AKgreatland]

PFD45 curious what you did to fix your issue.I dont have an issue at this time just wanted to make notes as we have had similar issues in the past.


Thanks

 

[PFD45]

We chased intermittent talk path failure associated with constant "IP Collisions" in the error log for a long time.
We pinned it down to the quad zero IP address issue and used DIM to pull an ARP cache list. It showed a MAC address and IP address 0.0.0.0.
I went to our IT guys and told them to quit it!
They recognized the MAC and changed come setting regarding 0.0.0.0 in our Cisco equipment. Something about device probing.
Everything cleared up after that.

 

[meyer1y2k]

I went to site Thursday night with an ISDN-PRI tester. I jacked into the monitor ports on the CSU and configured the tester so I could selectively listen to Eq audio and network audio.

Then the fun began with calling in, calling in, calling in, calling in. Could not duplicate trouble. I went back Friday morning and finally was able to get a similar trouble. I called in and there was no audio in either direction. I placed the call on hold so the system would broadcast music on hold and thankfully heard it on the test set so I know the system is doing its thing.

We left the call nailed up while the customer called Level 3 and tried to get them to help. We got the same old run around about the D-Channel setup being good which was never the issue. When we explained there was no audio on a B-Channel, you could hear the deer in the headlights look. The tech was going to open a ticket with T-Mobile (where the call originated from) but I think that is a stop gap.

We tore down the call and, for grins, I tried to replicate it. I did. We then tried 150 test calls from an AT&T wireless with no trouble. I was also not able to recreate the trouble for the rest of my visit from my phone.

I feel much more confident that this is not an NEC issue and I think I won the customer over on my side because I at least visited the site and performed some meaningful testing and could demonstrate logically what was happening.