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

Thu Apr 6 10:46:19 EDT 2017

I use t38 over AT&T just fine

On Thu, Apr 6, 2017 at 10:37 AM, Brian Meade <bmeade90 at vt.edu> wrote:

> I've got SIP with T.38 as well as PRI in different environments that are
> all working pretty well with that setup.
>
> On Thu, Apr 6, 2017 at 10:24 AM, Haas, Neal <nhaas at co.fresno.ca.us> wrote:
>
>> Do you use SIP or PRI, we use PRI 99.9% of the time, ATT does not allow
>> T.38 over SIP.
>>
>>
>>
>> I will likely get a SIP trunk from Comcast or Time Warner in the future,
>> they both do T.38 over SIP. Both say they can do Faxes without issue.
>>
>>
>>
>> Thank You,
>>
>>
>>
>> Neal Haas
>>
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On
>> Behalf Of *Brian Meade
>> *Sent:* Thursday, April 6, 2017 7:09 AM
>> *To:* Frank Arrasmith <frank.arrasmith at gmail.com>
>> *Cc:* cisco-voip at puck.nether.net
>> *Subject:* Re: [cisco-voip] Question regarding Rightfax Configuration
>> and "Transmission Error"
>>
>>
>>
>> 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
>>
>>
>>
>
>
> _______________________________________________
> 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/d926b8ce/attachment.html>