[cisco-voip] refining dial peers for Fax

Wed May 9 11:00:40 EDT 2018

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 <ryanhuff at outlook.com> 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 <bmeade90 at vt.edu>
>
>
> *Sent: *Tuesday, May 8, 2018 2:24 PM
> *To: *Anthony Holloway <avholloway+cisco-voip at gmail.com>
>
> *Cc: *Ryan Huff <ryanhuff at outlook.com>; cisco-voip at puck.nether.net; Fernando
> Fernandez Lopez <fferna12 at chemeketa.edu>; Jonatan Quezada
> <jonatan.quezada at chemeketa.edu>; Adrian Arevalo-Orozco
> <adrian.arevalo.orozco at 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-voip at gmail.com> wrote:
>
> /squints eyes
>
> Not sure if sarcasm, or helpful.
>
>
>
> On Tue, May 8, 2018 at 12:48 PM Brian Meade <bmeade90 at 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-voip at 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 <ryanhuff at 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.quezada at 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 <(503)%20399-7899>
>
> -or-
>
> Visit the help center from your employee dashboard found here:
>
> *https://dashboard.chemeketa.edu/helpcenter/default.aspx*
> <https://dashboard.chemeketa.edu/helpcenter/default.aspx>
>
>
>
>
>
> Johnny Q
>
> Voice Technology Analyst - TelNet
>
> Chemeketa Community College
>
> Johnny.Q at chemeketa.edu
>
> Building 22 Room 131
>
> Work 5033995294 <(503)%20399-5294>
>
> Mobile 9712182110 <(971)%20218-2110>
>
> SIP 5035406686 <(503)%20540-6686>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180509/f55bd07e/attachment.html>