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:
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
Date: Mon, 07 Dec 2015 08:38:09 GMT
CSeq: 200 INVITE
Reason: Q.850; cause=21
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:
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.