hosted PBX/VOIP thru VPN?

Wed Nov 12 04:03:44 UTC 2008

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