[asterisk-dev] Add attributes to Asterisk T38 invite for MAX TNT Interop? Update

[JR Richardson]

On Tue, Dec 8, 2009 at 7:31 PM, JR Richardson <jmr.richardson at gmail.com> wrote:
>> JR Richardson wrote:
>>
>> > Here is what Asterisk sends to the tnt:
>> > m=image 20228 udptl t38
>> > a=T38FaxVersion:0
>> > a=T38MaxBitRate:14400
>> > a=T38FaxRateManagement:transferredTCF
>> > a=T38FaxMaxBuffer:0
>> > a=T38FaxMaxDatagram:0
>> > a=T38FaxUdpEC:t38UDPRedundancy
>>
>> That is broken; T38FaxMaxDatagram should never be zero. Something is
>> wrong there.
>>
>> As far as the non-present parameters, they are all optional and it does
>> not matter whether they are present or not, unless the answerer intends
>> to support that particular option/feature. Most T.38 SDP parameters are
>> *not* negotiated, but instead are declarative and indicate what that
>> endpoint wants to receive.
>>
>> --
>> Kevin P. Fleming
>
> Hmm, ok, I think I buy that as well as Steve's commnet on a=T38FaxMaxBuffer:0.
>
> I did enable the three questionable parameters in chan_sip.c,
> re-compiled and ran test with same results, so even though all the
> proper attribuets were sent in the invite to the TNT, the TNT did not
> respond with any udptl packets.
>
> Here is my testing setup:
> PSTN PRI><MAX TNT><SIP><Asterisk><NAT><AC MP203 ATA><Fax machine
>
> I send fax from the fax machine out to the PSTN, the t38 session is
> started from the fax ATA.
> The invite from the ATA includes:
> a=T38FaxMaxBuffer:1024
> a=T38FaxMaxDatagram:372
>
> Asterisk ACK the invite back to the ATA and send t38 invite to TNT:
> The invite from Asterisk includes:
> a=T38FaxMaxBuffer:0
> a=T38FaxMaxDatagram:0
>
> So I'm guessing Asterisk is not reading or storing the parameters
> correctly from the ATA?
>
> I'll poke around here for a bit, if you have any suggestions, let me know.
>
> Thanks.
>
> JR

I hard coded
a=T38FaxMaxBuffer:1024
a=T38FaxMaxDatagram:400
in chan_sip.c and ran another test, sure enough the TNT started
sending udptl packets, completed t.39 fax transmission end-to-end
through Asterisk to the ATA with no errors.  So I guess the mechanism
that captures these values is not working properly.  I want to do some
more testing, then I'll file this in the bugtracker.

Thanks.

JR