poor quality & dropped VoIP & Google Hangouts packets, how to proceed?

Question

Hi all, 
 I'm trying to address poor online meeting performance for our users, most recently with Google Hangouts but also with GoToMeeting & others. 
 I also observe poor quality & high packet loss (both directons) for voip calls from a wired sip client (LinPhone & Callcentric.com voip service) on my lan. 
 So I thought I'd dive in & try to make Voip calls work, to make sure I understand the QoS features in the UTM9. 
 Our WAN is 100 mbit/sec (symmetrical). I configured Interfaces / Status for the 100mbit/sec up/down rates. I added two outbound traffic selectors, one for Voip protocols & another for sip, rtsp, and several relevant Collaboration app types. I added a bandwidth pool (10 megabits) with the two selectors checked, and I turned ON QoS on the WAN and LAN interfaces. I also tried adding two more selectors for inbound (the original two are outbound). We don't have any other Traffic Selectors or Bandwidth pools in place. 
 This didn't seem to make any difference. 
 A packet capture at the WAN interface (with tcpdump from within UTM9) shows all voip packets arriving & I can play the stream in wireshark, incoming audio is clear, but outbound packet loss is high. On the LAN side I see high packet loss and poor quality. A capture at the wired client shows high loss in the incoming stream, and good quality outbound. 
 I don't see dropped packets in the ethernet interfaces anywhere; not in my UTM, not in our managed ethernet switches, or in my pc. Hmmm. (And notably, our in-house voip phones, which ride on the same LAN but on a vlan, which go upstream thru an entirely different firewall router, all work fine, no dropped packets...) 
 >> Am I right to conclude that something is happening to my voip packets in the UTM9? Calls to go thru, and quality is better after hours when there's no other load. It sure seems like QoS policy or behavior and not firewall, right? 
 On a 2nd WAN IP address & same internet connection, I have a Cisco RV042 that is adjacent to the Sophos UTM. When I plug my PC with Linphone voip client in to the Cisco, voip calls work fine, no dropped packets, every time. 
 So far I'm not finding any reporting or troubleshooting tools in the UTM for understanding the QoS behaviour. 
 How should I proceed? 
 Rob

SaschaParis · Answer

Hi Rob 
 
 From my experience - if no misconfiguration as flooding protection, IPS or missing firewall rules are interfering, or no uplink balancing issues are present - VOIP issues usually occur due UDP timeout issues. 
 UTM has a default UDP timeout of 60s and SFOS too (or even 30s ?). However these timeouts are usually too low for reliable VOIP communication. Usually your VOIP provider declares some recommended UDP timeout figures for best experience...common are 120s. 
 I usually set UDP timeout in UTM and SFOS to 150s, which is totally perfect for most VOIP scenarios. 
 In UTM this is done on the console 
 The following command shows actual settings 
 asg01:/home/login # cc get packetfilter timeouts 
 { 'ip_conntrack_generic_timeout' => 600, 'ip_conntrack_icmp_timeout' => 30, 'ip_conntrack_tcp_timeout_close' => 10, 'ip_conntrack_tcp_timeout_close_wait' => 60, 'ip_conntrack_tcp_timeout_established' => 86400, 'ip_conntrack_tcp_timeout_fin_wait' => 120, 'ip_conntrack_tcp_timeout_last_ack' => 30, 'ip_conntrack_tcp_timeout_max_retrans' => 300, 'ip_conntrack_tcp_timeout_syn_recv' => 60, 'ip_conntrack_tcp_timeout_syn_sent' => 120, 'ip_conntrack_tcp_timeout_time_wait' => 120, 'ip_conntrack_udp_timeout' => 30, 'ip_conntrack_udp_timeout_stream' => 180 } 
 
 You can set/change the required value using 
 cc set packetfilter timeouts ip_conntrack_udp_timeout 150 
 which sets the UDP timeout to 150s 
 
 in SFOS similar thing can be set via device console 
 show advanced-firewall 
 This command will display the actual timeout values along with other advanced-firewall parameters. 
 and 
 set advanced-firewall udp-timeout-stream 150 
 will set the value to 150s 
 
 Usually this helps solving VOIP issues from my experience ;o) 
 
 BTW: Videoconferencing issues usually occur due flooding protection settings in the UTM. The default vvalues are too low for high ress streaming and starts dropping packets. Check your ips.log for "flood" messages and if flooding protection is active, disable it, or at least set the thresholds higher to avoid triggering flooding protection during normal network usage scenarios as videoconferencing (or exclude your VOIP equipment from flooding protection). 
 
 /Sascha