Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Wanet Telecoms Ltd on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

We cannot hear incoming callers (becoming a common complaint)

Status
Not open for further replies.
BWB8771

BWB8771

Technical User
Dec 28, 2012
124
US
I set up a wrapping capture file Wireshark trace on the MAC address of our IPO appliance.

When an employee called to inform me that she had just experienced the issue many about which many have been complaining, I stopped the capture session, and then filtered on the MAC of the employee's phone.

Wireshark's analysis tools really don't see anything obvious but, as an experienced network engineer who realizes many problems (and resolutions!) often start with a "hmm, that's odd...", I do see where Wireshark highlights "malformed" H.225 packets in packets number 10811, 10812, and 10813 in the file linked-to below.

Is there someone here who might have the time and the inclination to load my capture file into Wireshark and help me troubleshoot this? It's a spotty problem, but one that is growing in visibility.


My capture file --> Link

Thanks!


IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Sort by date Sort by votes
I would wager it's silent coming from the system so wireshark will not be relevant, we have had the same on some R8 and 8.1 systems with ISDN30 and a more than usual amount of calls being silent, monitor has nothing to show out the ordinary and BT see nothing, it's not frequent enough to catch on a Trend/ISDN30 tester but enough that you think this isn't normal...not sure where the issue is TBH but I suspect a software bug that only effects some systems :)



"No problem monkey socks
 
Upvote 0 Downvote
@HSM - our topology is fairly simple (I feel):

IP 500 8.1(63) and phones are connected to Nortel 5520-48T-PWR switch; phones are PoE by the switch. Phones with this issue are both/either 5621 or 4610 phones.

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
So no trunks?


BAZINGA!

I'm not insane, my mother had me tested!

 
Upvote 0 Downvote
No, we just use it for a very expensive intercome system.

Ahahahaha! D'OH!

Just one PRI as a trunk

Switch type: NI2
Ch. alloc: 23 -> 1
Line subtype: PRI
Framing: ESF
Zero supp.: B8ZS
Haul length: 0-115 ft <--- ??? extended demarc is MUCH longer than 115'
Line signalling: CPE <-- curious - we were always "CO" at old company...

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
Several weeks ago we had our telecom install a "CommWatch" appliance in between the extended demarc and our CPE because we our IPO interface was asserting Red Alarms about once every 6-10 days. Sine they installed we of course have not had the first alarm or circuit bounce. I'm now wondering if that might be related to the "Haul length" setting I just discovered set to about 1/3 of the actual distance from CPE to NIU.

Do any of you feel there is any chance that that CommWatch gizmo, sitting on the PRI just before the IPO interface, could have been complicit in our one-sided conversation issues? I'm grasping at straws here, and in looking back at the timeline of anything that changed, that was about the only thing I can think of.

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
It's entirely possible, a device now sits between your system and the lines and at about that time you started getting instances of 1 way speech on those lines, I know where I would look :)



"No problem monkey socks
 
Upvote 0 Downvote
Heh, it's been disconnected for about an hour now. I'll know if there's a definite correlation when everyone returns from vacation/holiday next Monday and the calls start coming in.

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
We're still having problems with one-way conversations. Well, since we can't hear the callers, it's too charitable to call 'em "conversations"

The problem was assigned a bugID in Avaya, but only as it related to SIP-delivered trunks, "IPOFFICE-36829 One way speech path incoming calls if arrive via VoiceMail Pro from a SIP trunk"

I'm in discussion on a two other threads to see if this is resolved in the 69-release.

It was also asked if our trunk is actually SIP, out in telco-land, but delivered to us as a PRI. I've just fired-off an email to our account rep.

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
Time Warner Telecom indicates our PRI is never SIP/IP, always TDM, so that answers one question.

Since we do not seem to be having problems with *internal* calls, and all external calls are answered by the VMPRO AA, is there a way I can debug the "redirects" (for lack of a better word) that occur when the external caller dials their desired extension, and VMPRO transfers the call?

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
What about the VCM card in the system?
Swap it and see what happens.


BAZINGA!

I'm not insane, my mother had me tested!

 
Upvote 0 Downvote
At the risk of jinxing myself, I think I found the/a culprit!

We were troubleshooting a situation and I had set the MAC table life to 5 minutes. It defaults to 360. When I set it back, I have not received any complaints, and I've made it very clear I want and need to hear about ANY "one-sided" conversation.

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
^^ This was (maybe not so obviously) on the Nortel 5520 Ethernet switch-stack.

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
I would be interested to hear if the problem pops up again.

Today I experienced the same issue (OWSP) with our IPO 8.1(63).

Calls coming in on a PRI.
Digital 9508 Telephones.
Problem happened on 4 or 5 calls in a row until we rebooted the phone system.
 
Upvote 0 Downvote
@dibthree - if your the number of IP phones is small, you can test if my issue is yours as well by setting up continuous pings to all the IP phones. This will force the MAC addresses to stay "fresh" in any forwarding tables/databases on the switch(es).

Not everyone is in the office this week, so when both our customers and employees return in full force next week, I'll have more of an idea if my situation is fixed.

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
Mine happened on both IP and Digital phones.

I also use Avaya 5000 series switches for our IP phones, and have loved the data product since the Bay Networks and then Nortel days.

Are you current on your software image on your 5520 switches? There were some bugs in the last few releases dealing with MAC Address tables not clearing correctly. They claim it is resolved in the most current release. (Current Image 5xxx_631038.img, Current Diag 5xxx_60016_diags.bin)

release notes: 6.3.1
 
Upvote 0 Downvote
This is our firmware rev levels:

FW:6.0.0.15
SW:v6.2.5.027
BN:27

IP 500 8.1(63)
VMPro 8.1.9016
46/5610s, 46/5621+25s
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Nortel4Ever
  • Locked
  • Question
Incoming Calls Have to be Parked or Held before Caller Can Hear the User
Replies
4
Views
900
Travis Harper
Travis Harper
AndoverService
  • Locked
  • Question
Echo on incoming calls analog lines 2
Replies
4
Views
549
ACSscott
ACSscott
R
  • Locked
  • Question
cannot find a suitable SIP URI to dial out | SIP Error
Replies
6
Views
523
MikeeOK
MikeeOK
finest
  • Locked
  • Question
Incoming call route to match extension 1
Replies
5
Views
1K
Qzwsa
Qzwsa
Jouik
  • Locked
  • Question
Incoming calls Caller ID Name not showing on SIP Phones although received in Monitor trace
Replies
1
Views
348
Mo. Abdullah
Mo. Abdullah

Part and Inventory Search

Sponsor

Back
Top