[cisco-voip] Question regarding Rightfax Configuration and "Transmission Error"

[Brian Meade]

I've had the most luck turning ECM off and running RightFax at only 9600.
Faxes are slower but usually higher quality and less failures.

On Wed, Apr 5, 2017 at 8:06 PM, Frank Arrasmith <frank.arrasmith at gmail.com>
wrote:

> Calling all Rightfax gurus,
>    I have the following question regarding the Rightfax configuration and
> transmission errors.
>
> Background:
> My enterprise has CUCM 10.5 with a pretty dialed in Fax/T38 setup over SIP
> and MGCP gateways.  For the most part, faxing is pretty solid inbound and
> outbound to and from PSTN GW's, CUBEs, ,analog VG's, and regular fax
> machines(we have a lot).  We have a SIP trunk connected to Rightfax 10.5
> server, which is managed by another group where we have limited
> access/experience with Rightfax configuration settings.  It took us awhile
> to get the Rightfax servers with the correct t38 setup because they had
> only run traditional CAS T1 prior to us, so it was new to everyone, but it
> is up and stable except for the following issue..
>
> Symptom :
> The problem we see with Rightfax is with Transmission errors.  It starts
> with our internal customers reporting that they do not receive a fax even
> when the sender receives confirmation.  Upon further review we see that the
> suspect call is listed as a "Transmission Error" in Rightfax, so the fax
> never gets delivered to the customers account/mailbox even though the call
> completes.
>
> Analysis:
> Since we are running T38, we can packet capture at the server, and  we see
> normal fax protocol exchange, except for the suspect calls where we see
> "RTN" Messages.  My understanding of the T.30 protocol is that when a RTN
> message is delivered to the sender, that is an indication for the sender to
> slow down and resend the last page. We actually see in the messages where
> the RTN message gets sent, and the sender complies with the notice, and
> sends again at 12000, then call completes as normal with an EOP message and
> a DCN message.  In these cases,the Rightfax team actually looks at the fax
> image and may see a bit of blurriness, but perfectly legible text ,even tho
> its still marked as transmission failure. We have asked them if there is a
> setting that can be tuned where the RTN does not cause the service to mark
> the transmission as failure. To this they reply, "It was working fine
> before when we were on CAS, so it must be on your end."
>
> I understand where there are cases where the RTN message is sent because
> the call quality is actually terrible, but in those cases, there is usually
> several RTN messages and the sender will drop down to 4800 or below , and
> then usually give up and the call will fail.  This type of failure is rare
> (unless we have a major outage) and in this case the sending fax sees that
> it failed and will proceed with its normal retries.
>
> Question:
>
> Is this RTN to transmission failure hard coded, or is this a configurable
> setting?  If this were a regular fax machine, i think this would be a non
> issue as the receiver would see the crappy page as well as the good copy of
> that was sent again in their bundle of received pages.
>
> Any insight is greatly appreciated and for anyone just getting into FAX
> over IP with Cisco, I highly recommend the following book and Cisco Live
> presentations from these guys from Cisco TAC.
>
> Fax, Modem, and Text for IP Telephony [Book]
> <https://www.google.com/aclk?sa=l&ai=DChcSEwiXgOn0wY7TAhXJCioKHRVCANoYABAMGgJ0bQ&sig=AOD64_1ddnEIE3WNy8NH5g7yJ-WnrcChJA&ctype=5&q=&ved=0ahUKEwjei-P0wY7TAhUnj1QKHejtCy0QwzwIEg&adurl=>
> from Textbooks.com
> by David Hanes, Gonzalo Salgueiro
>
>
>
>
>
>
> Thanks,
>  Frank
>
>
>
> _______________________________________________
> 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/20170406/7126b1de/attachment.html>