[asterisk-users] FFA SendFax rejects T.38 reINVITE (488 Not acceptable here)

[VoIP Question]

We're learning all the time and made some significant progress and some 
very nice calls scenarios, but specifically with this issue, is there 
anything we can do to solve the interop problem with this end-point?

Thanks.

-------- Original Message  --------
Subject: Re: [asterisk-users] FFA SendFax rejects T.38 reINVITE (488 Not 
acceptable here)
From: Kevin P. Fleming <kpfleming at digium.com>
To: asterisk-users at lists.digium.com
Date: Thursday, 21 October, 2010 16:11:00

> On 10/20/2010 11:35 AM, VoIP Question wrote:
>> On Wed, Oct 20, 2010 at 4:25 PM, Kevin P. Fleming<kpfleming at digium.com
>> <mailto:kpfleming at digium.com>>  wrote:
>>
>>
>>      This was fixed in Asterisk 1.6.2.12 and later releases, so if you were
>>      running the current version, you wouldn't have experienced this specific
>>      problem. This was listed in the ChangeLog for 1.6.2.12, but
>>      unfortunately the commit message the developer wrote did not explain why
>>      the change was made or what problem it was addressing, so you wouldn't
>>      have noticed it.
>>
>>      In any case, upgrading to 1.6.2.12 or later will cure this problem.
>>
>> I upgraded to 1.6.2.13 and now we get this error (with a specific
>> destination, to which we occasionally need to send faxes):
>>
>> WARNING[857]: udptl.c:1087 ast_udptl_write: (SIP/XXXXXXXXXXX): UDPTL
>> asked to send 50 bytes of IFP when far end only prepared to accept 30
>> bytes; data loss will occur.You may need to override the
>> T38FaxMaxDatagram value for this endpoint in the channel driver
>> configuration.
>>
>>
>> How can we fix it, without risking incompatibility with other
>> end-points? What's a "channel driver configuration" and where is it?
>
> It appears that you need to spend some time learning the basics of
> Asterisk. In this case, the channel driver is chan_sip, since the
> channel involved is a SIP channel, and the 'channel driver
> configuration' is the sip.conf file. It is unfortunate that you have
> chosen to tackle a very complex task (T.38 interoperability is fraught
> with problems due to widely varying implementations) as your first
> experience with Asterisk... there's a lot you'll need to learn to be
> able to diagnose and troubleshoot problems. Asterisk alone is not 'point
> and click', and adding T.38 to the mix makes things more complicated.
>