cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6132
Views
0
Helpful
5
Replies

Intermitent VoIP quality issues over AnyConnect VPN

s-daly
Level 1
Level 1

Hello:

I'm in the middle of converting the our remote access VPN environment from the old Cisco IPSec VPN client to AnyConnect (ver 3.1.01065) VPN. I have a number of beta testers on the new AnyConnect VPN environment, and we are having intermittent VoIP quality issues (IP Communicator 8.5.3 on the remote laptops) with the AC VPN. While I realize that we're running the calls over the Internet, which is a "best-effort" network, and cannot control QoS over the Inernet, the peculiar thing about this is the VoIP calling over the old IPSec VPN seemed to work just fine 99+% of the time.

I've done a series of G.729 calls on both the old IPSec client and AC client, with the same laptop, using the same remote access connection. The "VPN server" for the IPSec VPN is a ASA5520 (8.0(4)), on a 100mbps Internet connection with plenty of headroom, which is also running firewall services for an office of about 500 people and a small DMZ enviroment. The VPN server which is handling the AnyConnect VPN is a new ASA5515-X (8.6(1)2), using the same 100 mbps Internet pipe, and running VPN services only. When running call tests on the old IPSec VPN, the call jitter is pretty consistent, where ave jitter runs about 10 ms, and peak jitter runs 30-40ms. On the AC client, while the "good" calls run about the same jitter as the old VPN, the "bad" calls (intermittent drops from speaker, sometimes sounds "mechanized"), which happen about 1 of evey 5 calls, run ave jitter of about 120-150ms and peak jitter of 300-400 ms. FYI, I'm not seeing any packet loss to speak of , just call jitter is through the roof. While in most cases, this could be written off as a "bad Internet connection", the tests on the old VPN pretty much prove this is not the issue.

That said, does anyone have any idea why the call quality is sometimes bad over the AnyConnect VPN? Is there any pest practices that I can work from, or any tweaks you can recommend? Thanks.

1 Accepted Solution

Accepted Solutions

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Well there are several things within our implmentation that could help possibly, although I do believe you can open TAC case, we've seen some strange behaviors.

Things to enable check on ASA/SSL side:

- DTLS - check if it's enabled and WORKING (show vpn-sessiondb det anyconnect filter name NAME_HERE)

see if packets are tunneled by the DTLS protocol not TLS. Datagram transport is much better suited for performance.

- Compression - while we see a lot of deployments with it enabled we're saying this as much as we can. Compression was meant for high latency low bandwidth links. In modern day internet it should be used with caution.

- check ASP drop table on ASA (clear asp drop, run the rest and monitor "show asp drop" during low performance period.

- additional logging "logging class ssl ..." can give you some more input.

- show count proto ssl_np - good place to start

the list goes on and on.

What is important to understand is whether the problem is with traffic on the wire or coming from SSL operation.

Sniffer traces are key.

M.

View solution in original post

5 Replies 5

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Well there are several things within our implmentation that could help possibly, although I do believe you can open TAC case, we've seen some strange behaviors.

Things to enable check on ASA/SSL side:

- DTLS - check if it's enabled and WORKING (show vpn-sessiondb det anyconnect filter name NAME_HERE)

see if packets are tunneled by the DTLS protocol not TLS. Datagram transport is much better suited for performance.

- Compression - while we see a lot of deployments with it enabled we're saying this as much as we can. Compression was meant for high latency low bandwidth links. In modern day internet it should be used with caution.

- check ASP drop table on ASA (clear asp drop, run the rest and monitor "show asp drop" during low performance period.

- additional logging "logging class ssl ..." can give you some more input.

- show count proto ssl_np - good place to start

the list goes on and on.

What is important to understand is whether the problem is with traffic on the wire or coming from SSL operation.

Sniffer traces are key.

M.

Well, this is interesting. . . I checked the DTLS usage, and sure enough, even though it was enabled, it was not being used. After doing a little digging, I found out this was due to the firewall config; our VPN gateway (ASA 5512-X) actually sits behind another firewall, and udp/443 must be opened to the Internet in order for DTLS to work. After opening that hole in the firewall, I've confirmed that we now are using DTLS tunnels.

I'll run some more tests and post the results.

Also, I am currently using DTLS compression, but SSL compression is turned off. Specifically for VoIP usage over the Internet, just to verify, is it recommeneded that I should turn off DTLS compression?

Interesting, "back in the day" DTLS didn't have compression, I see we extended DTLS recently, I was not tracking the details.

Now AFAIU, and I cannot get my hands on the specification at the moment, compression regardless of method (deflate, being baaad, LZS a bit better) will be always done in software hence can impact performance.

I would be definately interested to see result without compression enabled.

Okay, DTLS enabled and verified working. Also, DTLS compression is now turned OFF. Initial feedback is throughput and jitter levels much more consistent with old VPN deployment. Thanks!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: