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

JR Richardson jmr.richardson at gmail.com
Tue Dec 8 21:13:36 CST 2009

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
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.



More information about the asterisk-dev mailing list