Announcement

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

  • Shoreware Director Event 119 Warning

    Good evening all,

    I am still a fairly new Shoretel/Mitel administrator, so still learning the ropes. One of the things I noticed in the event viewer of my Shoretel server was Event 119 being logged multiple times a day. The description is something like this:

    Switch ST100DA: Excessive number of packets lost from 10.11.10.2 (15753 out of 36829).

    Obviously the numbers change but the devices in question are always the same, the ST100DA and the host 10.11.10.2, which is our SBC. These are SIP trunks.

    So one of the things I have gone through with a fine toothed comb was QoS settings. I'm 100% confident QoS is configured end to end and is working properly. The SBC and ST100DA are on the same switch and the ports are nowhere near capacity. Nobody is reporting any call quality issues on these calls where the lost packets reported are so high, there would have to be some noticeable degradation. But I happened to be on a call earlier, after hours, and when I hung up, I got an notification about excessive packet loss on the call, but the call quality was fine. It then occurred to me that I had been placed on hold during the call, and there was a period of silence where there was no music or anything playing while I was on hold. I was able to duplicate this behavior on another call.

    So I guess my observation is that this is something that happens on SIP trunks when we're placed on hold, but my questions are, is this the way its supposed to work? I guess it could make sense to just not send any RTP packets during periods of silence, but it doesn't make sense to me that the Shoretel system would perceive this as packet loss. Is something misconfigured between my Shoretel and my Adtran SBC? Is this a bug/bogus error report and safely ignorable?

    Thanks in advance.

  • #2
    Hi there things to try;

    Connect the ST switch on to another LAN Switch port, change the ethernet port used on the ST Switch to the other, change the ethernet cable used

    Comment


    • #3
      OcalaGator asking "is this the way it is supposed to work" with SIP is a dangerous question. Being an RFC and not a spec still there are almost inevitably 30 answers to the question of how any one piece is supposed to work.

      We generally use Ingate for an SBC not Adtran so I can't answer on the specifics, but it sounds to me like there is some confusion at the SIP level about what it should be doing with the call during a hold. ShoreTel defaults to wanting to send whatever the system default for MOH is to the caller, but there are numerous ways that SIP can handle this and it might bear some looking into in order to confirm that the SBC, the carrier, and the ShoreTel are all expecting the same on hold behavior.

      Comment


      • #4
        I've seen this same exact problem... We even had our network engineering practice configure QoS for one of these cases so I know it was done right, but still had the same problem. In a lot of cases, the trunk switch and SBC are on the same network switch both connected to 1 Gbps switchports, but somehow ShoreTel detects all this packet loss between the two devices???

        I have seen cases where transcoding can cause false positives on the ShoreTel side (going from G711 to G729 for example). Are you guys using G711 for all calls in your environment? If not, try switching everything over to G711 for intra-site and inter-site calls, and see if you still get the events.

        Can you find this packet loss in the tmsncc logs in the Shoreline Data folder? If you don't, that's another sign this packet loss is bogus. You should be able to find the exact number that's flagging in the event logs in the tmsncc logs.

        Let us know what you find.

        Comment


        • #5
          One thing I notice alot of people miss is CoS. The general thought being that we have plenty of bandwidth at layer 2 so we dont need CoS. ToS is about traffic shaping. If the packets arent marked so the switch can understand thier order of importance (CoS)then it doesnt matter if the routers and other layer 3 systems push through correctly. Essentially you have FIFO on the switch. This can really be a problem with calls that are internal to a site, or 119 errors between devices on the same switch. ToS 184 = QoS 46 = CoS 5. Check to see if you have QoS to CoS mapping setup on your switch.

          Comment


          • #6
            I followed this document exactly and have it setup on all my routers and switches: https://oneview.mitel.com/servlet/fi...ent_1__Body__s

            Packet captures seem to confirm QoS is set on everything. Again, this seems to be a reporting anomaly, I was on a call that allegedly lost 50% of its packets but call quality was superb; obviously that would have been impossible if I had lost 50% of the packets.

            Comment

            Working...
            X