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

[Steve Underwood]

On 10/08/2011 04:04 AM, Kevin P. Fleming wrote:
> On 10/07/2011 02:20 PM, James Sharp wrote:
>> On 10/07/2011 12:27 AM, Nasir Iqbal wrote:
>>> Check firewall and NAT settings!
>>>
>>> Monitoring sip and media flow from asterisk cli can help, use "sip set
>>> debug on", "rtp set debug on" and "udptl set debug on"
>>>
>>
>> No NAT involved and I shut off IPTables. Still no luck. Debug shows the
>> SIP invite, RTP frames going in & out, the SIP reinvite, and then UDPTL
>> frames coming in until timeout.
>>
>> See the entire transaction at http://pastebin.ca/2087758
>
> Thanks for that; it helps.
>
> 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.
t38UDPFEC is perfectly valid for version 0 of T.38. It works badly, so 
it makes no sense to use it, but it is valid.
>
> 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).
>
> 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.
>
Steve