Category Archives: cuc

VMware Tools 10.0 Update Failures Creates Outage – CSCux90747, CSCva09767, CSCuy84075

A friend hit this delightful defect this week:

 

 

There are several workarounds, but ultimately there’s a COP file for this – ciscocm.VMwareTools2016c.cop.sgn.  The attached defects cover several initial install and help-me-its-dead scenarios.

 

It’s a bit of a horror.  Watch out for those VMWare tools updates!

 

#dontcalltac

Tagged , , , , , , , , ,

CSCux67499 – SQL NullPointer Exception causes CUC Subscriber Sync Failures

The later version (11.0 – 11.2) of PCP have a fairly painful caveat when it comes to Unity Connection.  CUC is currently afflicted by a(nother) horrid Informix problem that will cause subscriber sync failures.

 

The defect is below:

 

Unfortunately, there’s no workaround available as per the bug description:

 

Symptom:
User Sync of Unity Connection fails on Prime Collaboration Tool (PCP).
NullPointerException exception is seen in Nice log (PCP).

System or internal error java.lang.NullPointerException
java.sql.SQLException: System or internal error java.lang.NullPointerException
at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:488)
at com.informix.jdbc.IfxSqli.a(IfxSqli.java:9547)
at com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2634)
at com.informix.jdbc.IfxSqli.a(IfxSqli.java:1830)
at com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1768)
at com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1699)
at com.informix.jdbc.IfxResultSet.a(IfxResultSet.java:210)
at com.informix.jdbc.IfxStatement.executeQueryImpl(IfxStatement.java:1237)
at com.informix.jdbc.IfxPreparedStatement.executeQuery(IfxPreparedStatement.java:382)
at dfc.ipt.cisco.unity.util.UMPUtil.executeQuery(UMPUtil.java:247)

Conditions:
1) PCP User Sync in executed for Unity Connection
2) Having 5K or 20K End Users record in CUC11.x or 10.x

Workaround:
None

 

Please take note of the following, as this does affect planned PCP upgrades:

 

 

Nice work from the technical documentation team in listing out the caveat in the upgrade guide!

 

Before upgrading, you need to install an engineering special in Cisco Unity Connection(10.5.x & 11.0) for successful subscriber synchronization. Contact TAC to obtain the Cisco Unity Connection engineering special for the bug (CSCux67499). If you are using Cisco Unity Connection release below 10.5, then you must upgrade to Cisco Unity Connection version 10.5.x and then apply the engineering special.

 

A call to TAC to request an ES is going to be required (as of the date of this blog post).  Cross-reference the bug “Fixed In” details and check if this has been included in a later Unity Connection SU.  If in doubt, call TAC for  assistance.

 

 

Tagged , , ,

CSCup36072 – CUCM/CUC Patch Upgrade Fails

Hit another horror defect today…  Patch upgrades apparently do not work as of 10.5.x and up!

 

Selection_041

 

The defect is described below:

 

 

The bug details are below – only workaround is to install with a bootable image!

 

Symptom:
When doing a fresh install of a Call Manager node, there is an option to use an upgrade patch option.

For CUCM 10.5, this approach cannot be used. Not even by using the bootable image for 10.0 and upgrade file for 10.5

Conditions:
Installing CUCM 10.5 with bootable image of a lower version and upgrade file of CUCM 10.5

Workaround:
None -> Use Bootable image for CUCM 10.5 itself

 

To resolve, the only “supported” method is to request a bootable image from TAC.

 

Terrible.  Terrible.  Terrible.

Tagged , , , , ,

Unity Call Extended for Recording Fails

While implementing an Auto Attendent today, we faced a challenge as the client did not want to pay for professional recordings, and needed to implement quickly.

If you’ve done the odd AA, you’ll know that this is a pretty common requirement.  Link to the docs is here.

However, when I did this in the usual way, I faced a call failure, with Error Code 5:

error5.png

 

A pretty useless error code then!  At this point I’m pretty convinced that my CUC config is good, so really it’s time to gather SDL traces and review…

I get an immediate hit in response to the SIP INVITE:

SIP/2.0 433 Anonymity Disallowed
Via: SIP/2.0/TCP 192.168.5.6:5060;branch=z9hG4bK14fda803a44a4d418c4f8301d3fec2b5
From: sip:192.168.5.5;tag=3387e2bbf6114e90b27738f525f251d6
To: sip:0255667787@192.168.5.5;tag=331164~0d10edf8-0553-4009-a728-c065d8394e46-24136465
Date: Mon, 07 Dec 2015 08:38:09 GMT
Call-ID: fedb03ec6b74449ab2dcc8031eb18dc0@192.168.5.5
CSeq: 200 INVITE
Allow-Events: presence
Server: Cisco-CUCM11.0
Session-ID: 00000000000000000000000000000000;remote=22bfe535e32fa04bbd9367a0ab331164
Reason: Q.850; cause=21
Content-Length: 0

 

Now if you’re experienced with SIP, you’ll know that cause=21 means a call rejection – so all call routing root causes are OUT.  CUCM had the ability to route the call, and chose not to.

If we inspect this SIP message (don’t even need to go the INVITE to analyze this one), we see that head From header done not include a user portion – host only!  Something is configured on CUCM to reject the anonymous calls.  Since this is dialling to a device – the first port of call is the DN, which showed this up immediately:

css.png

 

Removing the Reject Anonymous Calls checkbox resolved this immediately.  Silly me – had this set in my User Line Template used for Self-Provisioning! 🙂

 

However… this is not really an eloquent solution.  What if we MUST have the anon rejection in place?  Also – not very useful solution on a large cluster!

The better solution lies on CUC at the source – Setting the Contact Line Name on the Port Group.

 

When this was done, I noted that this correctly updated Contact, From and privacy headers as well.

 

#dontcalltac

 

Tagged , , , ,

Lua Script Solves Call Forward Masking

Had to implement an Auto Attendant in Unity today.  The client had a requirement to send after-hours calls out to the PSTN, but had to be routed in to their Call Centre, which had it’s own IVR which matched on calling number, that needed to be the switchboard number for their site.

Call Flow was as follows:

  1. Inbound call from PSTN
  2. CTI RP re-direct to Unity
  3. Unity Call Handler, with Close and Holiday transfer to 2nd Call Handler
  4. After-Hours Call Handler transfers back to After-Hours CTI RP
  5. After-Hours CTI RP as Call Forward to a PSTN number

 

The behavior that we see is controlled by SIP Trunk Calling Party Selection parameter, which is set to “Originator” by default:

pic1

 

The SIP INVITE sent to the CUBE looked like this:

INVITE sip:0112223344@mygateway.mydomain.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.5:5060;branch=z9hG4bK55cd222ad94e
From: <sip:0255667787@myhostname.mydomain.com>;tag=336868~0d10edf8-0553-4009-a728-c065d8394e46-24136542
To: <sip:0112223344@mygateway.mydomain.com>
Date: Mon, 07 Dec 2015 10:38:00 GMT
Call-ID: 94dfb980-66516188-5120-247410ac@192.168.5.5
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM11.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:192.168.5.5:5060>;method=”NOTIFY;Event=telephone-event;Duration=500″
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
Session-ID: 97632eb36d62419cbdc5fe71aa336867;remote=00000000000000000000000000000000
Cisco-Guid: 2497689984-0000065536-0000000110-0611586220
Session-Expires: 1800
Diversion: “After-Hours Re-Direct” <sip:**999@mydomain.com>;reason=unconditional;privacy=off;screen=yes
P-Asserted-Identity: <sip:0255667787@myhostname.mydomain.com>
Remote-Party-ID: <sip:0255667787@myhostname.mydomain.com>;party=calling;screen=yes;privacy=off
Contact: <sip:0255667787@192.168.5.5:5060>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 227

v=0
o=CiscoSystemsCCM-SIP 336868 1 IN IP4 192.168.5.5
s=SIP Call
c=IN IP4 172.16.115.23
b=TIAS:8000
b=AS:8
t=0 0
m=audio 26842 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

 

  • In this case the calling party is sent out at 0255667787.  We want this sent out as 0255667000 to me the client’s requirement.
  • To do this, we need to correct the From, PAI, RPID, and Contact headers
  • The Diversion Header contains the Internal DN of the CTI RP – not very pretty, and something that our ITSP may bark at!  We must change it.
  • The headers MUST ONLY be modified when the call is forwarded FROM THIS CTI RP – my “hook” here will be the offending Diversion header.

 

I opted for a Lua script.  I find complex SIP Profiles unwieldly, which could have been another option.  Vomit.

 

So, here’s the script that achieved it.  Pretty simple in fact:

M = {}

trace.enable()

function M.outbound_INVITE(msg)

— Input for script
local ctirpdn = scriptParameters.getValue(“ctirpdn”)
local mainnumber = scriptParameters.getValue(“mainnumber”)
local rdnis = scriptParameters.getValue(“rdnis”)

— Get Diversion header
local diversion = msg:getHeader(“Diversion”)

— Check if Diversion Header exists and if the CTI RP DN is matched
if diversion and diversion:find(ctirpdn) then
trace.format(“Successful match on diversion – applying masking”)

trace.format(“CTI RP DN is : %s”, ctirpdn)
trace.format(“Main Number is : %s”, mainnumber)

— Apply masking to affected headers – From, PAI, RPID, Contact
msg:applyNumberMask(“From”, mainnumber)
msg:applyNumberMask(“P-Asserted-Identity”, mainnumber)
msg:applyNumberMask(“Remote-Party-ID”, mainnumber)
msg:applyNumberMask(“Contact”, mainnumber)
— Apply masking to Diversion to mask internal CTI RP DN
msg:applyNumberMask(“Diversion”, rdnis)

end
end

return M

The bold script params were applied on the SIP Trunk.  I decided to use Unity as the forwarding station, as set this as the “rdnis”.  The key is the IF STATEMENT, that only applied changes if the CTI RP DN is matched in the header.  Otherwise, the script is skipped.

 

Now, for testing… Let’s open up RTMT and trace this in SDL:

 

 

03149762.001 |13:00:37.979 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 192.168.1.3:[5060]:
[990360,NET]
INVITE sip:0112223344@mygateway.@mydomain.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.5:5060;branch=z9hG4bK5634188efa43
From: <sip:0255667000@myhostname.@mydomain.com>;tag=337995~0d10edf8-0553-4009-a728-c065d8394e46-24136584
To: <sip:0112223344@mygateway.@mydomain.com>
Date: Mon, 07 Dec 2015 11:00:37 GMT
Call-ID: bdb57e00-665166d5-516d-247410ac@192.168.5.5
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM11.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:192.168.5.5:5060>;method=”NOTIFY;Event=telephone-event;Duration=500″
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
Session-ID: 97632eb36d62419cbdc5fe71aa337994;remote=00000000000000000000000000000000
Cisco-Guid: 3182788096-0000065536-0000000119-0611586220
Session-Expires: 1800
Diversion: “After-Hours Re-Direct” <sip:0255667800@@mydomain.com>;reason=unconditional;privacy=off;screen=yes
P-Asserted-Identity: <sip:0255667000@myhostname.@mydomain.com>
Remote-Party-ID: <sip:0255667000@myhostname.@mydomain.com>;party=calling;screen=yes;privacy=off
Contact: <sip:0255667000@192.168.5.5:5060>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 227

v=0
o=CiscoSystemsCCM-SIP 337995 1 IN IP4 192.168.5.5
s=SIP Call
c=IN IP4 172.16.115.23
b=TIAS:8000
b=AS:8
t=0 0
m=audio 22640 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

 

Working perfectly! 🙂

 

#dontcalltac

 

 

 

 

Tagged , , , , , ,

Lua Scripting – Proxied Manager Breaks MWI for Centralized CUC Behind SME

I’ve been working as design and deployment lead on a globally significant full Collaboration on-premise deployment for the last 3 months (think 120 CUCM across 9 Leaf Clusters on 101 UCS C240’s) that’s been keeping me quite busy 🙂

As part of the deployment design phase, a decision was taken to centrally host Unity Connection for all 9 Leaf Clusters.  As I commenced with the dial plan design, while I reviewed the business requirements I identified a call flow that I knew would immediately create a problem.  Some like a board, pen and paper or even spreadsheets for call routing – I like to do these in my head as I jot down the configuration elements in notepad++.  Your preferred method is irrelevant – the point is always to model your call flow design prior to implementation – with the intention to find inherent call flow failures.

The client had a strong use case for a proxied manager configuration, with a secretary available to take calls on their behalf.  There are a number of ways to configure this, but from a routing perspective, a separate partition is always required for the manager, with reach-ability only from the secretary’s CSS.

The Challenge:

  • Call flow required is CUC > SME > Leaf > Manager Phone
  • MWI is routed from CUC via an Out-of-Dialog SIP NOTIFY
  • In the CUCM SIP construct, this uses the same Inbound CSS as a standard call

The Likely Result:

  • The manager’s MWI will never light up – no reach-ability in the inbound CSS without violating an inter-cluster proxied routing requirement
  • Depending on your configuration, the proxied line on the secretary’s phone is probably going to light up instead!

The requirement is not unique, but the advent of SIP, and wanting a scale-able solution posed a challenge.


Due to the scale of deployment and tight timelines, our local SE was kind enough to arrange some time with a BU dial plan specialist to review my dial plan design, with some recommendations along the way (what an awesome experience!).  I was keen to pose my dial plan issue to the BU, as I was quite sure that a special method would be needed to accommodate this.

After some discussion, a Lua script was proposed.  I was quite keen on the idea, as I’ve had some experience writing these before.  The call flow idea was actually quite simple:

  1. CUC > SME > Leaf (end-to-end SIP)
  2. SIP Normalization Script (on Leaf Trunk) > Custom Routing Prefix on Manager DN (think “**”)
  3. Translation Pattern (PreDot strip with correct re-prefixing) > Custom CSS with prioritization of Manager Partition(s)

The BU provided me a script for a similar case, which I customized to support my requirement:

–[[

Author : Jonathan Els

Description:

Script for separate handling of MWI to accommodate proxied partitions for centralized voicemail designs with SME – e.g. with Proxied Manager/Secretary configurations
Script strips initial chars (“0” hard-coded in this script) to add a prefix for custom routing

Future development:

1. Add contextual checks to specifically limit to MWI – possible matching on Content (“Messages-Waiting” etc.) or CUC source address could apply
1. Use prefix as script param.

–]]
M={}

trace.enable()

function M.inbound_NOTIFY(msg)

— Set prefix for MWI
prefix = “**”

— Need to convert E.164 to **-prefixed string in request URI and To header
local m,r,v = msg:getRequestLine()
r=string.gsub (r,”sip:0(%d*)@”, “sip:” .. prefix .. “%1@”)
msg:setRequestUri (r )

local t = msg:getHeader(“To”)
t=string.gsub (t,”sip:0(%d*)@”, “sip:” .. prefix .. “%1@”)
msg:modifyHeader (“To”, t)
end

return M

In our dial plan, we deviated from the +-E.164 CVD best practice due to a limitation on the client’s billing system.  We preferred localized DID’s instead.  As a result, the above script uses the following pattern match:

sip:0(%d*)@”

Without excessive deviation, if your call routing requirement dictates the need for Lua scripting, please take the time to understand Lua Pattern Matching.  Lua’s about *speed*.  Regex is damn slow.


During testing, I hit a snag and reached out to the BU once again…

Looking at SDL showed the script to be working:

00240075.000 |17:09:45.622 |SdlSig   |SIPNormalizeReq                        |wait                           |SIPNormalization(2,100,78,1)     |SIPHandler(2,100,79,1)           |2,100,14,91.8^192.168.116.12^*           |*TraceFlagOverrode

00240075.001 |17:09:45.622 |AppInfo  |//SIP/SIPNormalization/trace_sip_message: After inbound SIP Normalization msg is:

[20427,INT]

NOTIFY sip:**111001001@192.168.116.21:5060 SIP/2.0

Date: Wed, 24 Jun 2015 15:09:45 GMT

From: <sip:voicemail@192.168.116.12>;tag=36349161

Event: message-summary

Content-Length: 23

User-Agent: Cisco-CUCM10.5

To: <sip:**111001001@192.168.116.21>

Contact: <sip:voicemail@192.168.116.12:5060;transport=tcp>

Content-Type: application/simple-message-summary

Call-ID: ad6c800-58a1c839-13de1-c74a8c0@192.168.116.12

Subscription-State: active

Via: SIP/2.0/TCP 192.168.116.12:5060;branch=z9hG4bK13ecf35a0eda8

CSeq: 102 NOTIFY

Max-Forwards: 70

 

Messages-Waiting: yes

However, I soon found that the standard digit analysis engine was not being applied.  The TP’s in my CSS’s were not being matched!  I actually confirmed this by configuring my expected pattern – **111001001 – on an entirely different phone and watched its MWI light up.

The BU suggested that I try setting the Advanced CallManager Service Parameter Multiple Tenant MWI Mode to “True”.  In our initial discussions, I’d been informed that this was not required in the SIP Trunking use case, but this ultimately did not prove to be the case.  After doing this, the translation pattern kicked in and that elusive MWI lit up immediately.

Tagged , , , , , ,
Collaboration Engineer

All things Collaboration - Posts to save for when you need them

Gerry Keleghan's Blog

A Blog about Cisco Unified Communications

ccieme

my personal journey to ccie

Striving for greatness

Thoughts on emerging tech, open source, and life

Network Experts Blog

“Knowledge comes by eyes always open and working hands.”

SIP Adventures

A unified communications blog by Andrew Prokop

The Cloverhound Blog

Cloverhound Employees Talk Unified Communications and Contact Center

Warcop

Fog navigator. Get out of the clouds. Down to earth solutions. @Warcop

Cisco Collab Engineering Tips

Michael White - CCIE #26626

Darkroomstory

Photography by Manos,

afterthenumber

Thoughts and experiences of a Cisco Collaboration engineer after clearing the CCIE lab...

Longreads

The best longform stories on the web

The Daily Post

The Art and Craft of Blogging

The WordPress.com Blog

The latest news on WordPress.com and the WordPress community.