This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

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



This thread was automatically locked due to age.
  • Hey Rob,

    You've done quite some troubleshooting already. I'm not really a SIP expert. Although i'll advise you to open a support ticket @sophos if possible.

    Would you maybe detail a little bit how the normal traffic load is hitting the UTM, meaning what technologies at the UTM are you using and which tech handles what?
    L4FW for SIP, Web Protection for users and so on..

    Cheers,

    m

  • thanks, I'll open a ticket...  Rob

  • Hi, Rob, and welcome to the UTM Community!

    See #1 in Rulz.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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