Cisco Call manager, BE 6000 M6 and UCS-C220-M4 Integration requirement

[Shakespeare]

#Team #Cisco #Community

I need information if Cisco Call manager BE 6000 M6 running with V12.5 can be integrated with UCS-C220-M4 running with V11.5?

Can I assign BE 6000 M6 running with  V12.5 in an existing cluster as a subscriber Node, where there are already One Publisher node and another subscriber node exists in UCS-C220-M4 running with V11.5?

Thanks

[Roger Kallberg · Accepted solution]

If I understand correctly you’re asking if a CM 12.5 subscriber can be part of a cluster that runs CM 11.5. If so no that’s not possible.

[Shakespeare]

@Roger Kallberg 

Thanks a lot Roger, the problem is, I already got numbers of subscribers (Phones etc.) in an existing cluster that runs with CM 11.5.

There will be a new additional CM 12.5 with new server 6000 M6 plus new phones etc. onto it

So, without adding the new server into the existing cluster, how I can establish the communication between these two?

Thanks in advance. 

[Les Pruden]

The easiest way to set up communication between the two clusters would be via a SIP trunk. Build a SIP trunk between the two Call Managers and configure Route patterns / Route lists / Route groups that allow internal calling. If you do not have directory number overlaps this should be fairly simple to set up. 

An alternate solution would be to install a V11.5 subscriber off that cluster on the M6. Clustering over the WAN is an accepted design and works well. The installation is fairly straight forward - assuming you don't have firewalls between the two systems.

Cisco Collaboration System 12.x Solution Reference Network Designs (SRND) - Collaboration Deployment Models [Cisco Unified Communications Manager (CallManager)] - Cisco

[Roger Kallberg]

With a inter cluster trunk (SIP) between the two clusters.

[Vaijanath Sonvane]

Hi @Shakespeare,

In this case you have two options:

1. If you are looking to keep same cluster for all the phones (old and new) then build new CUCM subscriber on BE6000 M6 with version 11.5 and add it to the existing CUCM cluster. 

2. If you want to keep separate clusters for phones, then build new CUCM Publisher and Subscriber on BE6000 M6 with version 12.5. To establish communication between 11.5 and 12.5 CUCM cluster, create an Intercluster SIP Trunk between them. 

[Shakespeare]

Hi @

Hi  Vaijanath Sonvane,

Thanks for the suggestion. If I follow option 2:  With new CUCM Publisher and Subscriber on BE6000 and create a SIP trunk to existing Cluster would it guarantee me the redundancy?

The new CUCM will be built in one physical server and the existing CUCM has two redundant server. While adding these two in a SIP trunk it will ensure the voice communication in between but in case of new CUCM fails will the existing server (in redundant configuration) can handle the call control and call routing for the subscriber added to the failed CUCM?

Please give your suggestions.

Thanks 

Preview

[Jaime Valencia]

Bear in mind that adding subs to a BE 6K solution does not increase the amount of supported devices or users, the only purpose of adding subs to the solution is for redundancy.

[Shakespeare]

Hi Jaime,

In this case, I have one server (1 physical server) with BE 6K with all new subscribers, on the other hand there is an existing redundant server (2 physical server) running on UCS-C220-M4 . Now with a SIP trunk in between call call control and call routing can be achieved, but in case of the new BE6K server fails is the UCS-C220-M4 will act as a redundant server? can it manage and route the calls from telephone/subscriber added in the new BE 6K?

Or I need to upgrade UCS-C220-M4 (both the physical server) to BE 6K and then add the new server as a subscriber node, then only they will act as a redundant node? 

Your suggestions are highly appreciated.

Thanks in advance.

[Jaime Valencia]

Call control redundancy is only possible when all servers are part of the same cluster.

[Shakespeare]

Hi Jaime,

By creating a inter cluster SIP trunk between two different cluster (11.5 and 12.5) can I achieve call controlling, call forwarding  in case one cluster is down? 

Thanks 

[Roger Kallberg]

If one of the clusters is down there is nothing that can handle the call forwarding. So no you cannot do that.