<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Agreed. this is proper design. Any incoming device should not use a CSS
that contains a partition which contains a router pattern that points
back to the same gateway. This will prevent call routing loops.
Graphically:<br>
<br>
Incoming call via Gateway1 -> CSS -> Partition(s) -> Route
Pattern -> Route List -> Route Group -> Outgoing call via
Gateway1<br>
<br>
This is the most basic example. There are other examples involving call
forwarding and translations patterns. For those CM has built in
mechanisms to kill call routing loops. Only challenge here is the loop
has to get pretty bad before it can be detected and stopped.<br>
<br>
It is possible to look for call routing loops using CDR query. It is a
2 step process:<br>
1. identify times with high rate of calls per second. the
datetimeorigination field in cdr is in epoch time which conveniently
has granularity to the second so:<br>
<br>
select top 100 count(*) as cps, orignodeid, datetimeorigination,
DATEADD(ss, datetimeorigination, 'Dec 31, 1969 19:00:00') AS dts_EST<br>
from calldetailrecord<br>
where datetimeorigination>1173272400<br>
group by orignodeid, datetimeorigination<br>
order by cps desc<br>
<br>
You might choose to replace 1173272400 with a more recent epoch time.
Recall the CDRs are written using GMT timestamps.<br>
Any cps value over ~15 should raise suspicion.<br>
<br>
2. Once you have a specific datetimeorigination and orignodeid then:<br>
select
origdevicename,destdevicename,callingpartynumber,finalcalledpartynumber<br>
from calldetailrecord<br>
where <br>
datetimeorigination='<datetimeorigination>'<br>
and orignodeid = <nodeid><br>
<br>
substitute <datetimeorigination> for the specific value of
interest you found in the first query. Substitute <nodeid> for
the orignodeid from the same row of the first query.<br>
<br>
If the devicenames or numbers repeat 15 or more times in a second then
a very good chance of call routing loop. This also gives you the
numbers and devices that triggered the problem. You can investigate
the specifics of the situation to identify a more desirable behavior.<br>
<br>
Regards,<br>
Wes<br>
<br>
<br>
On Tuesday, June 30, 2009 9:23:03 PM, <a class="moz-txt-link-abbreviated" href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a> wrote:<br>
<blockquote cite="mid:0ADE6F4D-A216-487A-A89D-5E7B30BA0AF3@uoguelph.ca"
type="cite">
<div>Daniel has it spot on. The incoming calling search space of any
trunk/gateway/gatekeeper/etc should not include any partition that
contains any route pattern that would end up routing a call back to
itself.</div>
<div><br>
</div>
<div> <br>
<br>
Lelio Fulgenzi, <span class="Apple-style-span" style="">Senior Analyst</span>
<div><span class="Apple-style-span" style="">Computing &
Communications</span></div>
<div><span class="Apple-style-span" style="">University of Guelph</span></div>
<div><span class="Apple-style-span" style="">519-824-4120 x56354</span></div>
<div><span class="Apple-style-span" style=""><br>
</span></div>
<div><span class="Apple-style-span" style="">...sent from my iPod -
please pardon my fat fingers ;) </span></div>
<div><span class="Apple-style-span" style=""><br>
</span></div>
<div><span class="Apple-style-span" style="">[XKJ2000]</span></div>
</div>
<div><br>
On 2009-06-30, at 7:46 PM, Daniel <<a moz-do-not-send="true"
href="mailto:dan.voip@danofive.id.au">dan.voip@danofive.id.au</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div><br>
We had a very similar issue to this, ended up being that CSS was
configured wrong on our trunk to our gatekeeper.</div>
<div> </div>
<div>A call would come in from our external gateway or an internal
call, the externsion could not be found so the call would match the
catch all route pattern and go out the trunk to the gatekeeper. The
gatekeeper would have the correct zone prefixes and send the call back
to the same zone it came from. The inbound CSS of the gatekeeper trunk
had the wrong CSS configred which allowed calls to go back out to the
tieline which created a loop as call manager set the call back to the
gatekeeper and the gatekeeper sent the calls back to the same call
manager. </div>
<div> </div>
<div>I would advise to make sure that your gateways and gatekeepers
are only allowed to call internal extensions only, or at least the
gatekeeper so that itself is only allowed to call internal extensions.</div>
<div> </div>
<div>The call will still hit the gatekeeper once but when the call
comes back in from the gatekeeper to the call manager the call is
rejected, the extension can not be found and there is no partition in
the css that allows access to the route pattern for the trunk.</div>
<div> </div>
<div> </div>
<div> </div>
<div><br>
</div>
<div class="gmail_quote">On Wed, Jul 1, 2009 at 7:59 AM, Scott Voll
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">I
don't think I follow all of scenario 2 but as for #1 we had the same
thing with our old PBX and our CM. if the extension wasn't on either
system you would loop until all channels were in use or someone
disconnected. I think the only fix would be to have a RP with all the
extensions not in use forwarded to an AA. But every time you move an
extension over you will need to delete the RP extension. If you were
doing a trunk and not a channel based circuit to the other PBX you have
the ability to kill the system because it will keep looping until the
system can't take it any more.
<div><br>
</div>
<div>Scott<br>
<br>
<div class="gmail_quote">
<div>
<div class="h5">On Tue, Jun 30, 2009 at 12:47 PM, <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:steve.siltman@assurant.com">steve.siltman@assurant.com</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<div>
<div class="h5"><br>
<font face="sans-serif" size="2">Here is a couple of scenarios
that I need help with.</font> <br>
<br>
<font face="sans-serif" size="2">Scenario 1:</font> <br>
<font face="sans-serif" size="2">Cisco IP Phones and Avaya
phones mixed at the same location. MGCP router is the go-between. If
an extension is dialed and doesn't live on one system, it forwards the
call to the other system. This works great. What if the extension
doesn't live on either system? I was taking a trace from Call Manager,
on a different issue, and noticed a problem that looks like a call is
doing the above. Without adding specific route patterns and continuing
to use a large 1XXXX pattern to send calls across to Avaya when they
don't exist on Call Manager, can I limit this route loop or stop it
from happening somehow?</font> <br>
<br>
<font face="sans-serif" size="2">Scenario 2:</font> <br>
<font face="sans-serif" size="2">This one has me perplexed
because I'm not sure why I didn't notice this long ago or how it
continues to loop. The call comes into a remote H.323 gateway and the
DNIS is translated into a DN that lives on Call Manager. The dial-peer
looks up the DN on Call Manager but it doesn't exist. *sigh* We have a
route pattern configured to point all those extensions towards the
remote H.323 gateway. I believe the first office was setup this way
and its been copied for each additional remote office install. We now
have 20 offices that have a route pattern pointing the Internal DN
range back out to the remote H.323 gateway where the phones live
physically. I believe the resolution to this is to remove these
internal DN range route patterns. Call Manager already knows them and
doesn't need this route pattern. Correct? I still don't understand
how this could be looping but it must be looping within the Call
Managers. I turned on ISDN Q931 and VOIP DIALPEER debugs on the router
and saw the call come in and hit the dial-peer to Call Manager. Thats
all I saw on the router but yet the Call Manager had 250 trace files,
each 1 meg in size and rolled after 9 minutes. Digit analysis shows
the called number and the extension, that doesn't exist, over and over
and over in just under 1 second intervals. I'm pretty sure removing
this internal DN range route pattern will resolve this but I'd like to
know how its looping.</font> <br>
<br>
<font face="sans-serif" size="2">Any suggestions or you've seen
this before would be appreciated. Thanks!</font> <br>
<font face="sans-serif" size="2"><br>
Steve Siltman<br>
Assurant Corporate Technology<br>
<a moz-do-not-send="true"
href="mailto:steve.siltman@assurant.com">steve.siltman@assurant.com</a></font>
<hr>
This e-mail message and all attachments transmitted with it may contain
legally privileged and/or confidential information intended solely for
the use of the addressee(s). If the reader of this message is not the
intended recipient, you are hereby notified that any reading,
dissemination, distribution, copying, forwarding or other use of this
message or its attachments is strictly prohibited. If you have received
this message in error, please notify the sender immediately and delete
this message and all copies and backups thereof.
<p>Thank you.<br>
</p>
<hr>
<br>
</div>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a moz-do-not-send="true"
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a moz-do-not-send="true" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>cisco-voip mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a></span><br>
<span><a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br>
</div>
</blockquote>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
<br>
</body>
</html>