10-05-2014 07:28 PM - edited 03-18-2019 03:29 AM
Hello all,
Is there a CPL rule that can be written to block calls originating from a neighbor zone destined to the same neighbor zone?
We are having issues with calls being sent from CUCM to our VCS, then VCS routes the call back to CUCM, thus resulting in "Too Many Hops".
In Example
Movi user on VCS Control tries to dial CTS endpoint registered to CUCM, but dials incorrectly
Call does not match search rules for local zone
Call does not match search rules for VCS Expressway
Call matches catch all for CUCM (.*)@domain.com
CUCM does not have a DN or URI for the mis-dialed number and the call gets routed back to VCS Control due to SIP route pattern of *.* on CUCM
We have to have the catch all to CUCM at the end since we offer PSTN connectivity, as well as our users and phones have alphanumeric URIs assigned to the DNs for Jabber, etc.
I'm afraid that there really isn't an easy way to do this, as I know since the call hits CPL first, CPL wouldn't know which zone it was destined to.
Solved! Go to Solution.
10-06-2014 09:00 PM
It's probably more easily accomomplished with a slight modification to your search rules rather than spraying anthing "@domain" everywhere - something like:
Direct anything incoming to @domain from the neighbour zone to the local zone (as it's inside your organisation, as if the CUCM hasn't found it and sent it to the VCS it's not going to be on the CUCM, so must be local (or non existant) - and Stop.
And the opposite of the above - Route anything for @domain from the localzone (as it hasn't been found locally) to the CUCM neighbour - and Stop.
And do similar for anything that's coming in from other external zones to route to wheverver the endpoints are going to be. That way, your call shouldn't be bouncing back and forth between the CUCM and VCS and creating the loop you're currently experiencing.
Of course, if your environmetn is a bit more complex than just the single CUCM and VCSes, this may be a little oversimiplified, but could lead you in the right direction.
Another thing to consider too - if you put your endpoints in to a directory the users can use - that'll help stopping them from mis-typing stuff :)
Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
Please remember to mark helpful responses and to set your question as answered if appropriate.
10-06-2014 09:00 PM
It's probably more easily accomomplished with a slight modification to your search rules rather than spraying anthing "@domain" everywhere - something like:
Direct anything incoming to @domain from the neighbour zone to the local zone (as it's inside your organisation, as if the CUCM hasn't found it and sent it to the VCS it's not going to be on the CUCM, so must be local (or non existant) - and Stop.
And the opposite of the above - Route anything for @domain from the localzone (as it hasn't been found locally) to the CUCM neighbour - and Stop.
And do similar for anything that's coming in from other external zones to route to wheverver the endpoints are going to be. That way, your call shouldn't be bouncing back and forth between the CUCM and VCS and creating the loop you're currently experiencing.
Of course, if your environmetn is a bit more complex than just the single CUCM and VCSes, this may be a little oversimiplified, but could lead you in the right direction.
Another thing to consider too - if you put your endpoints in to a directory the users can use - that'll help stopping them from mis-typing stuff :)
Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
Please remember to mark helpful responses and to set your question as answered if appropriate.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide