Can you still access the URL of the DN itself? E.g.: ccmadmin/directoryNumberEdit.do?key=78b66301-8b01-db7e-647d-115e1c83c0ca&mapkey=154bc658-7df6-d5b6-61b5-3b23ec0aff38&devicekey=880f529d-78fd-a555-0481-87ed38442a48&index=1 If you do not delete the DN but replace it with a new one, can the old one be found under 'Unassigned DNs'? I think what happens is per design because the phones (as opposed to the UDPs) are not complete removed. When a DN is tied to a UDP only and the UDP itself is deleted you get a 'floating' DN, belonging to no other entity. When after deletion of the UDP you open the DN on the phone and hit 'delete' you're accually removing the DN as a whole. When reversing the process (starting at the phone and working your way down to the UDP) I think you will find the DN under unassigned DNs. ... View more

Can you see the numbers in the 'Route Plan report' (under Call Routing). Is there a specific reason the DNs are associated with both a UDP and a phone? (as opposed to one of them) ... View more

Device Mobility (as opposed to 'Mobility/Single Number Reach') does not require more licenses. So if I understand correctly your users deny that they have moved the phone but CM-administration proves otherwise? Assuming that you can identify a phone based on the voice vlan given to it you can filter on the IP using to register. Going one step further is using Device Mobility to disable calling for these phones.\ By saying 'they deny where the phone location of the phone' you indeed mean that phones get lost/stolen and you want those stolen phones to be unable to be used in another part of the building? ... View more

If the phones can be identified based on their IP-address you could implement Device Mobilty. Using this functionality you could force the phones into a specific Device Pool. By restricting this DP using CAC (via location) you could identify them and still restrict their calls. What is the original problem here? Are the phones stolen during movement? ... View more

I'm assuming you're trying to access Offnet destinations. The best way to go here (if you can edit both resources) is configure both the CUCM and AD with a universal numberingplan. In most cases the +E164 format is used here. Short version is you configure every valid PSTN number in +E164 format (eg +1 702 555 1234) and configure a \+! RP to access the PSTN. Big watchout here is impact on your CoS scheme. More info can be found in the SRND (http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/dialplan.html#wp1154092) or at INE (http://blog.ine.com/2009/12/07/building-global-dial-plans-in-cucm7-part-i-globalization/) ... View more

Hello Joao, You should use the backup of your current cluster and restore it to the new cluster. This process works only if the new installation has the (exact) same version CUCM installed as the backupset you're restoring to it. You would need to install the 7.1 release on your new UCS cluster first and then do an upgrade. http://www.cisco.com/en/US/customer/docs/voice_ip_comm/cucm/install/8_6_1/cluster/clstr861.html#wp87714 Also take note of the files not being restored in this process. You might have to have them in place before doing a restore (custom backgrounds and localization for example). You'll have to have new licenses in place as well. ... View more

Considering the handling by default session application; I am quite sure there is a different in this since 12.4(11)XW /cme4.2 and BACD 2.1.2.2. With CME4.0 you couldn't see the name of the phone that was ringing if you called BACD. In cme4.2 it does, the same like when calling a normal hunt-group. The display is updated every time a call switches over to the next hop. http://www.cisco.com/en/US/docs/ios/voice/tcl/developer/guide/tclivrv2_ch3.html#wp1076619 ... View more

Is the reason why it is difficult to make an outgoing TCL/IVR because you can't handle over to some default session app? I was just coming to the idea of an outgoing version of the script as it is. That way a caller would see the same of the called person in his screen while establishing an outgoing call. Also I am thinking of something like an 'external bulk speeddial list' by which TCL would send http query with the speeddial (eg *9123) and then return both the name and E164 number of the destination and establishing the call. Your note about difficult outgoing TCL/IVR however makes me consider.. ... View more

nice work! Name however doesn't seem to survive a transfer? (doesn't show up in the screen of phone to which call is transfered?) ... View more

The following url should do the job: http://dev.vannoorloos.net/num2name/lookup.php?ani=$ani username: user password: password Just let me know ... View more

also check sip-gateway in CLI config of CUE.. Should CUE be accessable from both routers? Or just from CCME? Refraised; is CUE-router also VOIP-enabled besides the dialpeer to CUE? ... View more

I do not understand what you mean with 'if you managed to have working for outgoing, let us know how you did' I only have it working on incoming DP, the name shows up in the display so lookup works. While I was tranfering an incoming ('looked-up') call to check if the DisplayInfo(name) was kept, I noticed that while completing the tranfers, the originating call is disconnected. However, because I can not see the script running (sh call appl sess), I was assuming that you, after running the script, handled over to the default sess application. Can you tranfer an incoming 'looked up' call? ... View more