PROTOCOL_WARNING when sending a fax via T.38
Hello, I want to send a fax between two freeswitches (1.4.20) via T.38. On the SENDER freeswitch, I have Sangoma A104 TDM card and use the following dialplan: <action application="export" data="fax_enable_t38=true"/> <action application="export" data="fax_enable_t38_request=true"/> <action application="export" data="fax_verbose=true"/> <action application="export" data="execute_on_answer=t38_gateway self"/> <action application="bridge" data="sofia/external/${destination_number}@${destination_ip}"/> On the RECEIVER freeswitch I use the this dialplan: <action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="set" data="fax_enable_t38_request=false"/> <action application="export" data="fax_enable_t38=true"/> <action application="rxfax" data="/tmp/FAX-${uuid}.tiff"/> When I try to send a fax, on the RECEIVER freeswitch, I can see in the (second) INVITE the T.38 data is present: ... a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:2000 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy … On the SENDER side I can see that it tries to start the t38_gateway … 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: IFP 00 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: indicator no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) ced -> no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: IFP 06 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: indicator v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) no-signal -> v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:52.072799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G HDLC underflow at 4 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: IFP c0 01 80 00 00 ff 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: (0) data v21/hdlc-data + 1 byte(s) … But then fails with a protocol error 2015-09-17 23:34:07.652799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Tx 1: indicator v21-preamble 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:659 INVALID WRITE: 8:3 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:671 TERMINATING T30 STATE … 2015-09-17 23:34:07.652799 [WARNING] mod_spandsp_fax.c:286 PROTOCOL_WARNING T.38 Tx packet handler failure On the RECEIVER side the fax fails with „result (49) The call dropped prematurely“. Can this be because of a wrong configuration (dialplans/mod_spandsp), or is this a bug? Thanks and Regards Markus
Try on 1.4.21? We did fix an issue in this area where the CNG packets were causing issues with t.38. /b On Thursday, September 17, 2015, Markus Bönke <mbodbg@gmx.net> wrote:
Hello,
I want to send a fax between two freeswitches (1.4.20) via T.38. On the SENDER freeswitch, I have Sangoma A104 TDM card and use the following dialplan:
<action application="export" data="fax_enable_t38=true"/> <action application="export" data="fax_enable_t38_request=true"/> <action application="export" data="fax_verbose=true"/> <action application="export" data="execute_on_answer=t38_gateway self"/> <action application="bridge" data="sofia/external/${destination_number}@${destination_ip}"/>
On the RECEIVER freeswitch I use the this dialplan:
<action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="set" data="fax_enable_t38_request=false"/> <action application="export" data="fax_enable_t38=true"/> <action application="rxfax" data="/tmp/FAX-${uuid}.tiff"/>
When I try to send a fax, on the RECEIVER freeswitch, I can see in the (second) INVITE the T.38 data is present:
... a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:2000 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy …
On the SENDER side I can see that it tries to start the t38_gateway
… 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: IFP 00 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: indicator no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) ced -> no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: IFP 06 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: indicator v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) no-signal -> v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:52.072799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G HDLC underflow at 4 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: IFP c0 01 80 00 00 ff 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: (0) data v21/hdlc-data + 1 byte(s) …
But then fails with a protocol error
2015-09-17 23:34:07.652799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Tx 1: indicator v21-preamble 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:659 INVALID WRITE: 8:3 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:671 TERMINATING T30 STATE … 2015-09-17 23:34:07.652799 [WARNING] mod_spandsp_fax.c:286 PROTOCOL_WARNING T.38 Tx packet handler failure
On the RECEIVER side the fax fails with „result (49) The call dropped prematurely“. Can this be because of a wrong configuration (dialplans/mod_spandsp), or is this a bug?
Thanks and Regards
Markus
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
I just upgraded to 1.4.21, but it is the same issue.
Am 18.09.2015 um 00:08 schrieb Brian West <brian@freeswitch.org>:
Try on 1.4.21? We did fix an issue in this area where the CNG packets were causing issues with t.38.
/b
On Thursday, September 17, 2015, Markus Bönke <mbodbg@gmx.net <mailto:mbodbg@gmx.net>> wrote: Hello,
I want to send a fax between two freeswitches (1.4.20) via T.38. On the SENDER freeswitch, I have Sangoma A104 TDM card and use the following dialplan:
<action application="export" data="fax_enable_t38=true"/> <action application="export" data="fax_enable_t38_request=true"/> <action application="export" data="fax_verbose=true"/> <action application="export" data="execute_on_answer=t38_gateway self"/> <action application="bridge" data="sofia/external/${destination_number}@${destination_ip}"/>
On the RECEIVER freeswitch I use the this dialplan:
<action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="set" data="fax_enable_t38_request=false"/> <action application="export" data="fax_enable_t38=true"/> <action application="rxfax" data="/tmp/FAX-${uuid}.tiff"/>
When I try to send a fax, on the RECEIVER freeswitch, I can see in the (second) INVITE the T.38 data is present:
... a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:2000 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy …
On the SENDER side I can see that it tries to start the t38_gateway
… 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: IFP 00 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: indicator no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) ced -> no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: IFP 06 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: indicator v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) no-signal -> v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:52.072799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G HDLC underflow at 4 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: IFP c0 01 80 00 00 ff 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: (0) data v21/hdlc-data + 1 byte(s) …
But then fails with a protocol error
2015-09-17 23:34:07.652799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Tx 1: indicator v21-preamble 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:659 INVALID WRITE: 8:3 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:671 TERMINATING T30 STATE … 2015-09-17 23:34:07.652799 [WARNING] mod_spandsp_fax.c:286 PROTOCOL_WARNING T.38 Tx packet handler failure
On the RECEIVER side the fax fails with „result (49) The call dropped prematurely“. Can this be because of a wrong configuration (dialplans/mod_spandsp), or is this a bug?
Thanks and Regards
Markus
-- Brian West brian@freeswitch.org <mailto:brian@freeswitch.org>
Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
The write_frame failed, but without some debugging in there to see why, I could only guess at this point, I don't have the TDM setup you do to verify it. On Thu, Sep 17, 2015 at 5:58 PM, Markus Bönke <mbodbg@gmx.net> wrote:
I just upgraded to 1.4.21, but it is the same issue.
Am 18.09.2015 um 00:08 schrieb Brian West <brian@freeswitch.org>:
Try on 1.4.21? We did fix an issue in this area where the CNG packets were causing issues with t.38.
/b
On Thursday, September 17, 2015, Markus Bönke <mbodbg@gmx.net> wrote:
Hello,
I want to send a fax between two freeswitches (1.4.20) via T.38. On the SENDER freeswitch, I have Sangoma A104 TDM card and use the following dialplan:
<action application="export" data="fax_enable_t38=true"/> <action application="export" data="fax_enable_t38_request=true"/> <action application="export" data="fax_verbose=true"/> <action application="export" data="execute_on_answer=t38_gateway self"/> <action application="bridge" data="sofia/external/${destination_number}@${destination_ip}"/>
On the RECEIVER freeswitch I use the this dialplan:
<action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="set" data="fax_enable_t38_request=false"/> <action application="export" data="fax_enable_t38=true"/> <action application="rxfax" data="/tmp/FAX-${uuid}.tiff"/>
When I try to send a fax, on the RECEIVER freeswitch, I can see in the (second) INVITE the T.38 data is present:
... a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:2000 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy …
On the SENDER side I can see that it tries to start the t38_gateway
… 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: IFP 00 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: indicator no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) ced -> no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: IFP 06 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: indicator v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) no-signal -> v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:52.072799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G HDLC underflow at 4 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: IFP c0 01 80 00 00 ff 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: (0) data v21/hdlc-data + 1 byte(s) …
But then fails with a protocol error
2015-09-17 23:34:07.652799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Tx 1: indicator v21-preamble 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:659 INVALID WRITE: 8:3 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:671 TERMINATING T30 STATE … 2015-09-17 23:34:07.652799 [WARNING] mod_spandsp_fax.c:286 PROTOCOL_WARNING T.38 Tx packet handler failure
On the RECEIVER side the fax fails with „result (49) The call dropped prematurely“. Can this be because of a wrong configuration (dialplans/mod_spandsp), or is this a bug?
Thanks and Regards
Markus
--
*Brian West* brian@freeswitch.org
*Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com
Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch>
*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
I was able to reproduce the problem also in our lab environment. Now I have a setup with 3 freeswitches (All have version 1.4.21): freeswitch1 (Sangoma A200 Card) <—TDM—> freeswitch2 (Sangoma A200 Card) <- SIP/T.38 —> freeswitch3 freeswitch1 and freeswitch2 are connected via TDM with an E1 crossed cable. freeswitch3 has only a SIP profile running. From freeswitch1, I originate the fax with fs_cli -x "originate freetdm/1/a/02211111111111 &txfax(/tmp/lenna-colour.tif)" then freeswitch1 sends the fax via TDM to freeswitch2. <extension name="fax-over-ip-test"> <condition field="destination_number" expression="^(02211111111111)$"> <action application="log" data="INFO Incoming TEST FAX" /> <action application="export" data="fax_verbose=true" /> <action application="export" data="fax_enable_t38=true" /> <action application="export" data="fax_enable_t38_request=true" /> <action application="export" data="execute_on_answer=t38_gateway self" /> <action application="bridge" data="sofia/external/${destination_number}@192.168.1.151" /> <action application="hangup" data="NORMAL_CLEARING" /> </condition> </extension> freeswitch2 then sends the fax via SIP/T.38 to freeswitch 3, where the fax is finally received: <condition field="destination_number" expression="^(02211111111111)$"> <action application="log" data="INFO Incoming TEST FAX" /> <action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="set" data="fax_enable_t38_request=true"/> <action application="set" data="fax_enable_t38=true"/> <action application="rxfax" data="/tmp/FAX-${uuid}.tif"/> <action application="hangup"/> </condition> On freeswitch2, which acts in this case as TDM->T.38 gateway, I can see the same protocol error. See the full log here: freeswitch2: https://pastebin.freeswitch.org/24400 <https://pastebin.freeswitch.org/24400> freeswitch3: https://pastebin.freeswitch.org/24401 <https://pastebin.freeswitch.org/24401> Let me know how I can analyze the problem, maybe it helps if I add more log/debug messages to mod_spandsp and the test again? With debugging freeswitch I’m not familiar yet ... Thanks and Regards Markus
Am 18.09.2015 um 02:18 schrieb Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>>:
The write_frame failed, but without some debugging in there to see why, I could only guess at this point, I don't have the TDM setup you do to verify it.
On Thu, Sep 17 , 2015 at 5:58 PM, Markus Bönke <mbodbg@gmx.net <mailto:mbodbg@gmx.net>> wrote: I just upgraded to 1.4.21, but it is the same issue.
Am 18.09.2015 um 00:08 schrieb Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>>:
Try on 1.4.21? We did fix an issue in this area where the CNG packets were causing issues with t.38.
/b
On Thursday, September 17, 2015, Markus Bönke <mbodbg@gmx.net <mailto:mbodbg@gmx.net>> wrote: Hello,
I want to send a fax between two freeswitches (1.4.20) via T.38. On the SENDER freeswitch, I have Sangoma A104 TDM card and use the following dialplan:
<action application="export" data="fax_enable_t38=true"/> <action application="export" data="fax_enable_t38_request=true"/> <action application="export" data="fax_verbose=true"/> <action application="export" data="execute_on_answer=t38_gateway self"/> <action application="bridge" data="sofia/external/${destination_number}@${destination_ip}"/>
On the RECEIVER freeswitch I use the this dialplan:
<action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="set" data="fax_enable_t38_request=false"/> <action application="export" data="fax_enable_t38=true"/> <action application="rxfax" data="/tmp/FAX-${uuid}.tiff"/>
When I try to send a fax, on the RECEIVER freeswitch, I can see in the (second) INVITE the T.38 data is present:
... a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:2000 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy …
On the SENDER side I can see that it tries to start the t38_gateway
… 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: IFP 00 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 2: indicator no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) ced -> no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to no-signal 2015-09-17 23:36:51.092799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: IFP 06 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 3: indicator v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing - (0) no-signal -> v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Changing to v21-preamble 2015-09-17 23:36:51.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G Non-ECM mode 2015-09-17 23:36:52.072799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38G HDLC underflow at 4 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: IFP c0 01 80 00 00 ff 2015-09-17 23:36:52.172799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Rx 4: (0) data v21/hdlc-data + 1 byte(s) …
But then fails with a protocol error
2015-09-17 23:34:07.652799 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38 Tx 1: indicator v21-preamble 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:659 INVALID WRITE: 8:3 2015-09-17 23:34:07.652799 [ERR] mod_spandsp_fax.c:671 TERMINATING T30 STATE … 2015-09-17 23:34:07.652799 [WARNING] mod_spandsp_fax.c:286 PROTOCOL_WARNING T.38 Tx packet handler failure
On the RECEIVER side the fax fails with „result (49) The call dropped prematurely“. Can this be because of a wrong configuration (dialplans/mod_spandsp), or is this a bug?
Thanks and Regards
Markus
-- Brian West brian@freeswitch.org <mailto:brian@freeswitch.org>
Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> T:+19184209001 <tel:%2B19184209001> | F:+19184209002 <tel:%2B19184209002> | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
-- Brian West brian@freeswitch.org <mailto:brian@freeswitch.org>
Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Brian West
-
Markus Bönke