Unity Connection can be integrated with CUCM using 2 methods, SCCP or SIP, the high level differences and similarities are detailed below;
SCCP Integration
- Requires SCCP Ports, along with Line Group, Hunt List & Hunt Pilot
- Has dedicated DNs for MWI on/off
SIP Integration
- Requires a SIP Trunk pointing to Unity Connection
- Requires a route pattern to send calls to the SIP trunk (or a route group if there is a clustered Unity setup)
- Does not require MWI DNs, uses SIP NOTIFY messages
Both integrations require a VM Pilot and a VM Profile. The VM Pilot is not a dialable DN/pattern, it’s more of a ‘speed dial’ for the phones to use, so when we change the VM profile for a DN it’s effectively a speed dial button for the VM pilot number references in the VM profile.
SCCP Integration – CUC Configuration
Firstly we have to create a ‘Phone System’ This is the highest-level element of the integration configuration, it will contain a port group which will then contain individual ports.
The options here control the integration between the two, including settings for MWIs (and the ability to initiate a synchronization in case the MWIs have become inconsistent for some reason). It also allows you to enable/disable loop detection (which is on by default), either by Extension (default) or by DTMF. Is it used to guard against scenarios such as breaking out of an auto-attendant system call handler to call a particular user and that DN they call is set to forward to VM because they are away from their desk. I need to add more information here. The Phone View feature is controlled from here – enabling/disabling the feature along with the username/password for Unity Connection to use (must be an application user on CUCM with CTI control of the required devices) – along with outgoing call restrictions (unrestricted/blocked/blocked during a given time period)
You must also go to ‘Edit’ and select ‘CUCM AXL Servers’ and add the CUCM servers with their IPs or hostnames if CUC uses DNS, ensure the port is set to 8443. Add in the user/pass for AXL access (must be created in CUCM with the ‘Standard AXL access’ role) and hit ‘Test’ for each CUCM server to ensure there is no error.
Once this is done, the next step is to create a port group. A port group is given a name, a device name prefix along with more detailed MWI settings consisting of MWI On/MWI Off extensions and some timers for MWI. The defaults are pretty sane I think. The Device Name Prefix is important, as it must match at CUC and CUCM.
The port group configuration also allows you to specify CUCM & TFTP servers along with detailed timer settings to be used if there are issues with the integration (typically the defaults are sane and work fine with CUCM, but these settings may need changed if the integration is to another voice system like Asterix/FreePBX). Finally, you can also control the codecs that Unity Connection will advertise during the capabilities exchange of any call setup. The default appears to be G711ulaw and G722. iLBC/G711alaw/G729 are also available.
The final step is to create ports. These ports can have 4 functions enabled on each port; Answer calls/MWI notification/MWI requests/TRAP notifications. With this in mind, groups of ports could be assigned separate functions or all ports could be assigned all functions, although doing this means you may run in to issues in not being able to ensure that users will almost always be able to get a port for checking voicemail if everybody happened to be recording a new greeting using all ports there would be none free for VM-checking. If a group of ports were enabled for answering calls only, then these would only every be used for users calling in to Unity Connection (for VM/call handlers/etc).
SCCP Integration – CUCM Configuration
There is a handy wizard at Advanced Features -> VM -> VM Port Wizard
First off, you enter the device name prefix. Ensure this matches what you configure at the CUC side, otherwise the ports will not register to CUCM correctly! Then you tell the wizard how many ports you want to create during the wizard.
When you hit next you are asked for the typical line/device information for the ports/DNs to be used, including Device Pool/CSS/Location/etc. The CSS for VM port devices/VM pot DNs is used by Unity Connection for calling out on any of these ports. Unity Connection has restriction tables that can block calls before they ever leave CUC, which is handy – we can give the ports full access but restrict it from the CUC side. Why do we set it twice in the wizard? Because a VM port is the same as any other ‘thing’ that can dial – it uses the line/device approach where the line and device are assigned a CSS.
After configuration the device/DNs you can chose to add the numbers to a new or existing line group, or do it manually. Thereafter you must add the line group to a hunt list, and add that hunt list to a hunt pilot. The hunt list must have the ‘for voicemail usage’ box ticket, although I’m not sure why. I wonder if I can find out…
Then we need to configure a VM Pilot and VM Profile. The VM pilot is the number used to dial in to Unity Connection. For an SCCP integration it is a number that is assigned a CSS that can reach the Hunt Pilot eventually containing the VM ports. This is then assigned to the VM profile assigned to each DN. I’m not sure why the VM Pilot has a CSS, does the calling party inherit that CSS when pressing the ‘Messages’ button or something? Update: from a bit of Googling, I think the CSS assigned there is used when a device forwards to voicemail.
We also need to ensure we configure the MWI On/MWI Off extensions in CUCM . Go to Advanced Features -> Voicemail -> Message Waiting and hit ‘add’ to add a new MWI DN, enter the number/partition/CSS and whether it is for on or off. Rather (un)helpfully, the MWI On icon is green and MWI off is red – despite the MWI light itself being red! The MWI DNs are assigned a partition which allows you to restrict whether users can dial the MWI directly (i.e the users devices/lines are assigned CSS’ that don’t contain the partition they are in). Unity Connection dials these with a spoofed calling number/ANI of the DN we wish to set an MWI for (I belive!), then CUCM signals that DN to display MWI. The voicemail port CSS must be able to reach the MWI DNs for this to work!
SIP Integration – CUC Configuration
Add a new port group, ensure the type is set to ‘SIP’ rather than ‘SCCP’ the default port/protocol settings are usually ok, add the IPv4 address of the CUCM at the bottom. Hit save and then click on the related link to add ports. You can also at this stage go to ‘Edit’ and add details for any other CUCM servers so it isn’t reliant on the single server configured on the main page. A reset of the port group is required after this.
We must then create ports the same as we do with SCCP, this is because this is a licensing requirement in Unity Connection – it is how they limit the number of calls in to the system.
Done! =D
SIP Integration – CUCM Configuration
Create a SIP trunk (default service type of ‘none’), give it a name/device pool/etc. Ensure inbound significant digits is set to all and the CSS’ and AAR settings are valid to ensure any outcall to the PSTN works. Disable outbound calling/called party xforms unless required. Ensure ‘Redirecting iversion header delivery – outbound’ is ticked so that the RDNIS info is included in the setup messages.
Enter the IP of the CUC server as the destination. Hit save & reset the trunk.
At this point, we need to create a new SIP Trunk Security Profile and ensure the following settings are selected;
- Accept Out-of-Dialog REFER
- Accept unsolicited notification
- Accept replaces header
If we’re creating a new SIP Trunk Security Profile for other Cisco UC Applications, it may make sense to also tick the box that mentions ‘SUBSCRIBE’ (I can’t remember the exact wording of it off the top of my head!) – it will be required for CUPS.
Assign this new SIP Security Profile to the SIP trunk & reset.
Next, create a route pattern that matches the VM pilot, set the destination to be the CUC SIP Trunk and hit save. Untick any PSTN settings.
Credit goes to http://protocol41.wordpress.com for this one!