Configure and Troubleshoot Call Forward to the PSTN using SIP Trunks

[Andrew Latamore]

Introduction

With the increased usage of mobility features and work from home scenarios, there is increased demand for the ability to transfer incoming calls from the PSTN back out to different PSTN destinations.  When using SIP trunks for PSTN connectivity these calling scenarios often fail due to call validation.  This document is a guide to configuration and troubleshooting of these call flows.

Core Issue

All outbound PSTN SIP calls are validated by the SIP Trunk provider to ensure the calls are valid and not toll fraud attempts.  The methods of call validation can vary from provider to provider, and many involve multiple methods for the same call.  This becomes a concern when using the default settings in a CUCM w/CUBE topology and attempting to call forward an inbound PSTN call back out to the PSTN.  One of the most common validation methods is for the SIP provider to examine the "From" field in the incoming INVITE of a call and make sure it matches to a known DID number for that customer.  The default setting in CUCM for forwarding calls is to maintain the CLID of the calling originator.  This causes the "From" field of an outgoing INVITE to contain the CLID number of the original PSTN caller, and not a valid DID belonging to the customer.  When the provider sees this with no additional information, it typically will reject the call setup attempt or ignore it completely.

Resolution

There are three common solutions to this issue. 

The first is to alter the "From" field so that the CUCM will send the information of the redirecting number instead of the call originator.  In this scenario the "From" field will contain a valid customer DID number, and the call will validate.  The advantage of this technique is that it works with virtually all SIP providers.  The disadvantage is that the receiving party of the forwarded call will only see the caller-ID of the number that was set to forward (typically their own office DID number).  They will not see the caller-ID of the original caller, and therefore will not know who is calling prior to answering the call. 

Here are the steps to use the first method:

-Navigate to the SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Change the value in the drop down entitled "Calling Party Selection" to "Last Redirect Number (External)"
-Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours)

A second method is also often used, though it requires the SIP provider to validate calls through a different method.  This technique involves adding a p-asserted identity line in the outbound INVITE containing a valid DID.  The advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.  The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the p-asserted identity value instead of the "from" field value. 

Here are the steps to use the second technique when using a CUBE gateway:

-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.  Also make sure to use a valid DID number and SBC URL information.)

voice class sip-profiles 1
request INVITE sip-header P-Asserted-Identity add "P-Asserted-Identity:<sip:1111111111@sbc.sipprovider.com>"

-Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider.  Also, most providers will look for a fully qualified domain name in the PAI, as opposed to an IP address.  Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address.

The third method is similar to the second but instead of a PAI line, this uses a Diversion Header.  The Diversion Header is added to the outbound INVITE and contains a DID number that the provider can validate the call with.  Like with the second option, the advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.  The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the diversion header value instead of the "from" field value. 

Here are the steps to use the third technique when using a CUBE gateway:

-Navigate to SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Check the "Redirecting Diversion Header Delivery - Outbound" Check box
-Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours)
-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.  Also make sure to use a valid DID number and SBC URL information.)

voice class sip-profiles 1
request INVITE sip-header Diversion modify "<sip:(.*)@(.*)>" "<sip:1111111111@sbc.sipprovider.com>"

-Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider.  Also, most providers will look for a fully qualified domain name in the diversion header, as opposed to an IP address.  Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address.

Troubleshooting
The following debugs are useful in this call scenario:
debug ccsip messages
debug voip ccapi inout

When reading these debugs keeping the different call legs straight can get confusing.  It is recommended to use an application such as Notepad ++, and to mark the Call ID of each call leg traversing the CUBE.  The goal of these debugs is to check that the outbound INVITE for the forwarded call contains either the correct "from" field, or the correct "p-asserted identity" or "diversion header" field.  If using the "from" field method, check that the SIP INVITE coming from the CUCM contains the full 10 digit DID number for the last redirecting party, and that this value is the same in the INVITE going to the provider.  If using either the "p-asserted identity" method or the "diversion header" method, make sure that the outgoing call is matching the correct dial-peer that has the voice-class sip profile set on it.  If it is matching a different dial-peer, add the sip profile to that dial-peer.

Related Information

SIP Profiles on CUBE Configuration Guide
http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080982499.shtml

CUCM Trunk Configuration - Search for "Calling Party Selection"
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmcfg/b06trunk.html

[Aomar bahloul]

Hi,

Will your solution preserve the original calling number?

Thank you.

Aomar.

[Aomar bahloul]

This worked for me on an ATT sip trunk. Initially ATT recommended to use PAI we tried many syntax but none worked. I decided to give this a try and it worked. Also I didn't have to change my SIP trunk config on CUCM.

I confirmed that it will preserve the original caller number.

Thank you very much for sharing.

Aomar.

[tkuehner1]

---

@Andrew Latamore wrote:

Introduction

With the increased usage of mobility features and work from home scenarios, there is increased demand for the ability to transfer incoming calls from the PSTN back out to different PSTN destinations.  When using SIP trunks for PSTN connectivity these calling scenarios often fail due to call validation.  This document is a guide to configuration and troubleshooting of these call flows.

Core Issue

All outbound PSTN SIP calls are validated by the SIP Trunk provider to ensure the calls are valid and not toll fraud attempts.  The methods of call validation can vary from provider to provider, and many involve multiple methods for the same call.  This becomes a concern when using the default settings in a CUCM w/CUBE topology and attempting to call forward an inbound PSTN call back out to the PSTN.  One of the most common validation methods is for the SIP provider to examine the "From" field in the incoming INVITE of a call and make sure it matches to a known DID number for that customer.  The default setting in CUCM for forwarding calls is to maintain the CLID of the calling originator.  This causes the "From" field of an outgoing INVITE to contain the CLID number of the original PSTN caller, and not a valid DID belonging to the customer.  When the provider sees this with no additional information, it typically will reject the call setup attempt or ignore it completely.

Resolution

There are three common solutions to this issue. 

The first is to alter the "From" field so that the CUCM will send the information of the redirecting number instead of the call originator.  In this scenario the "From" field will contain a valid customer DID number, and the call will validate.  The advantage of this technique is that it works with virtually all SIP providers.  The disadvantage is that the receiving party of the forwarded call will only see the caller-ID of the number that was set to forward (typically their own office DID number).  They will not see the caller-ID of the original caller, and therefore will not know who is calling prior to answering the call. 

Here are the steps to use the first method:

-Navigate to the SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Change the value in the drop down entitled "Calling Party Selection" to "Last Redirect Number (External)"
-Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours)

A second method is also often used, though it requires the SIP provider to validate calls through a different method.  This technique involves adding a p-asserted identity line in the outbound INVITE containing a valid DID.  The advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.  The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the p-asserted identity value instead of the "from" field value. 

Here are the steps to use the second technique when using a CUBE gateway:

-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.  Also make sure to use a valid DID number and SBC URL information.)

voice class sip-profiles 1
request INVITE sip-header P-Asserted-Identity add "P-Asserted-Identity:<sip:1111111111@sbc.sipprovider.com>"

-Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider.  Also, most providers will look for a fully qualified domain name in the PAI, as opposed to an IP address.  Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address.

The third method is similar to the second but instead of a PAI line, this uses a Diversion Header.  The Diversion Header is added to the outbound INVITE and contains a DID number that the provider can validate the call with.  Like with the second option, the advantage of this technique is that the "From" field retains the calling originator's information so that the recipient of the call can see who is calling on their caller-ID.  The disadvantage of this technique is that it is not universally used, and customers need to check with their SIP providers to make sure they will validate calls based on the diversion header value instead of the "from" field value. 

Here are the steps to use the third technique when using a CUBE gateway:

-Navigate to SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Check the "Redirecting Diversion Header Delivery - Outbound" Check box
-Save the change, and apply the change (may drop calls why you press apply, so be careful with this change during business hours)
-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing SIP profiles, or add it to your outbound SIP profile in use.  Also make sure to use a valid DID number and SBC URL information.)

voice class sip-profiles 1
request INVITE sip-header Diversion modify "<sip:(.*)@(.*)>" "<sip:1111111111@sbc.sipprovider.com>"

-Add the following configuration line to the dial-peer being matched to place the outbound call to the SIP provider:

voice-class sip profiles 1

Make sure that the SIP Profile contains a valid DID with your SIP provider.  Also, most providers will look for a fully qualified domain name in the diversion header, as opposed to an IP address.  Be use to use the FQDN in the profile, even if you are routing the calls directly to the provider's IP address.

Troubleshooting
The following debugs are useful in this call scenario:
debug ccsip messages
debug voip ccapi inout

When reading these debugs keeping the different call legs straight can get confusing.  It is recommended to use an application such as Notepad ++, and to mark the Call ID of each call leg traversing the CUBE.  The goal of these debugs is to check that the outbound INVITE for the forwarded call contains either the correct "from" field, or the correct "p-asserted identity" or "diversion header" field.  If using the "from" field method, check that the SIP INVITE coming from the CUCM contains the full 10 digit DID number for the last redirecting party, and that this value is the same in the INVITE going to the provider.  If using either the "p-asserted identity" method or the "diversion header" method, make sure that the outgoing call is matching the correct dial-peer that has the voice-class sip profile set on it.  If it is matching a different dial-peer, add the sip profile to that dial-peer.

 

Related Information

SIP Profiles on CUBE Configuration Guide
http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_configuration_example09186a0080982499.shtml

CUCM Trunk Configuration - Search for "Calling Party Selection"
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmcfg/b06trunk.html

---

Hi All

The best solution here would be a Lua script, masking conditionally using an if statement.  I have done this on numerous occasions.

The key benefit is to prevent interference with VM systems and where Diversions are useful for SNR situations.  The following code (may need some teaking) should suffice:

M = {}

trace.enable()
function M.outbound_INVITE(msg)

local issuepatternordn = scriptParameters.getValue("issuepatternordn")
local replacement = scriptParameters.getValue("replacement")
local diversion = msg:getHeader("Diversion") 

if diversion and diversion:find(issuepatternordn) then
trace.format("Successful match for issue pattern in diversion - applying masking")
msg:applyNumberMask("Diversion", replacement)
end
end

return M

Use "issuepatternordn" to include the offending regex string.

This is very similar to the sip profiles method on the CUBE, but wins as it can be extended to allow for non-trivial requirements more easily as you have coding logic at your disposal.

Jonathan/Andrew,

I am pretty new to LUA scripting but I agree that would probably be the best solution.  Can you please let me know what you would put in if valid DID is, for example, 5553333111.  Thank you.

[KY_]

Hi

Is it possible to block incoming redirected number which is contain diversion header ?

Thanks

[KY_]

Hi Team

I have a question about diversion header on cube, can we configure dievrsion header voice translation rule instead of cucm calling party transformation mask so i think t his should be possible but i can not archive it.

This is example configure which i copied from cube doc but it did not work for me.

voice translation-rule 4
rule 1 /^\(2....\)$/ /91939\1/
voice translation-profile outbound-translations
translate calling 1
translate redirect-called 4

dial-peer voice 5000 voip
description "Outbound dial-peer for external calls"
translation-profile outgoing outbound-translations
destination-pattern [2-9].......

6187673: Dec 26 21:16:42.273: //-1/10615E800000/DPM/dpMatchPeersMoreArg:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=5000
...
6187687: Dec 26 21:16:42.273: //-1/10615E800000/RXRULE/regxrule_profile_translate_
internal: number=26003 type=unknown plan=unknown numbertype=redirect-called
6187688: Dec 26 21:16:42.273: //-1/10615E800000/RXRULE/regxrule_profile_match_
internal: Matched with rule 1 in ruleset 4
6187689: Dec 26 21:16:42.273: //-1/10615E800000/RXRULE/regxrule_profile_match_
internal: Matched with rule 1 in ruleset 4
6187690: Dec 26 21:16:42.273: //-1/10615E800000/RXRULE/sed_subst: Successful
substitution; pattern=26003 matchPattern=^(2....)$ replacePattern=91939\1 replaced
pattern=9193926003
.......
.......
6187715: Dec 26 21:16:42.275: //154516/10615E800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:9193927003@192.168.202.164:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.202.165:5060;branch=z9hG4bK25B10102D
Remote-Party-ID: <sip:4083926001@192.168.202.165>;party=calling;screen=yes;
privacy=off
From: <sip:4083926001@172.18.110.119>;tag=787763BE-1354
To: <sip:9193927003@192.168.202.164>
Date: Tue, 26 Dec 2017 21:16:42 GMT
Call-ID: E7598E64-E9B811E7-B9149A97-7107F84E@192.168.202.165
...
Diversion: <sip:9193926003@192.168.202.165>;privacy=off;reason=unconditional;
screen=yes
Session-ID: f538138405505557b8f647ab3c

Thanks

[jacky.reinbold]

Hello Andrew,

This is a very interesting document, and I will add one more chalenge.

In my case, the customer has 16 sites and lines registering their 16 credentials and realms on one trunk.  All sites are using call forward back to the ISP, expecting to see the originating calling number on the destination phone or mobile in the PSTN.

1/The validation header for the ISP is one of the the 16 Contact header depending on which site is using CFWDALL. Each Contact header ist modified manually in 16 outgoing SIP profiles.

2/ The incoming 16 CUBE Dialpeers (from **bleep** to CUBE) for the forwarded calls are configured  to match only the welknown incoming 16 site phone numbers, providing the right expected Contact header.

Problem:

the incoming and forwarded originator number does not match the incoming Dialpeer mask, and is searching a coincidence output to ISP. 

Result: CFWD is done with a wrong Contact header and fails mostly, because it it trying any of the 16 Dialpeers and outgoing profiles.  Sometimes it's working, but it is pure coincidence, because it it trying the right DP.

3/ The challenge is not resolved yet and is to route correctly the originator number on the incoming CUBE DP and to select the right contact header  sip profile for the outgoing way to ISP.

4/ The idea would be to use last redirect number instead of the originator on the CUCM trunk, to match correctly any of the 16 incoming DP. on CUBE,

but the challenge here, would be to restore the originator ID on the second forwarded call leg to ISP.

As I know, copylist inbound and variables are only shared and working on the same call leg, inbound to cube and outbound from cube.

But what to do, if I need to store the originator on an outbound DP first (CUBE to CUCM) and to restore the originator value on the second call leg, on the inbound DP to CUBE, after the call forwarding ?

I would call this a kind of originator bypass  for the time of the last redirect CFWD and DP routing.

I have no answer on how to resolve this challenge.

Perhaps you have an idea in this forum ?

Thany you