<div dir="ltr"><div>Daniel,</div><div><br></div><div>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?  <br></div><div><br></div><div><br></div><div>- Jeff<br></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 14, 2021 at 10:54 PM Daniel Greenwald <<a href="mailto:dgreenwald@gmail.com">dgreenwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Is PCMU media flowing before the REINVITE? </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 6, 2021 at 5:10 PM Jeff Pyle <<a href="mailto:jeff@ugnd.org" target="_blank">jeff@ugnd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>This is on 1.10.6-release-18-1ff9d0a60e~64bit, the latest release version from the repo.<br></div><div><br></div><div>I run the following API command to send a TIFF file with txfax:</div><div><br></div><div><span style="font-family:monospace">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@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/<a href="http://4045551111@1.2.3.4:5060" target="_blank">4045551111@1.2.3.4:5060</a> &txfax(/usr/local/etc/faxtiffs/smiley-fine.tif)</span></div><div><br></div><div>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:<br><br><span style="font-family:monospace">[DEBUG] switch_core_media.c:5192 sofia/external/<a href="http://4045551111@1.2.3.4:5060" target="_blank">4045551111@1.2.3.4:5060</a> T38 ACCEPT on request<br>[DEBUG] switch_core_media.c:5296 sofia/external/<a href="http://4045551111@1.2.3.4:5060" target="_blank">4045551111@1.2.3.4:5060</a> T38 IS POSSIBLE on request</span><br></div><div><br></div><div>And then nothing.  No 200 OK, 488 Not Acceptable Here, nothing past the 100 Trying.  I can't tell why.<br><br></div><div>spandsp.conf.xml is vanilla with only ident, header and spool-dir updated.<br></div><div><br></div><div></div><div>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.  <br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Regards,</div><div>Jeff</div><div><br></div></div></blockquote></div></blockquote></div></div>