Need to make Jabber (CSF) calls route via a specific CUBE gateway, but route patterns are ignored.

[UrbanPeasant]

I have 3 CUBE ISR3925 gateways in production and a new virtual CUBE CSR1000V that's ready for testing. They trunk to CUCM 12.5.1 and currently using Jabber 12.9.3.
I need to send Jabber calls to a specific phone number out via the new vCUBE for the sake of testing remotely. At the office I'd simply use a skinny phone and the tried-and-tested route patterns would be deal with the job nicely. Not so with Jabber.

I've been looking at Application Dial Rules but they don't have a config element for which associated device to use (i.e. the Route List). So how do you force a Jabber call to a pattern-matched number to go via a specific Route List with just my new vCUBE in it, or one of my old 3925's for that matter)?

Didn't find an answer by search terms I was using, or here:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_010010.html#CUCM_RF_A18160F6_00

Thanks in advance
Nathan.

[Nithin Eluvathingal]

If your requirement is to make calls through  the new CUBE using jabber for testing try the below.

• Create a Partition P_NEW
• Create a CSS_NEW, add partition P_NEW.
• Create a new or Copy existing RP which match your dialings pattern and put them in P_NEW and select the Gateway/Route List  the trunk you configured( you can see the trunk if its not a part of RG).
• On jabber device/line assign the CSS CSS_NEW. 

Now you can call number which match the RP through jabber and it use CUBE to send outside. 

[UrbanPeasant]

Thanks for looking and replying Nithin,

Sounds so simple, but no joy with that.

New Partition - Test_Partition
New CSS - Test_CSS. 

Add only Test_Partition to Test_CSS

Select RP and assign to Test_Partition (8 is our access code, but Jabber seems to ignore it which is what raised the question in the first place.)

*I selected the new Test_CSS for inbound calls on the trunk to the CUBE*

For the DN I'm trying to call from (I have a few lines on my Jabber device) I left it in the Internal Partition with all other DNs, but allocated it to the new Test_CSS.

DNA says RouteThisPattern, via the correct CUBE, but the call doesn't reach the CUBE. 

If I change the DN into the new Test_Partition I still can't place the call.

RTMT throws up info showing that the number I dial has the access code removed and replaced by country code +44 which then generates an unallocated (unassigned) number error. Which is presumably why the call doesn't reach the new CUBE.

If I dial the same number from my regular DN, the +44 bit doesn't happen and the call connects via the regular CUBEs. 

I can't find where the +44 is happening yet. Odd that it's happening to a call placed from one DN, but not from another.

[Roger Kallberg]

Advice you to stay away from application dial rules. They would not add any value to this and are more trouble than anything else.

You can use DNA to check the call routing for the call from Jabber.

[UrbanPeasant]

Thanks Roger, advice on dial rules noted. DNA shows the call should progress as I expect it to, but it doesn't, as per reply to Nithin.

[UrbanPeasant]

It's the Application Dial Rules that are causing me the problem. Jabber listens to these rules before anything else, not even reported in CUCM traces (so there must be another trace I need to collect that I'm not familiar with)

For the post earlier about dialing the access code of 8 followed by UK number, there's an App Dial Rule says 'strip 80 and replace with +44 and send'. In the CUCM traces the 807814965--- mobile/cell number I dialed doesn't even show. They only see +447814965---.

If I adjust the route pattern to \+447814965--- the call still doesn't progress, but DNA still results in RouteThisPattern.

I honestly thought the \+44 bit in the route pattern was going to be my answer for a moment there!

Now wondering if the App Dial Rules are a hang-over from our long-gone on prem WebEx CWMS, meaning that without the CWMS we no longer need the ADRs either and I should just dump them all (or at least the 4 that affect UK numbers.)

[UrbanPeasant · Accepted solution]

It struck me that I know my CUBEs don't know what to do with anything sent to them as +44, they expect to receive the access code and have a translation rule to strip it. So I wondered how Jabber calls that have used the App Dial Rules actually get any calls to the hit the CUBEs. 
Turns out that after the ADR processing (which I'm starting to think is done by the Jabber client itself) which yields the +44 prefix, there is then a Route Pattern which takes the ADR output, and strips the +44, and puts 80 back in front of the dial string!

This is some crazy-ass config. Then the 80<dial number> gets to the CUBEs and the 8 is stripped for sending on to the carrier, which is fine and obviously needed.

So I've edited my new Route Pattern to show \+44.<my number> and strip pre dot then append 80 and the RP is now being used. It's no surprise my earlier RP's weren't being considered.

Now I get the call being dropped immediately instead of hearing the 'Your call cannot be completed as dialed.....' message. So I think this might be partition/css related at this point. Trial-and-error to find out.

[UrbanPeasant]

Finally got calls landing on the CUBE I want them on. Translation happening as it then should, and now receiving a Request Timeout back from the ITSP, so I've them to look at my INVITE and tell me what's wrong.

Application Dial Rules were the culprit to the problem I was having. No real knowledge or understanding of why they're implemented on our servers. 

Nithin's comment also worked in the end, but only because by then I'd figured out what was going on with the Dial Rules, which were also impacting the new Partition and CSS config. Ultimately I only needed to know that my Route Pattern was wrong, and it was wrong because of the App Dial Rules. But no one was going to be able to help me with that.
If I remove some or all of the Dial Rules, I'll also be able to remove the corresponding Route Patterns, and trim-down the config and its complexity a bit.
Small win.
Cheers 
Nathan.

[Roger Kallberg]

The really awful thing about dial rules is that they don’t have any awareness of partitions and calling search spaces. They just affects all applications with no control or discrimination. This is one of the many reasons to not ever use them.

IMO there is nothing that a dial rule can do that you cannot do with other means of configuration.

[UrbanPeasant]

Thanks Roger.

One final post from me on this thread and Application Dial Rules, wish I'd found this guy's post a little earlier, very similar as it's all to do with call routing. Copied here in case the weblink ends up going stale:
https://voipempath.blogspot.com/2015/04/application-dial-rules-and-call-routing.html

"Application Dial Rules and Call Routing with Remote Destinations

Yesterday we had an issue with dialing.  To put it plainly, a 10 digit number was being stripped to 7 digits for no apparent reason until right towards the end of the day when we discovered the Application Dial Rules for some reason applied to RD/RDP?!?!?  Yes, you heard that right, the application dial rules for the old school Unified Personal Communicator and other programs that could run with CUCM and make calls. 

The story starts off with my changing my cell phone number, actually, it goes before that but I figure we can start there.  I changed my number to a local number since I was still using my hometowns number from when I was in my army days.  I just never changed it and left it as is since it was considered a local call for my mother and she doesn't have long distance.  Anyways, I updated the Remote Destination to the new number and all of a sudden I wasn't getting calls from my desk phone on my cell phone.  Others had some minor issues but we blamed CUCM 8.5 at the time.  Now, we are on CUCM 10.5(2) so there are no excuses as to why something wasn't working that has been around for so long.

We opened up the gateways and watched the traffic from CUCM come in via H.323 and saw that my number was being presented to the gateway as 7 digits instead of 10.  This didn't make any sense since we checked the following:

Translation Patterns for crazyness
Route Patterns
We even made a explicit RP for my cell phone and no change...
Gateway Configs
Line and CSS config
Device Pools and Transforms

All of these checked out and left us scratching out heads.  Dialed Number Analyzer (DNA) was worthless in showing us the problem since it isn't going to show you transformations done at the application dial rule area. Towards the end we took a look at Application Dial Rules and saw some in there.  We use Jabber and as of now there is no reason to use the ADR(Application Dial Rules) with 10.5(2) unless you got some really old clients still in use. 

We noticed that there were about 7 rules and 2 of them could have been a match for my cell phone ANI.  I was basically being stripped down there then passed to another route pattern for Waco 7 digit dialing and dumping because of this.  Also, in case you were wondering, Waco does still use 7 digit dialing locally.  Additionally remote destinations use en-bloc dialing so urgent priority and other patterns that could match beforehand are not even considered.  All in all, these rules were for some weird reason, affecting remote destinations.  Please keep this in mind if you ever run into the same issue.

Moving on to another topic, I talked about en-bloc dialing.  I figured for those that may not know what en-bloc is I would go ahead and explain.  There are two different types of dialing.  The first is digit by digit in which the CUCM receives the numbers one by one and analyzes them against both the route patterns and internal directory.  This is common on SCCP phones and now, Type B SIP phones also support this via KPML(Keypad Markup Language).  The second method is en-bloc which cell phones and all SIP phones are capable of doing.  Basically, it sends the entire string all at once to the CUCM and then a match is determined.  In this case, urgent priority is disregarded since CUCM was never given the chance to look for a longer match.

So what is urgent priority you might ask?  Urgent priority is a checkbox that can be set on DNs and route patterns.  Translation patterns are always urgent priority.  This feature basically forces a route even if there are possible longer matches.  Usually you will see this used for emergency features such as 911 and is why you should be using an "8" to dial an outside line and not a "9". "