mattlandis Posted July 21, 2009 Report Share Posted July 21, 2009 How advisable is it to try to have a pstn gateway at a location other than the pbxnsip server? All locations are VPN'd together, but will there be odd issues? matt Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted July 22, 2009 Report Share Posted July 22, 2009 It all depends on latency. (IPSEC) has a 20% overhead... IF LOCAL LAN is 192.168.20.x and the PSTN GATEWAY is on a FOREIGN LAN 192.168.30.x using say .254 You would simply make the SIP trunk to the foreign IP 192.168.30.254 and let the routing table on the local firewall with the VPN link route the 192.168.30.x traffic to the next hop on the VPN link.... If you can keep the latency low and have adequate bandwidth this will work fine. Quote Link to comment Share on other sites More sharing options...
mattlandis Posted July 22, 2009 Author Report Share Posted July 22, 2009 thanks. i set this up today with a client and had bad audio. the problem is too low bandwidth which we will address, but i wanted to make sure other items won't bite me. ;-) Am i correct in this config we will have 2 audio streams going over our way connection? The extension at the remote location and the gateway? matt Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 22, 2009 Report Share Posted July 22, 2009 It all depends on latency. (IPSEC) has a 20% overhead... I doubt that VPN adds latency. Yes, it might add bandwidth. But encrypting the packet does not mean you are adding latency. Only if you are using TCP-based VPN then the fact that lost packets have to be repeated will add significant delay. Quote Link to comment Share on other sites More sharing options...
mattlandis Posted July 22, 2009 Author Report Share Posted July 22, 2009 I doubt that VPN adds latency. Yes, it might add bandwidth. But encrypting the packet does not mean you are adding latency. Only if you are using TCP-based VPN then the fact that lost packets have to be repeated will add significant delay. We have a sonicwall tz180 and tz150 doing a hardware vpn. Call quality is excellent as long as we don't run out of bandwidth (which we are). matt Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted August 2, 2009 Report Share Posted August 2, 2009 Your results are as expected. IPSEC VPN does add on average 15 to 20% packet overhead for the encryption/encapsulation. Also problems you may have will result from IPSEC adding it's 20 to 30 bytes to packets and commonly caused packets to fragment on MTU 1500 interfaces as packet sizes increase. Pushing RTP traffic within an encrypted TCP/IP stream removes the natural operations of RTP as suddenly all packets are delivered, checked, reassembled.. Learning a lesson from Verizon Business, they require IPSEC/VPN for the SIP 5060 traffic and hand off RTP to the proxy/gateway assuming you use TLS then all traffic would be protected still... I would also consider the following options; 1. G729 to reduce BW requirements 2. Move to L2TP on a quality Router that supports BW management with source or destination IP Quote Link to comment Share on other sites More sharing options...
andrewgroup Posted August 3, 2009 Report Share Posted August 3, 2009 A quick read of the TZ180 manual tells me this should do all that needed. I think you should be able to set these up for SIP/5060 to pass across your VPN, while letting TLS UDP RTP packets to run freely and by using the Bandwidth management features youy can enforce a rule so that that RTP packets will take extreme precedent over all other packets (Both ingress/egress) This might prevent the running out of bandwidth on the current setup, but bring all other traffic to a halt.... Figure 90K per ULAW call path up/down 32K for 729. I have no personal experience with the TZ180 but the manual looks as if its quite capable.... Cheers... Quote Link to comment Share on other sites More sharing options...
mattlandis Posted August 3, 2009 Author Report Share Posted August 3, 2009 hi, Really appreciate that input. Matt Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.