Cisco Jabber Software Download
Ortiz Ullery
I'm looking for some help with an issue that has come up.
Some VPN users that are using Cisco Jabber to answer calls are reporting that they are either unable to hear the person on the other end of the call, or that person can't hear them speaking.
I called one of the users and they could hear me, but I couldn't hear them. The weird thing is that I was talking to them via Microsoft Teams chat at the same time, and I could hear the audio ding of my message being received. I also had them play a Youtube video and I could hear the video loud and clear. I thought I could also hear typing on a keyboard, but it is difficult to say for sure I did. It's like Jabber is passing me the computer audio, and not the headset.
They all report that the headset and that works perfectly fine via Microsoft teams for meetings and what not, but the issues with CIsco Jabber calls.
We have successfully solved this issue.
We checked all the routing on the switches and that, and it all checked out fine.
The problem ended up being access control lists within Cisco ISE - The ACL that was applied to the phones wouldn't allow traffic to go to the network the PC's are on.
1 make sure they are not using Jabber via remote audio. I have found that running Jabber on a PC that you are RDP'd to and using the headset on your local PC causes sporadic audio issues. In other words Jabber must be running on the same PC the headset is connected to, not in an RDP session. As far as I can tell remote audio and Jabber do not work consistently.
Someone posted this site -test/ as a way to test home Internet connection for latency, jitter and packet loss. They will probably need to test without VPN as allowing inbound pings are required for a result.
I've checked all of those, and they seem good.
The issue is only occurring on internal devices, and is always the same after more testing.
If someone on an internal device makes a call via jabber, and that call is answer on a desk phone, the person calling from Jabber can't hear the desk phone, but the desk phone person can hear the person calling from Jabber.
Jabber to Jabber calls appear to be fine.
Well the traffic from the desk phone is not getting to the computer. I ran wire shark and can only see the computer sending RTP traffic.
So the issue likely is the phone network isn't routing the RTP traffic correctly, and/or blocking it. Where do I confirm this is happening or not though?
Hope you can direct me in the right direction here. I have RMA installed, and it has been working great. But lately, I have been getting user account lock out in the Jabber client, but the AD account isn't. End users said they did not type their password wrong! CUCM default account policy applies with:
During this duration, all i can do is to seat tight and wait. Application is locked even though i try again login! I am at the point where I may completely changed the credential and instruct users how long they have to wait before calling the help desk.
I had a TAC case on this recently and asked if they would kindly document this anywhere, since it isn't and is frustrating. Make sure the customer has connected to VPNs or whatever before opening Jabber, and that DNS discovery can succeed with network up, before signing in or opening Jabber if already previously signed in.
If the "Reset" option is not available, we've been able to trick the app by going to manual server configuration, which then seems to bypass the lockout but it's annoying. I don't remember exactly how else we got around it, I think I ended up deleting some of the application's files in my user appdata. Neither are really great workarounds unfortunately.
If you have the time to, I would ask TAC to see if they can identify what it was. If there was an adapter that's malfunctioning or something else they can pinpoint. If this is a corporate managed machine, there's a chance that there will be enough of a similarity to find a workaround.
Thanks for reply, it's just once happened, so not really important for now. I just want to know what tac reply for this problem. Workaround with manual server configuration is not bad, thanks(problem gone, so cannot check it).
I happened to have the same problem in my system with 12.5 CUCM, IMP and latest Jabber as well. It was really frustrating situation when a head of department called me but I don't know what to do. There is no Cisco documentation as well to solve it.
I contacted TAC and since I got the engineer to fix my issue, the issue was already resolved. So, I tried to ask them how to immediately fix it, and even they didn't know. He tried to trick me that my Cisco Jabber is also trying to contact Webex. So when we are installing the Cisco Jabber, we need to add cmd command to exclude Webex for Cisco Jabber.
I asked them to check if it was really a WebEx problem. He said to replicate the issue which I couldn't because user is already fixed by itself. I had to close the case.
After few months it repeated again. I got the PRT. I contacted the TAC and asked the same. He said because the user was not having the Voicemail access and Jabber was trying to contact Unity Connection which caused it to lock and we need to wait. Or we can create another Service Profile excluding CUC and it will work. Again as the user was already working, I could not test this. But I knew later it was wrong solution from TAC again. Sadly...
------------------------------------------------------------------------------
So, finally I found a SOLUTION by myself. This error is not server based but purely client app based. If we refresh the app by removing its temp files from windows or clearing the data and cache from Android/iPhone, we should be good to go.
C:\Users\%USERNAME%\AppData\Roaming\Cisco
C:\Users\%USERNAME%\AppData\local\Cisco
Exit the jabber completely. I deleted the appdata files from the computer for both local and roaming. Then Open Cisco Jabber and login again. It will work.
So, this fix worked every time when I faced this issue from any user.
If you found it helpful, please rate. Thank You.
Excellent work! These steps a lifesaver when you need to get remote contact center agents or receptionists re-connected ASAP. I followed your instructions and it worked great! Having them offline for an hour is not acceptable....that's lost revenue/missed SLA's for enterprise customers and Cisco should have thought about that.
@Jaime Valencia I see were port screen share uses port 3389 in the documentation but I do not see this port being utilized when I share my screen. When I send the invitation to the other person they start a connection on a source random port 49152-65535 but the destination port is a random port below 49152. What am I missing?
In case anyone else runs across this, the documentation is a little misleading. It states that the IM share uses RDP and while it may be using RDP it is not over port 3389. The remote client creates a connection to a random port and then uses TLS to the jabber process to share the screen. It may be using RDP over TLS but not over port 3389. If you do not define the port range like Jaime mentioned above, then I observed the connection on random ports below 49152 which is also misleading in the documentation.
Hi people, I'm trying to integrate Cisco Jabber over MRA with Cisco Unity. This is not my first time, and I basically know how to do it only now I'm probably missing something and can't get it to work.
Another fact that may be important, is that this is a multi domain deployment, means the internal domain is: domain.local and the external domain is domain.com. MRA of course is working fine, and there's the "VoiceServiceDomain" parameter in the jabber-config.xml file that is set to domain.com. My previous deployments where it worked are single domain, so that's why I raised this thing, because it may has something to do with my issue.
Another thing I've noticed is that when I'm logging in, there is no traffic that the Expressway-C is trying to send to Unity (mostly to port 7080 - JETTY service). Only when I put manually the credentials I see that Expressway-C initiates traffic over TCP/7080 to Unity, and it logs in fine. So looks like Cisco Jabber doesn't initiate anything towards Unity. Makes any sense?
When working with OAuth authentication in Expressway and CUCM (because CUCM is the OAuth Server, Expressway is the OAuth Client), when you're logging in in Cisco Jabber over MRA, and this feature is enabled, instead of sending Unity Connection the credential authentication it also sends the OAuth token, but Unity at first don't know what to do with it. So the solution is to connect Unity to CUCM in order for it to sync the OAuth tokens from the CUCM.
I found out that it happens when "Authorize by OAuth token with refresh" is enabled on Expressway-C, which means it tell the authentication process to work with OAuth tokens and not with authentication with credentials. So when I disabled it, and enabled "Authorize by user credential" on the Expressway-C, it logged in to the Voice Mail services right away.
c80f0f1006