Despite the VPN overhead, running VOIP through VPN is good idea because VPN
reorders encapsulated UDP packets in correct order. Security matters as
well.
I'd suggest to route VNC packets rather over internet than VPN (so do I), as
VPN usually has the highest priority.
On Thu, May 7, 2009 at
On Fri, 8 May 2009, Aurimas Skirgaila wrote:
Despite the VPN overhead, running VOIP through VPN is good idea because VPN
reorders encapsulated UDP packets in correct order. Security matters as
well.
Reorders? How so? I think it will maintain the order, only if they have
arrived in the
Access-list 100 permit ip host asterisk server any
Class-map match-any voip
Match access-group 100
Policy-map voip
Class voip
Priority 256
Class class-default
Fair-queue
Interface fastethernet 0
Service-policy output voip
Above is what I do to prioritize 256kbit of outbound bandwidth
On Fri, May 8, 2009 at 3:45 PM, Jeff LaCoursiere j...@jeff.net wrote:
On Fri, 8 May 2009, Aurimas Skirgaila wrote:
Despite the VPN overhead, running VOIP through VPN is good idea because
VPN
reorders encapsulated UDP packets in correct order. Security matters as
well.
Reorders? How
On Thu, May 7, 2009 at 3:54 PM, Brent Davidson
br...@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
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.
Garth van Sittert
Technical Director
BitCo
08600 24826
www.bitco.co.za
Aurimas Skirgaila wrote:
Despite the VPN overhead, running VOIP through VPN is good idea
because
On Friday 08 May 2009 10:07:43 Garth van Sittert wrote:
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.
Not all VPNs use TCP. OpenVPN, in particular, uses UDP for the backbone.
--
Tilghman
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),
Dave Platt wrote:
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.
in ~45 msec.
Frank
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Garth van
Sittert
Sent: Friday, May 08, 2009 10:08 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users
David Backeberg wrote:
On Thu, May 7, 2009 at 3:54 PM, Brent Davidson
br...@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
Jeremy Mann wrote:
Access-list 100 permit ip host asterisk server any
Class-map match-any voip
Match access-group 100
Policy-map voip
Class voip
Priority 256
Class class-default
Fair-queue
Interface fastethernet 0
Service-policy output voip
Above is what I do to prioritize
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
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
br...@texascountrytitle.comwrote:
I've got multiple satellite
14 matches
Mail list logo
