Hope that this isn't a problem with the network internally I take a regular phone down and conenct it directly to the vonage box and I get the same problem. At least that is one relief. Now I get on the phone with Vonage tech support (using our BroadVoice account) and spend over an hour and they can't figure it out. The boxes connect and register. You can dial and it rings. They can call in and they ring, but when you pick up there is no audio. So after the call dropped for the second time I found something interesting in my NAT tables. Connections were being given different external IP addresses for each connection.
Here is something I did not know and only happened upon it by accident. Setting up round-robin NAT is super easy with PF. I had put all of our external IP addresses on the one exteral interface and PF just started using them all as a pool. Instantly scalable, but not very SIP happy. More later on why BroadVoice was working and vonage was not.
So using PF we can keep this new found functionality, but we can tell the devices to be sticky. So once they go out on one interface stay there. That should look like this now:
nat on $ext_if from $sfu_net to any -> $ext_if round-robin sticky-address
Flushed the NAT table and rebooted the ATAs and viola I had calls working again! The reason BroadVoice was working was the fact we are using bi-directional NAT for the boxes in our DMZ so it was using a dedicated IP on the external interface for all of its traffic. For the record that is done like this:
binat on $ext_if from $asterisk_int to any -> $asterisk_ext
So we now have VoIP working again internally and externally.
Technorati Tags: networking, voip

No comments:
Post a Comment