Jabber users can't hit redial on missed calls

[Matthew Newbrough]

Hey all,

I am having an issue with Jabber for windows.  Users want to be able to re-dial from their missed calls page.  The caller hears "call cannot be completed as dialed".  We are using 9 as a dial-pattern for call routing on CUCM 10.5.  I'm thinking that Jabber is sending the 10 digit call to CUCM and it's not matching a route pattern.  This is a similar behavior to when jabber users with outlook try to call from outlook.  

Anyone know how to get this all working so users have a "click to dial" type experience in windows Jabber and Outlook (with Jabber installed on their workstation)?

[ryanticer]

Hi Matthew,

It sounds like you need some application dial rules setup in Jabber for just these cases, which will translate the 10-digit number to 9+10-digit as appropriate. Have you set those up in Call Manager yet?

Ryan

[Matthew Newbrough]

I haven't.  I have been spending most of my time working on translation patterns to solve the issue since the same thing happens when you redial from a phone.  The call comes in with the 10 digit caller id, and when you try and hit redial you get the same message.  Also, from outlook most phone numbers are 10 digit.  So, when you try and dial from there you run into the same problem.  You would think there would be an easy way to do this. 

At the moment, I have it working.  But it seems like I took the long scenic complicated route to get there!  I have a few translation patterns that slap a 9 on the called number field.  I also had to add a translation rule in the gateway to add a 1 to long distance.  Otherwise, the PSTN was rejecting the 10 digit call because there was no 1 on it. 

If anyone has a sexier way to do this, i'm totally open to it.  I feel like I brute-forced the issue.  And it doesn't seem like this solution would scale well.  I'm sure bigger companies have their outlook, jabber, and call history from a handset able to reach their number with a simpler solution.

[ryanticer]

Hi Matthew,

Which version of CUCM?

Starting with version 8.5, we've used a standardized +E.164 approach that translates inbound calling numbers to +E.164 format, and allows native +E.164 dialing, which resolves this issue. Also, the users seem to understand the format and don't complain about the 9.

Even still, for Jabber, I recommend the use of application dial rules to translate 10-digit numbers to either have the access code in front of them or to make them +E.164 compliant and allow +E.164 dialing on the system.

Thanks!

Ryan

[Matthew Newbrough]

Hey Ryan,

Thanks for the quick reply.  I'm using CUCM 10.5.  Honestly, I'm a route/switch guy just getting his feet wet in the CUCM/CUC/Jabber world.  Can you shed some light on the E164 format and how I would set it up in CUCM?  This is a new in house install, so I can still tweak with the setup before the official rollout. 

I appreciate all your help on this by the way.

Matt

[ryanticer]

Hi Matt,

No worries, started with voice the same way.

In its simplest form, there would exist an internal dialing domain with its own partition(s) and there would exist an external dialing domain with its own partitions.

The internal dialing domain would hold 4-digit dialing patterns, and the external dialing domain would hold +E.164 dialing patterns.

All inbound calls would flow through the external dialing domain (+E.164) and get translated to go in to the internal dialing domain (4-digit). Similarly, all outbound calls would flow through the internal dialing domain (4-digit) and get translated to go out of the external dialing domain (+E.164).

I can fill you in on more details, but it would probably be best over a phone call or webex or similar.

Thanks!

Ryan

rticer@team-sos.com

(916) 577-1741

[ryanticer]

Also I should mention, enabling +E.164 support does not mean you have to get rid of the access code. The access code can be incorporated quite well actually for a toll-bypass capability inherently in the call routing.

Thanks!

Ryan