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 IDFromToSourceDestinationServiceNAT17192.168.1.1/24WAN1192.168.1.0/240.0.0.0/0AllEnabled44WAN1 192.168.1.1/24 0.0.0.0/0vIPs (DNAT) (233.333.111.112 >> 192.168.1.10)All_ICMPRTP (6000-31000)DisabledPolicy 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 rootLog Description Session clashedProtocol 17Status ClashTime2024-05-03 07:57:28 euid3 epid3 dsteuid3 dstepid3 logver700140601 Log ID0100020085 Typeevent Sub Typesystem Old Statusstate=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 Statusstate=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 timestamp1714741048542189000

New Member

Question

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

Forum|Forum|2 years ago
May 3, 2024
7 replies
5975 views

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

Staff & Editor

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 - Fortinet Community Team

hbac

Staff

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,

saleem1Author

New Member

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

Staff

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

Sign up

Login with SSO

Login to the community

Login with SSO