Calling Party Routing of Anonymous Calls SIP Header Fix Up

Cisco’s “Route Next Hop By Calling Party Number” translation pattern option has addressed the common question of “how do I route or block calls based on Caller ID?” since CUCM version 8.  However, there still remains a limitation and that is how to deal with “Anonymous”, “Restricted” or “Unknown” Calling Numbers.  The problem is that the SIP information actually lists this as part of the From header where CUCM typically would expect to see a numeric value.  As an example, talk a look at this SIP invite:

INVITE sip:4085555555@1.2.3.4:61482 SIP/2.0
Via: SIP/2.0/UDP 5.6.7.8:5060;branch=z9hG4bK1439e2a1;rport
Max-Forwards: 70
From: "Anonymous" <sip:Anonymous@5.6.7.8>;;tag=as3bcef15a
To: <sip:4085555555@1.2.3.4:61482>
Contact: <sip:Anonymous@5.6.7.8:5060>
Call-ID: 6de2e4442c4ac0575ec457e518f1e609@5.6.7.8:5060
CSeq: 102 INVITE
User-Agent: voip.ms
Date: Thu, 10 Aug 2017 22:30:21 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "Anonymous" <sip:Anonymous@5.6.7.8>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 266

The bad news is this won’t be consumable by Unified Communications Manager in this present format.  The good news, however, is that this can be fixed a few different ways.  The most common I have found online is to write a SIP normalization script and apply it to the SIP trunk coming into CUCM.  There are a few problems with this.  One, normalization scripts are complicated, particularly if you’re not a programmer.  The second, and most compelling to an organization with serious reliance on their call control platform is that custom scripts aren’t supported by Cisco TAC.

The second mechanism is by far easier and actually off loads all the SIP normalization functions to the place they belong, the session boarder controller, aka Cisco CUBE.

CUBE allows regular expression matching header messages as well as the ability to change that header messages.  Often we see this use case when working with a carrier that doesn’t support a particular header or header format.  In this case our own Cisco system doesn’t like the format so it’s game on.

To change a header you need to use a SIP profile.  You can find some solid documentation on SIP profiles on Cisco’s website HERE.

To cut to the chase I used a SIP profile configuration to simply remove “Anonymous” and put a 10 digit Calling Party number in its place.  In my case I used “0000000000”.

voice class sip-profiles 1
request INVITE sip-header From modify "<sip:Anonymous@" "<sip:0000000000@"

 

This profile then will need to be applied to a dial-peer somewhere in the call flow.  I pick it up on the incoming dial peer with the “voice-class sip profiles” option.  My example dial-peer is below.

dial-peer voice 50 voip
 session protocol sipv2
 incoming called-number .
 voice-class sip profiles 1 inbound
 dtmf-relay rtp-nte sip-notify
 codec g711ulaw

 

I chose to manipulate this on the inbound dial-peer so translation profiles could then be used later in outbound dial-peers if there was a need.  Scripting crisis also adverted.  I hope you found this useful!

 

This entry was posted in Collaboration, Telephony and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *