1) Welcome to the Party!
2) As you are obviously new here, I have some suggestions to help us all help you:
When you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.
This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)
You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.
If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.
Similar to This:
Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600
(I note that you did mention vicibox 4.0.3 ... which is merely your Installer Version ... this is not your vicidial version, please remember to always post that at the very least)
3) You cannot rule out the servers based on "a load of under 35%". Where did you see "a load of under 35%"? The best way to check server load is at the command line of each server DURING an episode of poor sound quality. Use htop to see: 1,5,10 minute average server load AND immediate cpu usage on each core. If any individual CPUs are pegging out (100%) for more than a second or so, you could be experiencing overload even if your "average" is ok.
4) Try turning off recording during your next episode to see if this reduces the problem (could be an indication of low RAM availability or disk problems moving those recordings instead of deleting them after the call).
5) Seriously scour the htop for running processes that may be present (and using a lot of CPU) when an episode occurs. If you notice a process that is always present during an episode, but rarely present otherwise ...
6) Do you have any customizations? (Another thing you didn't mention in your setup ...)
7) Have you tried a 2nd carrier (after all, if it is indeed NOT your server ...)?
8 ) Have you cataloged the complaints to see if there is any correlation to any hardware/workstation/physical location in your facility? I've actually found an agent with a FOOT on a network wire (sometimes) to be a culprit with a poor connection issue. No way to find that without some tracing. LOL
9) Happy Hunting!