Technical Tip: SIP One-Way Audio Even With RTP Packets Present

[hgarara]

Description	This article explains a scenario where SIP one-way audio persists even though RTP packets are seen in both directions.
Scope	FortiGate.
Solution	When dealing with SIP one-way or no-audio issues in VoIP deployments, the most common troubleshooting steps involve inspecting SIP ALG behavior, NAT, and audio port translations. Before proceeding, make sure to validate the SIP session and port exchange behavior by referring to the following technical resources: Troubleshooting Tip: One-way Audio issue in VOIP with SIP-ALG Technical Tip: Most common cases of SIP implementation Once it is confirmed that SIP ALG is not modifying the audio ports(if RTP port are proxied then make sure it is changed back for return traffic) and RTP streams are visible in both directions, but the audio is still missing one way (or both), deeper packet-level inspection is recommended. Scenario Overview: In the scenario below, IP addresses have been replaced with names for easier understanding. Below captures are on LAN, but similar behavior should be expected on WAN as well, with the same troubleshooting steps. RTP Stream is Visible in Both Directions.  Call Flow: Deskphone initiates the call:  Deskphone-----ATA-----FortiGate-----Internet------cloudPBX------Cellphone It has been confirmed that: RTP streams exist in both directions (Deskphone ↔ Cloud PBX / Cellphone) SIP ALG is not altering the audio port numbers(if altered, then FortiGate should change it back to othe riginal port as requested). However, the Deskphone cannot hear audio. RTP Payload Analysis: Upon checking the LAN interface packet capture (where RTP from deskphone enters the FortiGate), it is observed that approximately 90% of the RTP packets from Deskphone to Cloud PBX (Cellphone) contain payloads with all 'FF' values. This indicates the RTP packets are essentially empty before reaching the FortiGate. 'Right-click' on Payload ->Apply as filter ->Selected: On the other hand, RTP packets from Cloud PBX (Cellphone) to Deskphone are intact and carry proper audio payload (verified on both LAN and WAN interfaces), showing 'non-FF' payloads. This means audio from the Cloud PBX is successfully passing through the firewall and reaching the Deskphone. Select packet with Payload as all FF's, Payload -> Apply as filter -> Not Selected (packets with non-FF value): Verifying RTP Audio Playback in Wireshark: This situation aligns with what is seen in step 2. Open Wireshark's Telephony -> VoIP Calls -> (Select RTP stream) -> Play Streams feature on the LAN/WAN packet capture. In the above screenshot: The red waveform represents the Caller (Deskphone). The black waveform represents the Callee (Cloud PBX/Cellphone). As seen in Step 2, the Caller’s waveform is mostly blank, indicating no audio was generated by the Deskphone before reaching the FortiGate. Meanwhile, the Callee’s waveform shows active audio, confirming audio was received from the Cloud PBX(On WAN interface) and passed through the FortiGate correctly (to the LAN interface). Conclusion: In this case, even though RTP streams are flowing and FortiGate is not blocking audio packets, the root cause lies downstream from the FortiGate. The Deskphone is connected to a SIP ATA (Analog Telephone Adapter). The ATA device was found to drop audio only for outbound calls, resulting in no actual voice payload being generated from the deskphone side or transversing the audio from PBX/cellphone to the Deskphone. Recommendation: If RTP streams are visible but audio is still missing, always check the RTP payload at both ingress (LAN) and egress (WAN) sides of the FortiGate to determine if the problem is: Within the internal network (e.g., VoIP phones, SIP ATA, PBX). Or caused by FortiGate configuration or inspection (e.g., NAT, ALG, firewall policies). Understanding whether the RTP payload is empty at source or lost during inspection helps isolate whether the issue is pre-FortiGate or post-FortiGate.