It would be helpful to see the Jabber stats for the other two call types (PSTN and internal IP phone). I would do the following to isolate:
1. repeat your steps with another Jabber user. Does the jitter remain for all call types with a different user on different ISP/PC, etc.?
2. Have the user run the following connectivity test which includes packet loss and jitter measurements:
- Browse to https://www.visualware.com/bcs/index.htm and download and install the appropriate version for your computer
- Browse to http://vac.visualware.com/portals/wfh/work-from-home-assessment.html.
- Skip steps 1 and 2, as you've already selected your network connection and downloaded the program.
- In step 3, select the nearest test location to you
- In step 4, leave the number of calls at 2
- Click Start Test
- When the test is complete, observe the latency and packet loss measurements. They include direction, so you should be able to rule in or out your user's local connection.
No, this is good data. If your clients can successfully run that test between their home network and the testing server, then they *likely have a good connection at home so you can remove your focus on ISP somewhat. Now, they do have a high latency...240ms is more than the round trip you'd typically want, but that is not the same as the packet loss. I would suggest now that you focus on obtaining packet captures at every point in the path that you can to see where the loss is occurring, starting with these:
1. Wireshark the client
2. TCP dump on Expressway E
3. TCP dump on Expressway C
4. Observe loss/direction on IP phone.
See where you first observe the loss and in which direction. Based on your jabber screenshot, you have both send and receive loss. Based on your out of order packets, I would guess that somewhere you will find a network issue.
Have you disabled ALG/SIP packet inspection on the FW? Is there any sort of asymmetrical routing that could be happening? Is there any policy to to prioritize voice in the ASA or Fortigate? I don't work on these devices, but have had to work with my team to correct issues in our ASA in the past.
If you can't find a choke point with the voice devices above, then you'll need to also include the network devices in your packet capture efforts as well.
As far as your reply about call statistics in the C or E, you can look at call legs. Go to Status>Calls>History. Select the call in question, and then you wills see the various components. If you look at the B2BUA component and then the media statistics, there you will see statistics that may be helpful for the call legs and hopefully gain clues where the loss is introduced.
Unless you have implemented ICE/Turn, the media traffic still passes through both your Expressway C & E, meaning those components could be the cause of sent or received loss and deserving of a look.
You really need to take a look at the full path and do some isolation testing/analysis at the entrance and egress points for the expressways to find out where the loss is being introduced. Several of us have offered places/methods to help isolate. Unless you have CVI, your MS calls are most definitely following the same call path, and only Zoom CRC calls would go through Expressway, so you have to focus on the MRA call failures and isolating the problem along that call path.
