[cisco-voip] Inter cluster trunk calls dropping at 10 minutes since upgrade to 7.0.2

Wes Sisk wsisk at cisco.com
Wed Sep 16 09:56:28 EDT 2009


your ASA is most likely terminating the TCP session.  try increasing 
session timeout on the ASA. if that works then you may need to enable 
h323 TCP keepalives via CM service parameter.

If that does not work then you will need to work with ASA team to 
identify why ASA is forcing session closed.

/wes

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090916/bf039e1a/attachment.html>


More information about the cisco-voip mailing list