Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

VCS Control Loop detection and out of search resources


we have a problem within a customer de-centralized VCS Control environment. Meaning 4 different sites, where a VCS Control, Expressway and MCU are installed. In of the the sites (headquarter) two VCS Control are running as a cluster. Additional there is condcutor cluster at the headquarter site.

All condcutor based MCU calles arw working accross all four countries.

No the problem

Due to the redundancy concept, we are using configured on all VCS Control. By using we would have problem to allow endpoint to failover to another country... to make it short we are using the same SIP domain on all VCS Control. Headquarter to do have a neighbour zones to the three countries (star topology). The countries between each other do not have direkt neighbour zone, just one to the headquarter

Our search rules on all VCS Control do look like the following

- Search Rules to the conductor

- Search Rules from the condcutor to the MCU's

- Search rules for local zone searches

- Search Rule for non towards Expressway

- Searches toward the three country neighbour zone/s.

No to our problem

When we are searching within the neighbour zones by searching for the same SIP domain, we are creating a loop.

We have seen two calls instead of one at the headquarter VCS Control (call should be native SIP, but it was changes to H323) and wrong not included countries are involved. Meaning if calling from Australia to Singapore, for any reason USA VCS is also involved in the call.

Within a Cisco  ticket we have created a workaround by setting the neighbour zone hop count from 15 to 2, meaning the searches to the wrong countries are abbending quite fast and the call connects to the correct VCS Control.

To minimize the connection initiation time gap between the countries we have changed the neighbourzone search rules from different to the same priority. Everything works fine and fast. Meaning it's a kind of broadcast to all three neighbour zones and two of them are dying within two hop counts and the call will be connected at the correct site.

Than we faced a problem that call from an enpoint in one country to another county cannot correctly dropped. The calls are hanging on the VCS and/or the endpoint. An orphaned calls (0kbps no screen resolution) are hanging around on the endpoints (drop not possible) which do prevent endpoints to call this endpoint again.

For this we just talked to Cisco to test a fully meshed solution meaning creating the missing serachrules at the non-headquartert country sites to prevent the star topology creating other problem. It lookt quite good. Call from one country to another was initiated correctly, fast and only involved country VCS controls are used.

Than we faced a problem that conductor driven MCU calls do run into a problem, when the ful meshed neighbour zone design is active. Meaning we are getting a out of search resources (service unavailbale message, therefore we have disbaled the fully meshed neighbour zone within the countries (but we kept the star from the headquarter to the countries.

So seems to be this hop count reduction was good, even if we are producing some loop, but cut quite fast by the limited hop count and the call handling it quite ok, but we do not know why the calls are not dropped correctly or if using the full meshed solution, all call cuntry to yountry endpoint calls are working fine and condcutor calls are blaiming us.

CreatePlease to create content