Dual VCS-C/VCS-E

[Dan Klanderman]

I have a customer who has deployed a VCS-C/VCS-E in one location and have now acquired a second pair for redundancy which will not be co-located.  The round-trip time between the two locations is greater than the alotted time for clustering.   Effectively they are looking to have the new pair in their other location as a backup.  Endpints all register to the C and just use the E for B2B.  Would appreciate any recommendations pros/cons on deployment. 

[Nick Halbert-Lillyman]

The VCS-E's should be OK - configure them with the same settings, zones and search rules etc.  On your VCS-C's, add the second VCS-E's IP in the zone profile.  Register a public SRV record that includes the second  VCS-E for inbound URI dialling.

Not sure about the VCS-C's however as if they aren't clustered, each VCS-C would not be aware of the other VCS-C's registrations.  You could probably do it with some fancy search rules but it wouldn't be pretty.

[Martin Koch]

If the delay is to big you should not cluster them.

But it should not be a problem to run independent VCS with apropirate search rules and srv records.

[Chris Swinney]

I have a query on this just as speculation - how would you get the client to fai over to VCS-C 2 if the normal VCS-C 1 fails without clustering? Would this be through using waited records in DNS or some other means?

[Nick Halbert-Lillyman]

You could have endpoint failover through SRV/DNS records, or for SIP endpoints you can put in multiple proxies (I think this is the preffered method).

With your search rules, I imagine you would need to use something like the following on both VCS's:

First rule: match local dialling rules, limit the source zone to the other VCS, target local zone, stop (this is to prevent searches bouncing between the VCS's endlessly)

Second rule: match local dialling rules, any source, target local zone, continue

Third rule: match local dialling rules, any source, target other VCS, stop