<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>My coworker spent a month in November working a issue only to find a Riverbed was messing with control traffic. Not your issue, but I find you spend more in labor hours than you get back in bandwidth costs. I’d exclude voip. How much wan optimization can you get out of G.7xx ?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net] <b>On Behalf Of </b>Abebe Amare<br><b>Sent:</b> Tuesday, February 14, 2012 12:45 PM<br><b>To:</b> Wes Sisk; Stephen Welsh; Mike King<br><b>Cc:</b> cisco voip<br><b>Subject:</b> Re: [cisco-voip] intercluster trunk over IPSec VPN<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><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. The VPN tunnels terminate at the ASA on each side. I am not comfortable with configuring QoS on the ASA, that is why I configured on the 2821. And since the 2821 can not see the pre-tunnel traffic, I decided to put the traffic passing over the tunnel in LLQ.<br>The VSAT link is used for basic Internet browsing. The speed of the VSAT connection is 768 kbps and we do take slow TCP connection as acceptable. We use IronPort web security appliance together with Packetshaper to tightly control what goes on the link.<br><br>I have collected some RTP streams using wireshark and it does not show excessive jitter, delay or packet loss in the RTP analysis which seems to contradict what I shared about the RTP statistics directly from the phone. How do I find out if the call setup signalling is delayed? <br><br>regards,<br><br>Abebe<br><br><o:p></o:p></p><div><p class=MsoNormal>On Tue, Feb 14, 2012 at 7:15 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>My QoS is a bit rusty as it's time to re-certify. That said "put the VPN traffic in LLQ" doesn't sound quite right. It is *voice* that needs to be in LLQ.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><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><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Otherwise, it might be beneficial to conduct some tests to better understand the network. What traffic flows over the VSAT link? Is the call setup signaling delayed? Is there excessive delay at the beginning of any TCP/UDP stream or is that unique to the UDP/RTP voice traffic?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Regards,<o:p></o:p></p></div><div><p class=MsoNormal>Wes<o:p></o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Feb 14, 2012, at 1:23 AM, Abebe Amare wrote:<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><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. 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 with reserved bandwidth. What other mechanisms do you suggest to improve the voice quality? <br><br>best regards,<br><br>Abebe<o:p></o:p></p><div><p class=MsoNormal>On Mon, Feb 13, 2012 at 6:06 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com" target="_blank">wsisk@cisco.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>Hi Abebe,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Those are pretty bad. These are of particular concern:<o:p></o:p></p></div><div><div><p class=MsoNormal>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<o:p></o:p></p></div><div><p class=MsoNormal>Cumulative Conceal ratio 0.0319<br>Max Conceal ratio 0.0446<br>Conceal sec 5<br>Severly conceal sec 1<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I interpret this as:<o:p></o:p></p></div><div><p class=MsoNormal>G.729 has a lower MOS so we're starting with less audio quality. The phone sent 709 packets but received 476 packets. At 20msec packetization the phone has sent 14.1 seconds of audio but received only 9.5 seconds of audio. The phone cannot begin counting until the first RTP packet arrives so this may account for an additional gap between these metrics and actual user experience. The tx/rx is normally very similar. Either there was a delay in signaling negotiating bidirectional audio or this phone first started receiving RTP packets ~5 seconds into the call. After that Jitter of 31 is not great but would generally still be intelligible audio. Max jitter of 185 is pretty much impossible to recover. Each packet should contain 20msec of audio. At least one packet arrived 185msec late. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Recvr discarded 1 means the phone discarded one rtp packet it received. Discard can happen for several reasons but with max jitter 185 it is very likely the packet was just too late to be used. When a 20msec slice of audio is unavailable the phone attempts to conceal that in the audio stream. This leads to next stats:<o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Conceal sec 5<br>Severly conceal sec 1<o:p></o:p></p></div></div><div><p class=MsoNormal>For 5 seconds the phone used the g.729 packet loss concealment algorithm to try and mask the absence of packets. This is going to be silence, noise, or otherwise unintelligible audio to the user.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It looks like something is indeed inhibiting RTP packet flow toward this phone. A packet capture will show more details but it's not particularly necessary from the phone/application perspective. The underlying packet network needs some improvements to delivery adequate voice quality.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#888888'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:#888888'>/wes<o:p></o:p></span></p></div><div><div><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Feb 13, 2012, at 9:31 AM, Abebe Amare wrote:<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><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<o:p></o:p></p><div><p class=MsoNormal>On Fri, Feb 10, 2012 at 8:32 PM, Lelio Fulgenzi <<a href="mailto:lelio@uoguelph.ca" target="_blank">lelio@uoguelph.ca</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal>I was surprised to find that SLA is not included in the IPBase module of v15, nor in the UC module. You need the Data module. <br><br>Sent from my iPhone...<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>"There's no place like 127.0.0.1"<o:p></o:p></p></div></div><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>On Feb 10, 2012, at 12:20 PM, Dennis Heim <<a href="mailto:Dennis.Heim@cdw.com" target="_blank">Dennis.Heim@cdw.com</a>> wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Maybe a good place for some IP SLA monitoring.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Dennis Heim<br>Senior Engineer (Unified Communications)<br>CDW Advanced Technology Services<br>10610 9<sup>th</sup> Place<br>Bellevue, WA 98004<br><br>425.310.5299 Single Number Reach (WA)</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>317.569.4255 Single Number Reach (IN)<br>317.569.4201 Fax</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> <br><a href="mailto:dennis.heim@cdw.com" target="_blank"><span style='font-size:10.0pt'>dennis.heim@cdw.com</span></a></span><u><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:blue'><br></span></u><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://www.cdw.com/content/solutions/unified-communications/" target="_blank">cdw.com/content/solutions/unified-communications/</a></span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>] <b>On Behalf Of </b>Wes Sisk<br><b>Sent:</b> Friday, February 10, 2012 10:36 AM<br><b>To:</b> Abebe Amare<br><b>Cc:</b> cisco voip<br><b>Subject:</b> Re: [cisco-voip] intercluster trunk over IPSec VPN</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>most likely still packet throughput issues. packets may be late to the point of discarded. they would not technically be lost in that case.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>this would manifest as high jitter. setup the initial all and press the "i" or "?" button twice on the phone to see call statistics. beyond that take a packet capture. wireshark has some decent RTP analysis tools built in.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>/wes<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Feb 10, 2012, at 6:41 AM, Abebe Amare wrote:<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><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 problem still persist. Bandwidth is reserved for at least four calls (taking into consideration VPN overhead) on a Packetshaper and the call quality is good mid-conversation. But it is is clipping the first few seconds. I dont see any packet loss n the CMR records for a test call. What should I be looking for?<br><br>thanks in advance<br><br>Abebe<br><br><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Thu, Feb 9, 2012 at 5:57 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com" target="_blank">wsisk@cisco.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>TCP keepalives are only used while a call is active.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>When no call is active there is no active h323/h225/h245 signaling, tcp session, or udp. The only exception is when gatekeeper is used. Then gk registration messages are maintained. Those are over UDP between the h323 ep and gk.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>for a static ICT defined between two CUCM clusters there is no network activity without an active call.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>For the duration of an active call the tcp keepalive parameter will help.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>regards,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>wes<o:p></o:p></p></div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Feb 9, 2012, at 8:13 AM, Adam Frankel (afrankel) wrote:<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Options Ping was added in 8.5(1).<br><br>The parameter "Allow TCP KeepAlives For H323 " should take care of this for H323 ICT. <br><br>-Adam</span><o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><hr size=2 width="100%" align=center></span></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Abebe Amare <a href="mailto:abucho@gmail.com" target="_blank"><abucho@gmail.com></a><br><b>Sent:</b> Thu, Feb 09, 2012 4:52:50 AM<br><b>To:</b> Ryan Ratliff <a href="mailto:rratliff@cisco.com" target="_blank"><rratliff@cisco.com></a><br><b>CC:</b> cisco voip <a href="mailto:cisco-voip@puck.nether.net" target="_blank"><cisco-voip@puck.nether.net></a><br><b>Subject:</b> Re: [cisco-voip] intercluster trunk over IPSec VPN<br><br></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style='font-size:10.0pt'>Hi Ryan,<br><br>The CUCM version is 6.1.3.1000-16. Is the SIP options ping parameter available in this version? Where would you enable it if it is available?<br><br>thanks in Advance,<br><br>Abebe</span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'>On Wed, Feb 8, 2012 at 8:07 PM, Ryan Ratliff <<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>> wrote:</span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'>What about a SIP trunk with options ping enabled? </span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'> </span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif"'>-Ryan</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'> </span><o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'>On Feb 8, 2012, at 7:05 AM, Abebe Amare wrote:</span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style='font-size:10.0pt'><br>Hi Dennis,<br><br>Configuring a persistent L2L tunnel proved to be very elusive. I settled for running a periodic ping scheduled to keep the tunnel running.<br><br>Thanks for your help<br><br>Abebe</span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'>On Tue, Feb 7, 2012 at 6:16 PM, Dennis Heim <<a href="mailto:Dennis.Heim@cdw.com" target="_blank">Dennis.Heim@cdw.com</a>> wrote:</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think you answered your own question. IPSEC tunnel’s take time to bring up. Maybe you could tweak some of the VPN negotiating parameters, or create a separate L2 tunnel profile/group just for your voice that is permanent and does not have an inactivity timer.</span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Dennis Heim<br>Senior Engineer (Unified Communications)<br>CDW Advanced Technology Services<br>10610 9<sup>th</sup> Place<br>Bellevue, WA 98004<br><br>425.310.5299 Single Number Reach (WA)</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>317.569.4255 Single Number Reach (IN)<br>317.569.4201 Fax</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br><a href="mailto:dennis.heim@cdw.com" target="_blank"><span style='font-size:10.0pt'>dennis.heim@cdw.com</span></a></span><u><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:blue'><br></span></u><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://www.cdw.com/content/solutions/unified-communications/" target="_blank">cdw.com/content/solutions/unified-communications/</a></span><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>] <b>On Behalf Of </b>Abebe Amare<br><b>Sent:</b> Tuesday, February 07, 2012 4:10 AM<br><b>To:</b> cisco voip<br><b>Subject:</b> [cisco-voip] intercluster trunk over IPSec VPN</span><o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Dears,<br><br>I have configured an Inter-Cluster trunk from CUCM to another site with CUCME. There is an IPSec L2L VPN terminating at ASA 5500 firewall on both 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 (default) which is causing a problem. When a phone in one site tries to call another phone in the other site there is a noticeable gap before actual conversation is heard over the phone. Once conversation starts, there is no delay or break in audio. Has anyone faced this issue?<br><br>best regards,<br><br>Abebe<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'> </span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">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></span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt'> </span><o:p></o:p></p></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style='font-size:10.0pt'><br><br></span><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>cisco-voip mailing list<o:p></o:p></pre><pre><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><o:p></o:p></pre><pre><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><o:p></o:p></pre><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> </span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">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><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">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><o:p></o:p></p></div></blockquote></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></div><p class=MsoNormal><br><br><br><span style='color:white'>itevomcid</span> <o:p></o:p></p></div></body></html>