Odd issue here. Using Cisco IP Communicator on Windows 7 laptops, users will remotely connect to our VPN (Cisco ASA with Anyconnect) and make voice calls. Heres the issue, the called partys (a DN internal to our company, AKA on our LAN) voice drops and speeds up/slows down when heard by the calling party (remote VPN user). However, audio from the calling party (again VPN user) to the called party is fine.
Connecting to another Cisco ASA VPN (we have ones in different regions) alleviates the issue. It only occurs when connected to this specific Cisco ASA for VPN. Internally, no issue when calling from the soft phone to a internal DN or any other number.
Routing to and from the remote client and called party are the same. Doesnt appear to be congestion related that I can see and seems like that would affect both voice paths.
When on the call, the CIPC shows in the call details that the Jitter jumps erratically (2 - 2000). On the called party's phone, the Recvr Dropped packets also increments though not consistently.
We rebooted the ASA for good measure but no change.
Any thoughts on where to look here? I can give model numbers of the ASA if needed. Just need a starting point to look on the ASA (or elsewhere).
I would think the Internet connection to the ASA with the jitter problem is introducing the jitter (as opposed to anything to do with your configuration). It's probably a sick circuit that works OK enough for data (so no one complains) but the timing required to do good quality voice exposes the problem with the circuit.
Whatever, where ever, but you cannot guarantee any voice quality over the internet. Make sure you communicate this to your users. That is just the way it is
I indicates problem with your internet line. Specifically in the upload direction on the internet link as the audio from called to calling is having problem.
In general there is no QoS guarantee over internet so you shouldn't be surprised when you see high jitter, latency, and packet loss values. This is normal depending where the anyconnent client is setting and the distance to the ASA.
Start with checking your netflow reports at the ASA side and verify your upstream/downstream utilization. If there is congestion on the link, you need to think about increasing BW depending on the importance of remote calls.
If the utilization is normal. Then you can't do anything about it as it will be related to global internet routing and utilization over global links. I have seen global carriers dropping packets over SEA Cables after triggering specific thresholds.
Thanks for the information! Ill try and check the Netflow, though the utilization shouldn't be maxed out. I definitely understand there's no QOS guarantee over the internet.
Whats odd is that if a user connects to your VPN in Europe, the issue is fine. Oddly enough, this takes almost the exact same path (few more hops) but works fine! Jitter usually doesn't jump over 90 ms over these connection despite going from the US to Europe and back to the US again.
For instance, from an user in the US:
Remote user--->Remote US ISP--->Internet--->Company US ISP A--->US ASA VPN--->Corporate LAN
If that same user connected to the VPN in Europe the path changes slightly:
Remote user --->Remote US ISP--->Internet--->Company Europe ISP A--->Europe ASA VPN--->Europe Corporate Firewall (not ASA)--->Company Europe ISP A--->Internet (Site to Site IPSec Tunnel)--->Company US ISP A--->US Corporate Firewall (not ASA)--->Corporate LAN
Might thought would be that if it was ISP based, the issue would occur here unless its somewhere more upstream on the US. Not ruling out the ISP issue, just providing more information. This is what made me think an issue on the ASA popped up. It hasen't always been this way, just within the last few months.