Cisco Jabber on windows drops first call

[BrandonBowers7775]

Good afternoon,

I'm running Cisco Jabber for windows version 12.7.1 on my PC for use as a softphone. Now that I'm working from home more and using it instead of my desk phone, I'm noticing a drop in the first call when I hit the answer button. 

This happens when someone calls me or if I dial out as well. When dialing out, internal or external and hit the green call button or press enter, it goes to the call screen then just drops. My second call right after will go through no problem. 

My thought is that it has something to do with the connection back to my call manager, my softphone is showing registered in CUCM and call alerts come through.

Any ideas on why the connection fails out the first time? Could it be related to a timeout issue with a setting? 

CUCM version 10.5.2

[wkyuen.ricky1]

You are saying that you are working from home now.
Are you using expressway or VPN?
Does the jabber work normally when you are in office?

[BrandonBowers7775]

We are using VPN (Checkpoint) which I know isn't Cisco supported. We also have expressway servers for our mobile apps. Office use was mostly for testing, however I would say it worked correctly there. 

VPN is staying connected and we did have to work to open up certain ports. It's strange I see the call come in but it doesn't connect until after the first time. I'm starting to notice around 2 minutes of no calls is when the issue will reappear. 

Thanks for the reply!

[Meisner]

I have a user experiencing this same issue. however he is connected via Cisco AnyConnect VPN. Did you ever find a solution?

[Adam Pawlowski]

You would need to look at some logging to see what is happening. Jabber isn't necessarily the most expressive when something occurs in the background that's unexpected. It's possible it is attempting an INVITE but it is not presently registered because something has gone amiss in the connection between Jabber and the UCM. You'd see this also perhaps in the logging from the UCM, either device registration or the CM logging of SIP traffic. If the INVITE comes from an unexpected address, endpoint is unregistered, the signalling is being mangled by some ALG, etc, there should hopefully be enough pieces to try and narrow down the culprit.

[anthony.smith]

We found that this issue is only affecting our Windows 8.1 machines with the Realtek audio driver installed. Updating to the latest Realtek drivers did not resolve the issue.

[stuart sharp]

Hi @anthony.smith , the driver update did or did not resolve the issue?

[anthony.smith]

Updating the Realtek drivers didn't work for us. So we had to keep our Windows 8.1 machines on an older version of Jabber. But at this point we've upgraded our systems to Windows 10 so we've somewhat overcome the issue that way.

[Andrew Wallbank]

We're experincing the same issue (First call of the day, inbound or outbound fails), IM is fine.

Only on devices running Windows 11.  Windows 10 devices (Any build number) are fine.

Fine in the office, but breaks over SSL VPN.  My initial thought was the VPN was dropping caused by some strange SIP traffic, but subsequent calls working rules this out.

CSF shows as registered in CUCM and in the client.

Tried updating VPN client and Audio drivers, neither work.

Changed SIP profile back to default (we have a custom SIP profile for CSF devices), no difference.

We're running 14.2 of Jabber which was the latest up until December.

[Carlo Poggiarelli]

Hi,

From my side I would check the vpn profile and see if it installs a duplicated route on your Windows client.

Is the SSL full or splitted?

Plese let me know 

Regards

Carlo

[Andrew Wallbank]

Thanks for the reply Carlo,

We do run split tunnel but not for anything CUCM related (That is all tunnelled), there are no duplicate routes.

In the Jabber logs I can see the registration to Call-Manager, the SIP INVITE and what appears to be all relevant comms.  It just drops the call! However, I am struggling to see that in the logs, and the CSA tool doesn't pick anything up either, just indicates the call didn't connect.   Once Jabber is registered again,  every subsequent call works fine.

[Carlo Poggiarelli]

Hi Andrew,

Which version of Jabber are you running?

Can you please attach here a PRT (Problem Report Tool) from jabber's help menu

Please let me know

Regards

Carlo

[Andrew Wallbank]

Version 14.2.0.58008 Build 308008

Sorry, I can't attach a PRT, too much internal info for a public forum, and redacting would be kind of pointless.

My post was to highlight we were having the same issues, and things I'd looked at/troubleshooted, rather than ask for a solution. 

It's almost certainly a call for TAC/VPN provider to resolve, but thought the info would be helpful to others to investigate, as I suspect it might come up more as organisations roll out Windows 11.

[Adam Pawlowski]

Jabber is somewhat of a dumb client and doesn't make a lot of decisions on its own. Especially if it thinks it can be doing call preservation, it should just sit there.

If you review the log file yourself, or CDR details, hopefully it points to why the call ended. Timeout from a timer issue, something funky with an ALG, etc.

While my org is not officially running Windows 11, I have some colleagues that do, and I do myself on my personal machine. We use MRA instead of VPN for Jabber, though when I connect to the office my MRA traffic is tunneled. No issues had been reported so I am afraid it is hard to speculate.