cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
116
Views
0
Helpful
2
Replies

CUCM 9.1 SU1 Directory Numbers

adamgibs7
Level 6
Level 6

Dears,

We are having a CUCM cluster 9.1 with  1 publisher and 3 subscribers,  recently we build a new branch and the users from the HO moved to branch, their phones have been configured according to the branch DID block, as they have recently moved some of the existing user in HO are still dialing their existing DN's instead of new branch DN's and then their phone's keep waiting for 3 to 4 minutes (hangs) and then back to normal,

Usually what i have seen always if a DN exist without a phone and any user dial the DN than the tut.... tut.... tut....beep sound is played and gets disconnects immediately, and if the DN is deleted completely from the call manager then the greeting plays " the number you have dialed doesn't not exist please check the number and dial again"" instead of getting expected phones are getting hanged for 4 minutes and then they coming back to normal , so i thought of deleting a particular DN which might be having a problem and then try to dial from another phone still it hangs then i again added the same particular DN and then i got the tut.... tut.... tut....beep sound.

My setup is as below In short to explain:

DN:111

PT-Internal -----111----->All phone in internal partition with landline & internal access only (without login)

PT-EM-----------111---when the user login (Device Profile) he will get the GSM access .

When a user ABC of corporates dials 111 IP phone which has been moved to branch DN XXX the user abc phone hangs

Anybody can give me hints why the phone's are hanging.

2 Replies 2

Jonathan Schulenberg
Hall of Fame
Hall of Fame

If a DN exists, is not associated to a single device, and the "Active" box is checked on it then the Call Forward Unregistered condition is matched. There is no "tut... tut... beep" sound in the Annunciator service.

The first thing I would check is to verify that the database replication is functioning properly. If the change hasn't replicated to the subscribers properly I would expect that there could be an internal SDL-related timeout within CUCM.

https://supportforums.cisco.com/document/52421/troubleshooting-cucm-database-replication-linux-appliance-model

If that doesn't get it try bouncing the CCM process to see if something is stuck in memory. Rare but it has happened. 

I agree with Jonathan about database replication specially if the remote office phones register with a different subscriber.