Announcement

Collapse
No announcement yet.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Call quality issue

    We have an interesting situtation. :glare:

    We have two sites (SA - Headquarters and Austin) that are connected via T1 w/qos enabled. When a Internal Austin caller dials an external SA number the call goes over the T1 to SA and goes out a SA trunk. If there is a large file transfer occuring on the T1 while the call is progress, the call sounds real bad (like when neo goes into the matrix) for about 15 seconds and then the call sounds ok (while the transfer is still going). For inter-site (SA internal to Austin Internal) calls sound fine when the same large transfer is occuring.

    I enabled QoS on the Adtrans and still no luck. I wouldn't think that trunk calls are any different than inter-site calls, but it seems so...any ideas?

  • #2
    This is where the quality of your traffic shaping device makes a difference.

    Comment


    • #3
      Call Quality

      Your QOS isn't setup correctly, or you wouldnt have this issue. Without question.

      You need to look at the QOS on the router that drives the T1. What kind of router is it? Can you post the QOS config.

      Comment


      • #4
        it's an adtran netvanta 3200:

        qos map VoIPMap 10
        match dscp 46
        priority unlimited
        !
        !
        !
        interface eth 0/1
        ip address 10.1.1.159 255.255.0.0
        no shutdown
        !
        !
        !
        interface t1 1/1
        description San Antonio
        fdl none
        tdm-group 1 timeslots 1-19 speed 64
        no shutdown
        !
        interface t1 1/2
        description San Antonio
        signaling-mode none
        no shutdown
        !
        interface ppp 1
        ip address 10.100.1.2 255.255.255.252
        qos-policy out VoIPMap
        no shutdown
        cross-connect 1 t1 1/1 1 ppp 1
        !
        !
        !
        !
        !
        ip route 10.20.1.0 255.255.255.0 10.100.1.1
        !
        no ip n-form agent
        ip http server
        ip http secure-server
        ip snmp agent
        no ip ftp agent
        !
        !
        !
        !
        snmp-server enable traps snmp
        snmp-server community public RO

        Comment


        • #5
          Qos

          I am not sure on how the Adtrans do QOS, but it is most likely that the failing part is the actual matching itself. Your are only doing QOS by DSCP bit 46. Something could be stripping off of 46 values, or not putting them on some traffic. I always do QOS by the 46 bit AND by the actual ports used by shoretel, just as a backup. it is possible that the adtran itself is stripping off the DSCP bits. The QOS has to be setup in both directions as well, because it only works on outbound traffic.

          You could have a data switch connected to the Shoretel T1 switch that is removing the DSCP marking, which would make your qos irrelevant.

          A quick test to prove/disprove would be to add QOS matching to look for UDP ports related to voice traffic, and remove the DSCP value matching, to avoid matching only on dscp bit, and see if the problem goes away immediately.....

          Something could also be marking ALL your traffic with EF dscp, which would make your file transfers just as important, and blow up your QOS policy. This could be one switch at one location that is set to mark all traffic going through it with EF/46........... could be one port connected to one server.


          ShoreTel | Support - WAN Best Practices

          Comment


          • #6
            Are you using an IPSec VPN over the internet? Or an MPLS or Private Line? If you're using the internet, then the DSCP markings will not work. You will need to use traffic shaping instead.

            Comment


            • #7
              Make sure that you are seeing traffic hitting your policies. You can use the command:

              show policy-map interface (Interface name)

              and it should display something like this:

              show policy-map interface atm 1/0.1
              ATM1/0.1: VC 0/100 -
              Service-policy output: cbwfq (1283)
              Class-map: A (match-all) (1285/2)
              28621 packets, 7098008 bytes
              5 minute offered rate 10000 bps, drop rate 0 bps
              Match: access-group 101 (1289)
              Weighted Fair Queueing
              Output Queue: Conversation 73
              Bandwidth 500 (kbps) Max Threshold 64 (packets)
              (pkts matched/bytes matched) 28621/7098008
              (depth/total drops/no-buffer drops) 0/0/0

              If you do not see any traffic on the counters, your policy is not being applied properly or your packets are not being tagged correctly.

              Comment


              • #8
                Jesse - I'm (was) having exactly the same problems on a managed MPLS circuit form AT&T. I've had Shoretel and them on the phone numerous times and come to find out we both had config problems.

                Looks like AT&T didn't have everyhitng set up just right (surprise, surprise), but additionally the ST switch wasn't the only place you need to config the DSCP setting. In Director you set the DSCP but the phones don't use that setting, and you have to add a line to the xxcustom.txt files in \\inetpub\ftproot of your ST server. The line is:
                "DscpAudio 46"

                Put this is each of the xxcustom.txt files (on EACH site server if you have > 1) and reboot all of your phones.This solved almost all of our inter-site calling problems.

                Good luck.
                Mike

                Comment

                Working...
                X