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

[mujeeb_khan]

Good Document.

[Michael Whaley]

Great write-up! I would urge caution on the Diversion Header (DH) method. We had our SIP provider recommend this method, and it messed up voicemail systems on the far-end like crazy because that modified DH was carried through to the called party. In our testing, if the called party answered the call, there was no issue, but if their voicemail system was SIP connected, that DH field was passed right on through and the voicemail system no longer knew what mailbox to play the greeting for.

I would highly recommend customers push back if your provider tries to get you to use DH. You will save yourself lots of headaches.

[Andrew Latamore]

I agree completely on the diversion header situation.  We often see situations exactly as you describe, where the diversion header is carried throughout the provider network (and beyond), then causes issues when hitting VM systems at the far end. 

The issue described most often happens when people use either a SIP profile to add a diversion header, or use a voice translation profile adding a redirecting number value.  These scenarios will cause the CUBE to send a diversion header on all outbound calls, regardless if they are actually diverted calls or not.

The writeup I have in the doc here is for the best compromise technique.  We have the CUCM add the diversion header, and the CUBE modify it to the correct value.  The CUBE alone has no way to know if a call is redirected, but the CUCM does.  So when you have the CUCM add the diversion header, it will only do so on calls that are actually redirected.  Normal, non-redirected, outbound calls will not get a diversion header.  Unfortunately the CUCM will not send the full E164 number in the diversion header (at least not at this point).  So by using a modify SIP profile on the CUBE, the diversion header will only be changed if it is already present.  If the CUCM does not add it, the CUBE will not add on either.  So this way we only add a diversion header on actual redirected calls.  While you still might run into the issue described, it is much less likely since you would only have the problem on a redirected call.  Most users will use mobility or CFA to send calls to a mobile or home line and not to another business office.  So it is not perfect, but better than sending out the diversion header on all calls.  The PAI option does not have this risk, but the option chosen has a lot to do with what your SIP provider supports for call validation.

Thanks for the kind comments on the doc!

[Ingo de Jager]

I found this document while trying to do exactly what Andrew describes here. Looking at Method #2 we would want to modify the P-Asserted-Identity to show the original called number. We need this so that we know who to bill for the call being forwarded out back to the PSTN. Method #2 states that you need to use a valid number but it seems to be fixed to EG. "P-Asserted Identity:<sip:1111111111@sbc.sipprovider.com>" used in the example. How can I change Method #2 to us the original called number? If I use a fixed number then that one number will be billed for all the forwarded calls out to the PSTN.

[WSonnylal]

Thanks for the good writeup, I recently used this to add a diversion header to outbound calls via an AT&T SIP Trunk on a CUBE.  In my case calls to Toll Free numbers were being rejected on the AT&T trunk.  I tried formatting the diversion header as in method 3 above replacing the values specific to my environment and it did not work.  I used the following below and this worked in my environment.  I did not need to enable the Diversion Header delivery on the SIP Trunk in UCM as well.

request INVITE sip-header From modify "From:(.*)<sip:(.*)@(.*)" "From:\1<sip:\2@\3\x0ADiversion: <sip:5552223333@11.22.33.44>;privacy=off;reason=unconditional;counter=1;screen=no

where 5552223333 is a DID on the AT&T Trunk and 11.22.33.44 is my peer interface IP on my CUBE router with AT&T.

[frantzdesrivieres]

Outstanding document.  Very specific on what changes need to be made, why the change needs to be made and the draw backs of each solution.  Great Great write up...............

[travlmoore]

Thank you for posting this!  I am also working with an AT&T SIP trunk and I was able to use your post as a template for fixing issues we have encountered.

[luke.maxwell]

Thanks for this, Is it possible for me to have two SIP trunks for the CUBE from CUCM, the first set to use 'first redirect number' and the second to use 'originator'

Both would use a different route pattern via CSS etc to get the calls to forward but I want to run both scnerios on the same CUBE/CUCM/SIP Trunk.

I know I can'd add the same IP Address twice so could I use DNS to get around that restriction?

If not is there any other way to acheive this?

[Andrew Latamore]

There is another way to get around this.  If you create a loopback interface on the CUBE with an IP address which is routable in the network then you can have 2 separate SIP trunks in CUCM which point to the same CUBE.  You will probably need to work out the dial-peers with bind statements to ensure the traffic leaving CUBE for CUCM (on inbound calls) uses the appropriate SIP trunks.

[luke.maxwell]

Hi I just added a DNS name to the second trunk in the end and it worked fine. So trunk 1 is set to keep the called number in call fordwar CLI and trunk 2 will retain the orifinal CLI.

[Jonathan Els]

Hi All

The best solution here would be a Lua script, masking conditionally using an if statement.  I have done this on numerus 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 yoru disposal.

 - Jonathan

[Andrew Latamore]

Great comment Jonathan!  I agree, LUA scripting is a very powerful tool and allows for a more graceful solution.  My only concern is that for many users it is a stretch of their technical skills.  However, with your script as a template it should provide another great option for folks running into this problem.  Thank you very much!

[Gustavo Moreschi]

Great document. I was wondering if there is a work around for H323 as well.

I tried all possible ways to send the original callerID via CFW to the PSTN with no success.

It always shows either main number or callerID from my office, but never from the external originator callerID.

I tried to add another rule 2 for voice translation in order to pass as it comes, but again the same results:

voice translation-rule 1
rule 1 /^7412/ /412208/ (valid DID)
rule 2 // // (pass as it is for redirect CFW calls back to PSTN)

ps: I checked and my provider allows me to send whatever callerID back to the PSTN.

I also tried those translate callback-number/redirect under voice translation-profile, but no success. 

Please let me know if someone knows if is possible to show the originator calledID when the call is being forward back to the PSTN via H323.

Thank you!

Gustavo

[abdul rasheed]

Dear Andrew Latamore,

I am getting Temporarily Unavailable (480) message from call manager to the CUBE while I am configuring CFNA. I connect to the ISTP through cisco CUBE. Please help me to sort it out.

Thanks and Best Regards

[Aamer Ainapore]

Excellent post Andrew... helped me.