Avaya IP Office SCN - No Audio + SCN Link Down (Network Related)

[William C290]

Hi everyone,

We are facing a persistent and critical issue with our Avaya IP Office Small Community Network (SCN) deployment across multiple branches. Specifically, we are experiencing no audio (one-way or completely absent) during calls between certain branches, and the SCN link itself shows as "Down" in System Status Application (SSA).

We have performed extensive troubleshooting and analysis of Avaya System Monitor logs, and our findings strongly point to a network-level blockage of RTP (Real-time Transport Protocol) traffic, rather than an IP Office configuration or hardware issue.

We have a setup with multiple Avaya IP Office systems (various hardware versions like IP500 V2, running different software releases like 8.1(63) and 9.0.0.0 build 829), connected over our WAN.

Problem Description:When making calls between Branch A (IP Office A.A.A.A) and Branch B (IP Office B.B.B.B), the call connects successfully (signaling works, phones ring, call shows connected), but there is no audio in either direction. This specific SCN link shows as "Down".

Our Analysis and Proof (Working vs. Non-Working Scenarios):

1. Non-Working Call Example: Branch A (A.A.A.A) <-> Branch B (B.B.B.B)

• Avaya IP Offices Involved:
  
  • Branch A: A.A.A.A (e.g., Extension 219)
  • Branch B: B.B.B.B (e.g., Extension 401)
• Signaling (H.323): Functional
  
  • SysMonitor logs confirm H.323 signaling works. Call setup completes, and the call progresses to a "Connected" state. This shows the IP Office systems are communicating at a control level.
• RTP (Voice Path) - Critical Issue:
  
  • From Branch B (B.B.B.B) perspective: The IP Office at Branch B is actively transmitting RTP packets towards Branch A (A.A.A.A).
    
    • Trace Snippet (RTP Transmission from B.B.B.B):
      
      RTPFEC: IP408_FEC(0): Receive Transmit octets: XXXXXXX ( X MB) YYYYYYY ( Y MB)<br>FecRtpFilter Transmit; int Q xmits: ZZZZZZ<br>
      (Values for X, Y, Z confirm active sending.)
  • From Branch A (A.A.A.A) perspective: The IP Office at Branch A is NOT receiving any RTP packets from Branch B (B.B.B.B).
    
    • Trace Snippet (RTP Reception Failure at A.A.A.A):
      
      RTPFTR:<br>== GLOBAL RTP RELAY STATS 1 of 4 ==<br>Total received UDP frames : 0<br>
      (This indicates no UDP/RTP traffic received from the problematic branch.)
  • Conclusion for Non-Working Call: The Avaya IP Office at Branch B is sending audio, but it's not reaching Branch A. This points to a network blockage of the RTP return path from B.B.B.B to A.A.A.A.

2. Working Call Example: Branch A (A.A.A.A) <-> Branch C (C.C.C.C)

• Avaya IP Offices Involved:
  
  • Branch A: A.A.A.A (e.g., Extension 219)
  • Branch C: C.C.C.C (e.g., Extension 309)
• Signaling & RTP: Fully Functional
  
  • Calls connect and voice is heard clearly in both directions, confirming successful RTP flow.
  • From Branch C (C.C.C.C) perspective: The IP Office at Branch C is actively transmitting RTP packets, which confirms it's sending audio for a working call.
    
    • Trace Snippet (RTP Transmission from C.C.C.C):
      
      FecRtpFilter FEC0 FEC1<br> Transmit; tx_noSpace: 0 0<br> int Q xmits: 8187171 0<br> TX BD xmits: 1 0<br>
      (The "int Q xmits" shows active RTP transmission.)
  • The fact that the call functions perfectly confirms that the RTP from C.C.C.C is successfully reaching and being processed by A.A.A.A.

Overall Conclusion:

The Avaya IP Office systems themselves are capable of establishing calls and processing RTP streams correctly, as demonstrated by the working calls to Branch C. The consistent failure of RTP in one direction (return path to Branch A) for Branch B strongly points to an external network issue (e.g., firewall, NAT, routing). This is the classic symptom for "no audio" and "SCN Down" when signaling is healthy.

Troubleshooting Steps Taken/Considered:

• Firewall administrator for Branch B has stated that "all ports are open" between branches, but the problem persists. They also reported not seeing traffic from Branch A's IP on their firewall. This indicates a potential issue upstream of the firewall, a misconfigured firewall, or monitoring issue on their end.
• We've confirmed Avaya IP Office versions are within reasonable compatibility ranges (e.g., 8.1(63) and 9.0.0.0).

We need your expertise to help us with the following:

1. Network Path Verification: Help us understand the complete network topology between Branch A (A.A.A.A) and Branch B (B.B.B.B), including all routers, firewalls, and security devices.
2. RTP Port (UDP) Configuration: Confirm that UDP ports within the RTP range (typically 49152-53247) are explicitly allowed in both directions between A.A.A.A and B.B.B.B on all intervening network devices.
3. SIP/H.323 ALG Disablement: Verify that SIP ALG and H.323 ALG features are disabled on all firewalls and routers in the path.
4. NAT Review: If NAT is in use, confirm it's correctly handling RTP streams bidirectionally.
5. Network Packet Captures: Conduct packet captures (e.g., Wireshark) on the LAN and WAN interfaces of relevant network devices (firewalls, routers) while a call is attempted between Branch A and B. This is crucial to pinpoint where RTP packets are being dropped.

Any insights or suggestions would be greatly appreciated.

Thank you

• 192.168.0.30 ( Tx219,Rx401).txt
• 192.168.1.60 (Rx401,Tx219).txt
• 192.168.0.30 - Tx219,Rx309.txt
• 192.168.2.100 - Rx309,Tx219.txt

 

[budbyrd]

Usually the first step is checking to see if Direct Media Path is on and turn it off if it is.

Direct media path allows the speech path between two IP extensions (after call setup) to be routed directly to each other. This allows the system to free up voice compression resources after establishing the end to end connection, allowing the resources to be used in the most efficient way.

This takes some of the network issues off the table.

 

[derfloh]

I bet that there is some kind of NAT in the connection. This must be disabled.