Incoming calls to Jabber for Windows immediately placed on hold, new call with dial tone opens

[SMART Net]

User only had a Jabber client, and works in-house, not registered via MRA. She receives a call, clicks to answer it, then call is immediately placed on hold and a second new call starts with a dial tone.

Originally reported while running 11.6.3, upgraded to 11.7.0, but no change in behavior.

The user's Jabber device configuration in CUCM (10.5.2) is identical to others in the organization, yet this is the only reported instance of this happening.

Reportedly happens "most of the time" but not 100%. User was given a new PC with Jabber 11.7.0 installed and the behavior continues. Any ideas?

[Jaime Valencia]

To isolate the issue, try with the credentials of other user in that same machine, if it doesn't happen, then that might hint that's something related to the specific config for that user (though I cannot imagine what might trigger that behavior), if it gets the same behavior, but works on other machines, then it might be something specific to that machine.

You can also try the credentials from the troubled user in a known working machine.

[SMART Net]

Thanks for the quick reply, Jamie. Since the problem followed to the new PC, we figured it's user-specific, not machine- and jabber-install-specific.

We'll run those two tests anyway and let you know the results.

[Torrance Zeiler]

Were you able to make headway with this issue? I have a customer with the exact same symptoms for a single user on CUCM v10.5.2, Jabber v11.0. Moved her to a new workstation and the issue followed.

[nelcnetworks]

I also have exactly the same issue that only started when upgraded to CUCM 11 , Jabber worked fine before then. Have reinstalled jabber , recreated user CSF profile no change. Causing major problem fo rthis user

[Torrance Zeiler]

For my particular case we found it was due to recording being enabled for the user.  I've set the Recording Option: Disabled on the user's line for now. TAC pointed me to Calabrio's support for further troubleshooting.

[cesar.rojas]

I have the same issue with Verint

[Phuong Hoai Huynh]

Hello Torrance and Cesar

The issue is actually not the recorder but the IP Phone/Jabber.

Whats happening is that the solution is unable to bring in a transcoder to handle the multi codec calls.

Example

Incoming call to Jabber - G729 Jabber answers the call 

Jabber then kicks of a call recording session to any recording solution that is set to use G711.

In this situation the CUCM will try to bring in a transcoding resource due to the codec differences and fails.

Its an old defect from well over 4 years ago.

Two solutions is too.

1. Disable the call recording option on the line.

2. Ensure that the codec being used is the same as the call recording solution.

Regards

Hoai Huynh

[cesar.rojas]

Hello Hoai!!

Thank you for you reply

We are using G.711 for incoming calls to Jabber and recording.

The verint administrator tells me that the recorder is enabled for G.711 and G.729;

However by region I send everything to G.711

Regards!!

CR

[hsood]

Hi,


This is seen mostly when the calls do not get recorded on the recording side.

Due to which, the recording Invite is sent a 404 not found response to the CUCM which when communicated to the Sip device (in our case  a Jabber device ) thinks that the original call has been put on hold and a new line is opened up.

The most common reason for such an instance is because the recording side does not have this DN configured for recording.

It is the same behavior that you see in your solution.

Can you check with Verint, if there are no issues with the call being recorded?

You can try with recording disabled as well ad then test.


Regards,

Hitesh

[seanvaid]

What do you mean recording side does not have DN configured for recording?

As in, there's a correlation between a user's calls not being recorded and this symptom showing up?

I will have to double check recordings of users experiencing this issue. 

[Ryan Huff]

Keep in mind that regions do not guarantee the codec used in that region per call; rather they specify the maximum allowable bandwidth codec used by the call.

So if your region is set to allow upto 64Kbps, it does not necessarily mean the call will use G.711, it could use G.729. If the capabilities from the recorder are being advertised at G.729 ingress, CUCM will attempt to invoke a transcoder (because G.729 is allowed in a 64Kbps region).

My suggestion is;

• Stick a transcoder in the call path if you're able to
• Work with the recorder vendor to ensure ingress capabilities are only advertised as G.711

Thanks,

Ryan

[David Rehl]

This is an old thread, but I had the same issue and I figured I would post my solution.

We were running 11.7 Jabber as softphones and CUCM v11.5 coupled with UCCX and Calabrio for recording. We had issues where our agents would answer calls and it would immediately place the call on hold and open a new line. We only used g.711 as our codec so when looking at logs it didn't make sense that it was trying to invoke a transcoder.

Long story short, it turns out that Jabber likes to use a little codec called g.722.1. Doesn't matter if you disabled g.722 in your Service Parameters, you must go into your Audio Codec Preference list, and move g.722.1 below your g.711 codecs.

This completely resolved the issue for our agents. If this doesn't help you, sorry. Just figured I'd post since no real solution was found.

Best of luck!

Dave

[Ilo]

Hello. One of our users had the same issue, plus his Jabber whas placed on hold even when he was opening or recieving a new email. The solution for me was simple. From windows and from jabber software, i had to set jabra link 380 as default and not the Jabra evolve 65 ( in my case ).