[Freeswitch-users] t38 fax receive stuck

[Mirko Brankovic]

Hi,

I have a strange situation where faxes gets stuck for good amount of time
on rxfax application.

Detailed debugging let me to conclusion that one side doesn't send signal
back and the other side is not 'timing out'/ giving up.

Callflow is fax...provider...gateway... rxfax(file.tif)

Here is the log:

> b8a0b22f-5733-499d-a32f-712106821a53 2016-12-07 10:08:03.434513 [DEBUG]
> sofia.c:5677 Channel sofia/external/496421607583 at 89.184.172.62 entering
> state [ready][200]
> 2016-12-07 10:08:03.504510 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38T Type
> FCD - CRC OK (clean)
> 2016-12-07 10:08:03.504510 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Stop
> none (0 remaining)
> 2016-12-07 10:08:03.504510 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Rx:
>  FCD without final frame tag
> 2016-12-07 10:08:03.504510 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Rx:  ff
> 03 06 41 02 d1 a5 0b d2 bf ef ff af ae 77 1f 06 eb 88 5e bf fb 82 40 5f 7f
> 15 04 41 af ba 2e d5 13 48 8c 5f d7 9f 20 13 87 62 6c ba e8 e2 4b 5c 89 40
> ec ea 1b 32 c7 21 e2 29 08 7a 41 10 f4 d6 fd ff aa bf ff 1f 22 2e 30 1e 82
> e2 5f 02 81 56 e9 ab 6e 08 02 bd 21 5c c3 82 20 90 ff 08 d6 fa 5f 10 e1 b8
> 59 55 10 84 e8 e2 0e fd 55 a6 70 28 34 8e 7f 7f c7 02 4b 47 15 04 fd 0c e9
> ff 4d c9 53 1b 7d d5 af ff f5 bf 52 0e 02 f9 70 54 ad a3 7f bd 4a 70 cc 2d
> 15 5d c4 67 08 59 69 fc 5f fa 15 ba f5 82 a0 c8 91 bd 25 fd 11 b5 be 5e 53
> 69 3a 2e ad ea 8f a8 af 12 04 fd ff 43 d0 10 e8 fd 54 8b 21 ba d8 fa ff 9a
> 2f 53 89 24 04 21 9a 64 31 3f 52 69 e2 13 9f 2e ba e8 d2 ff 7f 21 04 aa 82
> 88 ff 35 7d ba 40 a0 5d 5f 7a bc 9e 10 fd 2f be 52 5b fa ef a8 a6 e2 ff ff
> 6b f5 fd bf d0 d1 ff 7a ff
> 2016-12-07 10:08:03.504510 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Storing
> ECM frame 65, length 256
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Receive
> complete in phase T30_PHASE_C_NON_ECM_RX, state 7
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Non-ECM
> signal status is Carrier down (-1) in state 7
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30
> Trainability (TCF) test result - 14512 total bits. longest run of zeros was
> 14480
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30
> Changing from phase T30_PHASE_C_NON_ECM_RX to T30_PHASE_B_TX
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38T Set rx
> type 0
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.38T Set tx
> type 4
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30
> Changing from state 7 to 8
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Tx:
>  CFR with final frame tag
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 Tx:  ff
> 13 84
> 2016-12-07 10:08:03.524532 [DEBUG] mod_spandsp_fax.c:286 FLOW T.30 No
> signal is present



What I think from the log is that there is no signal from the initiating
side, which leads to the message "No signal is present" but my question is
why would spandsp still keep waiting?

Problem is that this is quite old version of FreeSwitch (FreeSWITCH Version
1.2.0 (git-89c590c 2012-05-08 20-08-26 +0000)) based on ooooold commit
89c590c

I've looked at the git diff between the current spandsp and that one, and
there are some changes but not that much.


Can anyone familiar with this bring some light to me please :)

Thanks,
-- 
Regards,
Mirko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20161207/606c017e/attachment.html