<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Dears<br><br>Any success on this issue !!!!!! , my Call is dropped after 5 min , CM 7.0.2<br><br>H225 Tcp session terminated abnormally in the TRACE FILE :)<br><br>I have a VPN between the 2 sites terminated on Cisco ASA 5510<br><br><br>--- On <b>Tue, 9/8/09, Wes Sisk <i><wsisk@cisco.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Wes Sisk <wsisk@cisco.com><br>Subject: Re: [cisco-voip] Inter cluster trunk calls dropping at 10 minutes since upgrade to 7.0.2<br>To: "Erick Bergquist" <erickbee@gmail.com><br>Cc: "cisco-voip mailinglist" <cisco-voip@puck.nether.net><br>Date: Tuesday, September 8, 2009, 10:09 PM<br><br><div class="plainMail">That should work around the issue but will not "fix" it. Issue is the <br>h225 TCP session is getting aborted by TCP
FIN or RST. Allowing h.323 <br>call preservation will mask the issue by allowing calls to stay up. <br>However, there will be no supplementary services for those calls such as <br>hold/transfer. Call will be in the same status as when a call is active <br>and phone changes to "cm down, features disabled".<br><br>Additionally, preserving h.323 calls is likely to leave abandoned active <br>RTP session active between endpoints in the network. Calls can be <br>nailed up indefinitely until endpoints are rebooted or calls forcibly <br>cleared. If the call goes out a gateway on remote site as an LD call <br>to, for example, a conference service, you could run up one whopping <br>phone bill. When call is "preserved" CM gives up on all management of <br>the call so even CM's "max call duration" does not tear the call down <br>after 24 hours.<br><br>/Wes<br><br>On Tuesday, September 08, 2009 9:41:55 PM , Erick Bergquist
<br><<a ymailto="mailto:erickbee@gmail.com" href="/mc/compose?to=erickbee@gmail.com">erickbee@gmail.com</a>> wrote:<br>> FYI,<br>><br>> Been awhile, but setting the H323 Peer Preserve Service parameter on<br>> both clusters fixed this issue for me.<br>><br>><br>> On Thu, Aug 13, 2009 at 11:47 AM, Erick Bergquist<<a ymailto="mailto:erickbee@gmail.com" href="/mc/compose?to=erickbee@gmail.com">erickbee@gmail.com</a>> wrote:<br>> <br>>> FYI,<br>>><br>>> This is line from the CCM Detailed trace where it disconnects due to<br>>> abnormal TCP Session disconnect.<br>>><br>>> 08/10/2009 11:08:21.108<br>>> CCM|H225Cdpc(0000476)::active10_TcpStopSessionInd: H225 Tcp session<br>>> terminated abnormally<br>>> |<CLID::StandAloneCluster><NID::10.12.5.2><CT::4,100,65,1.<br>>>
11216924><IP::10.12.5.2><DEV::SEP00DE735C201><LVL::Error><MASK::0100><br>>><br>>> Cisco TAC also suggested to set the H323 Peer Preserve value to True<br>>> on both clusters which we changed today. The H323 TCP Keepalive is<br>>> also to true on both sides (was).<br>>><br>>><br>>> On Wed, Aug 12, 2009 at 1:35 PM, Erick Bergquist<<a ymailto="mailto:erickbee@gmail.com" href="/mc/compose?to=erickbee@gmail.com">erickbee@gmail.com</a>> wrote:<br>>> <br>>>> No, there is no timeout set to 10 minutes for media exchange timeout I<br>>>> could find.<br>>>><br>>>> I have opened a TAC Case on this with the CCM traces I collected on a<br>>>> problem call.<br>>>><br>>>> Mike O, any success on your similar issue?<br>>>><br>>>> On Fri, Aug 7, 2009 at 10:44 AM, Wes Sisk<<a
ymailto="mailto:wsisk@cisco.com" href="/mc/compose?to=wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>>>> <br>>>>> check your CM service parameters to see if you have anything like media<br>>>>> exchange timeout set to 10 minutes.<br>>>>><br>>>>> alternatively you can look at CM SDI and SDL traces to see what timer is<br>>>>> firing.<br>>>>><br>>>>> Do you have any firewall or NAT between clusters? Have you enabled<br>>>>> H.225/h245 TCP keepalives (CM service parameter)<br>>>>><br>>>>> /Wes<br>>>>><br>>>>> On Thursday, August 06, 2009 9:42:42 AM , Erick Bergquist<br>>>>> <<a ymailto="mailto:erickbee@gmail.com" href="/mc/compose?to=erickbee@gmail.com">erickbee@gmail.com</a>> wrote:<br>>>>>
<br>>>>>> Anyone know of any issues with calls dropping across a Intercluster<br>>>>>> trunk (Non Gatekeeper controlled) between a CUCM 6.1.2 cluster and a<br>>>>>> 7.0.2 cluster? The calls stay connected for 10 mins and then<br>>>>>> disconnect. The disconnect occurs when a user on the 6.1.2 cluster<br>>>>>> calls someone on the 7.0.2 cluster and not the other way. This<br>>>>>> problem did not exist before the one side was updated to 7.0.2. I've<br>>>>>> compared the trunk configuration on both sides, etc and all that looks<br>>>>>> good.<br>>>>>><br>>>>>> Anything change in 7.0.2 trunk-wise I may need make adjustments for?<br>>>>>> Just posting here quick before I gather traces and open a TAC
case.<br>>>>>><br>>>>>><br>>>>>> Thanks, Erick<br>>>>>> _______________________________________________<br>>>>>> cisco-voip mailing list<br>>>>>> <a ymailto="mailto:cisco-voip@puck.nether.net" href="/mc/compose?to=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>cisco-voip mailing list<br><a ymailto="mailto:cisco-voip@puck.nether.net" href="/mc/compose?to=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></div></blockquote></td></tr></table><br>