<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)">
<title>Signature</title>
<style><!--
/* Font Definitions */
@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:11.0pt;
        font-family:"Calibri","sans-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;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle22
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle23
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle24
        {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="color:#1F497D">Eric,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The call should stay up if signaling is lost as long as RTP remains active.  There’s a “timer receive-rtp” and “timer receive-rtcp” that controls those type of call clearings.  In a case like this though, it’s
 most likely something about the SCCP communication with CUCM that is resulting in the connections on the gateway not being torn down 100%.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Brian<o:p></o:p></span></p>
<p class="MsoNormal"><span style="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""> Eric Pedersen [mailto:PedersenE@bennettjones.com]
<br>
<b>Sent:</b> Monday, February 03, 2014 3:02 PM<br>
<b>To:</b> Brian Meade (brmeade); cisco-voip@puck.nether.net<br>
<b>Subject:</b> RE: Stuck conferences on 2911<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks Brian. I'll keep an eye on it. I enabled debugs for sccp events and errors so if it happens again hopefully I'll get some information from the router. I have no idea how long these calls have been there.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Do you know what normal behavior is if communication breaks between a bridge and its CUCM while calls are active? Does the call stay up like a phone to phone call or is it immediately dropped?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Eric<o:p></o:p></span></p>
<p class="MsoNormal"><span style="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""> Brian Meade (brmeade) [<a href="mailto:brmeade@cisco.com">mailto:brmeade@cisco.com</a>]
<br>
<b>Sent:</b> 03 February 2014 12:29 PM<br>
<b>To:</b> Eric Pedersen; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> RE: Stuck conferences on 2911<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Eric,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The way I’ve usually resolved these issues is running the show sccp conn hourly until I can identify a recent inactive resource and then pull the realted CUCM traces and search for those conn_id’s until you can
 find the call that triggered the condition.  Last time I saw this issue, I was able to narrow it down to CSCtx65886 but you should have the fix for that in 9.1.2 so you’re probably looking at a different issue.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Brian<o:p></o:p></span></p>
<p class="MsoNormal"><span style="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 [<a href="mailto:cisco-voip-bounces@puck.nether.net">mailto:cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Eric Pedersen<br>
<b>Sent:</b> Monday, February 03, 2014 2:16 PM<br>
<b>To:</b> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> [cisco-voip] Stuck conferences on 2911<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We're using 2911s for conferences bridges, and we've been having reports of conferences failing. I looked at one of the routers and it shows inactive connections that never clear:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">BH-VOICE-GW1#show sccp conn    
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">sess_id    conn_id      stype mode     codec   sport rport ripaddr conn_id_tx<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">145723183  134217789    conf  inactive UNKNOWN 23566 0     UNKNOWN          
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">145913733  134269533    conf  inactive UNKNOWN 27940 0     UNKNOWN          
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New"">Total number of active session(s) 2, and connection(s) 2</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The CUCM performance counters show that this gateway has full conference resources available so it doesn't know about these connections. I don't know how long these have been on the router. I saw this on another router. no sccp/sccp cleared
 them but I'd like to know what the cause is.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Has anyone seen this?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CUCM 9.1(2)SU1 and IOS 15.1(4)M6<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Eric<o:p></o:p></p>
<pre>The contents of this message may contain confidential and/or privileged<o:p></o:p></pre>
<pre>subject matter. If this message has been received in error, please contact<o:p></o:p></pre>
<pre>the sender and delete all copies. Like other forms of communication,<o:p></o:p></pre>
<pre>e-mail communications may be vulnerable to interception by unauthorized<o:p></o:p></pre>
<pre>parties. If you do not wish us to communicate with you by e-mail, please<o:p></o:p></pre>
<pre>notify us at your earliest convenience. In the absence of such<o:p></o:p></pre>
<pre>notification, your consent is assumed. Should you choose to allow us to<o:p></o:p></pre>
<pre>communicate by e-mail, we will not take any additional security measures<o:p></o:p></pre>
<pre>(such as encryption) unless specifically requested.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The contents of this message may contain confidential and/or privileged<o:p></o:p></pre>
<pre>subject matter. If this message has been received in error, please contact<o:p></o:p></pre>
<pre>the sender and delete all copies. Like other forms of communication,<o:p></o:p></pre>
<pre>e-mail communications may be vulnerable to interception by unauthorized<o:p></o:p></pre>
<pre>parties. If you do not wish us to communicate with you by e-mail, please<o:p></o:p></pre>
<pre>notify us at your earliest convenience. In the absence of such<o:p></o:p></pre>
<pre>notification, your consent is assumed. Should you choose to allow us to<o:p></o:p></pre>
<pre>communicate by e-mail, we will not take any additional security measures<o:p></o:p></pre>
<pre>(such as encryption) unless specifically requested.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
</div>
</body>
</html>