Voicemail audio, caller identification and operator transfer for a remote site
Unity Connection 14 sits in the Amsterdam data center, integrated to CUCM 14 by SIP trunk. It has four voice-messaging ports, all G.711 only, and no G.729 licences. Singapore has 400 users on a 4 Mbps MPLS circuit whose EF queue is 512 kbps and which already carries steady G.729 call traffic. Since the last upgrade, Singapore callers hear the voicemail greeting and then silence, so they cannot leave a message, and Singapore users who retrieve messages hear nothing. Amsterdam users are unaffected. Separately, Singapore users who dial the voicemail pilot and press digits to sign in now hear the opening greeting instead of their own, and their message lamps do not light. Users who press 0 in a greeting wait eight seconds and then get reorder tone.
1. Diagnose the silence on voicemail for Singapore and size the remedy against the 512 kbps EF queue.
Read the worked answer
The call connects and the greeting plays because the SIP signalling and the early media path are fine; the moment the message-recording media stream is established, the codec negotiation fails to find a common format. The Singapore region is G.729; every Unity port is G.711; CUCM cannot bridge that without a transcoder, so it allocates one from the MRGL - and there almost certainly is not one, or it is not in the Singapore devices' MRGL. Confirm in RTMT/Perfmon that no transcoder session is used and in a SIP ladder that Unity's SDP offers only G.711.
Budget check before choosing a fix. Assume 8 concurrent voicemail sessions at the busy hour:
- G.711 end to end: 8 × 80 kbps = 640 kbps > 512 kbps EF - it does not fit, and the queue is already carrying G.729 voice.
- G.729 to Unity: 8 × 24 kbps = 192 kbps, leaving ~320 kbps for the existing call load.
Recommendation: enable G.729 on the Unity ports (capacity/licence permitting). It removes the DSP dependency entirely and is the only option that fits the queue with headroom. If G.729 cannot be enabled, put a transcoder in the Singapore MRGL so the G.711 segment is local and only G.729 crosses the WAN - same WAN math, but now you are paying for and maintaining DSP resources and must add them to the Location's CAC accounting. Also confirm the Unity SIP trunk's allowed codecs list includes G.729 before touching the ports.
2. Singapore users now hear the opening greeting and their lamps never light. What changed, and what are you looking for?
Read the worked answer
Unity identified the caller by ANI. If the ANI it receives no longer matches the user's configured extension, Unity treats the caller as an unknown external caller: it plays the opening greeting, asks for a mailbox ID, and - critically - any message left is not filed against that user, so no MWI is sent to the phone. That single mismatch explains both symptoms together, which is the clue that it is one fault, not two.
Given the last upgrade introduced +E.164 calling-party presentation across the cluster, the likely cause is that the transformation is also being applied to the Unity Connection SIP trunk. Unity still holds 4-digit extensions (e.g. 2XXX), while the INVITE now carries +33XXXXXXXXX.
What to check:
- SIP ladder on the CUCM→Unity trunk: read the
From/P-Asserted-Identity. If it is E.164 and Unity users are 4-digit, that is the fault. - In Unity, the user's Extension and Alias versus the
Recognize Callerbehaviour and the class of service.
Fix: apply a calling-party transformation pattern on the CUCM SIP trunk facing Unity that converts +33…2XXX back to the 4-digit extension (and exclude the Unity trunk from the cluster-wide +E.164 transformation). Do not change the 400 Unity users' extensions to E.164 - that churns MWI targets, greetings and the corporate directory. Re-test by leaving a message and confirming the lamp lights on the correct phone within a few seconds.
3. The press-0 transfer waits eight seconds and then fails. Where do you look, and what is the likely configuration gap?
Read the worked answer
An eight-second wait followed by reorder is Unity doing exactly what it was told: it took the caller input, dialled the operator number out its SIP trunk toward CUCM, and no route matched, so CUCM rejected it and Unity played the failure prompt.
Three places to check, in order:
- Unity restriction table applied by the caller's class of service / the system's restriction table. If the operator extension is not permitted by the pattern in that table, Unity blocks the transfer before it ever dials. A common gap is a table that allows
9.XXXXXXXXXexternal dialling but has no entry for the internal operator DN. - CUCM side routing for the number Unity sends. The SIP trunk to Unity has its own calling search space. The operator DN lives in the site's partition; if that partition is not in the trunk's CSS, the transfer fails with no route - even though a phone at the same site can dial 0 perfectly.
- Dialled digits. Check what Unity actually sends - if it prefixes an access code or sends E.164, the CUCM pattern will not match a 4-digit operator DN.
Fix: permit the operator DN in the relevant Unity restriction table and add the operator's partition to the Unity trunk's CSS (or add the operator as a system-level transfer number with an explicit route). Test both from a greeting and from a subscriber's caller-input mapping, and from an external PSTN caller, since the class of service applied can differ.