6.1 Cisco Unity Connection Architecture & SIP Integration

6.1 Cisco Unity Connection Architecture & SIP Integration

Cisco Unity Connection (CUC) is an enterprise-grade voice messaging, automated attendant, and speech-enabled unified messaging platform. Built on the appliance-based Cisco Voice Operating System (cVOS)—a hardened Linux kernel distribution—CUC provides robust voice message storage, directory services, and telephony integration with Cisco Unified Communications Manager (CUCM), Cisco Unified Communications Manager Express (CUCME), and third-party IP PBXs.

---

1. Cisco Unity Connection System Architecture & High Availability

Unlike legacy voicemail systems that required dedicated hardware cards or active/standby standby arrangements with idle hardware, modern Cisco Unity Connection clusters deploy in an Active/Active High Availability (HA) pair comprising two virtual appliances: a Publisher node and a Subscriber node.

+-----------------------------------------------------------------------------------+
|                 CISCO UNITY CONNECTION ACTIVE/ACTIVE CLUSTER                      |
|                                                                                   |
|         PUBLISHER NODE                                   SUBSCRIBER NODE          |
|   +--------------------------+                     +--------------------------+   |
|   |  - Handles Voice Calls   |                     |  - Handles Voice Calls   |   |
|   |  - Records Audio Files   |                     |  - Records Audio Files   |   |
|   |  - Primary status (DB)   |                     |  - Secondary status (DB) |   |
|   +------------+-------------+                     +------------+-------------+   |
|                |                                                |                 |
|                +================================================+                 |
|                     1. Database replication (Primary -> Secondary)                |
|                     2. Message store replication                                  |
|                     Max RTT: 100 ms (both answer) / 150 ms (pub only)             |
+-----------------------------------------------------------------------------------+

Dual-Active Processing Model

In an Active/Active deployment:

• Simultaneous Call Handling: Both the Publisher and Subscriber actively answer incoming telephone calls, play user greetings, accept voice messages, and execute call handler logic concurrently. Incoming calls can be load-balanced evenly across both nodes via CUCM Route Lists or DNS SRV records.
• Database Architecture: Configuration data resides in an IBM Informix database on each server. Normally the publisher has Primary status: it publishes the database and message store, and the subscriber (Secondary status) receives the replicated data. If the publisher fails, the subscriber takes Primary status until the publisher returns.
• Real-Time Audio Store Synchronization: Spoken voice recordings, voice names, and personal greetings do not reside directly within the relational database tables. Instead, recordings are stored as audio files in each server's message store, and the message store is replicated between the two servers so that either one can play any message.

Network Latency & Clustering Boundaries

• Maximum Round-Trip Time (RTT): When the two servers are in different buildings or sites, Cisco allows at most 100 ms RTT if both servers take calls, or 150 ms RTT if only the publisher takes calls while the subscriber just replicates.
• Cluster Size: A CUC cluster supports a strict maximum of two nodes (one Publisher and one Subscriber). Unlike CUCM, which scales to as many as 21 servers, CUC cannot add tertiary or auxiliary subscriber nodes.
• Port Capacity: An enterprise deployment OVA template (e.g., 20,000 mailboxes) supports up to 250 voice messaging ports per server. Cisco's design rule is that each server must have enough ports to handle all of the cluster's calls, because either server may have to carry the full load alone.

Node Failure & Split-Brain Survivability

If the Publisher server fails or network connectivity severs between nodes:

• The Subscriber continues answering calls, playing existing greetings, and recording voice messages using its local read-only database and local audio message store.
• The Subscriber queues directory modifications and message state transitions locally.
• When network connectivity restores, Informix replication resynchronizes database changes, and message store replication reconciles the two message stores without message loss.

---

2. CUCM SIP Integration Components

Modern voice messaging architectures utilize the Session Initiation Protocol (SIP) for telephony signaling between CUCM and CUC. SIP offers high scalability, native support for Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP), and simplified administrative routing compared to legacy Skinny Client Control Protocol (SCCP).

Integrating CUCM with Cisco Unity Connection requires four interconnected administrative objects in CUCM Administration:

[ Cisco IP Phone ] 
       | (Presses "Messages" button or forwards on CFB/CFNA)
       v
[ Directory Number (DN) ] ---> Assigned to: [ Voice Mail Profile ]
                                                    |
                                                    v
                                        [ Voice Mail Pilot Number ] (e.g., 5000)
                                                    |
                                                    v
                                        [ SIP Route Pattern / Trunk ] (Points to CUC)
                                                    |
                                                    v
                                        [ Cisco Unity Connection Cluster ]

1. SIP Trunk Security Profile

Located under System > Security > SIP Trunk Security Profile, this profile specifies Layer 4 transport and security settings:

• Device Security Mode: Non Secure (port 5060) or Encrypted (port 5061 with mutual TLS X.509 certificates).
• Incoming Transport Type: TCP or TLS (UDP is generally deprecated for enterprise CUC SIP integrations due to SIP message fragmentations from large Diversion headers).
• Outgoing Transport Type: TCP or TLS.
• Accept Unsolicited Notification: Mandatory. This checkbox allows CUCM to accept incoming unsolicited SIP NOTIFY transactions from CUC for Message Waiting Indication (RFC 3842).
• Accept Replaces Header: Enables call transfer optimization and consultative transfers from CUC auto-attendants.

2. SIP Trunk

Located under Device > Trunk, the SIP trunk establishes the logical signaling path between CUCM and CUC:

• Device Pool: Assigns the region, location, and network QoS parameters for voice calls directed to voicemail.
• Destination Address: Configured with the IP addresses or Fully Qualified Domain Names (FQDNs) of both CUC nodes (e.g., Destination 1: 10.1.10.51 for Publisher; Destination 2: 10.1.10.52 for Subscriber), each listening on destination port 5060 (or 5061 for TLS).
• SIP Profile: Standard SIP Profile with options ping enabled to track node availability dynamically.
• Reroute Calling Search Space: Evaluated when CUC executes call transfers back to CUCM.

3. Voice Mail Pilot Number

Located under Advanced Features > Voice Mail > Voice Mail Pilot:

• Defines the dialed directory number used to reach voicemail (e.g., 5000).
• Configured with an internal Calling Search Space (CSS) that possesses routing visibility to the SIP Route Pattern or SIP Trunk connecting to CUC.

4. Voice Mail Profile

Located under Advanced Features > Voice Mail > Voice Mail Profile:

• Binds a specific Voice Mail Pilot number to user endpoints.
• Assigned directly to individual Directory Numbers (DNs) on IP phones under Directory Number Configuration > Voice Mail Profile.
• When a user presses the physical "Messages" envelope button on an IP phone, CUCM reads the assigned Voice Mail Profile, retrieves the Voice Mail Pilot number, and routes the call to CUC.

---

3. CUC Telephony Integration: Port Groups & Voice Messaging Ports

Within Cisco Unity Connection Administration, telephony integration is configured under Telephony Integrations.

+-----------------------------------------------------------------------------------+
|                   CUC TELEPHONY INTEGRATIONS HIERARCHY                            |
|                                                                                   |
|  1. Phone System (e.g., 'CUCM-Cluster')                                           |
|     |                                                                             |
|     +---> 2. Port Group (SIP Signaling Configuration)                             |
|           - IP Addresses of CUCM Subscribers (Port 5060/5061)                     |
|           - Transport: TCP / TLS                                                  |
|           - Contact Header & Audio Codec (G.711u / G.722)                         |
|           |                                                                       |
|           +---> 3. Voice Messaging Ports (Logical Channels)                       |
|                 - Answering Ports (Inbound callers / message retrieval)           |
|                 - Dial-Out Ports (MWI on/off, external notifications)             |
+-----------------------------------------------------------------------------------+

Phone System & Port Groups

• Phone System: The top-level administrative wrapper representing the PBX environment.
• Port Group: Defines the SIP signaling configuration connecting CUC to CUCM. The Port Group contains the IPv4/IPv6 addresses of CUCM call-processing subscriber nodes, the SIP port, authentication credentials, and media codec preferences (typically G.711 mu-law, G.711 a-law, or G.722 wideband).

Voice Messaging Ports Allocation

Inside the Port Group, administrators provision logical Voice Messaging Ports. Unlike physical DSP ports on a voice router, CUC ports are software licenses and process threads allocated to handle simultaneous voice conversations.

Voice Messaging Ports are categorized into distinct operational roles:

---

4. SIP Signaling and Redirect Flow

When a call terminates in voicemail, CUC must determine why the call arrived and whose mailbox greeting to play. This intelligence is communicated through SIP message headers.

Forwarding Triggers in CUCM

On an IP phone directory number, three primary call forwarding settings direct unanswered calls to voicemail:

1. Call Forward Busy (CFB): Triggers when the target line is off-hook or reached its maximum call limit.
2. Call Forward No Answer (CFNA): Triggers when the phone rings past the configured No Answer Ring Duration (default: 12 seconds / ~3 rings).
3. Call Forward All (CFA): Unconditionally redirects all incoming calls immediately without ringing the station.

The RFC 5806 Diversion Header

When CUCM routes a forwarded call over a SIP trunk to CUC, it includes an RFC 5806 Diversion header (or RFC 4244 / RFC 7044 History-Info header). The Diversion header informs CUC of the original called extension and the redirection reason code.

INVITE sip:5000@10.1.10.51:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.1.10:5060;branch=z9hG4bK1a2b3c4d5e
From: "Alice Smith" <sip:2001@10.1.1.10>;tag=12345678
To: <sip:5000@10.1.10.51>
Call-ID: 9876543210@10.1.1.10
CSeq: 101 INVITE
Max-Forwards: 70
Remote-Party-ID: "Alice Smith" <sip:2001@10.1.1.10>;party=calling;screen=yes;privacy=off
Diversion: <sip:2002@10.1.1.10>;reason=no-answer;counter=1;privacy=off
Contact: <sip:2001@10.1.1.10:5060;transport=tcp>
Content-Type: application/sdp
Content-Length: 218

v=0
o=cisco-SIPUA 101 0 IN IP4 10.1.1.10
s=SIP Call
c=IN IP4 10.1.1.25
t=0 0
m=audio 24580 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Redirection Reason Codes

CUC parses the reason parameter inside the Diversion header to select the appropriate greeting:

---

5. SIP Integration Troubleshooting & Verification

When diagnosing SIP integration failures between CUCM and CUC, use the following systematic checklist:

+-----------------------------------------------------------------------------------+
|                         SIP INTEGRATION VERIFICATION STEPS                        |
|                                                                                   |
| 1. CUCM SIP Trunk Status -> Verify In Service / Normal via RTMT                   |
| 2. CSS & Partition Visibility -> Confirm VM Pilot CSS can reach SIP Trunk         |
| 3. Security Profile -> Verify 'Accept Unsolicited Notification' is checked        |
| 4. CUC Port Group -> Confirm CUCM Subscriber IPs match listening SIP addresses   |
| 5. Packet Inspection -> Verify Diversion header presence in SIP INVITE            |
+-----------------------------------------------------------------------------------+

Common Integration Failures

1. One-Way Audio or Fast Busy: Typically caused by network firewalls blocking bidirectional UDP RTP streams (ports 16384–32767) between phone endpoints and CUC servers, or mismatched codec negotiation in CUCM Regions (e.g., CUC configured strictly for G.711u while branch calls arrive as G.729 without a transcoder).
2. Generic Opening Greeting Plays Instead of User Greeting: Occurs when CUCM fails to populate the Diversion header in the SIP INVITE, or when the forwarded extension in the Diversion header does not match any primary or alternate extension configured in CUC.
3. CUC Port Group Registration Failures: Under CUC Port Group configuration, verify that the SIP Transport matches CUCM (TCP port 5060). If CUCM uses TLS port 5061, ensure CallManager and Connection X.509 certificates are exchanged and uploaded to tomcat-trust and CallManager-trust stores.