having a pstn gateway remote to pbxnsip?

[mattlandis]

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

[andrewgroup]

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.

[mattlandis]

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

[Vodia PBX]

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.

[mattlandis]

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

[andrewgroup]

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

[andrewgroup]

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...

[mattlandis]

hi,

 

Really appreciate that input.

 

Matt