MeetMe conferencing with Call Manager Express allows a CME phone to go off hook, press the MeetMe softkey, and dial the MeetMe bridge number to start a conference. Any other CME subscriber or off-net party may dial the MeetMe number to join the conference.  By default CME does not play tones when participants join or leave the bridge. Adding this capability requires the creation of a voice class for both the join tones and leave tones where tone frequencies are defined and then later referenced in the dspfarm profile.  In order to perform the following configuration you should already have hardware conferencing configured on CME.  Reference this post for assistance.

1. Configure a number to be a MeetMe Conference Bridge

ephone-dn  10  octo-line
number 4454 no-reg primary
conference meetme

2. Configure an ephone template that includes the MeetMe Softkey. This is so CME subscribers can easily start a conference.

ephone-template  1
softkeys remote-in-use  CBarge Newcall
softkeys seized  Redial Endcall Meetme Pickup Gpickup Cfwdall Callback
softkeys connected  Hold Endcall LiveRcd Park Trnsfer Confrn

ephone  1
privacy-button
mac-address 0022.90BA.2CC0
ephone-template 1
busy-trigger-per-button 4
button  1:1 2:2

3. Configure the appropriate voice class to define Join/Leave tones

voice class custom-cptone conf-leave
dualtone conference
frequency 300 900
cadence 300 150 300 100 300 50

voice class custom-cptone conf-join
dualtone conference
frequency 600 900
cadence 300 150 300 100 300 50

4. Assign each voice class to the dspfarm profile used for conferencing

dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
maximum sessions 2
conference-join custom-cptone conf-join
conference-leave custom-cptone conf-leave

associate application SCCP

Configure 802.3ad Link Aggregation for Broadworks

Posted: 13th July 2010 by Mark in Cisco

The Broadsoft Software Management Guide provides an example for configuring active/backup Ethernet interfaces (called mode 1) when configuring bonded Ethernet on a single Red Hat Enterprise server.  Only one Ethernet interface is transmitting and receiving traffic at a time while the other interface is in standby mode.  My preferred approach is 802.3ad Link Aggregation Control Protocol (LACP). LACP creates aggregation groups that share the same speed and duplex settings across Ethernet interfaces on a server. It utilizes all slaves in the active aggregate according to the 802.3ad specification.  802.3ad requires an Ethernet switch that is capable of supporting LACP.

## Red Hat Enterprise Linux ##

#vi /etc/modprobe.conf
alias eth0
alias eth1
alias bond0 bonding
options bonding miimon=50 mode=4   (note: miimon = frequency in milliseconds to monitor interfaces)

==AS1==
#vi /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=as1
NETWORKDELAY=25

#cd /etc/sysconfig/network-scripts
#vi ifcfg-bond0
DEVICE=bond0
BOOTPROTO=static
ONBOOT=yes
USERCTL=no
BROADCAST=192.168.126.255
IPADDR=192.168.126.145
NETMASK=255.255.255.0
NETWORK=192.168.126.0
GATEWAY=192.168.126.1

#vi ifcfg-eth0
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

#vi ifcfg-eth1
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

## Cisco Switch ##

interface Port-channel30
description Port-Channel to as1
switchport
switchport access vlan 12
switchport mode access
spanning-tree portfast

interface GigabitEthernet3/24
description [as1] IBM x3650 m2 – eth0
switchport access vlan 12
switchport mode access
spanning-tree portfast
channel-group 130 mode active

interface GigabitEthernet6/24
description [as1] IBM x3650 m2 – eth1
switchport access vlan 12
switchport mode access
spanning-tree portfast
channel-group 130 mode active

The only reason I can foresee Broadsoft not providing this approach in the Software Management Guide is due to the requirement of an Ethernet switch capable of supporting LACP and the associated configuration.  Using active/standby “mode 1″ bonding does not require any additional configuration beyond RHEL, so while it is more convenient and simplistic, this configuration does not fully maximize the capability of the servers.  This can be especially useful for the Media Servers, Conference Servers, or the Application Servers where Broadworks log files or Radius CDR’s are being offloaded to a separate server.

When configuring a SIP Trunk with Unified Communications Manager to a SIP Service Provider there is a need to use a router running CUBE (Cisco Unified Border Element) between UCM and the provider offering the SIP Trunk.  One benefit is this automatically alleviates the challenges most IP PBX’s face with hosted nat traversal specific to SIP and RTP.  However, an even greater benefit is the power and flexibility that CUBE provides with its ability to modify SIP headers much like the larger and more costly Session Border Controllers used by SIP Service Providers.

In this case the modification is for SIP Diversion. By default, when UCM forwards a call to another number over the SIP Trunk it sends the internal DN as the number performing the redirect. This is a problem when forwarding calls back to the PSTN as the provider expects 10 digits instead of 4 (or whatever the internal dial plan may be).  An easy solution to this problem is using a SIP Profile with CUBE and replacing the 4 digit number with the 10 digit Pilot Number (this is same number in your sip-ua portion of the router config).

When CUBE is set to “allow sip to sip” it is possible to reference a SIP Profile that will modify a particular SIP message (or messages) traversing through the router. In this example it’s any SIP signaling message that contains a SIP header called Diversion.  The goal is to change 9948 (the 4 digit DN) to the full 10 digit phone number 9494289948 otherwise the SIP provider will reject a redirected call with only 4 digits in the user portion of the SIP URI in the Diversion header.

Below is the SIP Invite in its entirety as originated by UCM and sent towards the Cisco router running CUBE where the original Diversion header only contains the 4 digit DN. The call flow is a PSTN call originated from 4802317040 to a number on UCM 9494289948 and the UCM number forwards back to PSTN 7023100500. Below is the forwarding part of the call-flow back to CUBE/PSTN.

*Oct 14 00:25:06.327: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:17023100500@192.168.1.1:5060 SIP/2.0
Date: Sat, 10 Jul 2010 20:09:26 GMT
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: “HOLLOWAY MARK  ” <sip:4802317040@192.168.1.254>;tag=9fc21ef0-b4f8-4240-a30e-86b6cfa8e8f7-27463414
Allow-Events: presence
P-Asserted-Identity: “HOLLOWAY MARK  ” <sip:4802317040@192.168.1.254>
Supported: timer,resource-priority,replaces
Supported: Geolocation
Min-SE:  1800
Diversion: “9948″ <sip:9948@192.168.1.254>;reason=unconditional;privacy=off;screen=yes
Remote-Party-ID: “HOLLOWAY MARK  ” <sip:4802317044@192.168.1.254>;party=calling;screen=yes;privacy=off
Content-Length: 214
User-Agent: Cisco-CUCM7.1
To: <sip:17023100500@192.168.1.1>
Contact: <sip:4802317040@192.168.1.254:5060>
Expires: 180
Content-Type: application/sdp
Call-ID: 8aa2480-c381d376-c6-fe01a8c0@192.168.1.254
Via: SIP/2.0/UDP 192.168.1.254:5060;branch=z9hG4bK1b172bdcdc9
CSeq: 101 INVITE
Session-Expires:  1800
Max-Forwards: 7

The following CUBE configuration modifies the User portion of the SIP URI to replace 9948 with 9494289948 which is our valid 10 digit number the Service Provider is expecting.

voice service voip
allow-connections sip to sip
sip
sip-profiles 1

voice class sip-profiles 1
request INVITE sip-header Diversion modify “<sip:(.*)@(.*)>” “<sip:4804101040@voip.markholloway.net”

The characters  .*@.* in the first set of the expression identify all characters in the original Diversion header coming from UCM and the second set identifies what the first set will be replaced with.

This is the new SIP Invite modified by CUBE in its entirety as it leaves CUBE and goes towards the SIP Service Provider.

*Oct 14 00:25:06.355: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:17023100500@voip.markholloway.net:5060 SIP/2.0
Via: SIP/2.0/UDP 174.26.121.21:5060;branch=z9hG4bK81718
From: “HOLLOWAY MARK  ” <sip:4802317040@voip.markholloway.net>;tag=2C06BC-1C60
To: <sip:17023100500@voip.markholloway.net>
Date: Wed, 14 Oct 2009 00:25:06 GMT
Call-ID: DB7F2DFB-B78E11DE-801FA01B-F10CA800@174.26.121.21
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3682385244-3079541214-2149163035-4044138496
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1255479906
Contact: <sip:4802317040;tgrp=9494289948;trunk-context=voip.markholloway.net@174.26.121.21:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 6
Session-Expires:  1800
Diversion: <sip:9494289948@voip.markholloway.net>;privacy=off;reason=unconditional;screen=yes
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 216

You do not need to build the profile for multiple numbers since the router is using the pilot user (from sip-ua) as the Diversion number.  It’s common for Service Providers to build a trunk group in a parent-child hierarchy so if the redirect number is the pilot number, regardless of which DN is doing the forwarding, the call is permitted. This will not interfere with caller-id either.

The following are more SIP Profile examples.  These are for supporting a Trunk Group Identifier.  Some SIP Provider platforms such as Broadworks and Sonus will allow tgrp to be used for validating a legitimate call rather than using a phone number from the trunk group.  This allows the customer to send any outbound caller-id they want without the call being rejected.

In the following examples the customer in Broadworks would have their Trunk Group Identifier set by the Service Provider.  For simplicity, the Provider is using the main trunking number as the identifier.  It needs to be set for both SIP registrations and SIP Invites.

request REGISTER sip-header Contact modify “<sip:(.*)@(.*)>” “<sip:\1;tgrp=9494289948;trunk-context=voip.markholloway.net@\2>”
request INVITE sip-header Contact modify “<sip:(.*)@(.*)>” “<sip:\1;tgrp=9494289948;trunk-context=voip.markholloway.net@\2>”

Below is another example where a call coming from UCM includes the leading 9 for outside dial tone. Rather than stripping 9 on UCM it will be stripped by CUBE using a SIP Profile.

response 183 sip-header Remote-Party-ID modify “(.*):9(.*)” “\1:\2″

Broadworks Exteme Overload Controls

Posted: 27th April 2010 by Mark in BroadWorks, SIP

The Broadworks platform uses an enhanced algorithm called Overload Control to offer protection when a cluster node is under severe conditions. The goal is that during an overload period of 150% the throughput will be no less than 90%. Behavior of the Application Server is dependent upon a series of configuration parameters configured through bwcli.  Extreme overload control provides message throttling at the decoding and encoding queues. The maximum packet age used during overload is different from that used during non-overload. Both the maximum packet age and maximum packet age during overload are configurable via the CLI.

Example:

AS_CLI/System/OverloadControls> get
enabled = true
mgcpOverloadAction = error
sipOverloadAction = error
percentMemoryInUseToEnterYellow = 85
percentMemoryInUseToEnterRed = 90
percentMemoryInUseToLeaveYellow = 85
percentMemoryInUseToLeaveRed = 85
allowEmergencyCallsInOverload = true
maxPacketAgeInMsecs = 3000
maxPacketAgeDuringOverloadInMsecs = 1500

One of the most critical parameters to configure is the sipOverloadAction.  This determines how Broadworks will respond during a period of an Overload. The three possible options are:

  • drop (silently discarded)
  • redirect (302 Move Temp)
  • error (503 Service Unavailable)

I do not recommend using drop as this is the least graceful approach and will cause the User Agent Client to rely on its SIP expiration timer before initiating additional SIP messages.  While error should be a viable option it does not guarantee the UAC will reattempt another SIP invite upon receiving a SIP 503 Service Unavailable message.  My recommendation and current best-practice is to use redirect.  The Broadworks Application Server (AS1) will respond to the UAC with the address of the secondary Application Server (AS2) in the SIP contact header. The remaining dialog between the UAC and UAS will be carried out through AS2.

Example call flow for a redirect action

NOTE: Registration Time Extension

During overload a SIP REGISTER messages may be discarded. To reduce the chances that a user’s registration is no longer valid (and cannot receive or possibly make calls), the extension should be set based on expected overload time, which is typically at least twice the non-callp minimum time in zone.

Emergency Calls

If the system is configured to allow emergency calls during overload, then originations matching the call type “Emergency” in the system calling plan are allowed to progress.

Summary

Extreme Overload Controls are an important element for all Broadworks deployments. Setting the proper thresholds between the Yellow and Red Zones will provide the appropriate alarming and graceful call redirection while at the same time notifying an administrator when the platform is reaching its capacity for growth.

This is an example of how to modify a SIP header with an Acme Packet Session Border Controller (SBC).  An SBC is a device most commonly used by Service Providers to provide topology hiding between their SIP platform and the public Internet.  In the most simplistic terms think of it as a Cisco PIX or ASA but explicitly dedicated to Voice over IP (SIP, H.323, MGCP).

The topology in this scenario is an Avaya IP PBX with a SIP Trunk registered to an ITSP’s SIP platform running Broadsoft Broadworks.  The Avaya user wants to place an anonymous outbound call but the Avaya platform is sending the SIP URI as restricted@sip.domain.com rather than anonymous@sip.domain.com.   Although RFC 3261 does not forbid a User Agent Client (UAC) from using something other than anonymous, using anonymous is recommended.  However, Avaya chose not to follow the recommendation.

Our Acme Packet SBC is physically located in the core of the network but provides the logical separation between all customer facing devices and the core Broadworks cluster nodes.  This means all SIP signaling must traverse through the SBC before reaching Broadworks.  This provides a huge benefit when it comes to SIP incompatibilities between various vendors.  In this case we can modify the messaging coming from the Avaya IP PBX and literally replace anything that matches a URI with restricted@ and send anonymous@ before the SBC passes the messaging to Broadworks.

I have provided the examples in the form of screenshots to retain the formatting of the Acme Packet configuration text placement.

The first step in doing this is to create the actual SIP manipulation rules in the Acme Packet SBC.


The second step is to assign the SIP manipulation rule to the Access realm where the Avaya’s signaling is coming in.


The in-manipulationid parameter is what tells the SBC to identify a match for the values assigned to anonSwitch. If there is a match, the URI is modified and successfully sent to Broadworks.

Broadworks incompatible with sudo 1.7

Posted: 22nd April 2010 by Mark in BroadWorks, Unix

As of this writing the latest version of the Unix application sudo is not compatible with Broadworks.  Version 1.6 and below will work appropriately although Broadsoft is working to fix this.  In the event 1.7 is inadvertently installed and Broadworks will not start then the sudo application must be downgraded.

Broadsoft has provided an advisory for customers running RHEL 5.  I have summarized the steps and provided steps for those running RHEL 4 (which Broadsoft did not provide information for).

RHEL5:

Execute the following: rpm –qa | grep sudo

The output should be like the following: sudo-1.6.7p5-30.1.5

If it shows version 1.7.2 you will need to revert to the previous supported version via: yum downgrade sudo

RHEL 4 (uses up2date instead of yum):

Login to the Red Hat web site and visit the download section.  You must download a version of sudo that is part of 1.6. One you have downloaded the appropriate version you must execute the following:

rpm –oldpackage sudo**.rpm

Retrieving Music on Hold files from UCM

Posted: 20th March 2010 by Mark in Cisco

This is a brief explanation of how to retrieve the Music on Hold files from Cisco Unified Communications Manager 7 and load the files into a router’s flash for remote-site streaming directly from the router.  Alternatively, if you have Call Manage Express you can use music-on-hold.au file. The only difference between them is the actual music is different.

In order to complete this you must have a Secure FTP (SFTP) server available on your network and reachable by the UCM Publisher or Subscriber.  If you don’t already have an SFTP server on your network you can use CentOS, FreeBSD, RHEL, Mac OS X, or any Unix-based platform where SFTP is natively part of the OS.

Perform the following steps.

  1. SSH to the UCM Publisher or Subscriber node.
  2. Enter the following command file list activelog mohprep/* and note the list of files displayed.
  3. In this case we want to SFTP the file SampleAudioSource.g729.wav to our SFTP server
  4. Enter the following command file get activelog mohprep/SampleAudioSource.g729.wav
  5. The following information will be displayed. Enter the appropriate SFTP information when prompted.

___

Please wait while the system is gathering files info …done.
Sub-directories were not traversed.
Number of files affected: 1
Total size in Bytes: 2702728
Total size in Kbytes: 2639.3828
Would you like to proceed [y/n]? y

SFTP server IP: 177.1.10.2
SFTP server port [22]:
User ID: mark
Password: *********

.
Transfer completed.

___

At this point the file SampleAudioSource.g729.wav now resides on the SFTP server.  Copy this file to a TFTP server and issue the command copy tftp flash on the router the file should reside on.  The same server I used for SFTP is also a TFTP server.  Any Unix-like OS is capable of supporting SFTP and TFTP.

router# copy tftp flash
Address or name of remote host []? 177.1.10.2
Source filename []? SampleAudioSource.g729.wav
Destination filename [SampleAudioSource.g729.wav]?
Accessing tftp://177.1.10.2/SampleAudioSource.g729.wav…
Loading SampleAudioSource.g729.wav from 177.1.10.2 (via Serial0/3/0.1): !!
[OK - 332600 bytes]

332600 bytes copied in 51.848 secs (6415 bytes/sec)

Cisco’s hidden Gatekeeper debug command

Posted: 13th January 2010 by Mark in Cisco

The following undocumented command is useful for debuging H323 messages.  This command cannot be found in the help-context of IOS as noted below.

router# debug gatekeeper main 10

router# debug gatekeeper ?
gup Gatekeeper GUP messages
load Gatekeeper load-balancing messages
servers Gatekeeper Servers

The great thing about this command is the simplicity in the debug output.

Click the screenshot for a sample output.

Cisco CSIM (Call Simulation) – Hidden IOS Command

Posted: 5th December 2009 by Mark in Cisco

CSIM is an undocumented IOS command.  When configuring a router to act as a voice gateway it is possible to test outbound calls by originating calls from the router.  If the router is configured correctly then the far end number will ring and may be answered. Use the csim start dialstring hidden command to initiate simulated calls to whichever real-world E.164 number is desired. This allows you to determine whether you can properly go offhook from the router to the PSTN, send digits, and complete a call to the destination phone. You can modify the POTS dial-peer appropriately to account for long-distance access codes and other prefixed digits as necessary. In the example below, the POTS dial-peer can match on any string of digits starting with “9”, and all digits that follow the “9” are played out voice-port X/Y/Z.

dial-peer voice 1 pots
destination-pattern 9T
port 1/0:0

r1# csim start 918005551212

csim: called number = 18005551212, loop count = 1 ping count = 0

csim err csimDisconnected recvd DISC cid(28)

csim: loop = 1, failed = 1   csim: call attempted = 1, setup failed = 1, tone failed = 0

Despite the call working in this case CSIM will always display failed=1.  There is no real explanation for this.  CSIM can also be used with PRI, CAS, and if calls are not completing it is recommended to begin analyzing the call flow using debug commands. For example debug isdn q931 will show the Tx and Rx messages (including ISDN Cause Codes) between the local router and the far end TDM equipment.

Here are other examples of POTS dial-peers which reflect different ways to pass digits to the TDM network.

Any of these now sends the entire string “12345678” to the PBX:

!
dial-peer voice X pots
 destination-pattern 1234....
 port 1/0:0
 forward-digits all
!

or:

!
dial-peer voice X pots
 destination-pattern 1234....
 port 1/0:0
 no digit-strip
!

or:

!
dial-peer voice X pots
 destination-pattern 1234....
 port 1/0:0
 prefix 1234
!

CUE Upgrade (Cisco Unity Express 7)

Posted: 25th November 2009 by Mark in SIP

I acquired a used CUE module running CUE 2.1.2 and wanted to proceed upgrading the module to CUE 7.0.3.  The only way to upgrade CUE is through FTP.  Here is the procedure.

First thing I needed to do was install vsftpd on my RHEL 5 Client Workstation.  If you are running CentOS or Fedora you may already have vsftpd installed or you can easily install it using YUM.  The YUM repository for RHEL5 Client Workstation does not include the option to install vsftpd through YUM but you can login to your Red Hat account on their web site and search ‘vsftpd’ and there is an RPM you may download and install (with no dependency problems).

# rpm -ivh vsftpd-2.0.5-16.el5.x86_64.rpm to install vsftpd

# man vsftp to read the very short manual

# chkconfig vstpd on to start vsftpd on bootup

# service vsftpd stop|start|restart to reload the service at any time

By default the ftp root directory is /var/ftp

# cd /etc/vsftpd

# vi vsftpd.conf and allow anonymous users (not required but makes things a bit easier)

From Cisco’s CCO page navigate to Cisco Unity Express 7.0.3 and download cue-vm-k9.nm-aim.7.0.3.zip. This file is for NM-CUE and AIM modules and there is a different zip file for NME-CUE. You also must download the appropriate license files for the number of mailboxes you are using and the IVR ports if applicable. I also had to include the specific language file cue-vm-en_US-langpack.nm-aim.7.0.3.prt1 in my FTP folder or the installation would fail regardless of the language pack being present. Extract all the zip files into the /var/ftp folder on your FTP server.

Log in to your CME router populated with the CUE module.  You will need to open a session through enable mode (not config mode). You should already have your service-engine and service-module parameters configured. IP 177.3.11.1 is the default gateway on my router and 177.3.11.254 is the IP I have assigned to my CME service module.

interface Service-Engine1/0
ip unnumbered Vlan11
service-module ip address 177.3.11.254 255.255.255.0
service-module ip default-gateway 177.3.11.1

router# service-module service-engine 0/1 session
Trying… Open

cue# show software version
Cisco Unity Express version 2.1.2

Be sure you can ping your FTP server form the CUE command prompt.

cue# ping 177.3.11.2
PING 177.3.11.2 (177.3.11.2) 56(84) bytes of data.
64 bytes from 177.3.11.2: icmp_seq=1 ttl=255 time=0.506 ms
64 bytes from 177.3.11.2: icmp_seq=2 ttl=255 time=0.287 ms
64 bytes from 177.3.11.2: icmp_seq=3 ttl=255 time=0.252 ms
64 bytes from 177.3.11.2: icmp_seq=4 ttl=255 time=0.257 ms
64 bytes from 177.3.11.2: icmp_seq=5 ttl=255 time=0.272 ms

— 177.3.11.2 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.252/0.314/0.506/0.098 ms, ipg/ewma 0.551/0.407 ms

In this particular scenario I am performing a clean install. CUE offers the option of doing an upgrade instead of a clean install but you must refer to the Cisco Unity Express 7.0 Installation and Upgrade Guide to make sure the the existing version of CUE is at the correct version.

cue# software install clean url ftp://177.3.11.2/cue-vm-k9.nm-aim.7.0.3.pkg username anonymous password anonymous@

The file cue-vm-k9.nm-aim.7.0.3.pkg is downloaded by CUE which then proceeds to download the remaining files from the CUE zip files that was extracted in to the FTP folder. You will be prompted to choose a language and this is where you must have the specific language pack in your FTP folder (referred to as language payload by CUE). CUE will run through a series of steps to install CUE 7.0.3 and prompt you to reload the module.

cue# show software version
Cisco Unity Express version (7.0.3)
Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc.

Components:

- CUE Voicemail Language Support version 7.0.3

The license files must now be loaded. Be sure you downloaded the correct ones as one is for CCM and the other CME. Once you install one license type you cannot change the system to a different license unless you perform a clean install.

cue# software install clean url ftp://177.3.11.2/cue-vm-license_12mbx_cme_7.0.3.pkg username anonymous password anonymous@

cue# software install clean url ftp://177.3.11.2/cue-vm-license_4port_ivr_7.0.3.pkg username anonymous password anonymous@

cue# reload

cue# show software licenses
Installed license files:
- voicemail_lic.sig : 50 MAILBOX LICENSE
- ivr_lic.sig : 4 PORT IVR BASE LICENSE

Core:
- Application mode: CCME
- Total usable system ports: 8

Voicemail/Auto Attendant:
- Max system mailbox capacity time: 6000
- Default # of general delivery mailboxes: 15
- Default # of personal mailboxes: 50

- Max # of configurable mailboxes: 65

Interactive Voice Response:
- Max # of IVR sessions: 4

Languages:
- Max installed languages: 5
- Max enabled languages: 5

As I go through my CCIE Voice tasks I frequently need to wipe the CUE configuration and start with a fresh CUE 7 initialization:

cue# offline
cue# restore factory default

To wipe the config and reboot into a fresh system prompt with the initialization questions do the following:

cue# erase startup-config

The first time you log into the web interface of CUE you will need to associate the administrator credentials of the router with CUE so CUE may access CME.

r3-br2(config-telephony)#web admin system name admin password cisco

r3-br2(config)#ip http path flash:/gui

If you forget the last statement containing ip http path flash:/gui then CUE will fail to validate the admin/cisco credentials when entered in the CUE web interface.  CUE requires administrator access to CME.