Anthony, I like to do it at every angle possible; by changing TX at the machine level, I ensure that is the machine capability no matter where it gets moved to in the enterprise (Ex. Moved to a different department using a different VG). I like dealing with it on the dial-peer level sometimes because I get more granularity, and that is a personal preference. Also, software in my experience, has not been reliably great at muxing fax modulation (reducing a higher TX to 14400/9600, disabling ECM). The more I can address at the machine level and the less “interferers” I allow to get involved with the transmission, the better experiences I’ve had.
Lowering the transmission rate helps because the transmission often has less loss. This is especially helpful with TDM if you’re going over weaker/old copper and also in the sip world if you’re using UDP. ECM is computationally intensive and requires dedicated resources in carrier switches to successfully deliver error correction end to end; most carriers don’t do a great job handling ECM and by turning it off, helps to avoid problems. Disabling ECM will also prevent cancellations of transmissions that would be successful, but might have a little loss. Not all fax machines are created equally, tempered with the user’s perception that, a fax machine is a fax machine and they should all work no less reliably than an “email machine”. One must also consider the “younger than 30” workforce has a really good chance of never having used/seen a fax machine outside of work or the Smithsonian Institution and their perception of a fax machine’s reliability is that of email, texting or IM -it should just work because it always does. The reality is though, faxing is an old analog technology (subject to all the frailties of an analog technology) that we have thrown enough “digital dressing” on to make users think it isn’t a crappy way to communicate. It’s the legacy that “big print” created back in the late 90s early 00’s because they didn’t want the faxing business to die off ….. ok, that may have been a bit “tin foil hat’ish”, but you get the idea. There is a wildly diverse fax machine population out there with varying implementations of the facsimile standard; some support SG3, some are pre-SG3, some only have a 14.4 kbps modem in them cause it’s that friggin’ old; getting faxing “to work everywhere” like one can call from phone to phone just isn’t a reality any more, and its only going to get worse as time goes on. The point is and because of this; getting faxing to work is less of a binary science and more of a, “getting it to mostly work for all the places your users send faxes”. These are analog machines; their capabilities and use of protocols aren’t generally updated on the fly or at all in some cases, much less known by the user that updating should occur. Generally speaking, the way the fax machine used the facsimile standard out of the box is the way it’ll work for the rest of its days. -Ryan- From: Brian Meade<mailto:bmead...@vt.edu> Sent: Tuesday, May 8, 2018 2:24 PM To: Anthony Holloway<mailto:avholloway+cisco-v...@gmail.com> Cc: Ryan Huff<mailto:ryanh...@outlook.com>; cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>; Fernando Fernandez Lopez<mailto:ffern...@chemeketa.edu>; Jonatan Quezada<mailto:jonatan.quez...@chemeketa.edu>; Adrian Arevalo-Orozco<mailto:adrian.arevalo.oro...@chemeketa.edu> Subject: Re: [cisco-voip] refining dial peers for Fax It really does seem to help from what I've seen. Users have accepted faxing is going to be slow. Most machines I find have it set to 9600 anyways. On Tue, May 8, 2018 at 2:17 PM, Anthony Holloway <avholloway+cisco-v...@gmail.com<mailto:avholloway+cisco-v...@gmail.com>> wrote: /squints eyes Not sure if sarcasm, or helpful. On Tue, May 8, 2018 at 12:48 PM Brian Meade <bmead...@vt.edu<mailto:bmead...@vt.edu>> wrote: I like to limit down to 9600. That seems to work out much better. On Tue, May 8, 2018 at 12:54 PM, Anthony Holloway <avholloway+cisco-v...@gmail.com<mailto:avholloway+cisco-v...@gmail.com>> wrote: What's the explanation for setting the fax machine itself to 14400, or the dial-peer for that matter, when for the most part SG3 is not supported, and SG3 gets spoofed down to G3, and the command "fax rate voice", which is the default, already caps at 14400? I might have explained that poorly, but basically, I see 14400 speeds all the time, and I don't change the fax rate command nor set the speed on the machine. I'm not challenging what you're saying, just trying to understand it. Fax has been a pain for me, just like everyone else, so the more I know, the better I can deal with it. I do like to avoid unnecessary config when possible, but in this case, I just don't know if there is proven evidence, that you need to do these two things. On Tue, May 8, 2018 at 11:35 AM Ryan Huff <ryanh...@outlook.com<mailto:ryanh...@outlook.com>> wrote: Set the TX/RX rate at 14400 kbps and turn ECM. I would do that at the machine level first, and/or the dial-peer level second. Sent from my iPhone On May 8, 2018, at 12:17, Jonatan Quezada <jonatan.quez...@chemeketa.edu<mailto:jonatan.quez...@chemeketa.edu>> wrote: we are finding that after our sip cutover, that our faxes are happiest signalling over a T1 connection that originally we were trying to get away from, however trouble shooting was terrible and we are moving past having all voice traffic on the SIP trunk. Currently we are signalling for voice( calls ) only on the trunk and fax traffic can come in and out via that T1. My question is , still every so often we are seeing fax drops and incomplete page transmissions. looking at the controller the interface is solid no slips and seems to negotiate the connections just fine. but again every so often there are drops or sending fails altogether. We are wanting to try limiting the transmission rates but on the ATA190 and 191s you cannot rate limit on the device. It sounds like this needs to done at the dial peer level. if so what is the best starting configuration for the dial peers that will handle on ly fax and go out a certain gateway that has the T1 on it? https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/115742-fax-modem-call-flows-00.html Im looking at this call flow Telco - PRI - GW - MGCP - CUCM - SIP - ATA187 - Fax/Modem<https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/115742-fax-modem-call-flows-00.html#anc7> except the ATAs are 190 and 191s If we go the dial peer route, since the DID are not contiguous I will need a dial peer for each one huh? -- For immediate assistance please reach out to Chemeketa IT Help Desk at 5033997899<tel:(503)%20399-7899> -or- Visit the help center from your employee dashboard found here: https://dashboard.chemeketa.edu/helpcenter/default.aspx Johnny Q Voice Technology Analyst - TelNet Chemeketa Community College johnn...@chemeketa.edu<mailto:johnn...@chemeketa.edu> Building 22 Room 131 Work 5033995294<tel:(503)%20399-5294> Mobile 9712182110<tel:(971)%20218-2110> SIP 5035406686<tel:(503)%20540-6686> _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
