ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Intermittent call quality issues with a FreePBX instance on Vultr in Chicago

    IT Discussion
    vultr voip.ms freepbx 13 freepbx audio problems
    7
    12
    2.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      JaredBusch
      last edited by

      Having some intermittent problems with an instance in Chicago.

      4 office locations with phones. (3 fiber, one coax)
      3 residences with phones. (1 fiber, 1 coax, 1 copper)
      4 PJSIP /SIP trunks to 4 VoIP.ms POPS (chicago2, chicago3, chicago4, denver2)
      1 IAX2 trunk to my PBX (also in Chicago datacenter)

      Users at all 4 offices and one of the homes experience intermittent bad call quality where the person on the PBX cannot hear most of what the other party says like missing every other second of the audio. But the other person can hear the PBX user perfectly the entire time.

      When it happens, it seems to happen at all sites at the same time. It is not tied to only one site. This leads me to suspect Vultr or VoIP.ms

      [root@bpbx ~]# sar
      Linux 2.6.32-642.6.2.el6.x86_64 (bpbx.flstl.com) 	08/18/2017 	_x86_64_	(1 CPU)
      
      12:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
      12:20:01 PM     all      7.08      0.00      3.60      0.04      0.32     88.96
      12:30:01 PM     all      6.00      0.00      2.70      0.06      0.24     91.00
      12:40:01 PM     all      6.26      0.00      2.93      0.05      0.20     90.57
      12:50:01 PM     all      7.90      0.00      4.13      0.06      0.25     87.67
      01:00:02 PM     all      8.18      0.00      4.56      0.05      0.30     86.92
      Average:        all      6.08      0.00      3.02      0.12      0.20     90.57
      

      response time to VoIP.ms sites

      [root@bpbx ~]# ping denver2.voip.ms
      PING denver2.voip.ms (173.248.159.210) 56(84) bytes of data.
      64 bytes from 173.248.159.210: icmp_seq=1 ttl=51 time=23.2 ms
      64 bytes from 173.248.159.210: icmp_seq=2 ttl=51 time=23.1 ms
      64 bytes from 173.248.159.210: icmp_seq=3 ttl=51 time=23.3 ms
      ^C
      --- denver2.voip.ms ping statistics ---
      3 packets transmitted, 3 received, 0% packet loss, time 2878ms
      rtt min/avg/max/mdev = 23.188/23.251/23.346/0.141 ms
      [root@bpbx ~]# ping chicago2.voip.ms
      PING chicago2.voip.ms (208.100.39.53) 56(84) bytes of data.
      64 bytes from 208.100.39.53: icmp_seq=1 ttl=57 time=1.18 ms
      64 bytes from 208.100.39.53: icmp_seq=2 ttl=57 time=1.12 ms
      ^C
      --- chicago2.voip.ms ping statistics ---
      2 packets transmitted, 2 received, 0% packet loss, time 1990ms
      rtt min/avg/max/mdev = 1.129/1.157/1.186/0.044 ms
      [root@bpbx ~]# ping chicago3.voip.ms
      PING chicago3.voip.ms (208.100.39.54) 56(84) bytes of data.
      64 bytes from 208.100.39.54: icmp_seq=1 ttl=57 time=1.13 ms
      64 bytes from 208.100.39.54: icmp_seq=2 ttl=57 time=1.18 ms
      64 bytes from 208.100.39.54: icmp_seq=3 ttl=57 time=1.10 ms
      64 bytes from 208.100.39.54: icmp_seq=4 ttl=57 time=1.11 ms
      ^C
      --- chicago3.voip.ms ping statistics ---
      4 packets transmitted, 4 received, 0% packet loss, time 3261ms
      rtt min/avg/max/mdev = 1.107/1.132/1.180/0.044 ms
      [root@bpbx ~]# ping chicago4.voip.ms
      PING chicago4.voip.ms (208.100.39.55) 56(84) bytes of data.
      64 bytes from 208.100.39.55: icmp_seq=1 ttl=57 time=1.13 ms
      64 bytes from 208.100.39.55: icmp_seq=2 ttl=57 time=1.15 ms
      64 bytes from 208.100.39.55: icmp_seq=3 ttl=57 time=1.14 ms
      64 bytes from 208.100.39.55: icmp_seq=4 ttl=57 time=1.25 ms
      64 bytes from 208.100.39.55: icmp_seq=5 ttl=57 time=1.21 ms
      ^C
      --- chicago4.voip.ms ping statistics ---
      5 packets transmitted, 5 received, 0% packet loss, time 4071ms
      rtt min/avg/max/mdev = 1.132/1.180/1.252/0.044 ms
      

      response times to offices
      these response times are typical whether or not there are problems being reported.

      [root@bpbx ~]# ping suba.domain.com
      PING suba.domain.com (12.xxx.xxx.xxx) 56(84) bytes of data.
      64 bytes from 12.xxx.xxx.xxx: icmp_seq=1 ttl=53 time=8.83 ms
      64 bytes from 12.xxx.xxx.xxx: icmp_seq=2 ttl=53 time=8.90 ms
      64 bytes from 12.xxx.xxx.xxx: icmp_seq=3 ttl=53 time=8.73 ms
      ^C
      --- suba.domain.com ping statistics ---
      3 packets transmitted, 3 received, 0% packet loss, time 2951ms
      rtt min/avg/max/mdev = 8.734/8.823/8.903/0.128 ms
      [root@bpbx ~]# ping subb.domain.com
      PING subb.domain.com (71.xxx.xxx.xxx) 56(84) bytes of data.
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=1 ttl=50 time=35.8 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=2 ttl=50 time=35.6 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=3 ttl=50 time=34.2 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=4 ttl=50 time=34.2 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=5 ttl=50 time=34.9 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=6 ttl=50 time=44.2 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=7 ttl=50 time=43.4 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=8 ttl=50 time=35.1 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=9 ttl=50 time=39.0 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=10 ttl=50 time=33.6 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=11 ttl=50 time=34.6 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=12 ttl=50 time=34.8 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=13 ttl=50 time=35.6 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=14 ttl=50 time=36.1 ms
      64 bytes from 71-xxx-xxx-xxx.static.stls.mo.charter.com (71.xxx.xxx.xxx): icmp_seq=15 ttl=50 time=34.2 ms
      ^C
      --- subb.domain.com ping statistics ---
      15 packets transmitted, 15 received, 0% packet loss, time 14639ms
      rtt min/avg/max/mdev = 33.663/36.405/44.212/3.159 ms
      [root@bpbx ~]# ping jeff.domain.com
      ping: unknown host jeff.domain.com
      [root@bpbx ~]# ping subc.domain.com
      PING subc.domain.com (216.xxx.xxx.xxx) 56(84) bytes of data.
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=1 ttl=52 time=13.3 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=2 ttl=52 time=13.9 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=3 ttl=52 time=13.1 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=4 ttl=52 time=14.4 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=5 ttl=52 time=15.3 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=6 ttl=52 time=13.8 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=7 ttl=52 time=14.4 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=8 ttl=52 time=15.5 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=9 ttl=52 time=13.8 ms
      ^[[A64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=10 ttl=52 time=14.5 ms
      64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=11 ttl=52 time=15.3 ms
      ^C64 bytes from 216.xxx.xxx.xxx.reverse.socket.net (216.xxx.xxx.xxx): icmp_seq=12 ttl=52 time=16.4 ms
      ^C
      --- subc.domain.com ping statistics ---
      12 packets transmitted, 12 received, 0% packet loss, time 11964ms
      rtt min/avg/max/mdev = 13.199/14.536/16.469/0.951 ms
      [root@bpbx ~]# ping subd.domain.com
      PING subd.domain.com (216.xxx.xxx.yyy) 56(84) bytes of data.
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=1 ttl=55 time=12.8 ms
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=2 ttl=55 time=12.4 ms
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=3 ttl=55 time=20.0 ms
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=4 ttl=55 time=12.6 ms
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=5 ttl=55 time=12.7 ms
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=6 ttl=55 time=12.5 ms
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=7 ttl=55 time=12.4 ms
      64 bytes from 216-xxx-xxx-yyy.adams.net (216.xxx.xxx.yyy): icmp_seq=8 ttl=55 time=12.9 ms
      ^C
      --- subd.domain.com ping statistics ---
      8 packets transmitted, 8 received, 0% packet loss, time 7632ms
      rtt min/avg/max/mdev = 12.429/13.570/20.022/2.448 ms
      
      1 Reply Last reply Reply Quote 2
      • A
        Alex Sage
        last edited by Alex Sage

        Noisy Neighbor? Submit a ticket with Vultr 🙂

        A 1 Reply Last reply Reply Quote 1
        • A
          AdamF @Alex Sage
          last edited by

          @aaronstuder said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

          Noisy Neighbor? Submit a ticket with Vultr 🙂

          I had this exact issue a couple months ago with the NJ data center with VULTR. Noisy neighbor. Opened ticket with Vultr and the neighbor was shut down within 10 minutes.

          1 Reply Last reply Reply Quote 2
          • W
            wrx7m
            last edited by

            Get it figured out?

            J 1 Reply Last reply Reply Quote 0
            • J
              JaredBusch @wrx7m
              last edited by

              @wrx7m said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

              Get it figured out?

              I am not working on this until Tuesday.

              S 1 Reply Last reply Reply Quote 1
              • S
                scottalanmiller @JaredBusch
                last edited by

                @jaredbusch said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                @wrx7m said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                Get it figured out?

                I am not working on this until Tuesday.

                @jaredbusch said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                @wrx7m said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                Get it figured out?

                I am not working on this until Tuesday.

                Because, eclipse.

                DashrenderD 1 Reply Last reply Reply Quote 0
                • DashrenderD
                  Dashrender @scottalanmiller
                  last edited by

                  @scottalanmiller said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                  @jaredbusch said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                  @wrx7m said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                  Get it figured out?

                  I am not working on this until Tuesday.

                  @jaredbusch said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                  @wrx7m said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                  Get it figured out?

                  I am not working on this until Tuesday.

                  Because, eclipse.

                  LOL - I.E. customer, we don't care about your ability to use the phone system. 😛

                  J 1 Reply Last reply Reply Quote 0
                  • J
                    JaredBusch @Dashrender
                    last edited by

                    @dashrender said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                    @scottalanmiller said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                    @jaredbusch said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                    @wrx7m said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                    Get it figured out?

                    I am not working on this until Tuesday.

                    @jaredbusch said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                    @wrx7m said in Intermittent call quality issues with a FreePBX instance on Vultr in Chicago:

                    Get it figured out?

                    I am not working on this until Tuesday.

                    Because, eclipse.

                    LOL - I.E. customer, we don't care about your ability to use the phone system. 😛

                    They already knew I was going to be unavailable. I am working on other things now anyway..

                    1 Reply Last reply Reply Quote 0
                    • syko24S
                      syko24
                      last edited by

                      I have a client on the same setup with Vultr (Chicago) and Voip.ms (chicago2.voip.ms). They were having the same issue on Friday with calls dropping in and out. This morning I am still getting a couple complaints but not as bad as Friday.

                      1 Reply Last reply Reply Quote 0
                      • syko24S
                        syko24
                        last edited by

                        So I submitted a ticket with Vultr and they moved me to a new server to see if that would make any difference. The call quality is a little better but there is still a little static/pop every couple of seconds. They had me send MTR results to them. I pointed out that there is some packet loss happening on the last hop but they said everything looks good. Below are my results. I removed the first few lines.

                        Host Loss % Sent Recv Best Avrg Wrst Last
                        be-33491-cr02.350ecermak.il.ibone.comcast.net 0 36 36 12 16 25 17
                        be-10563-pe01.350ecermak.il.ibone.comcast.net 0 36 36 11 15 26 12
                        50.242.150.34 0 36 36 11 17 69 13
                        0.ae12.cr2.ord6.scnet.net 0 36 36 12 17 34 17
                        ae2.ar9.ord6.us.scnet.net 0 36 36 12 16 32 13
                        ethernetxe-0-0-0:0-er1-q8.chi2.choopa.net 0 36 36 13 18 54 14
                        No response from host 100 7 0 0 0 0 0
                        No response from host 100 7 0 0 0 0 0
                        myinstance.vultr.com 4 32 31 0 13 20 13
                        ________________________________________________ ______ ______ ______ ______ ______ ______

                        WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

                        1 Reply Last reply Reply Quote 0
                        • syko24S
                          syko24
                          last edited by syko24

                          The issue seems to have been resolved. No packet drops on MTR this time around.

                          1 Reply Last reply Reply Quote 1
                          • J
                            JaredBusch
                            last edited by

                            Opened a ticket with Vultr. We'll see what they suggest.

                            1 Reply Last reply Reply Quote 0
                            • 1 / 1
                            • First post
                              Last post