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

[Kevin P. Fleming]

On 10/07/2011 03:29 PM, James Sharp wrote:
> 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

You shouldn't be *receiving* CNG, as you are the calling endpoint.

If you are seeing UDPTL packets containing T.38 CED, V.21 preamble, DIS, 
etc. then something is badly wrong.

... and, that thing is probably the sequence number. Once Asterisk sees 
a packet with sequence number 0, any subsequent packets received with 
the same sequence number will be dropped (because according to the T.38 
recommendation, they must be retransmissions... new packets would have 
higher sequence numbers). So these UDPTL packets are never making their 
way up to the FAX stack, and the FAX transaction never gets started.

I guess it must be common for UDPTL stacks out there to just not care 
about repeated sequence numbers, although the one in Asterisk sure does 
(and it's based on the same code as the one in CallWeaver, FreeSwitch 
and maybe other packages too).

If you'd like to experiment, you can comment out lines 495 and 511 of 
main/udptl.c, which will make Asterisk's UDPTL stack just not care at 
all about the incoming sequence number.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org