[cisco-voip] Call Routing (Loop)

[Daniel]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090701/642ef8f7/attachment.html>