Calling Party Routing of Anonymous Calls SIP Header Fix Up

Posted on August 11, 2017

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!

5 comments

  • Ahmad Kefaya says:

    Thanks alot for your help, very helpful, but This configuration is missing this command:
    voice service voip
    sip
    sip-profiles inbound
    exit
    ================================
    OR i do it Global not under dial-peer, like the below:

    voice service voip
    sip
    sip-profiles inbound
    sip-profiles 10 inbound
    exit

    voice class sip-profiles 10
    request ANY sip-header From modify “<sip:anonymous@" "<sip:+00000000000@"

    i hope that will help some one

    Regards,
    Ahmad Kefaya

    • Adam says:

      Thanks!! I assumed everyone had the global config but it certainly is worth having here for completeness. Glad it helped!

  • Gary Parker says:

    Thanks, this was super helpful! I had to do a little bit more to get it working on our system, though. Looking at the SIP traces I saw that we were receiving:

    From:

    As I match traffic on my inbound dial-peer by URI I also had to rewrite the portion to the right of the ‘@’. I’ve got two possible endpoints that could be sending me calls, so couldn’t just put in a static address. Fortunately the “Contact:” field held the correct IP address, so I could just copy it out of there and include in the rewrite:

    rule 1 request ANY sip-header Contact copy “@(.*):” u01
    rule 2 request ANY sip-header From modify “” “”

    The Cisco SIP-Profile Test Tool is invaluable for testing these without tinkering with your live system!
    https://cway.cisco.com/tools/SipProfileTest/

  • Pingback: Your Name’s Not On The List… – Gary's Blog
  • Adam says:

    Great stuff, thanks!!

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Copyright © 2026 | All Rights Reserved Design By: Patrickoslo