SIP Invites timing out for certain calls

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

SIP Invites timing out for certain calls

L0 Member

Hi all,


I've have a sip voice issue for a few weeks that I am a bit lost on. For a bit of background, we have a cloud phone system we just moved over to around a month ago. A cloud phone system links up to Webex softphone for our call center to receive calls. If someone dials our main phone line it will start in the cloud PBX but then send the call over to an agent on their laptop's webex client. Most calls go through but for some reason certain calls do not automatically route to our agents webex clients. They have to manually grab the call from a cloud call center dashboard and then it connects which is strange. There does not seem to be a pattern when these calls happen but it's causing our call center stress because they have to keep watching the call center dashboard all day so they don't miss a call since it does not route automatically.


I reached out to our phone system support and they ran a pcap on their end and can see SIP invites being sent and hitting our public IP but then times out with error 408 request timeout. I can see from the pcap SIP invite that it comes back with a request-URI of an agent's local ip address which seems like it's reaching the endpoint correctly. I asked one of our agents while working from home to disconnect from vpn so they are off our firewall temporary when they see a call that does not automatically hit our call center and then it did route correctly after disconnecting. That leads me to believe something on our firewall is causing calls to not route on certain inbound calls. We do have different zones setup for vpn, desktops, wifi which all route through the firewall so once they were off our network and received traffic, it lead me to believe something in the firewall is causing this.


The firewall is setup to NAT traffic from each of our zones with endpoints just outbound though. That could be related and I have considered creating a NAT exempt rule just for sip traffic but not sure if that would be a security issue. I also disabled SIP ALG and created an app override for sip traffic. My phone provider also provided a list of IP's to allow which have been added to a security policy but it's strange since the policy to allow the traffic from the IP's they mention has no hit count inbound but outbound there is a hit count. It's also hard to isolate getting a pcap from the firewall for the calls that do not route properly since they are inconsistent, and I don't want to be running a pcap all day.


I am a jack of all trades system admin so my understanding is not super deep on firewalls but enough to get around. If you all have any insight if my NAT exempt solution could help or if there is anything else that could help this issue would be greatly appreciated! Thanks!


L0 Member

I should also clarify that we have 2 HA PA-820 firewall's setup to route all our traffic.

Cyber Elite
Cyber Elite


Set all security policies to log at session end. Check the traffic logs to see why the traffic is getting denied. Since its SIP traffic, its going to be UDP so you'll have to check the 'Session Browser' to see the traffic before it times out.


Cyber Elite
Cyber Elite


Just as clarification to what @OtakarKlier already mentioned, all security policies set to log at session end includes the interzone-default policy. This policy doesn't log by default because it generates a lot of logs and the logs are just pointing towards denied traffic, but when you're troubleshooting an issue like this enabling that interzone-default policy logging is critical to ensure you aren't seeing a drop due to your security policy.

Unless you're using public IPv4 or IPv6 addresses internally you wouldn't see any improvement from disabling your NAT policy. More than likely the only NAT that you're doing is converting your RFC1918 addresses to actual publicly routable addresses; negating that will just cause all of your traffic to stop functioning. 

  • 3 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!