Hi Barry,
I used SIP over OpenVPN when travelling, especially from hotel rooms or
showfloors. Of course I did not expect the performance of a local SIP
connection, but generally it worked OK. The latency would not suffer
much in comparison to direct connection, but a WLAN was involved which
would screw quality anyway. Using a bluetooth headset would not help
much, either. Having my geographic number from Europe ringing on my
twinkle softphone over in California was nice-to-have
Everything I say will be relevant to OpenVPN, which might be a bit
different from IPsec, PPTP or other solutions.
Am Montag, den 11.12.2006, 17:26 -0500 schrieb Barry
Fawthrop:> Hi All
>
> Could a VPN be used to help with SIP Tunneling and QoS issues.
>
> State 1:
> Two IP Networks Connected via the Public Internet transmitting VoIP Traffic
> Say a VoIP User and VoIP Termination Provider.
> Each side can put QoS onto their part, but if QoS does NOT exist between
> them
> then call quality will be bad anyhow.
>
> State 2:
> Same as above except a VPN tunnel is setup between each side.
> Thus making them appear on the same network and possibly same subnet.
>
> (1) Would this now traceroute a one hop ?
Yep, but the packet containing the ICMP (ping) packet to traceroute the
connection will itself be bumped around, so it will be the same number
of hops really, just those between the VPN endpoints will be hidden.
You win the bonus of getting around complicated NAT, possibly.
> (2) Would this have a lower or higher ping time, thus latency ?
Higher, it can impossibly be faster than the packets carrying the VPN. I
think you will not notice the difference though, because OpenVPN seems
to do a good job.
> (3) With the additional Encryption etc.. if using a 1 Mbps Internet
> connection
> What would the "actual" amount available now be 700kbps, in
other words
> How much overhead is there with a VPN tunnel that would reduce the
> available bandwidth ?
Sorry, no numbers from me. For connection oriented protocols like HTTP,
FTP, Mail, the additional problem of encapsulating TCP in TCP will kill
the TCP windowing, as such not allowing for full line saturation (do not
ask me for details, I slept to much during the networking lecture last
year to tell you without a look into transcripts). No problem for UDP
(like SIP/RTP). General data/overhead ratio will be probably better with
larger data packets - I seem to remember you can configure the
packetation size for some audio codecs in Asterisk. Alas I did not care,
telephony was good enough.
I would expect some throughput value wildly between 70 and 95%, but that
is a guess, and not even an educated one. It probably depends on the VPN
technology you use, and the maker(s) will be your authoritative data
source there.
Let us not forget that of course the data stream can be encrypted. Just
that you think you are talking boring stuff does not mean there would be
noone interested in wiretapping and listening in.
(Even if I'm not paranoid they may be after me... ;>)
Hth
Anselm