Solved: call GW -> ICM -> CUCM -> CFA failing

Keith Abbott · ‎10-23-2019

Hi group,

I hope you can help - I am totally stumped on this.

The scenario is:

A caller calls a toll-free number. The call hits a cisco gateway where it is pointed to an ICM script.

The script has an option that allows the caller to enter a 5-digit extension to go directly to an individual (Bob - option 9 5digit exten 55262). The script then builds a label to forward the call to the desired extension. All of that works perfectly. If Bob's extension is not forwarded, the call rings through to Bob and he is able to answer it.

In this case, the Bob's extension is CFA'd to an external number - Bob's cell.

If Bob calls his cell phone from his desk phone the call completes successfully.

If an internal caller dials Bobs extension - the call successfully forwards to Bobs cellphone. (Bob doesn't not have a DID that points directly to his extension)

However when the call comes via the route described above - through UCCE, after entering Bobs 5-digit extension, the call drops within seconds without a sound.

In gateway debugs showing 'isdn q931' , 'ccapi inout' 'ccsip messages' and 'dialpeer', (attached - phone numbers and ip networks were changed to protect the innocent) you can see the call come in and connect to CVP, the caller gets the menu options, selects 9 for 'dial-by-extension'.

The debugs show the caller entering the extension number

From there, there is an invite from the called number on CVP (8008003366@00.000.255.54) to the ISDN call on the gateway (3005556310@00.00.255.54) [line 708838]

A normal looking 'Trying' at [708848]

A normal looking 'OK' at [708849] and 'Acked' at [708850]

These offer compatible codecs (PCMU and phone events)

Then, at [708855] I see a REFER to the ISDN call on the gateway (3005556310@00.00.255.54) from CVP (8008003366@00.000.255.54) with a 'Refer-To' that points to the error tone. (Refer-To: <sip:111051111117777@vxml-103.div.company.com;transport= tcp>)

What I NEVER see is any indication of a call trying to go out to the CFA#.

CDR shows lastRedirectDN of Bobs extension, and shows a call going from my cell (as the caller) to Bobs cell as the finalcalledparty.

directoryNum (callingPartyNumber)	directoryNum (finalCalledPartyNumber)
3005556310	+14005555568

and shows origCause_Value as 41 (temporary Failure)

===============

cucm call logs show the same:

2019/10/22 07:30:31.234|CC|SETUP|61036414|61036417|3005556310|+44444555262|+14005555568

2019/10/22 07:30:31.236|SIPT|61036414|TCP|OUT|00.000.254.12|5060|UCCE-CVP2|00.000.255.54|55310|3,100,14,671753.451^00.000.255.54^*|107348874|89484A8FF3FE11E9ACF500AA6E2FEFAA-157174743063333940@00.000.255.54|480 Temporarily Not Available

2019/10/22 07:30:31.265|SIPT|61036414|TCP|IN|00.000.254.12|5060|UCCE-CVP2|00.000.255.54|55310|3,100,14,671753.452^00.000.255.54^*|107348875|89484A8FF3FE11E9ACF500AA6E2FEFAA-157174743063333940@00.000.255.54|ACK

2019/10/22 07:30:31.265|CC|RELEASE|61036414|61036417|41

===========

I can tell that the call is hitting the user's DN configuration, since call logs showing it attempting to go to the user's cell phone. Does that mean it will be using that DN/device CSS and partition? If so, why isnt the call hitting the gateway?

Does anyone have any thoughts or ideas as to what is going on here? or where I can look next?

Thanks for any help you can give

(Note: I didnt see a way to attach a file, and I dont want to paste in the entire file - so ignore that part)

Chris Deren · ‎10-24-2019

With SLRG you also need to consider what the "Local route group for redirected calls" service parameter is set to. Default is "Local route group of calling party", but many deployments use "Local route group of last redirecting party.

In your call flow since you are doing REFER call transfer with the default setting the SLRG would be of the PSTN GW where the original call arrived to (assuming the call was made from outside), if the call flow was dialed from internal IP phone then the originator's CSS is the phones CSS. Assuming this is a call from PSTN the call flow looks like this:

PSTN --> Ingress GW (CUBE) --> CVP --> ICM --> script RF transfers to internal dynamic label --> CVP --> refer to CUBE --> CUBE matches dial-peer and sends the call to CUCM as it was internal destination --> CUCM receives the call on CUBE SIP trunk (this is the first call arriving to CUCM) --> rings IP phone --> forwarded to external number --> Route pattern --> Route List --> Standard Local Route Group --> here SLRG from dialing device is inserted, hence Route Group assigned to CUBE SIP trunk is used. As far as CSS it would use whatever is assigned as the forwarding CSS on the phone, the CSSes at trunk level are only for inbound calls not outbound.

So, you need to ensure the Device Pool assigned to the SIP trunk has proper SLRG and that the forwarding CSS on the phone has access to proper route pattern.

View solution in original post