Hi Nick, Peter<br><br>Enabling H323 fast start on both ends did the trick. I highly appreciate all of the incredible support I received from the group.<br><br>best regards,<br><br>Abebe <br><br><div class="gmail_quote">On Thu, Feb 16, 2012 at 1:28 AM, Nick Matthews <span dir="ltr"><<a href="mailto:matthnick@gmail.com">matthnick@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A few notes:<br>
-ICT to CME isn't the recommended option. ICT is very similar to<br>
H.323 so it will work but you may run into weird issues like transfers<br>
failing with ICT vs H323 Gateway.<br>
<br>
-When the ASA creates the IPsec tunnel it will automatically copy the<br>
DSCP marking from the inside packet to the outside packet. So if<br>
you're correctly doing QoS based on DSCP you should still be in good<br>
shape. If you need it based on L4-L7 it would need to happen before<br>
the ASA. On a router you use 'qos pre-classify' if it's doing both<br>
the tunneling and QoS.<br>
<br>
-IPSec through any wan acceleration is probably not very effective.<br>
It may be best to exempt the entire stream, as well as any RTP/UDP<br>
traffic.<br>
<br>
-Pete has a very good point. They call it fast start for a reason.<br>
When you switch it to a H323 gateway enable both inbound and outbound<br>
fast start. You'll need to check 'MTP Required' and make sure you've<br>
got a software MTP on a router to do g729 mtp sessions. This could<br>
cut down a few seconds of delay.<br>
<span class="HOEnZb"><font color="#888888"><br>
-nick<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Feb 15, 2012 at 8:28 AM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
> Abebe,<br>
><br>
> I also believe Jason has a good point. I have only seen bad results when<br>
> combining with WCCP mechanisms.<br>
><br>
> /wes<br>
><br>
> On Feb 15, 2012, at 3:52 AM, Abebe Amare wrote:<br>
><br>
> Hi Peter,<br>
><br>
> It is possible to create an ICT pointing to a CME. On the CME side, you just<br>
> configure voip dial-peer pointing to the CM. Saying that, here is a how the<br>
> problem manifests:<br>
> 1.The problem occurs during call set up and on one leg (the caller does not<br>
> hear the receiver). This happens regardless of the call setup originating<br>
> from the CM or CME side.<br>
> 2.The caller usually does not hear the other side for few seconds (3-4);<br>
> this happens right after the ring-back tone is stopped.<br>
> 3.The receiver when picking up the phone and starts by saying hello the<br>
> other party does not hear any voice until 3-4 seconds elapse.<br>
><br>
> Wes, I will collect packet captures and call statistics from the phone<br>
> concurrently and compare the result.<br>
><br>
> best regards,<br>
><br>
> Abebe<br>
><br>
> On Wed, Feb 15, 2012 at 12:20 AM, Jason Aarons (AM)<br>
> <<a href="mailto:jason.aarons@dimensiondata.com">jason.aarons@dimensiondata.com</a>> wrote:<br>
>><br>
>> My coworker spent a month in November working a issue only to find a<br>
>> Riverbed was messing with control traffic. Not your issue, but I find you<br>
>> spend more in labor hours than you get back in bandwidth costs. I’d exclude<br>
>> voip. How much wan optimization can you get out of G.7xx ?<br>
>><br>
>><br>
>><br>
>> From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
>> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Abebe Amare<br>
>> Sent: Tuesday, February 14, 2012 12:45 PM<br>
>> To: Wes Sisk; Stephen Welsh; Mike King<br>
>><br>
>><br>
>> Cc: cisco voip<br>
>> Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Hi Wes,<br>
>><br>
>> Here is how the devices involved are connected<br>
>><br>
>> CUCM->6509->ASA->Packetshaper->2821->VSAT Link->Internet<-ASA<-CUCME<br>
>><br>
>> I do not have control over the CUCME on the remote side for the moment.<br>
>> The VPN tunnels terminate at the ASA on each side. I am not comfortable with<br>
>> configuring QoS on the ASA, that is why I configured on the 2821. And since<br>
>> the 2821 can not see the pre-tunnel traffic, I decided to put the traffic<br>
>> passing over the tunnel in LLQ.<br>
>> The VSAT link is used for basic Internet browsing. The speed of the VSAT<br>
>> connection is 768 kbps and we do take slow TCP connection as acceptable. We<br>
>> use IronPort web security appliance together with Packetshaper to tightly<br>
>> control what goes on the link.<br>
>><br>
>> I have collected some RTP streams using wireshark and it does not show<br>
>> excessive jitter, delay or packet loss in the RTP analysis which seems to<br>
>> contradict what I shared about the RTP statistics directly from the phone.<br>
>> How do I find out if the call setup signalling is delayed?<br>
>><br>
>> regards,<br>
>><br>
>> Abebe<br>
>><br>
>> On Tue, Feb 14, 2012 at 7:15 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
>><br>
>> My QoS is a bit rusty as it's time to re-certify. That said "put the VPN<br>
>> traffic in LLQ" doesn't sound quite right. It is *voice* that needs to be<br>
>> in LLQ.<br>
>><br>
>><br>
>><br>
>><br>
>> <a href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/netstruc.html#wp1044413" target="_blank">http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/netstruc.html#wp1044413</a><br>
>><br>
>><br>
>><br>
>> Otherwise, it might be beneficial to conduct some tests to better<br>
>> understand the network. What traffic flows over the VSAT link? Is the<br>
>> call setup signaling delayed? Is there excessive delay at the beginning of<br>
>> any TCP/UDP stream or is that unique to the UDP/RTP voice traffic?<br>
>><br>
>><br>
>><br>
>> Regards,<br>
>><br>
>> Wes<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Feb 14, 2012, at 1:23 AM, Abebe Amare wrote:<br>
>><br>
>><br>
>> Hi Wes, thanks a lot for your detail explanation, it is very educational.<br>
>><br>
>> I should have stated earlier that the Internet connection is a VSAT link.<br>
>> Here is a ping output from the CUCM to the far side CUCME,<br>
>><br>
>> admin:utils network ping 192.168.100.1<br>
>> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.<br>
>> 64 bytes from <a href="http://192.168.100.1" target="_blank">192.168.100.1</a>: icmp_seq=0 ttl=254 time=577 ms<br>
>> 64 bytes from <a href="http://192.168.100.1" target="_blank">192.168.100.1</a>: icmp_seq=1 ttl=254 time=579 ms<br>
>> 64 bytes from <a href="http://192.168.100.1" target="_blank">192.168.100.1</a>: icmp_seq=2 ttl=254 time=587 ms<br>
>> 64 bytes from <a href="http://192.168.100.1" target="_blank">192.168.100.1</a>: icmp_seq=3 ttl=254 time=584 ms<br>
>><br>
>> --- 192.168.100.1 ping statistics ---<br>
>> 4 packets transmitted, 4 received, 0% packet loss, time 3036ms<br>
>> rtt min/avg/max/mdev = 577.892/582.386/587.697/4.048 ms, pipe 2<br>
>><br>
>> I have configured QoS on the gateway routers to put the VPN traffic in LLQ<br>
>> with reserved bandwidth. What other mechanisms do you suggest to improve the<br>
>> voice quality?<br>
>><br>
>> best regards,<br>
>><br>
>> Abebe<br>
>><br>
>> On Mon, Feb 13, 2012 at 6:06 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
>><br>
>> Hi Abebe,<br>
>><br>
>><br>
>><br>
>> Those are pretty bad. These are of particular concern:<br>
>><br>
>> Rcvr Codec G729<br>
>> Sender Codec G729<br>
>> Rcvr size 20ms<br>
>> sender size 20ms<br>
>> Rcvr Packets 476<br>
>> sender packets 709<br>
>> Avg Jitter 31<br>
>> Max Jitter 185<br>
>> Rcvr discarded 1<br>
>><br>
>> Cumulative Conceal ratio 0.0319<br>
>> Max Conceal ratio 0.0446<br>
>> Conceal sec 5<br>
>> Severly conceal sec 1<br>
>><br>
>><br>
>><br>
>> I interpret this as:<br>
>><br>
>> G.729 has a lower MOS so we're starting with less audio quality. The<br>
>> phone sent 709 packets but received 476 packets. At 20msec packetization<br>
>> the phone has sent 14.1 seconds of audio but received only 9.5 seconds of<br>
>> audio. The phone cannot begin counting until the first RTP packet arrives<br>
>> so this may account for an additional gap between these metrics and actual<br>
>> user experience. The tx/rx is normally very similar. Either there was a<br>
>> delay in signaling negotiating bidirectional audio or this phone first<br>
>> started receiving RTP packets ~5 seconds into the call. After that Jitter<br>
>> of 31 is not great but would generally still be intelligible audio. Max<br>
>> jitter of 185 is pretty much impossible to recover. Each packet should<br>
>> contain 20msec of audio. At least one packet arrived 185msec late.<br>
>><br>
>><br>
>><br>
>> Recvr discarded 1 means the phone discarded one rtp packet it received.<br>
>> Discard can happen for several reasons but with max jitter 185 it is very<br>
>> likely the packet was just too late to be used. When a 20msec slice of<br>
>> audio is unavailable the phone attempts to conceal that in the audio stream.<br>
>> This leads to next stats:<br>
>><br>
>> Conceal sec 5<br>
>> Severly conceal sec 1<br>
>><br>
>> For 5 seconds the phone used the g.729 packet loss concealment algorithm<br>
>> to try and mask the absence of packets. This is going to be silence, noise,<br>
>> or otherwise unintelligible audio to the user.<br>
>><br>
>><br>
>><br>
>> It looks like something is indeed inhibiting RTP packet flow toward this<br>
>> phone. A packet capture will show more details but it's not particularly<br>
>> necessary from the phone/application perspective. The underlying packet<br>
>> network needs some improvements to delivery adequate voice quality.<br>
>><br>
>><br>
>><br>
>> /wes<br>
>><br>
>><br>
>><br>
>> On Feb 13, 2012, at 9:31 AM, Abebe Amare wrote:<br>
>><br>
>><br>
>> Hi Wes,<br>
>><br>
>> Here is the call statistics from the phone for one call<br>
>><br>
>> Rcvr Codec G729<br>
>> Sender Codec G729<br>
>> Rcvr size 20ms<br>
>> sender size 20ms<br>
>> Rcvr Packets 476<br>
>> sender packets 709<br>
>> Avg Jitter 31<br>
>> Max Jitter 185<br>
>> Rcvr discarded 1<br>
>> Rcvr lost packets 0<br>
>> Avg MOS LQK 0.0<br>
>> Min MOS LQK 0.0<br>
>> Max MOS LQK 0.0<br>
>> Cumulative Conceal ratio 0.0319<br>
>> Max Conceal ratio 0.0446<br>
>> Conceal sec 5<br>
>> Severly conceal sec 1<br>
>><br>
>> Is the jitter too high?<br>
>><br>
>> regards,<br>
>><br>
>> Abebe<br>
>><br>
>> On Fri, Feb 10, 2012 at 8:32 PM, Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>> wrote:<br>
>><br>
>> I was surprised to find that SLA is not included in the IPBase module of<br>
>> v15, nor in the UC module. You need the Data module.<br>
>><br>
>> Sent from my iPhone...<br>
>><br>
>><br>
>><br>
>> "There's no place like 127.0.0.1"<br>
>><br>
>><br>
>> On Feb 10, 2012, at 12:20 PM, Dennis Heim <<a href="mailto:Dennis.Heim@cdw.com">Dennis.Heim@cdw.com</a>> wrote:<br>
>><br>
>> Maybe a good place for some IP SLA monitoring.<br>
>><br>
>><br>
>><br>
>> Dennis Heim<br>
>> Senior Engineer (Unified Communications)<br>
>> CDW Advanced Technology Services<br>
>> 10610 9th Place<br>
>> Bellevue, WA 98004<br>
>><br>
>> 425.310.5299 Single Number Reach (WA)<br>
>><br>
>> 317.569.4255 Single Number Reach (IN)<br>
>> 317.569.4201 Fax<br>
>> <a href="mailto:dennis.heim@cdw.com">dennis.heim@cdw.com</a><br>
>> <a href="http://cdw.com/content/solutions/unified-communications/" target="_blank">cdw.com/content/solutions/unified-communications/</a><br>
>><br>
>><br>
>><br>
>> From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
>> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Wes Sisk<br>
>> Sent: Friday, February 10, 2012 10:36 AM<br>
>> To: Abebe Amare<br>
>> Cc: cisco voip<br>
>> Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN<br>
>><br>
>><br>
>><br>
>> most likely still packet throughput issues. packets may be late to the<br>
>> point of discarded. they would not technically be lost in that case.<br>
>><br>
>><br>
>><br>
>> this would manifest as high jitter. setup the initial all and press the<br>
>> "i" or "?" button twice on the phone to see call statistics. beyond that<br>
>> take a packet capture. wireshark has some decent RTP analysis tools built<br>
>> in.<br>
>><br>
>><br>
>><br>
>> /wes<br>
>><br>
>><br>
>><br>
>> On Feb 10, 2012, at 6:41 AM, Abebe Amare wrote:<br>
>><br>
>><br>
>> Dears, thank you all for the excellent support<br>
>><br>
>> I managed to keep the VPN tunnel up be sending periodic ping but the<br>
>> problem still persist. Bandwidth is reserved for at least four calls (taking<br>
>> into consideration VPN overhead) on a Packetshaper and the call quality is<br>
>> good mid-conversation. But it is is clipping the first few seconds. I dont<br>
>> see any packet loss n the CMR records for a test call. What should I be<br>
>> looking for?<br>
>><br>
>> thanks in advance<br>
>><br>
>> Abebe<br>
>><br>
>> On Thu, Feb 9, 2012 at 5:57 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
>><br>
>> TCP keepalives are only used while a call is active.<br>
>><br>
>><br>
>><br>
>> When no call is active there is no active h323/h225/h245 signaling, tcp<br>
>> session, or udp. The only exception is when gatekeeper is used. Then gk<br>
>> registration messages are maintained. Those are over UDP between the h323<br>
>> ep and gk.<br>
>><br>
>><br>
>><br>
>> for a static ICT defined between two CUCM clusters there is no network<br>
>> activity without an active call.<br>
>><br>
>><br>
>><br>
>> For the duration of an active call the tcp keepalive parameter will help.<br>
>><br>
>><br>
>><br>
>> regards,<br>
>><br>
>> wes<br>
>><br>
>><br>
>><br>
>> On Feb 9, 2012, at 8:13 AM, Adam Frankel (afrankel) wrote:<br>
>><br>
>><br>
>><br>
>> Options Ping was added in 8.5(1).<br>
>><br>
>> The parameter "Allow TCP KeepAlives For H323 " should take care of this<br>
>> for H323 ICT.<br>
>><br>
>> -Adam<br>
>><br>
>> ________________________________<br>
>><br>
>> From: Abebe Amare <<a href="mailto:abucho@gmail.com">abucho@gmail.com</a>><br>
>> Sent: Thu, Feb 09, 2012 4:52:50 AM<br>
>> To: Ryan Ratliff <<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>><br>
>> CC: cisco voip <<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>><br>
>> Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN<br>
>><br>
>> Hi Ryan,<br>
>><br>
>> The CUCM version is 6.1.3.1000-16. Is the SIP options ping parameter<br>
>> available in this version? Where would you enable it if it is available?<br>
>><br>
>> thanks in Advance,<br>
>><br>
>> Abebe<br>
>><br>
>> On Wed, Feb 8, 2012 at 8:07 PM, Ryan Ratliff <<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>> wrote:<br>
>><br>
>> What about a SIP trunk with options ping enabled?<br>
>><br>
>><br>
>><br>
>> -Ryan<br>
>><br>
>><br>
>><br>
>> On Feb 8, 2012, at 7:05 AM, Abebe Amare wrote:<br>
>><br>
>><br>
>> Hi Dennis,<br>
>><br>
>> Configuring a persistent L2L tunnel proved to be very elusive. I settled<br>
>> for running a periodic ping scheduled to keep the tunnel running.<br>
>><br>
>> Thanks for your help<br>
>><br>
>> Abebe<br>
>><br>
>> On Tue, Feb 7, 2012 at 6:16 PM, Dennis Heim <<a href="mailto:Dennis.Heim@cdw.com">Dennis.Heim@cdw.com</a>> wrote:<br>
>><br>
>> I think you answered your own question. IPSEC tunnel’s take time to bring<br>
>> up. Maybe you could tweak some of the VPN negotiating parameters, or create<br>
>> a separate L2 tunnel profile/group just for your voice that is permanent and<br>
>> does not have an inactivity timer.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Dennis Heim<br>
>> Senior Engineer (Unified Communications)<br>
>> CDW Advanced Technology Services<br>
>> 10610 9th Place<br>
>> Bellevue, WA 98004<br>
>><br>
>> 425.310.5299 Single Number Reach (WA)<br>
>><br>
>> 317.569.4255 Single Number Reach (IN)<br>
>> 317.569.4201 Fax<br>
>> <a href="mailto:dennis.heim@cdw.com">dennis.heim@cdw.com</a><br>
>> <a href="http://cdw.com/content/solutions/unified-communications/" target="_blank">cdw.com/content/solutions/unified-communications/</a><br>
>><br>
>><br>
>><br>
>> From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>
>> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Abebe Amare<br>
>> Sent: Tuesday, February 07, 2012 4:10 AM<br>
>> To: cisco voip<br>
>> Subject: [cisco-voip] intercluster trunk over IPSec VPN<br>
>><br>
>><br>
>><br>
>> Dears,<br>
>><br>
>> I have configured an Inter-Cluster trunk from CUCM to another site with<br>
>> CUCME. There is an IPSec L2L VPN terminating at ASA 5500 firewall on both<br>
>> ends<br>
>><br>
>> CUCM --->ASA 5540--->Internet <---ASA 5510<---CUCME<br>
>><br>
>> On the ASA,the IPSec tunnel is terminated after 30 minute of inactivity<br>
>> (default) which is causing a problem. When a phone in one site tries to call<br>
>> another phone in the other site there is a noticeable gap before actual<br>
>> conversation is heard over the phone. Once conversation starts, there is no<br>
>> delay or break in audio. Has anyone faced this issue?<br>
>><br>
>> best regards,<br>
>><br>
>> Abebe<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cisco-voip mailing list<br>
>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>><br>
>> cisco-voip mailing list<br>
>><br>
>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cisco-voip mailing list<br>
>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cisco-voip mailing list<br>
>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> itevomcid<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> cisco-voip mailing list<br>
> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
><br>
</div></div></blockquote></div><br>