[asterisk-users] Digium FFA + Gafachi T38 outgoing issues

[James Sharp]

On 10/07/2011 04:04 PM, Kevin P. Fleming wrote:

> First, we can see that Gafachi's T.38 implementation still has some
> breakage in it (although the problems are ones that Asterisk has been
> taught to deal with). In its 200 OK to the T.38 re-INVITE, it has
> "a=T38FaxRateManagement:transferredTCFlocalTCF"; this is not valid (the
> valid values for this are 'transferredTCF' and 'localTCF'). In addition,
> even though Asterisk sent "a=T38FaxUdpEC:t38UDPRedundancy", Gafachi
> replied with "a=T38FaxUdpEC:t38UDPFEC". For T.38 version 0 (which is in
> use here), the only valid response was either what Asterisk sent, or no
> T38FaxUdpEC value at all.
>
> However, it is unlikely those are causing the call failure here. It's
> hard to say for sure without seeing the contents of the UDPTL packets,
> but based on their sizes, they are very likely "t38-nosignal" packets,
> and if that's all the FAX stack in Asterisk ever received, it would not
> trigger a FAX transaction to begin. Another possible problem is the
> repeated 'seq 0' in all the UDPTL packets, but this could be a problem
> with the UDPTL stack debugging messages themselves (this was just fixed
> in the Subversion branches for Asterisk 1.8 and later a couple of days
> ago).

Theres a few t30-nosignal packets at the beginning, but then they 
transition to other t30 packets, including CNG, CED, preambles, training 
and data.  Wireshark says the sequence number is always 0, so it appears 
that Asterisk is not mis-displaying

http://pastebin.ca/2087784

I can provide the raw tcpdump file if needed.

>
> If you would, please retry this with the HEAD of the Asterisk 10 branch
> instead of 10.0.0-beta1, and also capture the UDPTL packets themselves
> so we can see what they contained.
>