Snoop Posted October 10, 2012 Report Posted October 10, 2012 This is going to be a hard one to explain... We initially ran Snom ONE on Windows Server 2008 and recently migrated to the VMware appliance. All appeared to be going well, until we noticed complaints from certain users about call quality issues. Here's the scenario: Extensions on the same LAN (in the same IP subnet as the PBX) can call each other with no issues. They can also break out via the gateway trunk with no quality issues. Extensions in different LANs (different IP subnets) can call extensions in the same LAN as the PABX with no quality issues, but the moment they break out via the gateway the quality suffers and nobody can make out what anyone is saying. The configuration was backed-up and restored directly from the Windows instance to the appliance and the appliance is running on the same VMware host as the old Windows instance was. Any guidance would be greatly appreciated. Quote
Vodia PBX Posted October 10, 2012 Report Posted October 10, 2012 Hmm. Did you set anything up on the VMware regarding CPU Resources? For example, you could reserve some MHz for the appliance. You can also set the Scheduling Affinity. We know from non-virtualized environments that the processor affinity is important to keep the OS from swapping the process from one core to another, which causes tremendous jitter. Quote
Snoop Posted October 10, 2012 Author Report Posted October 10, 2012 Thanks for the suggestion. I used the defaults from the template (1 CPU & 512MB RAM), so no reservations or affinity. I have set affinity and a 1Ghz reservation now, but it made no difference. The other guests on the host are idling at the moment, so I'm quite confident that it's not a resource issue. Incidentally, the old 2008 Server had the same resource allocation. The quality issues make it sound like someone is talking through a voice modulator. Very strange... Quote
Vodia PBX Posted October 10, 2012 Report Posted October 10, 2012 512 MB RAM sounds very low to me. I guess the VM is constantly swapping. Try to increase it dramatically, just to see if that is the right parameter. Quote
Snoop Posted October 11, 2012 Author Report Posted October 11, 2012 Thanks, I'll increase the RAM now to see if that helps. I don't think it's swapping though. See below: top - 20:31:49 up 14 days, 2:46, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 57 total, 2 running, 55 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 510596k total, 295108k used, 215488k free, 38380k buffers Swap: 128512k total, 0k used, 128512k free, 131252k cached I just left it at 512MB initially because that was the template's default and it worked fine under Server 2008. I'll revert tomorrow and confirm whether or not it made a difference. Thanks again for the assistance! Quote
Vodia PBX Posted October 11, 2012 Report Posted October 11, 2012 Oh oh. I saw the title that says that only off-net calls are affected. Then this has nothing to do with the memory size or CPU load. Sorry for sending you in the wrong direction. If internal calls are fine, then you don't have to worry about memory size or CPU load. If only off-net calls are the problem, then there must be something different or wrong with the routing. Because this is a new system essentially, you should double check if the routing table is what you would expect (route command). How many interfaces do you actually have (private/public IP). Is the VM host applying NAT to the host? Quote
Snoop Posted October 14, 2012 Author Report Posted October 14, 2012 Route are all fine: [root@localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.133.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 192.168.133.254 0.0.0.0 UG 0 0 0 eth0 [root@localhost ~]# traceroute 192.168.132.220 traceroute to 192.168.132.220 (192.168.132.220), 30 hops max, 40 byte packets 1 192.168.133.254 (192.168.133.254) 0.387 ms 0.397 ms 0.433 ms 2 192.168.132.220 (192.168.132.220) 7.896 ms 7.887 ms 7.897 ms [root@localhost ~]# When an extension from 192.168.133.0/24 calls an extension in 192.168.132.0/24 (or vice versa) everything is fine. Snom ONE is in the 192.168.133.0/24 range. However, when a phone from the 192.168.132.0/24 range tries breaking out via the gateway (in the same IP range as Snom ONE) the quality suffers. Quote
Vodia PBX Posted October 14, 2012 Report Posted October 14, 2012 7.8 ms to ping something in the subnet? I would try to run a Wireshark on the call, ideally with a Ethernet port mirror from the switch (not locally on the virtual machine). Then it will be clear where the problem comes from, and it probably saves a lot of time for trying this and that. Quote
Snoop Posted October 18, 2012 Author Report Posted October 18, 2012 Hi, Sorry about the late response. I ran the exact same config on Windows 2008 Server and everything worked well. Nothing has changed besides moving from Windows to the VMware appliance. Same host, same NIC, same network configuration. The reason for the higher latency is because the phone I pinged is on the other end of a 4km wireless link. Quote
Vodia PBX Posted October 18, 2012 Report Posted October 18, 2012 If you have a switch that support port mirroring, I would stiff get a PCAP trace to see if the jitter is caused by the VM or comes from somewhere else. Quote
Snoop Posted October 18, 2012 Author Report Posted October 18, 2012 Let's assume, for the moment, that it comes from the VM. Is there anything that I can adjust in CentOS to compensate for jitter being introduced when passing through it's routing layer? Thanks for the prompt response. Quote
Vodia PBX Posted October 18, 2012 Report Posted October 18, 2012 The PBX does that already. It binds the process to the first core by default, so that there is no switch over delay when moving the process to another code. You can double check if your VM is bound to a specific CPU; I guess moving the VM from one CPU to another cannot be good for jitter! Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.