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?
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...
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?
I dont see any problem in it.
Below document shows you the best practice for it.
Rate helpful posts.
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.
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.
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.
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.
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.
Please rate helpful posts...
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.
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.
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.
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?
It's one way because you are experiencing quality issues in the path from CME to CUCM, but in the other direction you are getting better results....
Check all the basic stuff like errors on interfaces along the path etc
When you are making a test call, if you are on a 79xx phone hit the ? button twice quickly and you can see call stats for the call. It will show you the jitter/lost packets etc so you can see what the problem is.
If you have packet loss or high jitter and think it's not your kit at fault, and you are expecting better service then speak to your service provider.
The whole SIP/H.323/whatever discussion won't have much impact on this, setups will be different but once it's running you will be using the same codec regardless of what call control protocol you are using.