CUBE: Conditional SIP Profiles

Some interesting enhancement on the Unified Border Element 8.6 I run into lately is ‘Conditional SIP Header Manipulation’. One of the roles of the CUBE is to normalize incoming SIP requests to your IP Telephony server.

Cisco Unified Border Element 8.6 adds support for manipulation of one SIP header based on the contents of another SIP header. This feature extends the SIP profile function that is already available on the Cisco Unified Border Element. It includes the capability to copy the contents of one header to another, or modify the contents of one header based on the contents of another. SIP headers on the out-leg can be modified based on the contents of any SIP header on any SIP message received on the in-leg.

Lets look at a practical application of this feature.

Some providers send in the SIP-URI a global reference number and only place the phone destination number in To: SIP header.Typically the CUCM is routing on the URI. So how to normalize the SIP header in that case?

Lets look at an incoming SIP invite:

INVITE sip:43565432A5@ SIP/2.0

From: <;user=phone>;

To: <>

The URI 43565432A5 is non-routable  and with the header manipulation we want to replace it with the 25555552, the real number to reach.

So how do we solve this?

The possible steps:

-> Copy the TO: header from the incoming invite to a variable

-> Translate the incoming URI to a routable number

-> Match this now routable number with a outgoing dial-peer

-> Apply a SIP normalization profile on the outgoing dial-peer

-> The SIP profile copies the number of the original TO: variable to the URI of

the outgoing invite

-> Cisco CUCM receives a normalized URI.

With this we want to obtain:

INVITE sip: 25555552@ SIP/2.0

From: <;user=phone>;

To: <>

Let us look at the important parts of the configuration.

First of all how do we catch the incoming SIP invites seen its non-routable ?

On an incoming dial-peer multiple methods are possible, in this example we took the user-id field. Another method could be to catch it based on the source ip address.

voice class uri TRUNK sip

user-id 2555555.

This command has a set of rules by which the URI in a call is matched to a dial peer using the tag TRUNK in this example.  2555555. represents the number range off our CUCM.

Next step is to copy the sip-header TO.

voice class sip-copylist 1

sip-header TO

One translates the SIP-URI to a routable number as to be able to match an outgoing dial-peer later on.

voice translation-rule 9

rule 1 /43565432.*/ /025555550/

voice translation-profile Incoming

translate called 1

We apply all off the previous to our incoming dial-peer:

dial-peer voice 99 voip

description incoming SIP Trunk

translation-profile incoming Incoming

session protocol sipv2

session target sip-server

incoming uri to TRUNK

voice-class codec 1

voice-class sip copy-list 1

Note: The translation happens after the copy-list.

The incoming invite is matched to a outgoing dial-peer. Remember the CUBE is a back-to-back UA. It is on this outgoing dial-peer we can apply the ‘service profile’. The service profile typically allows you todo add, delete, match and replace on a header. Moreover now we can copy variables!

voice class sip-profiles 1

request INVITE peer-header sip TO copy “sip:(.*)@” u01

request INVITE sip-header SIP-Req-URI modify “.*@(.*)” “INVITE sip:\u01@\1”

The u01 is a variable that is populated with the number (.*) in this case 25555552 from our peer-header.  This variable is then used to modify the SIP-Req-URI for the outgoing invite.

We apply this on our outgoing dial-peer:

dial-peer voice 1 voip

description to/from cucm publisher

destination-pattern 02555555.

session protocol sipv2

session target ipv4:

voice-class codec 1

voice-class sip profiles 1

dtmf-relay rtp-nte

no vad

As you see with the new enhancements on the SIP profiles one can store temporary variables from an incoming SIP invite to be reused later.  Its worth while to look at the other recent enhancements of the Cisco CUBE.  Especially in releases 15.1(2)T and 15.1(3)T.

For more information on IOS 15.1(3)T release:

For information on Cisco CUBE:


4 Responses

  1. Hello,
    I have a similar but somewhat different scenario. The topology applies but in my case it goes out PRI’s matched by different dial-peers on the router instead of CUCM.

    SIP providerRouterPRI with 5 digit extensions on router.

    You lost me when you said “2555555. represents the number range off our CUCM.” Aren’t ranges in form of wilcards? example “2……..”? You seem to be using a particular number on the CUCM. Please correct me if am wrong. This will not be visible with lets say a 100 lines.

  2. your correct, in the above example a specific range was used while real life you’d use a pattern to match UCM numbers.

  3. Hi Jerome, thanks for the tut. Is it possible to make this manipulation with CUBE and CME in one router?

    And a small correction, I think the translation-rule is 9, not 1 at the translation-profile.

Comments are closed.

%d bloggers like this: