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.

 

[IPOriface]

I think you've already identified the issue - packets are leaving site A and not arriving at site B (but are OK site A to site C).

Was the capture on the B firewall done on the WAN or LAN port? I assume there's a site to site VPN in place, so capturing traffic after it leaves the VPN but before any NAT/Security rules are applied can be tricky. If the capture was done on the LAN port, it's possible the traffic did arrive but was dropped.

And yeah, NAT is the most common culprit for these sorts of issues. What the make & model of the firewall(s)?

 

[William C290]

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.

Thank you for the suggestion — we fully agree that disabling Direct Media Path is a recommended first step in these cases.

In fact, we've already disabled Direct Media Path on the H.323 SCN Line between the two affected systems, and confirmed that RTP should now flow through the IP Office systems themselves.

Unfortunately, even after doing so, the RTP stream from 192.168.1.60 is still not being received by 192.168.0.30 , as confirmed by the monitor logs.

This clearly indicates a network-level issue, potentially a firewall or NAT blocking RTP packets on the path from 1.60 → 0.30.

We've attached multiple trace files showing:

• RTP being transmitted from 192.168.1.60
• But not received at 192.168.0.30
  Even with Direct Media disabled, the audio path fails.

Let us know if there's any additional setting or diagnostic you'd like us to try — we're happy to assist.

 

[William C290]

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

That’s a valid point — NAT interference with RTP is indeed a common cause of one-way or no-audio issues.


We’re currently checking with the network team whether there is any NAT traversal occurring between 192.168.1.60 and 192.168.0.30.


However, both systems are on private IP ranges within our WAN (192.168.X.X), and we expect traffic to be routed directly without NAT in between.


If any NAT or firewall session translation is happening unexpectedly along the path, it could absolutely be the culprit.

 

[William C290]

I think you've already identified the issue - packets are leaving site A and not arriving at site B (but are OK site A to site C).

Was the capture on the B firewall done on the WAN or LAN port? I assume there's a site to site VPN in place, so capturing traffic after it leaves the VPN but before any NAT/Security rules are applied can be tricky. If the capture was done on the LAN port, it's possible the traffic did arrive but was dropped.

And yeah, NAT is the most common culprit for these sorts of issues. What the make & model of the firewall(s)?

Great insight — yes, exactly: the RTP is sent from site B (192.168.1.60), but it never arrives at site A (192.168.0.30), while traffic from site C works just fine.

Regarding the packet capture:
We're still checking with the network team which interface it was performed on — LAN or WAN — and whether it was before or after decryption/NAT stages.
There is a site-to-site VPN in place between the locations, and it's likely that the Sophos firewall at site B is handling the VPN tunnel.

We'll double-check if the traffic is being dropped internally post-decryption due to a NAT rule or security policy.

Unfortunately, we don’t have direct access to the firewall console at the moment — the device is Sophos, but we’re waiting for the responsible team to confirm the configuration and conduct a deeper review.

We'll share updated results once packet captures are done on both ends.

 

[Mo. Abdullah]

Faced this issue once. and was solved by disabling the NAT configuration. The issue was due to the NAT configuration on the firewall from the beginning.
Also, check if the Media ports are enabled and configured on the remote site firewall and between all subnets that are involved in the traffic, and make sure that the firewall configuration rules are both directions.