Jabber SoftPhone over Remote Desktop w/ AnyConnect - Choppy Audio

[stevenle]

Like most places we're now almost an entirely remote organization. We have a Cisco ASA 5515 and Anyconnect version 4.6.03049. Our users will VPN connect from their BYOD devices into our network. From a BYOD device we only allow Remote Desktop, DNS and Ping. 

Users configure their remote audio options in the local remote desktop application (Win10). When connecting over the RDP the far end Jabber softphone in the office recognizes the remote audio (speaker / microphone / camera), so no problems there.

The problem we're having is that across the board we have choppy audio when using Jabber Softphone in a remote desktop session. Call signaling works and calls complete (placed, received) without issue but the call quality is really bad. Delay, missed words and at times you can't carry a conversation. I can't imagine other organizations are not experiencing this same issue.

The call flow is BYOD Win10 device > Anyconnect v4.6 > ASA 5515 > Cat9k > 3650 > Local Machine. We are a CUCM 11.5.1 SU4 shop. Jabber version is 12.6 across the board with a sprinkling of 12.7 clients. 

Does anyone have this working well in their environment? I have TAC cases open with the Collaboration / Security teams and so far, very little progress in over a weeks time. 

[Adam Pawlowski]

We have people trying this at our organization as well because... I don't know why.

It does not work well. It sort of works, but the audio can be choppy, and when it isn't there is a delay in the audio. As far as I am aware it's better than nothing but it is not really a supported use case. The VDI solution requires software to be installed. If you deploy it to someone's device, then it can leave logging and things on someone's workstation true, but that's probably the way to go with it. RDP just isn't meant for realtime audio/video as far as I can say.

[wkyuen.ricky1]

i am facing the problem as well.

In my lab, version 12.8 does not have the problem, but it still have problem in the production site.

I tried to wireshark the traffic from the remote computer. The rtp sent out from the remote computer is choppy.

[wkyuen.ricky1]

any update from the TAC?

[stevenle]

Absolute silence from TAC. Both on their collaboration and security teams. I've had to configure a very complex split tunnel scenario so that BYOD users can use Jabber locally and divert them to Expressway over MRA through their local ISP. Although this helps, Jabber over MRA lacks a few features like screen sharing and P2P file transfer. 

According to TAC Jabber use over RDP is a supported scenario but I'm guessing they don't know how to make it work and we have to spend a lot of man hours on a workaround. Not real happy with this. I can try Jabber 12.8 although I'm not real optimistic.

[wkyuen.ricky1]

jabber 12.8 works if there is only RDP.

if there are RDP + VPN, choppy sound still exists.

[joeharb]

Any updates on this...we have a customer that is attempting the same thing...if they RDP on the LAN everything works fine...once the VPN is introduced things are choppy and very poor quality.

In reading the post, it appears TAC says this supported...any other documentation or information?

Thanks,

Joe

[wkyuen.ricky1]

Hi, I am still working on this issue.

I found that the audio quality is better in my lab compared to the production.

In these days, the VPN usage in the production site is very high. Perhaps the poor quality is because of the full usage of VPN. However, I need to do more test.

Also, I am giving ip communicator to the users at this moment. It does not have this problem or it is not so sensitive to network quality as jabber.

[stevenle]

I have an ASA 5512 in my DR site that is barely used with gig connectivity throughout. I and a co-worker were the only ones connected to it testing this scenario. Same voice quality issue over RDP, although we were on Jabber 12.7 and not 12.8. Not sure that'll make a difference but I'll test and report back.

I just don't think this works or something in the ASA doesn't handle the traffic right. Hoping Cisco either releases a fix or says it's not a supported scenario. Going remote was a huge success, connectivity has been solid for the most part although some ISP's have had bottlenecks. Everything was great until this voice issue was discovered, now most of the company is saying voice communications has been our biggest challenge to date. And by challenge they mean failure. Not good.

[stevenle]

The collaboration engineer said it was supported as long as we were using ASA / Anyconnect. Never did provide any documentation to back it up. But I have it in writing from him. I can't get a hold of the Security / Collaboration engineers together for a collab session. Each one says they need the other. Packet captures show jitter when the ASA was introduced between the RDP sessions.

We've given up on this. I don't think there will be a magic fix and getting a response from TAC these days is difficult. We've configured a split tunnel workaround and users are using Jabber locally. Very frustrating because certain Jabber features are unavailable when on MRA. 

I don't see any way around this. I read somewhere that the MTU size needs to match all the way across the connection from the anyconnect client to the remote machine. I do have the MTU size of 1500 set all the way across except in the ASA Group policy. It only allows a maximum size of 1462. Not sure this is the issue but all I see. 

[Adam Pawlowski]

@stevenleDid you ever get a resolution to this? We have a few people dealing with this still, and wondered if it was a MTU thing myself for some reason.

[stevenle]

@Adam Pawlowski No resolution. Got the official 'not supported' from Cisco. This was after a conference call Webex with a security and collaboration engineer. I can PM you the TAC case for reference should you need it.

'Problem description: Call Audio Quality over Cisco ASA VPN - RDP Session

Resolution summary: As with the consultation of higher resources, unfortunately this method is not supported since the RDP feature is not really meant to be used for audio/video due to quality problems as you already experienced.

There is no official cisco documentation or bug that we can provide since this is not the common scenario."

They also added that this was never a documented test case scenario. Which means they never tested their applications over this connectivity method along with RDP. Because of that, this is a defined as unsupported. We abandoned this altogether. But we've also had problems like this with Microsoft Teams / Webex over RDP as well. Forced to go the local route / split tunnel.