Ideally, I prefer setting transmission speed at the machine and not letting IOS do anything regarding speed.
Yes, the handshake “noise” samples, so to speak (RTP payload) in a fax over SIP will always be UDP; the signaling (SIP) could be TCP or UDP. If you do have a poor connection, you could lose signaling due to packet loss, and the connection terminate (whereas TCP would attempt a retransmission). Admittedly, mostly a mute point because if you have packet loss for sip, you generally have packet loss with all other protocols .... unless; the loss is due to a poor / ill informed QoS strategy that happens to be trashing signaling? Then again, likely a limited scenario that would generally impact other things beyond faxing. All this drives to my final point. I love to know why something works too! As I have grown older though (Hey, still under 40); I’ve found it more efficient to me, to focus that effort only in areas that will benefit me into the future. I think as we grow older, time and it’s use becomes more valuable; at least it has for me. Most of us in the industry who have had to deal with faxing over VoIP and faxing over sip have come to the unofficial consensus that it is much more effective, when facing faxing issues with fax over VoIP/SIP, to throw a set of known fixes at the problem and in doing so, generally solves our issue or reduces the scope of issue enough to be accepted by the customer. You could burn your cycles getting an RCA on every fax issue you encounter; I’d ask though, to what end? I would ask myself if understanding the peculiarities of the faxing issue and its founding conflicts are going to create knowledge I can use to grow and build, or would it be an investment in understanding a legacy? I tend to answer with the latter for faxing. Sure, grasping the configuration fundamentals are necessary as long as customers still fax; but is “knowing” how faxing works like you “know” how sip works a worth while rabbit hole? I’d say not. Regarding NSF; back in the day some fax machines would transmit proprietary capabilities encoded into the frequency modulation (Ricoh and Konica Minolta did this, some others I’m sure too). The idea was that if you did an “intra vendor” fax (same to same), you could get “enhanced” faxing abilities. It was like SDP’s weird analog cousin from the 80s with crooked teeth that shows up only to the family reunions (no offense to all the dentally challenged weird cousins from the 80s out there). The issue IOS had when it got in the middle as a fax relay, is that it would demodulate and decode the fax tones; since these “enhanced” capabilities (tones) weren’t standard, IOS would kill the transmission. Enter NSF, which overwrites the “non standard facilities” in the demodulated transmission and only allows the standard group 3 requirements. To your point though, it probably won’t fix much nowadays because most machines don’t do that anymore. Still a useful command if your Grandfather’s fax machine ever made it onto a customer’s network though. -Ryan- On May 9, 2018, at 11:00, Anthony Holloway <[email protected]<mailto:[email protected]>> wrote: Thanks for replying Ryan, I enjoy reading your replies. Shall we post the popcorn image again? I agree that setting the fax machine to 14400 helps with when it's moved around the environment, and the different gateways may or may not be set correctly. However, I was wondering more for the stationary scenario. As in, if you are troubleshooting a fax machine which isn't currently moving, would setting the TX speed on the machine, really be critical step. I do think that setting it couldn't hurt, and if you're taking shots at a problem, then why not, but I think you and I can agree on this: I want to know why something works, versus just throwing everything at the problem until it works. Also, you said: "..in the sip world if you’re using UDP." The choice in SIP transport for is signaling only, not the transmission of payload (RTP for passthrough or T.38 for relay), which if I'm not mistaken, is always UDP. Am I incorrect in my understanding, or possibly in what you were saying? Lastly, have you considered disabling Non-Standard Facilities (NSF) in IOS? I do this, but honestly, I've not actually seen it solve anything, I just think it's a good practice, since it really only works with like fax machines. On Tue, May 8, 2018 at 2:53 PM Ryan Huff <[email protected]<mailto:[email protected]>> wrote: 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:[email protected]> Sent: Tuesday, May 8, 2018 2:24 PM To: Anthony Holloway<mailto:[email protected]> Cc: Ryan Huff<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Fernando Fernandez Lopez<mailto:[email protected]>; Jonatan Quezada<mailto:[email protected]>; Adrian Arevalo-Orozco<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: /squints eyes Not sure if sarcasm, or helpful. On Tue, May 8, 2018 at 12:48 PM Brian Meade <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
