[SOLVED] Call has to be put on hold before audio

Hi guys,

I have a bit of an odd setup, so please bear with me whilst I try to explain it:

I have two network locations, here and a remote site. Routers at both locations are connected by openvpn.
I have a freepbx server at each location. They are not (currently) configured to talk to each other at all.
One location has a more or less direct connection to the internet. The other location goes through two intermediate routers before connection to the outside world.
Due to a network peculiarity, there is a deskphone connected through one of the firewalls, but it is vlanned in to the network concerned.
All locations are on separate subnets. All subnets are configured as local networks in FreePBX config of both servers (including the vlan and the openvpn).
All subnets can ping one another fine. Registrations and most traffic appear to work fine between all networks.

The remote site is new. It has not ever worked properly. I was in the process of setting it up when everything went sideways.
The local site has recently been modified. It worked properly prior to modification (modification was, essentially, adding another firewall - F/W 2 - in between. It was a necessity, unfortunately).

See a topology diagram at http://i.imgur.com/VTFhLFv.png
The legend is as follows:
Green = intermediate links (via external subnets).
Black = separate subnets. Considered ‘internal’ network/s (except the provider)
Red = notes
Blue = theoretical representation of OpenVPN link.

Please find a SIP debug output pasted here: http://pastebin.com/LNFXj3NV
This is calling in from an external number to ‘Deskphone’ via ‘Server B’ No audio was observed until the hold/unhold.

I have looked at Call needs to put on hold first before having audio, but it appears there was no resolution posted.

Let me know if I need to elaborate on anything. I have tried to be as clear as possible.
Please assume that the current topology is required. Suggestions of changing it are currently not possible. This setup is designed to work regardless of physical location of any subnet, with minimal intermediate firewall config (where required)

All IPs and phone numbers have been redacted (for security)

Please, if you do manage to locate the problem, I would appreciate if you wouldn’t mind shedding some light on why it’s a problem. If I can gain a bit more understanding, this problem should be solveable in future.

Thanks for any and all help. I’ve another three locations waiting to go live once I can sort this issue out, but as I rely on SIP traffic to keep the whole thing running, it’s just currently borked.

Edit: Some more information
F/W 1 had SIP ALG under firewall settings. I’ve removed it. This piece of hardware was in place when the setup was working, though, so I don’t think it’s that.
F/W 2 is located in a DMZ, in case there’s an issue there.
Deskphone can contact voicemail fine on both servers, and both receive and record messages (2-way audio)

bump for great justice

You don’t post your netmasks nor your various routing tables between the networks , I would start there to investigate your problems . . .

1 Like

Thanks for the assistance, dicko.

All netmasks are CIDR/24 (, except for the VPN tunnel and the VLAN, which are /30 (

All subnets can send/receive/transmit ICMP packets (ping), so I assume routing tables are set up correctly.

I have been poring over the pastebin debug output, and it would seem the phones IP ( is only being called after the call has been taken off hold. How do I make sure the RTP is travelling all the way to the phone? I would have thought by the mere virtue of the phone being connected to the server the signalling should be taken care of properly, but apparently I have missed something here.

My next step is to remove one of the layers of firewall and see what that does, but any assistance in the interim is appreciated.

Your RTP connections being initiated by the SDP session requested by your SIP Invites are not being forwarded/honored correctly through your various networks/firewalls, fix that and it should work. When in doubt as to what is happening there is always tcpdump. Your problem is not directly Asterisk nor FreePBX doing this, it is your network setup.

1 Like

Brilliant. Thanks for the help. I’ll do some research, and report back to close off the issue.

Thanks once again for the help, dicko. Sometimes it’s hard to see the forest for the trees, I guess.

It was indeed the routing between networks. Not sure what happened, but when I re-created them this weekend (as part of a step-by-step replacement of almost everything) the phone lit up like the city of Toledo. Good to know that my FreePBX setup wasn’t the problem, and the build is more stable than I gave it credit for. I’ll mark the issue as resolved.

Also, learnt much more about CLI logs and TCPdump in this exercise, so not all bad I guess.