H323 over VPN?

[Robert Craig]

Anyone have anything against doing an H323 trunk over an IPSEC L2L VPN? Have a remote site that gets VOIP services extended with an H323 to a local CME, then out to a few phones. But, an engineer I recently spoke with recommended not to do VOIP over VPN. Pro's, Con's?

[kking2008]

You want the standard answer?  it depends.

It depends on your goal.  It does work with some limitations.  Consider how many phones/conversations you're trying to handle at once.  More than a small remote office, or if its a call center, then probably not a good idea.  But if its a small office with patient users and you're trying to save a buck it will work as a low cost solution to a more expensive leased line.

my two cents...

[Dennis Mink]

I have seen it run in smaller deployments, say 5-10 phones on a remote site. What I have seen I dont consider it an issue running H323 over a VPN.  Too bad that engineer didnt specify why he recommended not to do voice over VPN.  Overhead ?  delay?

[ronpatel]

Hi

I dont see any problem in it.

Below document shows you the best practice for it.

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/V3PN_SRND/v3p_over.html

Regards

Ronak patel

Rate helpful posts.

[Robert Thomas]

It's all about QoS. You cannot guarantee QoS over public Internet connections. Depending on your provider you might get good or bad quality due to overprovisioning on their Core infraestructure. For guarantee QoS you need to look at an MPLS connection or other L2 WAN server with a signed SLA from your provider backing up your QoS level.

Other than that your voice traffic will be treated equal as your neighbor rapidshare download.

[Robert Craig]

My satellite provider can gurantee QOS across the link, but obviously once it hits the internet, its fair game. We'll see. I'm still working out the bugs in the satellite.

[stevenholzem]

Robert,

Your engineer was right about not using VoIP over VPN if you are using satellite. The average ping time is between 600 and 700 msec for a very good connection. There will be latency that will disturb the end users.VoIP is designed for a latency of up to 150 msec. This will far exceed that. It will work, but may not sound the best due to the pause.

Steven

[Robert Craig]

Well we do it here in the military and as long as QOS is applied over the SAT link, the conversation isn't bad. So I am trying to achieve the same results with my commercial stuff.

[Aaron Harrison]

Hi Robert

I have some experience of this. I was required to sort out a customer network where they had distributed CM and CME systems over satellite connected via h.323 over satellite links.

Latency was 600ms + on a good day.

Basically as long as connectivity is consistent, your voice quality will probably be OK - it'll take a bit longer to get there but as long as there isn't huge jitter or packet loss it isn't hugely noticeable.

What IS a problem is h.323. Even with fast start it's a bit... slow. There are a lot of packet exchanges involved in setting up each call, and when you multiply each packet exchange by your latency it's easy to get call setups that take 10 seconds or worse before the audio cuts through after the call is answered.

To resolve this we simply switched to SIP. It's much less chatty, so a typical call setup is significantly quicker over high latency links. On that particular customer network we dropped setup times (post-answering to cut through) to about 2 seconds and they were happy with this.

Regards

Aaron Harrison

Principal Engineer at Logicalis UK

Please rate helpful posts...

[Robert Thomas]

We had some experience like this in TAC. The best setup time we were able to get over a satelite link was about 3 seconds with FastStart in this case the RTT was somewhere between 450msec and 600msec.

I agree SIP with Early offer is your best option to minimize call setup time, H323 is just awful.

[Robert Craig]

I might try that. I will tell CUCM to do a SIP trunk to the CME and vice versa with a dial peer. I can control QOS better via SIP in my opinion too.

[Aaron Harrison]

I would - I think there aren't many scenarios where H.323 is preferable to SIP now, and only a few where MGCP has the upper hand.

Aaron

[Robert Craig]

OK, so I had issues trying to make a call from CME to CUCM over sip, but CUCM to CME worked fine. That did speed up the initial connection, but for whatever reason, I can hear calls from the CUCM just fine. But, the CUCM end still says my CME audio is choppy. I know SIP might have cleaned it up a bit, but I can't figure out why audio from satellite site to CUCM and beyond is choppy. I have 200k (give or take) of bandwidth, but not even using half at the time I am placing these calls. What am I missing?

[Robert Thomas]

Bandwidth is not as much concern as delay and jitter over the connection.

[Robert Craig]

Why would it be only one way though?