[cisco-voip] Call Routing (Loop)
lelio at uoguelph.ca
lelio at uoguelph.ca
Tue Jun 30 21:23:03 EDT 2009
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.
Lelio Fulgenzi, Senior Analyst
Computing & Communications
University of Guelph
519-824-4120 x56354
...sent from my iPod - please pardon my fat fingers ;)
[XKJ2000]
On 2009-06-30, at 7:46 PM, Daniel <dan.voip at danofive.id.au> wrote:
>
> We had a very similar issue to this, ended up being that CSS was
> configured wrong on our trunk to our gatekeeper.
>
> 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.
>
> 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.
>
> 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.
>
>
>
>
>
> On Wed, Jul 1, 2009 at 7:59 AM, Scott Voll <svoll.voip at gmail.com>
> wrote:
> 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.
>
> Scott
>
> On Tue, Jun 30, 2009 at 12:47 PM, <steve.siltman at assurant.com> wrote:
>
> Here is a couple of scenarios that I need help with.
>
> Scenario 1:
> 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?
>
> Scenario 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.
>
> Any suggestions or you've seen this before would be appreciated.
> Thanks!
>
> Steve Siltman
> Assurant Corporate Technology
> steve.siltman at assurant.com
> 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.
> Thank you.
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> 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/20090630/981d0a2b/attachment.html>
More information about the cisco-voip
mailing list