<div dir="ltr"><div>Hi Brian/Sreekanth, </div><div>thanks for the recommendation. </div><div><br></div><div>The managed service guys gotten the fix from TAC using </div><div>1) "no voice hunt unassigned-number" </div><div>2) "huntstop" on dial-peer level. </div><div><br></div><div>Previously when I was dealing with h323 or mgcp, this problem doesn't seems to be there?</div><div><br></div><div>Is it something new due to SIP gateway configuration? </div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 14, 2017 at 11:46 AM, Sreekanth <span dir="ltr"><<a href="mailto:sknth.n@gmail.com" target="_blank">sknth.n@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr">Have you tried the 'huntstop' command on DP 200 so that the IOS stops hunting for more dial-peers after matching DP 100 and DP 200?<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 14 August 2017 at 09:09, Brian Meade <span dir="ltr"><<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr">You can do things like "no voice hunt unassigned-number" and "no voice hunt invalid-number" on IOS to keep it from trying more dial-peers.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_106856513456336834h5">On Sun, Aug 13, 2017 at 10:47 PM, Ki Wi <span dir="ltr"><<a href="mailto:kiwi.voice@gmail.com" target="_blank">kiwi.voice@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div><div class="m_106856513456336834h5"><div dir="ltr"><div>Hi Group, </div><div>I have encountered this interesting problem on customer PBX. Didn't work on live system for a long time but I am pretty sure this shouldn't be a default behavior. </div><div><br></div><div>When external PSTN caller calls an unassigned number in the DID range, CUCM returns with error code 27 ( destination out of order). </div><div><br></div><div>This causes the voice gateway to retry other dial-peers. </div><div><br></div><div>There's 3 dial-peer which matches this e164 number.</div><div>1)Dial-peer 100 goes CUCM (longest match, most specific)</div><div>2)Dial-peer 200 goes CUCM (longest match, most specific)</div><div>3)Dial-peer 300 goes to PSTN (the destination-pattern is .T) </div><div><br></div><div>When dial-peer 100 and 200 "fails", the voice gateway will dial-out to PSTN via dial-peer 300. Once again, PSTN route back to the customer VG. This causes a routing loop and it can fills up all the available E1 channels quickly. </div><div><br></div><div><br></div><div><strong>Just wondering if anyone encounter the following issue and have a explanation to it? Just the engineering side of me want to get down to the root cause. </strong></div><div><br></div><div>The CUCM have "stop routing on unallocated number" turns off (false). Just in case it matters. </div><div><br></div><div>I tried to google around but can't seems to find any article that talks about </div><div>1) dial-peer behaviors (on voice gateway side) - on what error code will cisco voice gateway retry other dial-peers?</div><div>2) why CUCM returns error code 27?</div><div><br></div><div>It's a managed service system so I'm unable to do a deep dive troubleshooting. </div><div><br></div><div>The current workaround introduced is to create a dial-peer 250 with a higher preference that matches the DID range and block it. </div><div><br></div><div>This means that incoming dialed number will match to 4 dial-peers (100, 200, 250 and 300) </div><div><br></div><div>After failing on 100 and 200, the call gets block on dial-peer 250. </div><span class="m_106856513456336834m_8434475771765599498HOEnZb"><font color="#888888"><div><br>-- <br></div><div class="m_106856513456336834m_8434475771765599498m_4901106149497882774gmail_signature"><div dir="ltr"><div>Regards,</div><div>Ki Wi</div></div></div>
</font></span></div>
<br></div></div>______________________________<wbr>_________________<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" rel="noreferrer">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<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" rel="noreferrer">https://puck.nether.net/mailma<wbr>n/listinfo/cisco-voip</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div><div>Ki Wi</div></div></div>
</div></div>