Cisco Unified Border Element Diversion Header

In HQ-CUCM, navigate to Device > Device Settings > SIP Profile. Create a new SIP Profile named SIP Profile CUBE and enable the SIP Option.

Navigate to System > Security > SIP Trunk Security Profile. Create a new SIP Trunk Security Profile named SIP_Trunk_Security_Profile_CUBE.

Navigate to Device > Trunk. Create a SIP Trunk named vCUBE that points to the IP address of CUBE.

Under the SIP Information enter the IP address of the CUBE 10.1.5.252 in the Destination Address field.

In the SIP Profile section, select the SIP Profile named Named SIP Profile CUBE.

In the SIP Trunk Security Profile section, select the security profile named SIP_Trunk_Security_Profile_CUBE.

Navigate to Call Routing > Route/Hunt > Route Pattern and create a route pattern 9.! in the partition HQ-PT. Make sure the phones has the device or line CSS that includes the HQ-PT partition.

In the Calling Party Transformations section configure the Calling Party Transform Mask 2126774XXXXX.

In the Called Party Transformations section select the PreDot in the Discard Digits.

Access the CUBE using CLI, enter the following command.

Configure the CUBE to bind media and signaling to G1 interface. Use TCP as default protocol for SIP signaling with the following commands.

Using the binding on the voice service configuration mode, this means that you dont need to configure the binding on each dial peer.

voice service voip

sip

voice service voip

mode border-element

 allow-connections h323 to sip

 allow-connections sip to h323

 allow-connections sip to sip

 sip

  bind control source-interface GigabitEthernet1

  bind media source-interface GigabitEthernet1

  session transport tcp

  header-passing

  error-passthru

  pass-thru content sdp

Configure the following dial peers on CUBE to route call to PSTN.

dial-peer voice 11 voip

 destination-pattern 11…

 session protocol sipv2

 session target ipv4:10.1.5.15

 dtmf-relay rtp-nte sip-kpml sip-notify

!

dial-peer voice 51 voip

 destination-pattern 51…

 session protocol sipv2

 session target ipv4:10.1.5.15

 dtmf-relay rtp-nte sip-kpml sip-notify

!

dial-peer voice 9011 voip

 destination-pattern 011T

 session protocol sipv2

 session target ipv4:10.1.140.2

 dtmf-relay rtp-nte sip-kpml sip-notify

!

dial-peer voice 911 voip

 destination-pattern 911

 session protocol sipv2

 session target ipv4:10.1.140.2

 voice-class sip early-offer forced

 dtmf-relay rtp-nte sip-kpml sip-notify

!

dial-peer voice 100 voip

 session protocol sipv2

 session target ipv4:10.1.140.2

 incoming called-number .

 dtmf-relay rtp-nte sip-kpml sip-notify

!

dial-peer voice 212 voip

 destination-pattern 212677…..

 session protocol sipv2

 session target ipv4:10.1.5.15

 dtmf-relay rtp-nte sip-kpml sip-notify

!

dial-peer voice 408 voip

 destination-pattern 1408…….

 session protocol sipv2

 session target ipv4:10.1.140.2

 dtmf-relay rtp-nte sip-kpml sip-notify

!

dial-peer voice 813 voip

 destination-pattern 1813…….

 session protocol sipv2

 session target ipv4:10.1.140.2

dtmf-relay rtp-nte sip-kpml sip-notify

Enable the debug ccsip messages command.

From the US Phone 11001, call the international number 14082347788. On PSTN Phone, the line National-SJ should ring.

From the output you can see that the outgoing SIP INVITE message (in the second SIP INVITE) is using TCP as the transport type, and you can see that the calling number 212677411001 in From field with the IP address 10.1.5.252 of the Cisco CUBE and the called number 14082347788 in the To field with the IP address 10.1.140.2 of the ITSP call processing server.

On the CUBE, enter the command show voip rtp connections to show the active RTP streams. You will see output similar to the following.

From the Cisco Jabber Client jdoe@lab.local 51001, call the international number 14082347788. On PSTN Phone, the line National-SJ should ring.

On the CUBE, enter the command show voip rtp connections to show the active RTP streams. You will see output similar to the following.

For more details about the call, enter the command show voip rtp connection detail.

When a user forwards his phone (US Phone 11001) to his mobile phone (PSTN 918136661234) the call fails. The user wants you to resolve this issue, and to send the originating calling number to his phone. This means the calling number of the person that dialed his Office phone (US Phone).

When we have calls forwarded to the PSTN, such as a mobile phone, the calling number sent to the PSTN is the originating number that called your office extension. If the originating number is an external number, the PSTN will not recognize it, and therefore the call will be rejected by ITSP. Most ITSPs support any calling number being sent over the PSTN, if we present the diversion number as the local number. This is why we need to add the DIVERSION header to outgoing call toward ITSP, if you want to allowsuch redirected calls and at the same time have a correct presentation number on your redirecting device(Mobile phone for example).

To do that edit the SIP Trunk that points to CUBE and on the Outboung Calls section, enable the Redirecting Diversion Header Delivery option as shown below.

Edit the US Phone, and the Directory Number, configure call forwarding as follow:

Forward > All Destination: 918136661234.

On the CUBE, execute the debug ccsip message command to collect SIP traces.

On PSTN Phone dials the PSTN number of US Phone 212677411001, the call should be forwarded to Mobile-US 918136661234. In a real scenario this call will fail.

Why ?  let’s verify the debug ccsip messages command output, we can see the SIP INVITE fo redirected call from HQ-CUCM including the diversion header with 11001, however we can see that the calling number and the called number, and the diversion number 11001 from the SIP INVITE on the outgoing call sent by the CUBE 10.1.5.252, the ITSP does not recognize the calling number as the number from your organization, and therefore rejects the call. However, the ITSP supports sending any calling number in the From field, as long as you provide your PSTN number in the diversion header. The call will be rejected for two reasons. The calling and diversion numbers are unrecognized by the ITSP. We need to correct at least one. If we change the calling number to your PSTN number, then you will not know who calling your number (the US Phone’s Mobile number), after it is redirected to PSTN number. Best would be to correct diversion number to correct format, and allow passing unrecognized calling number by your ITSP to redirected number. In this way you will see the originating number on the mobile phone.

On CUBE, configure a SIP profile as follow.

The SIP profile will modify an outgoing SIP INVITE generated the CUBE, if it contains the Diversion header. In the first part, we configure a matching rule. The configuration below matches anything followed by “<sip” value, and also anything untill the “@” sign. In the second part, we configure a replace rule. We will replace everything we have matched with this rule. The configuration replaces whatever number is presented in the diversion to 212677411001 number. This is the requirement from the ITSP, therefore the SIP profile should be configured in the outgoing dial peers toward ITSP.

On PSTN Phone dials the PSTN number of US Phone 212677411001, the call should be forwarded to Mobile-US.

Verify the debug output on CUBE.

We can see that the Call is ringing on the PSTN Phone on the line Mobile-US. The debug output of CUBE, we can see the SIP INVITE to redirected call from HQ-CUCM including the diversion header with 11001. However, this is changed on the outgoing SIP INVITE message from CUBE to ITSP with the diversion header 212677411001.

Published by:

Redouane MEDDANE

Redouane MEDDANE is Cisco Instructor CCSI #35458, 3xCCNP Collaboration, Security and Enterprise and he a published author of some of the most important OSPF Protocol, Security and Collaboration books in the world titled OSPF Demystified With RFC, Network Security All-in-one, and Dial Plan and Call Routing Demystified on CUCM. He is also a blogger at ipdemystify.com and writes articles about collaboration and security to demystify the most complex topics. His books are known for their technical depth and accuracy especially the OSPF Demystified With RFC book, which is considered as the best OSPF book in the world and named "One of the best OSPF ebooks of all time" by BookAuthority It gives you a hint at the ability to explain complex topics with remarkable ease. He worked as a Cisco Instructor and consultant indifferent Cisco Learning Partner and awarded twice as Cisco Distinguished Instructor Award and Cisco Security Instructor Excellence Award on 2018 and 2019, and Cisco Collaboration Instructor Excellence Award on 2020. The Distinguished Instructor Award recognizes the top 5% of Cisco's most influential CCSI's who provide the highest quality training experience and demonstrate the best overall instructor performance across multiple Cisco technologie and Instructor Excellence Award recognizes the top 25% of elite CCSIs being recognized for delivering top quality training and maintaining high customer satisfaction in their field of expertise.

Categories CollaborationLeave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s