VG224 running SCCP, but CUCM Admin page shows MGCP

Unanswered Question
Apr 12th, 2010


We have a strange situation on a CUCM 6.1.3-1000 cluster. We have a VG224 which is running SCCP, but the CUCM Administration Web Page shows that the VG224 is running MGCP! Also if you look into the VG224 details, we don't have any Subunit selected, but we do have all 24 ports! If I look into the VG224 IOS configuration, we have everything in place for a SCCP VG224, so on that point everything's OK.

I tried to correct this error by deleting the VG224 in CUCM Admin Page, but now I can't add the new VG224 in CUCM Administration: I receive the next error: ""Add failed. One of the required fields on the page has the same value as an entry that already exists in the database. Please check the corresponding File List page to verify your entry does not exist." If you search for the device, you don't find it.

I've added the print screen of the error and search result in attach.

So it's impossible to add the same VG224 (which was deleted previous) running SCCP to CallManager. Workaround was to convert the VG224 to MGCP, but we need the SCCP SRST functionality.

Did somebody ran into this problem?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Aaron Harrison Tue, 04/13/2010 - 00:15


It sounds to me like you were looking at the wrong gateway - i.e. someone had added two, similar looking gateways one of each type.

Now you are trying to add it correctly, and it's already there are you deleted the bad one.

Post the config of the VG224, and we'll hopefully be able to help you find it in CCM.



Aaron Harrison Tue, 04/13/2010 - 02:49

Hi David

That VG224 is running MGCP.

If you do a 'show ccm-manager' on the VG224 CLI, you should see whether it's registered, and what name it is using to register. If it is registered, copy that MGCP domain name and paste it into the CCMAdmin gateway search page (just the hostname.domainnameifpresent portion) and you should find it.

If not, add a new MGCP gateway, and copy paste the hostname.domainnameifpresent portion from show ccm-manager into the name field.

If it still complains you have a duplicate, try running this command from the CCM publisher CLI:

Run sql select domainname,description,tkclass from mgcp where domainname like 'GOD%'

Post back the results...


david.vanherck Tue, 04/13/2010 - 04:34

Hi Aaron,

Yes, indeed, the VG224 is running MGCP now: yesterday I tried to remove the VG224 (which was running SCCP, but the CUCM Admin page showed MGCP; neither the Subunit was selected, but we have all 24 analog ports). I wasn't able to add the VG224 again for SCCP, so therefore I was forced to use MGCP, otherwise all analog devices were out of service.

I ran the SQL statement that you posted, but it failed. I ran the SQL statement "run sql select name from device". The output is attached.

Also I made a short list of a few GW's which are in CUCM. The file is called "GW's in CUCM.txt" and attached. In the file you can see the different kinds of GW's (MGCP & H.323 voice gateways | MGCP & SCCP analog voice gateways). All the voice gateways can be found in the output of the SQL statement and also the MGCP VG224 voice gateways can be found, but none of the SCCP VG224 analog voice gateways (in fact, no device starting with "SKIGW" can't be found). You can find the converted SCCP to MGCP analog voice gateway in the DB (called GODNDVA07Z01AA).

So we don't have the analog voice devices in the DB, but we can't add them in CUCM because it's in the DB... Strange!


P.S.: We still have 1 "strange" analog in service.

Aaron Harrison Tue, 04/13/2010 - 04:57


On my lab 6.1 system, my MGCP and SCCP gateways are both in a table called MGCP.

admin:run sql select * from mgcp where domainname like 'SKI%'

pkid domainname description scratch tkproduct fkcallmanagergroup xml versionstamp specialloadinformation tkdeviceprotocol tkclass resettoggle tkreset

==================================== =============== =============== ======= ========= ==================================== ================================================================================= =============================================== ====================== ================ ======= =========== =======

fa52a595-b3ec-1650-3cb8-197ee591303d SKIGWABCDAABACA SKIGWABCDAABACA 30038 d13c4201-7802-11d3-bdf0-00108302ead1 1246328097-8f391a20-4dfa-4c3f-80c4-6888b958f1a5 NULL 0 2 f 2

There's then a link table 'mgcpdevicemember' containing the link of devices in the mgcp table to the device table:

admin:run sql select * from mgcpdevicemember

pkid fkmgcp fkdevice slot subunit port

==================================== ==================================== ==================================== ==== ======= ====

2e41e1c5-ba85-4876-a652-832aa646acb5 fa52a595-b3ec-1650-3cb8-197ee591303d 89282eac-bf0d-c98f-ebe4-6375fae1e015 7 3 127

a44d7d4a-0c16-90f2-eb29-b86e0469772b fa52a595-b3ec-1650-3cb8-197ee591303d b0cf08d3-d7f0-5a7f-a359-7f22fd2d6610 2 0 0

What do you see in those tables as a result of those queries?


david.vanherck Tue, 04/13/2010 - 05:37

Hi Aaron,

Yes, I have result when running the SQL querie "run sql select * from mgcp where domainname like 'SKI%'":

pkid                                 domainname      description             scratch tkproduct fkcallmanagergroup                   xml versionstamp                         specialloadinformation tkdeviceprotocol tkclass resettoggle tkreset

==================================== =============== ======================= ======= ========= ==================================== === ==================================== ====================== ================ ======= =========== =======

88acf9d6-8530-42d6-a6b8-5ed3f2a9b362 SKIGW21D8452246 Analog Phone GW Godollo         30038     394c0e6c-7b3e-4072-b075-dba9769d6d4b     9d8e4ff9-5c64-4de2-9173-290100a150f2 NULL                   12               2       f           2      

You can see that the domainname SKIGW21D8452246 is in the result, which is the other analog VG224 running SCCP. I don't see the one that I've deleted (called SKIGW21D845223C), so don't get it why CUCM is complaining about duplicate entry...

In attach you'll have the result of both SQL statements that you asked.


Aaron Harrison Tue, 04/13/2010 - 05:52

Hi David

I'm a little stumped as well - it's definitely not there... I can only think that something is cached somewhere and has lost track... perhaps you are at the stage where you need to restart something?

I presume it allows you to add using a different MAC address? If so, perhaps you can add the VG224 using the MAC address from the fa0/1 port and repatch it to that port as a workaround?


david.vanherck Tue, 04/13/2010 - 06:21

Hi Aaron,

As you can see, it's a very strange behavior! I also tested it in our lab and also ended up with the same problem. A reboot didn't solve the thing, so the cache is not the problem.

Now we have the VG224 running MGCP as workaround, but we need the SRST functionality, so SCCP is mandatory. What you proposed is also a solution: plugging in the Fa0/1, but I don't have physical access to the VG224, so can't do that :-(

I contacted Cisco for a TAC case: I'm curious what the problem is & also the answer to this problem. I'll keep you in the loop!

And thanks for helping me out! I really appreciate it! I've learned a few things about the SQL, so it was helpfull for me! :-)


Aaron Harrison Tue, 04/13/2010 - 06:38

I’d be interested to see what TAC come up with..

Is your lab system a restored backup of your live system?

david.vanherck Tue, 04/13/2010 - 06:54

Yep, the lab is a reproduction of the customer's live environment, but less servers (1 Pub & 1 Sub/tftp, while the customer has 7 servers in production).

TAC case is opened: I'm curious what the result will be ;-)

david.vanherck Wed, 04/14/2010 - 08:01

Hi Aaron,

An update of my case: I needed to check the DB replication between the servers (which was successfull). Then I needed to check any route list associated with the gateway, but since it's a VG224, no route lists are associated.

Then I needed to check SQL (as you also told me), but the querie was "run sql SELECT description from MGCP": this gives a list of all voice gateways with Description as value, but even there I don't have my "strange" VG224.

Now I'm waiting for feedback of Cisco...

Tommer Catlin Wed, 04/14/2010 - 09:08

I had problems with 6.13 and SCCP vg224s.  I ended up upgrading to latest 6.14 and it resolved my issues. I think if you search the bug report with vg224 and 6.13, they will list them out.

Sounds like though its a database issue on CUCM, replication or something is "stuck"  To me, it looks like you have dbreplication issue.  

Aaron Harrison Wed, 04/14/2010 - 09:12

I thought about replication for a minute, but it's unusual for a replication issue to exhibit itself on the publisher...

Tommer Catlin Wed, 04/14/2010 - 09:15

You can run an import/export of the gateways. If you see it still in there, then you know its "stuck" in the database. Its just not showing on the GUI in "gateways"

david.vanherck Mon, 04/26/2010 - 09:31

Hi Aaron,

Last week, Cisco had root access to CUCM and they were able to insert the new VG224 into CUCM. So what you need to do is log a TAC case and ask Cisco to add the VG224 in the DB.



This Discussion