cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12701
Views
9
Helpful
8
Replies

Running VOIP Over Internet VPN

networkwise
Level 1
Level 1

Hi

Is running VOIP between sites feasible within the US over VPN connections?? I realise that once on the internet there is no QOS more best effort etc.

I have been studying the Cisco SNF 2.0 configuration templates for SMB and Cisco's Validated Design Templates which provide guidace for configuring VPN between sites with QOS applied within the VPN.

I just wondered if anyone out there can share there experience with the voice quality and reliability using VOIP over VPN. It seems like a cost effective solution for SMB customers using the public Internet as a transport for intersite voice calls.

Andy

3 Accepted Solutions

Accepted Solutions

paolo bevilacqua
Hall of Fame
Hall of Fame

Is running VOIP between sites feasible within the US over VPN connections??

Yes, and actually works very well. It is actually very popular across vendors and applications.

View solution in original post

Tim Smith
Level 4
Level 4

Hi Andy,

It can be done. Think Skype

Just for consideration - like you said - no quality guarantees.

Most people tolerate slight call quality issues with Skype because it is free, and a big money saver.

Business users are not so tolerant usually.

So you need to have a fallback to allow them to dial out the PSTN if they have issues on a call.

A couple of points to consider..

   1. Take into account your RTT's - usually people say 150ms maximum, but we usually prefer it to be less. If you are over this, it will still work, but the experience may not be that good. Think users on the end of Satelite links. Sometimes we have up 700ms RTT and they still manage to use Sat phones and even VoIP in some cases. They just adjust the way they converse, more like a 2 way radio!

   2. Make sure you can use a codec designed for lossy links - iLBC for example - http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec (Cisco supports this in all the new gear)

   3. It is most likely your access links that there will be congestion. You can still perform QoS here on the egress. You dont have full control over the ingress though. Using the best quality links and providers here will help. Using the same ISP usually helps, but probably difficult internationally.

   4. Packeteer Packetshapers (Now Bluecoat) do a good job of bandwidth control on internet links. They do things like intercept TCP sessions and adjust the windowing size to reduce bandwidth consumption for hogs like FTP, P2P etc. You need to be very careful about what sort of other traffic you allow on the links, and how you control it.

   5. Protocols like SIP and MGCP will perform better over higher latency links. If you end up with H323, you may have delayed audio cut through issues, in which case you should look at H323 fast start options.

   6. Make sure you figure out how many calls you can support, and use call admission control to limit the number of simultaneous calls you allow.

I have customers running from Australia to parts of Asia using this scenario, they find it acceptable, considering the cost of the call.

Cheers,

Tim.

View solution in original post

stowellp
Level 1
Level 1

Hi Andy,

We currently have over 30 remote sites in Europe running VoIP over VPNs without any issues. Our HQ is in London and we have VoIP to countries which have pretty poor links i.e 512kbps and RTT of 300ms+, due to the distances (+5 hours from London) and on the whole it is fine.

We have rolled out Riverbed WAN Accelerators to a few countries and this has improved the voice quality.

Cheers,

Phil

View solution in original post

8 Replies 8

paolo bevilacqua
Hall of Fame
Hall of Fame

Is running VOIP between sites feasible within the US over VPN connections??

Yes, and actually works very well. It is actually very popular across vendors and applications.

Thanks for you response the clarification is good. It gives me confidence in the technology.

Andy

Tim Smith
Level 4
Level 4

Hi Andy,

It can be done. Think Skype

Just for consideration - like you said - no quality guarantees.

Most people tolerate slight call quality issues with Skype because it is free, and a big money saver.

Business users are not so tolerant usually.

So you need to have a fallback to allow them to dial out the PSTN if they have issues on a call.

A couple of points to consider..

   1. Take into account your RTT's - usually people say 150ms maximum, but we usually prefer it to be less. If you are over this, it will still work, but the experience may not be that good. Think users on the end of Satelite links. Sometimes we have up 700ms RTT and they still manage to use Sat phones and even VoIP in some cases. They just adjust the way they converse, more like a 2 way radio!

   2. Make sure you can use a codec designed for lossy links - iLBC for example - http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec (Cisco supports this in all the new gear)

   3. It is most likely your access links that there will be congestion. You can still perform QoS here on the egress. You dont have full control over the ingress though. Using the best quality links and providers here will help. Using the same ISP usually helps, but probably difficult internationally.

   4. Packeteer Packetshapers (Now Bluecoat) do a good job of bandwidth control on internet links. They do things like intercept TCP sessions and adjust the windowing size to reduce bandwidth consumption for hogs like FTP, P2P etc. You need to be very careful about what sort of other traffic you allow on the links, and how you control it.

   5. Protocols like SIP and MGCP will perform better over higher latency links. If you end up with H323, you may have delayed audio cut through issues, in which case you should look at H323 fast start options.

   6. Make sure you figure out how many calls you can support, and use call admission control to limit the number of simultaneous calls you allow.

I have customers running from Australia to parts of Asia using this scenario, they find it acceptable, considering the cost of the call.

Cheers,

Tim.

Also take a look at iLBC as a phone-to-phone codec over internet sites.  It's an adaptive, low bit-rate codec with good quality.

Hi Tim,

Thanks for the information. From what I read on the Cisco Smart Designs and Validated Design Web Sites it seems like it works, but it is also good to hear from Engineers that have deployed the technology in real world situations like yourself. It gives the confidence to offer this as a solution to potential customers.

As far as the CODEC you were recomending, this would be under the VOIP dial peer configuration is that correct?? See below this is the output from from within the cme dial peer voice voip and the codec options. You would recomend the last one in the list for Internet VOIP is that correct?

lab-branch1-rtr(config-dial-peer)#codec ?
  clear-channel  Clear Channel 64000 bps (No voice capabilities: data transport
                 only)
  g711alaw       G.711 A Law 64000 bps
  g711ulaw       G.711 u Law 64000 bps
  g722-48        G722-48K 64000 bps - Only supported for H.320<->H.323 calls
  g722-56        G722-56K 64000 bps - Only supported for H.320<->H.323 calls
  g722-64        G722-64K 64000 bps - Only supported for H.320<->H.323 calls
  g723ar53       G.723.1 ANNEX-A 5300 bps (contains built-in vad that cannot be
                 disabled)
  g723ar63       G.723.1 ANNEX-A 6300 bps (contains built-in vad that cannot be
                 disabled)
  g723r53        G.723.1 5300 bps
  g723r63        G.723.1 6300 bps
  g726r16        G.726 16000 bps
  g726r24        G.726 24000 bps
  g726r32        G.726 32000 bps
  g728           G.728 16000 bps
  g729br8        G.729 ANNEX-B 8000 bps (contains built-in vad that cannot be
                 disabled)
  g729r8         G.729 8000 bps
  ilbc           iLBC 13330 or 15200 bps

Again thanks for your input I appreciate it.

Andy

Hi Andy,

Yep, couple of points I should add for you!

I said in my original post 150ms RTT.. should have been 300ms RTT (150 one way)

Last option (iLBC) is what I was referring to.

I havent actually had a chance to deploy this yet, but it is designed for lossy links, so should perform better over the internet.

It is fairly new - your end points / gateways / call control will need to support the codec otherwise you will need xcoding.

My deployments have used G729 so far with good results.

You can always deploy a prefix to use for voip calls, this way users can choose which method, and pilot the quality.

Cheers,

Tim

stowellp
Level 1
Level 1

Hi Andy,

We currently have over 30 remote sites in Europe running VoIP over VPNs without any issues. Our HQ is in London and we have VoIP to countries which have pretty poor links i.e 512kbps and RTT of 300ms+, due to the distances (+5 hours from London) and on the whole it is fine.

We have rolled out Riverbed WAN Accelerators to a few countries and this has improved the voice quality.

Cheers,

Phil

I appreciate your input, thankyou this is good to know.

Andy

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: