No audio after changing PBX IP default gateway

In my office, I’ve got 2 routers - one router is a basic Fortigate Internet router (, and the other router is a carrier supplied Cisco router ( with a SIP trunk ( The PBX has an IP of

The Cisco router does not have Internet capabilities. When the PBX has a default gateway of the Cisco router, incoming and outgoing calls work fine but cannot do updates or voicemail to email because the Cisco router has no Internet. When I change the PBX default gateway to the Fortigate and set a static host route to get to the Cisco SIP trunk, ie. IP ROUTE, it picks up a call just fine but no audio. Any ideas? As a last resort, I might just have to leave the PBX default gateway pointing to the carrier’s Cisco router and ask them to set a static route for Internet that goes through the Fortigate.

It would seem unlikely that the SIP server ( also handles media. You’d need to check the actual IP addresses that get negotiated within the SDP during call setup. My guess is they use separate servers for handling the media, so you would need an additional static route to direct media via your cisco router. See if you can find out the addresses of those media servers, or ask your carrier.

The SIP server is definitely capable of handling media also because like I mentioned, I can change the PBX default gateway back from the Fortigate to point to the carrier’s Cisco router, and my entire office could make/receive calls all day long (for the past couple of months now) with no issues other than no Internet on the PBX. I’m beginning to suspect that the carrier’s Cisco/SIP server might have an ACL lock on the IP/MAC address of the PBX, and any other MAC addresses would be denied. Any other ideas?

I don’t see how changing the default route has any influence on the MAC addresses involved in communications, they are still the same. If it works with the default route set to the cisco router, but doesn’t work when the default route points to your internet router and you have a static route installed to have routed to your cisco, this paints a pretty clear picture. There must be other traffic involved that does not use This could be RTP traffic, or DNS queries that can only be successfully resolved using the cisco/your carrier’s DNS servers or something else. If you can find out what traffic causes the problem, there surely is a solution to the problem.

Use the setup that’s working (default route to cisco), then use tools like tcpdump/wireshark to see what traffic is not using