Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

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


 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users
View previous topic :: View next topic  
Author Message
jeff at ugnd.org
Guest





PostPosted: Fri Aug 06, 2021 4:12 pm    Post subject: [Freeswitch-users] inbound T.38 re-invite transaction stalls Reply with quote

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@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@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@1.2.3.4:5060 T38 ACCEPT on request
[DEBUG] switch_core_media.c:5296 sofia/external/4045551111@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
Back to top
dgreenwald at gmail.com
Guest





PostPosted: Sat Aug 14, 2021 10:29 pm    Post subject: [Freeswitch-users] inbound T.38 re-invite transaction stalls Reply with quote

Is PCMU media flowing before the REINVITE? 

On Fri, Aug 6, 2021 at 5:10 PM Jeff Pyle <jeff@ugnd.org (jeff@ugnd.org)> wrote:

Quote:
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@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@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@1.2.3.4:5060 T38 ACCEPT on request
[DEBUG] switch_core_media.c:5296 sofia/external/4045551111@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



_________________________________________________________________________

The FreeSWITCH project is sponsored by SignalWire https://signalwire.com
Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services.
Build your next product on our scalable cloud platform.

Join our online community to chat in real time https://signalwire.community

Professional FreeSWITCH Services
sales@freeswitch.com (sales@freeswitch.com)
https://freeswitch.com

Official FreeSWITCH Sites
https://freeswitch.com/oss
https://freeswitch.org/confluence
https://cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
https://freeswitch.com
Back to top
jeff at ugnd.org
Guest





PostPosted: Thu Aug 19, 2021 8:18 am    Post subject: [Freeswitch-users] inbound T.38 re-invite transaction stalls Reply with quote

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@gmail.com (dgreenwald@gmail.com)> wrote:

Quote:
Is PCMU media flowing before the REINVITE? 

On Fri, Aug 6, 2021 at 5:10 PM Jeff Pyle <jeff@ugnd.org (jeff@ugnd.org)> wrote:

Quote:
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@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@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@1.2.3.4:5060 T38 ACCEPT on request
[DEBUG] switch_core_media.c:5296 sofia/external/4045551111@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




Back to top
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group

VoiceMeUp - Corporate & Wholesale VoIP Services