Persistent One Way Audio Issues, no RTP packets on Trunk machines

[saleem1]

Hello,
I am experiencing consistent one-way audio issues (inbound) with one of my main VOIP providers. It happens about 1 in every 20 calls. The provider says the calls look fine on their end, and every time I've done a network capture on our trunk servers, I can see outbound RTP traffic but I don't see any inbound for the one way audio calls. I suspect it has to do with NAT but we haven't made any changes recently. This started about 2 months ago (coincidentally around the time our firewall management company did a reboot for a security update). It happens sporadically but typically during high activity periods.
Our firewall cpu utilization gets high, about 75% but memory is consistently around 30%. It gets up to about 30,000 sessions during peak activity. 
This is a Fortigate 200E running v7.0.14 build0601 (Mature). There are two machines set up in Active Passive configuration. 
The main message in the log that stands out to me are these session clash messages due to the policy switching?
Policy 17:

Policy ID	From	To	Source	Destination	Service	NAT
17	192.168.1.1/24	WAN1	192.168.1.0/24	0.0.0.0/0	All	Enabled
44	WAN1	192.168.1.1/24	0.0.0.0/0	vIPs (DNAT) (233.333.111.112 >>  192.168.1.10)	All_ICMP RTP (6000-31000)	Disabled

Policy 17 has NAT enabled because our firewall provider said it will use vIPs as SNAT, so we have them mapped to use the outgoing interface. 

Thank you for any help or advice!

Virtual Domain root
Log Description Session clashed
Protocol 17
Status Clash

Time	2024-05-03 07:57:28
euid	3
epid	3
dsteuid	3
dstepid	3
logver	700140601
Log ID	0100020085
Type	event
Sub Type	system
Old Status	state=04050204 tuple-num=2 policyid=17 dir=0 act=1 hook=4 192.168.1.10:11255->34.278.901.15:49233(233.333.111.112:11255) dir=1 act=2 hook=0 34.278.901.15:49233->233.333.111.112:11255(192.168.1.10:11255)
New Status	state=00212204 tuple-num=3 policyid=44 dir=0 act=2 hook=0 34.278.901.15:49233->233.333.111.112:11255(192.168.1.10:11255) dir=1 act=1 hook=4 192.168.1.10:11255->34.278.901.15:49233(233.333.111.112:11255) dir=0 act=0 hook=4 34.278.901.15:49233->192.168.1.10:11255(0.0.0.0:0)
Log event original timestamp	1714741048542189000

[Stephen_G]

Hello saleem1,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[Stephen_G]

Hello saleem1,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[hbac]

Hi @saleem1,

Do you have SIP ALG disabled? Please refer to https://community.fortinet.com/t5/FortiGate/Technical-Tip-Disabling-VoIP-Inspection/ta-p/194131

If you don't see inbound traffic during one way audio calls, it means traffic was lost somewhere else and not reaching the FortiGate. 

Regards, 

[saleem1]

Hi @hbac 
Thank you for taking the time to look at this request. I can confirm the SIP ALG is disabled. I've been capturing network traffic internally, and for the problematic calls I show RTP packets being sent outbound, but nothing being received. When I contact our provider who is sending the media, they claim to see both inbound and outbound RTP traffic. This is why I suspected the firewall, but I may be mistaken. We have SSL-certificate inspection and Linux-Default inspection configured on this policy, is it possible traffic is inadvertently being blocked?

[smaruvala]

Hi,

- Is the session clash log generated when the call fails?

- captures are taken on the CPU level. So if the Firewall is dropping due to some settings or configuration then usually we should be able to see the packets being received. 

- Are you seeing any difference in the SDP headers of the SIP communication in a working call flow and non-working call flow?

- If NAT is involved without ALG how the SDP headers are being translated? Are you using the SIP servers to publish the Public IP's/NATed IPs in the SDP header?

Regards,

Shiva

[saleem1]

Hello, thank you for reaching out. 
1. The session clash messages are generated every couple of minutes, and the one way audio happens less often than that. The reason I suspected these messages is because the same policy that is clashing is the one responsible for bringing RTP packets in to our trunks. 
2. We took a capture for UDP packets on the firewall yesterday, and packets seemed to flow in both direction but the inbound traffic had occasional RDT malformed packet sent to our trunk servers. 
3. I am not seeing any difference between the working call SIP captures and non working SIP captures. The private IP is always mapped correctly to it's public IP in the SDP section and requests traffic in a port that is within range. 
4. In the SDP section, my trunk server presents the public IP address correctly  in the c and o section. We also have destination NAT set up through VIPs, is it possible having both of these at the same time can cause issues? I didn't think so as the firewall doesn't inspect the payload but maybe having double NAT can cause issues. 

[hbac]

@saleem1,

Did you capture the packets on FortiGate itself? As I mentioned, if you don't see inbound traffic during one way audio calls, it means traffic was lost somewhere else and not reaching the FortiGate. 

Regards, 

[saleem1]

Hi @hbac after running a packet capture, it appears RTP traffic is flowing in both directions, sorry for taking your time. It is likely an issue somewhere else