new CUBE breaks existing conference calls

[tato386]

We recently decide to setup a warm standby CUBE as a backup to our primary CUBE.  We used a copy of the existing CUBE config with everything identical expect the IP **bleep** of the new CUBE.  Very soon after the standby CUBE came online users reported that conference calls were failing.  We immediately suspected the new CUBE and shut it down to restore services.

So it seems that the new CUBE registered itself to the CM without an admin making any changes on the CM side?  Does this make sense or is there something else that caused this?

Thanks,

[Roger Kallberg]

If you can share the configuration of both your SBC (Cube) in separate text files we can help you better understand what is causing this.

[tato386]

attached is CUBE config.  The only difference is that is that Gig0/0/0 on each CUBE have different IPs.  The primary CUBE is .81 and the backup was configured with .89.

[Roger Kallberg]

Thank you! My suspicion was correct, you have a conference media resource in both that use the same name when registering the resource with CM. You need to use individual names for this part.

sccp ccm group 1
 associate profile 1 register CUBE-CONF

Change the bolded part in at least one of your routers, preferably in both to have a clear differential name between the two. If you change it in both you’ll need match the name in CM on the conference resource and also create a new resource with the name you put in the second router. Don’t forget to add the new resource to a suitable Media Resource Group, MRG in short, so that devices can use it.

[Roger Kallberg]

Apart from what I pointed out earlier you have not turned on the Cube functionality in the router. You’ll do that in the voice service voip section by this command mode border-element.

For more information on how to configure a SBC please see this document. Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards 

[tato386]

@Roger Kallberg your advice sounds solid, and I will definitely follow but here's what has me scratching my head on this one.  Analyzing the CM config two things stand out.

First is that the new CUBE was not defined on the CM, yet it appears it was able to register?  Assuming it did register is that normal for the CM to allow an undefined device to register with it? 

Second thing is that even if it did register (I never confirmed this because I quickly turned it off) I noticed that the only conference bridge in the one and only MRG is the CM built-in software bridge.  The legacy CUBE is indeed registered, but it is *not* in the MRG at all so it would seem that phones are using the CM bridge and should have no knowledge of any one of the two CUBEs.

Does that make sense?  Seems like I am missing something here.

[Roger Kallberg]

The CFB uses SCCP to register. This has no relevance to if the SBC is created as a SIP trunk in CM. These are two independent items. A media device that is in no MRG will be available for any device to use it. As that is quite often not wanted as you for the most want to control what media resources that are available to a device. For instance based on region.

[tato386]

Good info, thanks.

Is there a way to see what SCCP resources are registered on the CM?  Maybe some CLI command?

[Roger Kallberg]

Look under Media Resources menu. There are a number of different types of resources.

The types that are of interest is Conference Bridge, Media Termination Point and Transcoder. 

[tato386]

@Roger Kallberg , yes I am familiar with that screen but it seem to me that that screen only shows resources that have been defined by the CM admin.  That screen didn't show the new CUBE that registered with a duplicate name via SCCP.  I was looking for a way (maybe with CLI?) that could be used to show registered devices that have not been setup on CM.

Remember in my case I was aware that I had recently setup a CUBE so I suspected something to do with that guy right away but if I was having similar issues without any knowledge of new devices how could I get a definitive view of what media resources have registered with the CM?

[Roger Kallberg]

I think you are missing the point here. You have two devices that are configured to register a Conference Bridge with the same name. That is what is causing your problems. As they are setup to register the media resource with the same name you won’t see two devices in CM and the routers will contend for the registration. So you must change the name on at least one of them and create another CFB resource in CM. There is no such thing as resources registering without being defined in configuration in CM.

[Roger Kallberg · Accepted solution]

To make it super clear what I mean I took the part from one of my earlier replies and modified it and added screenshots from what you need to have in CM for the individual SBCs to register as a CFB.

*** On CUBC with IP .81 ***
sccp ccm group 1
 associate profile 1 register CUBE-CONF81

*** On CUBC with IP .89 ***
sccp ccm group 1
 associate profile 1 register CUBE-CONF89

[tato386]

gotcha. I'll reconfigure during maintenance window this weekend and post back with results.

[tato386]

both CUBEs online and working.  Thank you @Roger Kallberg