Call establishes, no audio, but only when forwarding to external number

Asterisk: 13.11.2
Server is running as a VM on ESXi 5.5 host.

We have a problem when attempted to forward inbound external calls back out to an external number such as a mobile.

Inbound external to internal extensions works fine.
Outbound internal calls to external numbers works fine.
Internal to internal extensions works fine.

If I configure an extension to unconditional forward to an external mobile, and then call that extension from another internal extension, this also works.

However if I call from an external mobile to a DID which routes the call to the extension with the unconditional forward to external mobile, the call goes through, but there’s no audio at either end.

I’ve run a packet capture on both scenarios I’ve just described, and the only difference I could see, was that the call initiated from the external mobile had no RTP traffic.

Here’s the flow sequences from Wireshark, the successful one has bi-directional RTP traffic, whereas the unsuccessful one doesn’t, but I don’t really know where to dig next to figure out why this is. The capture is happening at the switch port going into my PBX server.

Successful call from internal extension

Unsuccessful call from external mobile

Not sure what to look at next, would love a point in the right direction.

Hi tlarrea,
reading your post, I think that it is a similar issue as mine, called “Codec issue?”. It seams that the endpoints are not configuring the audio codec correctly to be used for the session.
Something similar occurred in the old ISDN services, when the bearer capability information element was not interpreted correctly. The result was a connected channel with no audio…!
Right now I don’t have enough SIP knowledge, like I had on ISDN, and I hope somebody could help us.

Hi Lorne,

already have that setting in place.

I will check the RTP traffic config at firewall, but I believe it’s already allowed.

From what I can understand in my flow sequence as per pictures above, that they appear to agree on g711A codec?

There’s an invite and and response of ok. Would that be a correct interpretation?

I’ve another test scenario, call initiated from an internal extension, to one of our external DIDs. The call rings, I can answer, but no audio on either end. The call flow sequence for this situation appears slightly different, I’m seeing RTP traffic, but the directions and ports seem odd.
There are 2 RTP streams, both coming from the PBX server to our external IP and the ports are indentical, but reversed.
Is this normal?

When you call yourself with a firewall in the way, all kinds of strange things can fail.

In this last scenario, you may need to set up a “Loopback” route so that you avoid interacting with the local firewall trying to route traffic out to a provide that can’t get the traffic back to you.

Note - this last scenario is one that I have. In order to “solve” the problem, I added a second outbound provider to handle the calls that might come back to me (cell phones, for example) so that the inbound and outbound traffic looks like it’s legitimately coming from somewhere other than me.


The following is another way of doing a loopback route like Dave (@cynjut) suggested:

You completely avoid having your VoIP get out to get back in…

Good luck and have a nice day!


This looks like it would resolve the local extension calling my own DID, but I’m not sure it would have any effect on the forwarding to external mobile?


I would be the first surprised if it did… :wink:

The only thing a loopback route done this way does is route your call to your DIDs back to your inbound routes without them ever leaving your PBX…

I must confess that I don’t know what to suggest about your other problem…

What kind of firewall do you have?

Does it have SIP ALG? (which most people agree should be turned off)

Good luck and have a nice day!


Using Bluereef Sonar (pretty much IPTables + squid, with a few extra features), which I personally suspect is the issue. According to packet trace I sent tor our voip provider, the point that two data streams should connect to each other, the function which helps do this is advertising incorrect header details to the two ends. My firewall vendor tells me they don’t have SIP ALG enabled, but they aren’t filling me with confident in their knowledge…

Firewall vendor disabled their SIP module which, in conjunction with adding rtp forwarding, seems to have fixed the forward to external mobiles issue. They tell me there is no sip alg module but presumably their sip module messes with Nat in some fashion.

Thanks for the help everyone.



They might not have called it that but it was a SIP helper of some kind which apparently wasn’t doing too good of a job…

That reminds me of the previous firewall they had somewhere I know. I don’t know under which situation it would do that but the SIP helper would segfault from time to time…

I believe the manufacturer eventually fixed it but the people I know who were using it are no longer this brand of firewall anymore (Fortinet IIRC)…

Have a nice day!



What you need to do is to add RTP keep alive to your streams in order to allow them to “live” through your firewall’s sessions. the setting in the sip.conf file is: rtpkeepalive=1 and you can set it in the sip settings module of the Freepbx.

If you are using Fortigate firewall please notify me so I can send you the instructions how to remove the SIP helpers.

Thank you,

Daniel Friedman
Trixton LTD.