VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
jeff at ugnd.org Guest
|
Posted: Fri Aug 06, 2021 4:12 pm Post subject: [Freeswitch-users] inbound T.38 re-invite transaction stalls |
|
|
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
|
Posted: Sat Aug 14, 2021 10:29 pm Post subject: [Freeswitch-users] inbound T.38 re-invite transaction stalls |
|
|
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
|
Posted: Thu Aug 19, 2021 8:18 am Post subject: [Freeswitch-users] inbound T.38 re-invite transaction stalls |
|
|
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 |
|
|
|
|
|
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
|