<div>the School district that had 5.1.2 had this same issue.&nbsp; It must be a bug.&nbsp; they upgraded to 5.1.3(newest) and the problem went away.</div>
<div>&nbsp;</div>
<div>it worked if it was in one partition but then did not from the other partition.&nbsp; (it was NOT a CSS issue)&nbsp; ran it throught the DNA and it said it should route also.&nbsp; It was really strange.&nbsp; but after the upgrade it started behaving.</div>

<div>&nbsp;</div>
<div>Scott<br><br></div>
<div class="gmail_quote">On Feb 18, 2008 11:42 AM, Matthew Saskin &lt;<a href="mailto:matt@saskin.net">matt@saskin.net</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Just a guess - do a no mgcp/mgcp on the gateway itself. &nbsp;I&#39;ve seen this<br>happen frequently, but only for the entire range of numbers.<br>
<br>Also, have you run DNA within the cluster to make sure that particular<br>DN isn&#39;t being mis-routed somewhere?<br><br>-matt<br>
<div>
<div></div>
<div class="Wj3C7c"><br>Kienzle, John wrote:<br>&gt;<br>&gt; Hello. Although we have a TAC case open, I thought I would get some<br>&gt; opinions from this excellent resource.<br>&gt;<br>&gt; We have a CM 5.1.2.2000-3 cluster in our company. One of our sites was<br>
&gt; recently migrated from a standalone legacy CM 4.2 cluster to our new<br>&gt; corporate 5.x CM cluster. The only issue We have had was after a few<br>&gt; days, one of our phones stopped receiving calls. DID calls, local LAN<br>
&gt; calls by direct extension, calls over the WAN by direct extension -<br>&gt; all of them give a fast busy tone. The behavior is similar to an<br>&gt; unused or unassigned directory number. The phone registers to CM just<br>
&gt; fine and can place calls in/out of network just fine. We&#39;ve tried<br>&gt; completely removing the phone/DN from CM and adding it back again with<br>&gt; no luck. Also, if you assign the phone a different DN it works fine.<br>
&gt; Phone and line configuration has been verified. The problem definitely<br>&gt; follows the suspect DN. A debug ISDN q931 give the following when<br>&gt; calling the DN over our PRI:<br>&gt;<br>&gt; *Feb 12 13:44:57.810: ISDN Se0/3/1:23 Q931: RX &lt;- SETUP pd = 8<br>
&gt; callref = 0x0A1B<br>&gt;<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; Bearer Capability i = 0x8090A2<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Standard = CCITT<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Transfer Capability = Speech<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Transfer Mode = Circuit<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Transfer Rate = 64 kbit/s<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; Channel ID i = 0xA98386<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Exclusive, Channel 6<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; Calling Party Number i = 0x2181, &#39;sourcenumber&#39;<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Plan:ISDN, Type:National<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Called Party Number i = 0xC1, &#39; 5870 &#39;<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Plan:ISDN, Type:Subscriber(local)<br>&gt; *Feb 12 13:44:57.926: ISDN Se0/3/1:23 Q931: TX -&gt; CALL_PROC pd = 8<br>&gt; callref = 0x<br>&gt; 8A1B<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; Channel ID i = 0xA98386<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Exclusive, Channel 6<br>&gt; *Feb 12 13:44:57.926: ISDN Se0/3/1:23 Q931: TX -&gt; DISCONNECT pd = 8<br>&gt; callref = 0<br>&gt; x8A1B<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; Cause i = 0x8081 - Unallocated/unassigned number<br>
&gt; *Feb 12 13:44:58.006: ISDN Se0/3/1:23 Q931: RX &lt;- RELEASE pd = 8<br>&gt; callref = 0x0A<br>&gt; 1B<br>&gt; *Feb 12 13:44:58.082: ISDN Se0/3/1:23 Q931: TX -&gt; RELEASE_COMP pd = 8<br>&gt; callref =<br>&gt; &nbsp;0x8A1B<br>
&gt; *Feb 12 13:44:58.614: ISDN Se0/3/1:23 Q931: RX &lt;- SETUP pd = 8<br>&gt; callref = 0x0968<br>&gt;<br>&gt;<br>&gt;<br>&gt; John Kienzle<br>&gt; Senior ITS Analyst<br>&gt; Anadarko Petroleum/WGR<br>&gt; 1400 E. Lincoln<br>
&gt; Gillette, WY. 82716<br>&gt; WP - 307.685.5870<br>&gt; CP - 307.680.1746<br>&gt; <a href="mailto:John.Kienzle@anadarko.com">John.Kienzle@anadarko.com</a><br>&gt;<br>&gt;<br>&gt; * Anadarko Confidentiality Notice: This electronic transmission and<br>
&gt; any attached documents or other writings are intended only for the<br>&gt; person or entity to which it is addressed and may contain information<br>&gt; that is privileged, confidential or otherwise protected from<br>
&gt; disclosure. If you have received this communication in error, please<br>&gt; immediately notify sender by return e-mail and destroy the<br>&gt; communication. Any disclosure, copying, distribution or the taking of<br>
&gt; any action concerning the contents of this communication or any<br>&gt; attachments by anyone other than the named recipient is strictly<br></div></div>&gt; prohibited. *<br>&gt;<br>&gt; ------------------------------------------------------------------------<br>
&gt;<br>&gt; _______________________________________________<br>&gt; cisco-voip mailing list<br>&gt; <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>&gt; <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
&gt;<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>
</blockquote></div><br>