Jabber Decline in DeskPhone Mode different than when in SoftPhone Mode

[Chuck Reid]

Hello,

We have an interesting issue when users decline a call on Jabber for Windows, IM&P 9.1 Jabber 9.2.4

If Jabber is in softphone mode the decline goes to UCXN over CUCM Trunk as expected as a fwd no answer and user gets VM.

If Jabber is in deskphone mode the decline goes to UCXN over Avaya PIMG Trunk, not as expected, as a direct call with no called or redirected number and the call gets UCXN general greeting.

We have an Avaya PBX with VM already in place with UCXN and Pim G routing.

Inbound calls come in to CUCM via a cube, DID’s were ported over a week ago.

If same user hits idivert on their 7942, the call goes to VM as expected, so only issue is with Jabber when in deskphone mode and user selects decline….

There is an xml file pointing users to use UDS on CUCM.

Both the CSF and 7942 phones are setup identically.... identically....

Any thoughts?

[Chuck Reid]

Issue resolved by changing partition of VM Profile matched pattern, no idea why there was a difference in behavior between soft phone and desk phone control though....

[Robert.N.Barrett_2]

Is there any chance you could provide some more detail on what you changed?  We have a similar situation.  In softphone mode, Jabber will not do the decline (Accept/Decline toast window will not go away when clicking decline, and incoming call is not forwarded to VM).  In deskphone mode, clicking decline works as expected.  DN settings for both devices are the same, devices and line CSS's are the same, etc.  Also - if the incoming call is not answered in softphone mode, call is forwarded to VM.  If the user only has Jabber (no deskphone device), the behavior is the same (decline does not forward to VM, but call will forward to VM if not answered).

I have a case open with TAC, but no solution in over 2 weeks and multiple packet captures/traces.  It's got to be a configuration problem...

[Chuck Reid]

Hi Robert, In our scenario, we have a sip trunk between UCXN and CUCM, all version 9.1.2

We run an E164 dial plan, so everything that is dialed gets globalized to +1 XXX XXX XXXX

We changed the partition of the VM Route Pattern that forwards VM calls over the SIP trunk to UCXN and that fixed the issue... What the issue actually was and why this fixed it we never really discovered....

If i remember anything more, Ill let you know.

[Robert.N.Barrett_2]

Are you sure you don't work where I do?  :)

We're E.164 as well, globalizing everything dialed -- even if I use 5 digits to dial the person sitting next to me.