All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? Thanks! Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell@OfficeConnect.net ocbannerjoomla
On 12/11/2008, at 3:17 PM, Lorell Hathcock wrote:
All:
My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet.
Thoughts? Should I try to dissuade him from this if performance is his main motivator?
Yep. I've done this sort of thing to get around NAT problems, that's about it. Perhaps their theory is that a VPN gives them a "private" network, and they've heard that "private" networks do VoIP better. Obviously, a VPN doesn't give you control of the packets on the wire like a private network does, so that theory doesn't work. -- Nathan Ward
Yes, dissuade him. If anything a VPN will add latency unless possibly gear is replaced to provide the VPN that is significantly greater than current. But... if a provider en-route decided to "slow down" competing voice traffic, the VPN would hide it from the filters which might make it seem like voice traffic was speeding up. Of course that is a major "if". Shouldn't take much to lab it, and show the customer the difference in quality, if any. Regardless, if the customer insists, it's billable so why not you than someone else. Just make sure said customer knows that you are not recommending the solution and why. If you implement the VPN and voice quality does not improve, you are covered. -- Tim Sanderson, network administrator tims@donet.com -----Original Message----- From: Lorell Hathcock [mailto:lorell@hathcock.org] Sent: Tuesday, November 11, 2008 9:17 PM, if any To: nanog@nanog.org Subject: hosted PBX/VOIP thru VPN? All: My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet. I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors. The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true. Specifically the ASNs in the middle are Level 3, Sprint and Time Warner. Thoughts? Should I try to dissuade him from this if performance is his main motivator? Thanks! Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell@OfficeConnect.net ocbannerjoomla
On Nov 11, 2008, at 6:17 PM, Lorell Hathcock wrote:
All:
My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet.
I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors.
The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true.
Specifically the ASNs in the middle are Level 3, Sprint and Time Warner.
Thoughts? Should I try to dissuade him from this if performance is his main motivator?
The implementation of a VPN indeed would probably not result in an improvement of your customer' RTP packet delivery, either for jitter or packet loss. If you wish to see if RTP is being meddled with, try changing the RTP port numbers on the ATA or on the remote side to something less typical of the RTP port range - try something <10000. While some deep-packet inspections will dig through each packet to categorize and stomp on RTP voice audio, it is probably not the case that anyone in the path you describe is applying anything other than port number and protocol (UDP/TCP) inspections, if they are doing any such punitive QOS at all. I would be very interested to learn if you or anyone does know of a transit carrier who is de-pref'ing RTP packets as a peered transit provider (or non-paid peering partner.) This doesn't mean static "end customers" - I'm really talking about traffic that is ingress/egress from some other ASN, even if that ASN is paying for transit. This would be a fairly major departure from any type of QOS or de- preferencing that I've seen before, and I'm sure the list would be interested in any results as well. The root cause of the problem your customer describes also needs to be identified - that will tell you a lot. Wireshark a few calls and see what you can see on the RTP packet path. Without more specifics on the "bad performance", it will be difficult to determine if this is even a network issue at all - maybe it's just a sub-standard ITSP, gateway, or even PSTN path on the far side of the equation. A very slight chance exists that due to round-robin routing you are getting out-of-order packets in one or both directions of the media stream. RTP does not recover well from OOO packets. Try some traceroutes in the RTP port range to see what happens. You can see one direction for the traceroute UDP outbound and watch for multi- pathing, and you can see the other direction with wireshark on inbound OOO RTP streams to your customer. If the problem is out-of-order RTP packets, then there are some things that a GRE tunnel plus some creative route announcements/static routes might be able to solve, and those are left as an exercise for the reader. But a "VPN" is almost always going to be the wrong answer for VoIP performance increases - GRE is better suited for encapsulating UDP, and I run VoIP connections over GRE all the time due to the perverse and unfortunate routing situation for my home network, which resides at the end of a consumer- grade cable IP connection. I would not recommend even GRE as a matter of course for VoIP RTP transport; I merely say that it is possible, and in some fringe cases the only solution available. FWIW: Snom (a SIP-based desk phone) now includes a built-in IPSEC tunnel protocol stack so the phone can securely establish connections back to the PBX or other endpoints. The reasons for doing this are not clearly not performance-oriented - they are security-oriented. It even will encapsulate traffic from any hosts attached to the one-port switch on the back. Desk phones are getting pretty scary. I'm waiting for "sh ip bgp" for my Cisco 7960... http://wiki.snom.com/VPN http://www.snom.com/en/products/snom-370-voip-phone/ JT
On Tue, Nov 11, 2008 at 9:17 PM, Lorell Hathcock <lorell@hathcock.org> wrote:
All:
My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet.
I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors.
The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true.
Specifically the ASNs in the middle are Level 3, Sprint and Time Warner.
Thoughts? Should I try to dissuade him from this if performance is his main motivator?
Your customer may have seen this article (or a similar one): http://www.oreillynet.com/etel/blog/2006/03/strangely_ssl_vpns_can_help_vo.h... After reading it a year ago, I've found their discoveries to hold true on my own (small) projects with voip. In a nutshell: "In every case, adding an SSL VPN to a VoIP call over a good broadband network improved call quality. So in effect, wrapping a VoIP call in SSL gives it more structure, kind of like the rind of good Brie. What we had not counted on was the huge difference between what VoIP requires (64Kbps) and a typical broadband connection of 500Kbps or more. Because the broadband connection was so fast, TCP was able to repair the impairments without reducing voice quality. " May or may not apply to your situation, but if bandwidth isn't scarce then I wouldn't be surprised if your customer is correct, at very least they are not crazy :) Good luck -Aaron
Thanks!
Sincerely,
Lorell Hathcock
OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell@OfficeConnect.net
ocbannerjoomla
On 13/11/2008, at 12:39 AM, Aaron Wolfe wrote:
Because the broadband connection was so fast, TCP was able to repair the impairments without reducing voice quality. "
That works fine if latency+window size is low, so that segments are retransmitted quickly. You really should also do the math and factor in the latency that comes from doing something like this, assuming you lose a packet. G. 114 recommends an end to end latency of no more than 150ms for voice applications, where over 400ms is unacceptable (between 150 and 400 you should indicate that performance is not ideal). Finally, some audio codecs work well with fairly high amounts of loss - I'd recommend doing something like that first. iLBC does this really well. G.729 etc. do not - they rely on context, so a single packet lost results in several packets of lost audio (and so, silence). iLBC doesn't rely on context, and quality degrades during packet loss before you get silence. The i stands for Internet - so no surprise it works great in typical Internet conditions. -- Nathan Ward
Nathan hit the nail on the head in his first sentence. With a VPN, if the latency is low enough to allow retransmission of the UDP-based RTP packets before the ATA's jitter buffer is starved, there can definitely be an improvement in audio quality. This was documented in a VoIP testing review that Network Computing performed several years ago. Since most jitter buffers range from 20 to 80 msec (2 to 4 times the sampling size), it's unlikely a hosted PBX with service delivered over the internet would benefit from a VPN. Frank -----Original Message----- From: Nathan Ward [mailto:nanog@daork.net] Sent: Wednesday, November 12, 2008 6:01 AM To: nanog list Subject: Re: hosted PBX/VOIP thru VPN? On 13/11/2008, at 12:39 AM, Aaron Wolfe wrote:
Because the broadband connection was so fast, TCP was able to repair the impairments without reducing voice quality. "
That works fine if latency+window size is low, so that segments are retransmitted quickly. You really should also do the math and factor in the latency that comes from doing something like this, assuming you lose a packet. G. 114 recommends an end to end latency of no more than 150ms for voice applications, where over 400ms is unacceptable (between 150 and 400 you should indicate that performance is not ideal). Finally, some audio codecs work well with fairly high amounts of loss - I'd recommend doing something like that first. iLBC does this really well. G.729 etc. do not - they rely on context, so a single packet lost results in several packets of lost audio (and so, silence). iLBC doesn't rely on context, and quality degrades during packet loss before you get silence. The i stands for Internet - so no surprise it works great in typical Internet conditions. -- Nathan Ward
Lorell, It has been my experience that the VPN traffic will not be prioritize through the Internet. Why don't you suggest a test site for a comparison. Frank On Tue, Nov 11, 2008 at 9:17 PM, Lorell Hathcock <lorell@hathcock.org>wrote:
All:
My customer wants to try to improve performance to his ATAs by creating a VPN from his network to the VOIP provider's network through the internet.
I have to admit, the idea caught me flat footed. At the outset, it seems like we would want to do it just to improve security for end users. However, my customer wants it because he thinks it will improve performance (i.e. voice quality). We are suffering from poor VOIP quality due to the Sprint / Cogent depeering and subsequent squirming by our vendors.
The only reason I can think that VOIP thru a VPN would help is that *perhaps* routers in the middle on ASNs I have no control over *may* prioritize VPN traffic higher than regular traffic. They opposite could also be true.
Specifically the ASNs in the middle are Level 3, Sprint and Time Warner.
Thoughts? Should I try to dissuade him from this if performance is his main motivator?
Thanks!
Sincerely,
Lorell Hathcock
OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell@OfficeConnect.net
ocbannerjoomla
participants (7)
-
Aaron Wolfe -
Frank Bulk -
Frank Yocum -
John Todd -
Lorell Hathcock -
Nathan Ward -
Tim Sanderson