[Freeswitch-users] inbound T.38 re-invite transaction stalls

[Jeff Pyle]

Daniel,

As it turns out, there is not.  The far-end fax server sends the T.38
re-INVITE immediately after sending the ACK to the 200 OK on the initial
transaction, and doesn't send RTP.  By your specific question I suspect
this is relevant.  Am I able to handle this scenario in Freeswitch?


- Jeff


On Sat, Aug 14, 2021 at 10:54 PM Daniel Greenwald <dgreenwald at gmail.com>
wrote:

> Is PCMU media flowing before the REINVITE?
>
> On Fri, Aug 6, 2021 at 5:10 PM Jeff Pyle <jeff at ugnd.org> wrote:
>
>> Hello,
>>
>> This is on 1.10.6-release-18-1ff9d0a60e~64bit, the latest release version
>> from the repo.
>>
>> I run the following API command to send a TIFF file with txfax:
>>
>> originate
>> {sip_h_P-CustomHeader=value,ignore_early_media=true,fax_ident='Fax
>> Test',origination_caller_id_name='Fax
>> Test',origination_caller_id_number=2165551111,absolute_codec_string=PCMU at 20i
>> ,fax_verbose=true,fax_enable_t38=yes,fax_enable_t38_request=yes,fax_use_ecm=no,fax_end_page=1,jitterbuffer_msec=200:200:200}sofia/external/
>> 4045551111 at 1.2.3.4:5060 &txfax(/usr/local/etc/faxtiffs/smiley-fine.tif)
>>
>> The INVITE goes out as expected, and the call connects normally.  One
>> second later, the far side sends a re-invite for T.38.  Local FreeSWITCH
>> shows the remote SDP on the console, sends a 100 Trying, and this appears
>> on the console:
>>
>> [DEBUG] switch_core_media.c:5192 sofia/external/4045551111 at 1.2.3.4:5060
>> T38 ACCEPT on request
>> [DEBUG] switch_core_media.c:5296 sofia/external/4045551111 at 1.2.3.4:5060
>> T38 IS POSSIBLE on request
>>
>> And then nothing.  No 200 OK, 488 Not Acceptable Here, nothing past the
>> 100 Trying.  I can't tell why.
>>
>> spandsp.conf.xml is vanilla with only ident, header and spool-dir updated.
>>
>> The environment is relatively simple with all static public IPs, no NAT,
>> etc.  This particular FS instance serves only as an endpoint for testing
>> like this fax example.
>>
>> This configuration has been working in general for years and specifically
>> on this box for almost a year.  Apparently something has changed somewhere
>> but I can't see what.  I'm hoping someone might be able to point me in a
>> direction to diagnose and solve this.
>>
>>
>> Regards,
>> Jeff
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20210819/03f3a594/attachment.html>