FreePBX: 13.0.190.19
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.
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.
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.
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?
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.
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)…
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.
