I've got multiple satellite office all linked back to the main office via VPN. Each office has their own asterisk server which registers back to the main office's Asterisk server. Each office also has a 1Mb downstream / 384k - 768k upstream connection. The branches are using Speex for their connections back to the main office. The issue I'm having is that there are times that I need to VNC in to machines at the various offices for tech support while the user is also on the phone. Unfortunately the VNC connection apparently takes priority and makes it impossible for me to understand anything the person on the phone is saying, although they can still hear me fine. Our Main office uses a Cisco PIX 506 for the main firewall and VPN concentrator. Each branch office used a Cisco 1700 series router with IPSec enabled in the IOS. Is there any sort of QoS I can turn on on the main router or the branch routers to make sure the voice quality takes precedence over the VNC? (Any example configs would be greatly appreciated) Would I be better off routing the voice packets over the internet rather than the VPN, and could I safely do that without exposing the asterisk boxes to unnecessary security risks? (At present all of our asterisk boxes are behind the firewalls and only talk to each other over the VPN. All PSTN connection is done through TDM boards so they have no direct exposure to the internet.) Thanks, Brent Davidson
I do not have examples, but if you are using the 1700 series router in order to originate the ipsec vpn, you may use command qos pre-classify (please search for it on cco.cisco.com) On Thu, May 7, 2009 at 9:54 PM, Brent Davidson <brent at texascountrytitle.com>wrote:> I've got multiple satellite office all linked back to the main office > via VPN. Each office has their own asterisk server which registers back > to the main office's Asterisk server. Each office also has a 1Mb > downstream / 384k - 768k upstream connection. The branches are using > Speex for their connections back to the main office. The issue I'm > having is that there are times that I need to VNC in to machines at the > various offices for tech support while the user is also on the phone. > Unfortunately the VNC connection apparently takes priority and makes it > impossible for me to understand anything the person on the phone is > saying, although they can still hear me fine. > > Our Main office uses a Cisco PIX 506 for the main firewall and VPN > concentrator. Each branch office used a Cisco 1700 series router with > IPSec enabled in the IOS. Is there any sort of QoS I can turn on on the > main router or the branch routers to make sure the voice quality takes > precedence over the VNC? (Any example configs would be greatly > appreciated) > > Would I be better off routing the voice packets over the internet rather > than the VPN, and could I safely do that without exposing the asterisk > boxes to unnecessary security risks? (At present all of our asterisk > boxes are behind the firewalls and only talk to each other over the > VPN. All PSTN connection is done through TDM boards so they have no > direct exposure to the internet.) > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090507/788a7416/attachment.htm
On Thu, May 7, 2009 at 3:54 PM, Brent Davidson <brent at texascountrytitle.com> wrote:> I've got multiple satellite office all linked back to the main office > via VPN. ?Each office has their own asterisk server which registers back > to the main office's Asterisk server. ?Each office also has a 1Mb > downstream / 384k - 768k upstream connection. ?The branches are using > Speex for their connections back to the main office. ?The issue I'm > having is that there are times that I need to VNC in to machines at the > various offices for tech support while the user is also on the phone. > Unfortunately the VNC connection apparently takes priority and makes it > impossible for me to understand anything the person on the phone is > saying, although they can still hear me fine.VNC is very asymmetric. It doesn't generate much traffic from the person viewing, and it generates lots of traffic FROM the system being viewed. This helps explain why the system being viewed side can hear incoming voice packets, and outbound voice packets that have to compete with the large amount of outgoing video signal data lose. QoS may or may not help you here. If voice quality is important, you should have a separate connection dedicated to just voice. The obvious workaround is grab your cell phone and call them with that. You DO have a way to dial directly to that office without going over the PIX, right, right? How do you call the remote office when the PIX goes down? What will help you is getting a bigger line or separating the voice traffic from the data traffic completely. If you are good with ssh, you can also do a compressed ssh tunnel to encrypt and on-the-fly compress the VNC session. But if this is Windows good luck with that.
> I would think that VoIP over VPN is a bad idea as UDP packets need to be > in realtime not corrected by the TCP of the VPN.That depends very much on the VPN in use. OpenVPN doesn't suffer from this problem. Although it's SSL-based (and one might think it does everything through SSL-over-TCP), it actually sends the VPN traffic via UDP... it uses TCP only for the negotiation and administrative aspects of setting up the VPN connection. As far as I know, OpenVPN makes no attempt at all to re-order the packets that it encapsulates and transmits. It simply accepts the IP packets it is to carry, encrypts them individually, wraps them in UDP, and retransmits them to its peer. The peer receives the UDP, decrypts, and forwards. No re-ordering. There may be other VPNs which actually carry all of the VPN'ed data in a single TCP stream... but I think this is generally agreed to be a Bad Idea for several reasons. I run SIP over OpenVPN between my Nokia N810 handheld, and my Asterisk server at home. I have not noticed any difference in call quality between SIP-over-OpenVPN, and non-VPN'ed SIP, between these two endpoints... except, of course, when the OpenVPN-encapsulated traffic gets through, and non-VPN'ed traffic doesn't due to firewall or NATing problems at a particular wireless network access point.