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

[Keith Abbott]

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)

[Keith Abbott]

an additional note: I am also getting a RTMT route list exhausted alert:

RouteListName : E164 to Local PSTN, Reason=41, RouteGroups) CallingPartyNumber : 3005556310 CallingDeviceName : Router-VG1 CalledPartyNumber : +14005555568 CalledPartition : 3ba6933c-79e2-72a5-2231-78909ddd3bf7
CalledPattern : +1[2-9]XX[2-9]XXXXXX

[Chris Deren]

Are you using standard local route groups for routing external calls from CUCM? If so, does the SIP trunk from ingress point (in this case if this is SIP refer call from GW) does the SIP trunk to the gateway have proper device pool associated with defined SLRG?

CUCM traces need to be looked at here if the call does not make it to the gateway for the egress leg.

[Keith Abbott]

Hi Chris,

Thanks for the response! After looking at the RTMT message, that is the direction I was starting to look. The devpool of the extension in question does use SLRG.

When I look at the SIP trunk to that gateway (I presume the 'outbound calls' section is the section of interest. It looks like this:

Called Party Transformation CSS: KAMis Localize Xform   (this transforms the dialed number to 81NPANXXxxxx format)
Use Device Pool Called Party Transformation CSS: <unchecked>
Calling Party Transformation CSS: <none>
Use Device Pool Calling Party Transformation CSS: Originator
Calling Party Selection: Default
Calling Line ID Presentation: Default
Calling Name Presentation: Default
Calling and Connected Party Info Format: Deliver DN only in connected party
Redirecting Diversion Header Delivery - Outbound: <unchecked>
Redirecting Party Transformation CSS: <none>
Use Device Pool Redirecting Party Transformation CSS: <checked>

On the device pool side:

Calling Search Space for Auto-registration: Auto Registered Devices

Adjunct CSS: <None>

'Phone Settings' section:

Calling Party Transform CSS   <None>

Connected Party Transform CSS   <None>

Redirecting Party Transform CSS   <None>

It kind of looks like the only CSS the outgoing call has a chance to pick up, is the 'originator' css. Would this be the redirecting phone (Bobs in our example) - or since the call is originating through ICM, is it something else? This aspect has always thrown me a little.  If it picks up Bobs, it should be ok, as Bob is able to make a direct call from his extension to his Cell.

Thanks again for your help.

[Chris Deren · Accepted solution]

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.

[Keith Abbott]

Hi Chris, Thanks for taking the time to provide the detailed explanation.



I checked the 'Local route group for redirected calls' setting - it is 'Local route group of calling party'



Then I checked the SLRG setting for the Devpool assigned in the 'SIP trunk to the ingress gateway: It was set to .

I set it to point to the ingress gateway and retested. YIPPEE IT WORKED!!!!



I will go back through everything and try to make sure I understand what is happening



Thanks again for all your help!!

[gysgt@bellsouth.net]

I have found that ACD does not like forwarding.  I setup one reach to allow the call to ring both the Cisco phone and the cell phone and remove the forwarding. This resolves the issue and allows the call to still function within the script.

[Keith Abbott]

Thanks for the suggestion gysgt.

Since we're using a dynamic label that is created based on the digits the caller enters, and can be any of dozens, Im not sure how this would work for our situation. How did you get yours to target 2 destinations simultaneously - a broadcast HG maybe?

[joel.decarvalho]

On CUCM, please check the CSSs on  CVP SIP trunk

[Keith Abbott]

A good point Joel. In response to Chris' post, I checked the SIP trunk to the GW originating the call, but did not think to check the SIP trunk to CVP. Which is the more pertinent here? Or is it both equally? Can someone explain the call control that occurs through a mishmash like this where gateway, CVP, and extension are all involved?

thanks

[Keith Abbott]

This is the way I picture a rough diagram of the situation, and the key properties involved for each. Is it approximately correct?

SIP Trunks A and B(right side of the green block) would be the same trunk, would they not?

Once the call reaches the 'extension' which properties are important to the forwarded call getting back out?

Does the call use the DN 'Forward CSS'? If so it should be able to route out, since a direct call from the user extension - using the same CSS - completes, should it not?