Sangoma Talk – No Audio in Egypt | Strict RTP Rejecting Packets (Sequence +2)

Commercial Modules Sangoma Talk / Software Phone
,
1

Hello everyone,

I’m looking for technical assistance with a persistent no-audio issue affecting our VoIP users in Egypt.

We have spent considerable time troubleshooting this issue without finding a reliable solution.

Our setup

  • FreePBX 17.0.33.2

  • Asterisk 22.11.0

  • Debian 12

  • Sangoma Connect module 17.0.3.40

  • Sangoma Talk on iOS and Android

  • SIP over TLS (TCP 5061)

  • SDES-SRTP

  • G.711 A-law / μ-law

  • RTP ports UDP 10000–20000

  • RTP Symmetric, Rewrite Contact and Force rport enabled

  • Direct Media disabled

The problem

Extensions 103 and 104 in Saudi Arabia work perfectly with Sangoma Talk, including encrypted two-way audio.

However, extensions 101 (iPhone) and 102 (Android) in Egypt can register and establish calls, but experience no audio.

Important findings

We performed detailed packet captures and Asterisk RTP debugging.

Working extension 103:

  • RTP sequence increments: +1

  • RTP timestamp increments: +160

  • Strict RTP accepts the packets.

  • Two-way audio works.

Failing extension 101:

  • RTP sequence increments: consistently +2

  • RTP timestamp increments: +320

  • Strict RTP probation repeatedly fails.

  • Asterisk rejects incoming audio.

  • The server fails to learn the correct external RTP destination.

In one test, SRTCP sender reports indicated approximately 50 packets per second, while the PBX captured approximately 25 packets per second.

We reproduced the issue across Wi-Fi and a reported mobile-data test.

Interestingly, the same +2 sequence pattern was observed during a later test using PortSIP and unencrypted RTP, so we cannot conclude that Sangoma Talk or SRTP itself is responsible.

Extension 102 also fails Strict RTP probation, although its packet sequence pattern has not yet been measured.

What we have tried

We have tested TLS, SRTP, temporary unencrypted RTP, NAT Traversal, Sangoma Talk advanced network settings, application reprovisioning, codec configuration, firewall rules, and explicit TLS transports.

The problem remains unresolved.

Questions

  1. Has anyone encountered RTP packets consistently arriving with sequence increments of +2, causing Strict RTP probation to fail?

  2. Could this indicate systematic UDP packet loss or filtering along the network path?

  3. What is the best way to determine whether the missing packets originate at the mobile client or are being dropped in transit?

  4. Are there any Sangoma Talk or Asterisk settings you recommend investigating without permanently disabling Strict RTP?

  5. Has anyone resolved a similar issue involving remote users in Egypt?

We want to keep TLS and SRTP enabled as our final secure configuration.

We have detailed sanitized SIP/SDP logs, RTP sequence analysis, and Asterisk debug reports available if needed.

Any technical guidance or experience with a similar issue would be greatly appreciated.

Thank you!

2

The direction of the RTP is not clear to me, but this sounds like your network is alternating packets over two routes, one of which is broken. TCP would recover, and SIP signalling will recover, because of retransmissions.

Is ICMP blocked on the router at the source end of the RTP? There should be a destination unreachable which stop the broken route. Maybe that is not being generated, or maybe the sender is not getting the message, because a firewall is blocking it. The parallel routing might not be within a system you or your other party actually control.