Jabber Decline in DeskPhone Mode different than when in SoftPhone Mode

Unanswered Question
Oct 9th, 2013
User Badges:

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Chuck Reid Wed, 10/09/2013 - 09:47
User Badges:

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 Sun, 04/06/2014 - 07:50
User Badges:
  • Bronze, 100 points or more

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 Mon, 04/07/2014 - 07:32
User Badges:

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 Mon, 04/07/2014 - 19:10
User Badges:
  • Bronze, 100 points or more

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.

Actions

This Discussion