If you can’t click save on any of your IP Phone Device pages in CUCM 7.1.5, then you have probably hit a bug causing missing XML information.
To Resolve this
- SSH to your Publisher
- Execute the command “run loadxml”
Note: This is a pretty intensive command so it should be run at a time of low load on your CUCM cluster.
I recently upgraded a clients CUCM 6.1(2) to 6.1(4) and then up to 8.5(1). The upgrade went mostly smoothly however after the upgrade users complained that there directories menu looked like this:
1 – Missed Calls
2 – Received Calls
3 – Placed Calls
4 – Missed Calls
5 – Received Calls
6 – Placed Calls
7 – Personal Directory
8 – Corporate Directory
Weird Huh! This client uses a lot of multiple line presentations on their phones which made me think that maybe it was a new feature and each DN had its own directory menu. A quick test in the lab proved this hunch was wrong.
It turns out that on 6.1(x) upgrades to 8.5(1) it is quite common for the ITL file to get out of whack and cause weird behaviour on the handsets. To rectify this issue I had to re-generate the ITL files.
To do this I followed the following steps on each of the TFTP servers:
- Log into Cisco Unified OS Administration
- Security > Certificate Management
- Click Find
- Click on CallManager.pem
- Click Regenerate in the top left corner
- Log into Cisco Unified Servicability
- Tools > Control Centre – Network Services
- Select your TFTP Server
- Restart the Cisco Trust Verification Service
- Tools > Control Centre – Feature Services
- Select your TFTP Server
- Restart the Cisco TFTP Service
Repeat this on each of your TFTP servers and then restart your phones.
We recently had a client with a branch office that they wished to expand with 3x VG224 Analogue gateways. Unfortunately they were only running a 2811 ISR router which is limited to 36 ephones in SRST. Whilst VG224 ports consume no DLU’s in CUCM from a licensing perspective each VG224 ports is a seperate SCCP registration when failed over into SRST. To avoid forcing them to upgrade their existing SRST router we looked at solutions that could provide survivability whilst still being easy to manage maintain.
Option One : Configure the VG224 as H.323
This is a perfectly valid solution and will probably fit most peoples requirements. We chose not to do this for the following reasons:
- Their existing 2811 voice gateway was already configured up with MGCP and was running perfectly fine. They have consistently deployed this type of gateway across the organisation. Using H.323 for the VG224’s would require converting the voice gateway to H.323 also and break standards.
- It doesn’t provide the ability to monitor analogue ports from a central configuration database (Cisco Unified Communications Manager)
Option Two : Configure the VG224 as an MGCP gateway with fallback to H.323
This was the option we decided to go for as it provided centralised management, ability to failover without using SRST SCCP registrations and maintained configuration autonomy.
Key configuration points are outlined below:
1. Configure the gateway for MGCP as per usual:
no ccm-manager fax protocol cisco
ccm-manager config server x.x.x.x y.y.y.y
2. Configure your VG224 gateway for MGCP in CUCM. You can confirm this is working when you have the CCM successfully configuring the gateway:
|%CMAPP-6-CONFIG_DONE: Configuration by CCM is doneVG224# sh run | i mgcp
mgcp call-agent y.y.y.y 2427 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode out-of-band
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp package-capability sst-package
no mgcp package-capability res-package
no mgcp package-capability fxr-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp fax t38 inhibit
mgcp rtp payload-type g726r16 static
mgcp profile default
You can can also confirm it is working with the following :
MGCP Domain Name: VG224
Priority Status Host
Primary Registered y.y.y.y
First Backup Backup Ready x.x.x.x
Second Backup NoneCurrent active Call Manager: y.y.y.y
Backhaul/Redundant link port: 2428
Failover Interval: 30 seconds
Keepalive Interval: 15 seconds
Last keepalive sent: 16:07:55 WAST Jul 11 2011 (elapsed time: 00:00:12)
Last MGCP traffic time: 16:07:55 WAST Jul 11 2011 (elapsed time: 00:00:12)
Last failover time: 14:54:19 WAST Jul 11 2011 from (10.24.0.241)
Last switchback time: 14:54:49 WAST Jul 11 2011 from (10.24.0.240)
Switchback mode: Graceful
MGCP Fallback mode: Enabled/OFF
Last MGCP Fallback start time: 14:54:52 WAST Jul 11 2011
Last MGCP Fallback end time: 14:55:10 WAST Jul 11 2011
MGCP Download Tones: Disabled
TFTP retry count to shut Ports: 2Configuration Auto-Download Information
Current version-id: 1306736658-af125081-aa59-4451-b342-2c7091b18cc9
Current state: Waiting for commands
Configuration Download statistics:
Download Attempted : 31
Download Successful : 31
Download Failed : 0
Configuration Attempted : 3
Configuration Successful : 3
Configuration Failed(Parsing): 1
Configuration Failed(config) : 0
Last config download command: New Registration
FAX mode: disable
Configuration Error History:
3. Configure the VG224 for Fallback Mode as per usual:
service alternate Default
4. Configure your VG224 ports in CUCM and on the VG224:
timeouts ringing infinity
timing digit 50
timing inter-digit 50
dial-peer voice 500 pots
5. Configure your dial-peers as required pointing them at the SRST gateway:
|dial-peer voice 900 voip
session target ipv4:184.108.40.206
6. Now on your SRST gateway you must configure appropriate H.323 dial-peers for routing the extension ranges to the VG224’s for when it is in mgcp-fallback:
|dial-peer voice 123 voip
description Send to VG224
session target ipv4:220.127.116.11
This solution will provide MGCP registration back to your CUCM for both your SRST Voice Gateway and VG224 when in service but allow for fallback to H.323 in a WAN failure scenarios. All IP handsets can still register SRST via SCCP to your gateway in WAN failure.
Caveats & Points of Interest
- Supplementary Services are only available for the VG224 when they are registered via SCCP. Things like Audible Message Waiting Indicators, Call Transfer, Call Waiting, Distincitve Ring, Feature Access Codes and Speed Dial will not work when the ports are MGCP registered.
- Because we are using this to provide fallback as well any changes to DN on the CUCM would still require updating of the destination-pattern under the pots dial-peer for that port.
On an ASA you can test AAA Authentication from the command-line with the following syntax:
|test aaa-server [authentication|authorization] <aaa_server_group> [host <name>|<host_ip>] username <user> password <pass>
|test aaa-server authentication AAAGroup username adminuser password ThisIsAWeakPassword
As of IOS 12.4(23)T you no longer need to rely on a “reload in” command to save you from potentially locking yourself out of a remotely managed router.
You can enter configure mode with “config terminal revert time x” and IOS will save the running configuration to a backup file on flash to revert to after x minutes.
When your changes are successful and you want to cancel the revert you simply exit configuration mode and feed the router “config confirm” to commit your changes persistently. Though obviously you will still need to write your running configuration to NVRAM as per usual!
What is the advantage of this? Well for one you don’t have to wait for the router to reload to get access again and secondly any other services this router is providing eg Voice gateway, transcoding etc will be unaffected.
Lets take a look at how this behaves on the CLI:
Enable Configuration archiving
Enter Configure mode with a reversion timer
|Router#conf terminal revert timer 2
Rollback Confirmed Change: Backing up current running config to flash:backups-0
Enter configuration commands, one per line. End with CNTL/Z.
*Apr 11 02:38:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_BACKUP: Backing up current running config to flash:backups-0
*Apr 11 02:38:30.5711: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_START_ABSTIMER: User: console: Scheduled to rollback to config flash:backups-0 in 2 minutes
Make a configuration change
Take note of reversion warnings
|*Apr 11 02:39:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_WARNING_ABSTIMER: System will rollback to config flash:backups-0 in one minute. Enter “configure confirm” if you wish to keep what you’ve configured
Reversion takes place
|Rollback Confirmed Change: rolling to:flash:backups-0
Total number of passes: 1
*Apr 11 02:40:30.571: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_ROLLBACK_START: Start rolling to: flash:backups-0
*Apr 11 02:40:30.575: Rollback:Acquired Configuration lock.
*Apr 11 02:40:33.091: %PARSER-6-EXPOSEDLOCKRELEASED: Exclusive configuration lock released from terminal ‘0’ -Process= “Policy Manager”, ipl= 0, pid= 21
Alternatively Commit your changes
*Apr 11 02:46:08.615: %SYS-5-CONFIG_I: Configured from console by consoleonf
*Apr 11 02:46:10.899: %ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_CONFIRM: User: console: Confirm the configuration change
RevertMe#copy running-config startup-config
You want your MGCP controlled E1/T1 to present a single outbound CLI for a group of DN’s that is different from their individual DID’s. You also want all other DN’s to present as normal.
- You could hardset the Caller ID DN field on the E1 under “Call Routing Information – Outbound Calls” – This will overwrite all DN’s not just the ones you want
- You could adjust the “External Phone Number Mask” on the DN. – This works but it will also change the phone display and can have AAR Implications
- You could duplicate your dialplan in a seperate partition with new CSS’s and Route lists. Overwrite the CLI at the Route List – This is just yuck and doesn’t scale
Transformation Patterns to the Rescue! A Transformation Pattern will allow you to adjust the Calling Party number when it hits the gateway conditionally based on the original internal calling party number.
- Create a Partition called CLIRewrite
- Create a CSS called CLIRewrite that looks at Partition CLIRewrite
- Configure your MGCP Gateway:
- Device > Gateway
- Select your Gateway
- Select your E1/T1 Interface
- Under “Call Routing Information – Outbound Calls Uncheck “Use Device Pool Calling Party Transformation CSS”
- Choose “CLIRewrite” in Calling Party Transformation CSS Combo Box
- Create your Transformation Mask:
- Call Routing > Transformation Pattern > Calling Party Transformation Pattern
- Click Add New
- Under Pattern enter the internal DN you wish to rewrite (Pattern matches like 28XX also work for matching multiple DN’s)
- Under Calling Party Transformation Mask enter the full number you wish to present out your E1
- Reset your MGCP gateway under Devices>Gateways
- I also had to do a “no mgcp” and then “mgcp” on the gateway itself
- Make a test call to your mobile phone to see the re-written number
Use the Following config to configure your 827 into Bridge Mode :
no service single-slot-reload-enable
no service pad
service timestamps debug uptime
service timestamps log uptime
logging rate-limit console 10 except errors
no ip finger
no ip dhcp-client network-discovery
no ip address
no ip address
no ip mroute-cache
no atm ilmi-keepalive
protocol ip inarp
dsl operating-mode itu-dmt
no ip http server
bridge 1 protocol ieee
line con 0
transport input none
line vty 0 4
scheduler max-task-time 5000
So you want to access the CLI huh?
Well it can be accessed through the web interface by appending /exec to the URL.
When authenticating l2tp-ipsec users against the local database on an ASA, you must use the mschap keyword when creating the user accounts:
username l2tp password secret mschap
I have been involved with a CUWN deployment using 1252 AP’s in a healthcare environment. Several of the Access-points were making buzzing noises whilst operating but for all intents and purposes were functioning ok.
I knew these units probably needed to be replaced but I hadn’t had the time to report the issue to TAC and get a replacement.
Well apparently I’m not alone. Jeremy at ciscoblog.com has mentioned the same issue showing up in a TAC Field notice. There is even a web tool for checking your serial numbers if they are affected.
The Field notice mentions issues with radio communication whilst buzzing, however I haven’t experienced these issues.