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

  • Faxing Issue

    Hello All,

    I'm new to the forums, so first, an official Hello to everyone, this has been a much-appreciated wealth of knowledge compared to whatever else is available on the internet.

    So, onto my problem: I'm having an issue sending/receiving faxes. The issue began a few weeks ago; analog extensions in different sites could not fax internally. They would hear a second of the fax tone and then the call would drop. I tested within the same site and saw the same problem. I've verified the lines were set up properly (Fax Machine/User - No Redirect, etc) as well as an in-depth check of our network, yet test calls from both analog and VOIP extensions to the ports that our fax server are on fail with the same symptoms.

    I wired a splitter into the analog port for one fax line, and proceeded to call - the extension calling was disconnected, but the fax machine was still attempting to handshake and the port showed in use. CM shows the call simply ending, and a telnet session into the phone itself shows an error of "HAPI_RTP_EGRESS_ERROR_PAYLOAD_TYPE" the moment the call drops. None of this occurs if I plug an analog telephone into the port and have a coworker answer when it rings.

    I've attempted calling the analog extension from a number of different types of clients, including analog ports on the same and different switches, ST 230's within the site and outside, and a statically configured phone on the same VLAN and subnet as the switches. All failed if it were dialing a fax machine, and all succeeded with a analog phone and person. I've reset every component of the system and I've also verified that there is no packet loss, sniffed traffic for errant issues, and completely deleted the extension the fax ports are on and recreated them on a different switch only to experience the same problem.

    I contacted our vendor who tried a few things, and then switched the CODEC from 128k to 64k. This fixed the problem, but it was set to 128k by me many months ago to fix handshaking/transmission errors. Setting it back to 128k makes no difference internally, but now incoming calls from OUTSIDE are failing with the same issue. It seems to me that the system is ignoring the preferences regarding fax-redirects or a CODEC issue. We recently went from 6.1 -> 7.0, but that was a few months ago.

    I'm at a complete loss here, and I'm not sure my vendor is 100% sure of the 128k setting, or the true cause of the issue, so my question is: has anyone else experienced this, and/or does anyone have a recommendation as to the proper CODEC for faxes and whether or not that would cause a call to completely drop?
    Last edited by pete.kline; 03-04-2008, 09:04 AM.

  • #2
    Could you please post your exact build version. Also, what type of fax device? Is it a fax server, or a fax machine?

    The following defects have been corrected in ShoreTel 7 build 12.5.8901.0
    Modems fail to complete negotiation through ShoreTel.

    Modem calls fail to connect.

    obviously, I would move the device as close to the shoretel switch as possible, and change ports on the switch. This does 3 things:
    1. Moving it closer. Punch the analog device as close as possible to isolate any cable that is being run.
    2. Change the Port. Just to verify the problem follows.
    3. By changing the port, you change the DB. This has been known to resolve issues after upgrades. (create a whole new record for it)

    FAX machines require 0 Packet loss, which you stated before that you have ZERO packet loss, but this is from the IP side. A bad or damaged cable between the switch and the Fax machine could create a similar condition.

    Also, totally off the wall and out of the box. You can modify Analog trunk Gain via the DB directly (not through Shoreware director). I wonder if you could adjust it for the analog extension, as it's blank as well. Instructions are available from Shoretel on this.


    • #3
      There was something about an 8db loss on analogue trunk ports in one of the releases as well. This would affect faxing I think. What type of trunks do you have?


      • #4
        We're using Build 12.5.8902.0, connected directly to a Brooktrout 4-Port card in a machine directly below the 120/24 switch it is connected to. I've got the switch connected to a 2-foot MDF-to-Patch panel, the Brooktrout-specific shielded 4-pair cable plugs into that. Probably no more then 9 feet of distance. Each of the 4 extensions are set up as "Fax Server" in the appropriate area.

        For what it's worth, I've actually moved the ports to a different switch, and tried a different fax machine on the ports, all with the same behavior. It acts just like the switch is saying "hey, this is a fax call, let's redirect it" as though it were a desk extension, despite being set up differently. I did remove the extension completely when I moved it to a different switch as I've seen that happen with user extensions, but that didn't seem to change anything either.

        We have 2 T1 trunks running into the building, though this isn't really effecting outside-to-inside calls. It started out as an extension-to-extension issue; our vendor moved the CODEC from 128k Linear to 64k G.711, wondering if it were necessary despite it causing issues many months ago prompting me to change it. Either way, after a few toggles back and forth, it's now at 64k and working extension-to-extension, it's been intermittent and I'm guessing it's going to come back or be forced to stay at 64k to work around the issue, causing grief with our clients and failed faxes.

        As you can see, it's quite frustrating and I'm fairly out of ideas and our vendor doesn't seem to understand why the setting would make a difference or if 64k vs. 128k would make a difference for faxes, which my previous experience says that it should be at 128k. Either way, I'd expect the call to not drop but just error out if it were an inappropriate CODEC.
        Last edited by pete.kline; 03-03-2008, 09:33 PM.


        • #5
          Maybe try upgrading to the latest release of 7.0: 12.6.2301.0

          Other than that, I have no clue.


          • #6
            You should upgrade your build of 7.0 to the latest release Charles mention. There were quite a number of issues in 8901 that have been fixed, including analog related issues.

            Further, you Shoretel Partner is correct. The 128k codec should NOT be used for fax and modems calls. There are in fact problems with it and Shoretel is probably going to wind up removing it (hint in a future version, the codec selection for fax/modem changes).

            There are also issues with modems on the kilaeu hardware (these are the full 1U switches) and it does impact fax machines on occassion. It is especially rampant with USR modems. I've seen it impact fax machines with customers on a few rare occasions. New releases have improved this.

            Of course, checking the wiring is always helpful.


            • #7
              I'll get with my vendor to see if we can attempt an update to the newest builds. I really appreciate the second pair of eyes, so I can at least remain semi-secure in my sanity. For now, it appears that the 128k CODEC is not functioning correctly when it's a fax call, but perfectly fine otherwise. If I find a red-herring, I'll make sure to post it in case someone else has the same problem!


              • #8
                cburgy, our posts most have crossed each other on the way. I hadn't heard of an issue with the 128k CODEC and our vendor wasn't sure what the difference would be either way. Currently, they're in contact with Shoretel, so I'm certain they'll fall on the same information.

                I really appreciate the assistance.


                • #9
                  Originally posted by Charles View Post
                  Maybe try upgrading to the latest release of 7.0: 12.6.2301.0

                  Other than that, I have no clue.
                  It is worth a try by simply upgrading to the most stable version.


                  • #10
                    I hope after 2 years the problem has been resolved. Or