[asterisk-bugs] [JIRA] (ASTERISK-28887) sendFAX fail with T.38

Tue May 12 05:43:25 CDT 2020

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250723#comment-250723 ] 

Asterisk Team commented on ASTERISK-28887:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

> sendFAX fail with T.38
> ----------------------
>
>                 Key: ASTERISK-28887
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28887
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_fax, Resources/res_fax_spandsp
>    Affects Versions: 16.2.0
>         Environment: AWS Debian GNU/Linux 10 (buster)
>            Reporter: Yasiru Gaminda
>              Labels: fax
>
> sendFAX dialplan application stop responding after send OK for T.38 re-invite.
> I manage to send fax using G711 without issues. Only issue is with T.38.
> Debug log is like below,
> {noformat}
> [May 12 19:25:44] DEBUG[21084][C-00000039] pbx_variables.c: Result of 'fax_file' is '/home/admin/files/20.tiff'
> [May 12 19:25:44] DEBUG[21084][C-00000039] pbx.c: Launching 'SendFAX'
> [May 12 19:25:44] DEBUG[21084][C-00000039] res_fax.c: Reserving a FAX session from 'Spandsp FAX Driver'.
> [May 12 19:25:44] DEBUG[21084][C-00000039] res_fax.c: Selected FAX technology module (Spandsp FAX Driver) does not support reserving sessions.
> [May 12 19:25:44] DEBUG[21084][C-00000039] channel.c: Channel SIP/staging-mediagw-00000035 setting write format path: slin -> alaw
> [May 12 19:25:44] DEBUG[21084][C-00000039] channel.c: Scheduling timer at (50 requested / 50 actual) timer ticks per second
> [May 12 19:25:44] DEBUG[21084][C-00000039] res_rtp_asterisk.c: Ooh, format changed from none to alaw
> [May 12 19:25:44] DEBUG[21084][C-00000039] res_rtp_asterisk.c: Starting RTCP transmission on RTP instance '0x7fb448015560'
> ...
> [May 12 19:25:45] DEBUG[21084][C-00000039] chan_sip.c: T38 state changed to 3 on channel SIP/staging-mediagw-00000035
> [May 12 19:25:45] DEBUG[21084][C-00000039] chan_sip.c: Done building SDP. Settling with this capability: (nothing)
> [May 12 19:25:45] DEBUG[21084][C-00000039] chan_sip.c: Trying to put 'SIP/2.0 200' onto UDP socket destined for 3.105.135.109:5060
> [May 12 19:25:45] DEBUG[21084][C-00000039] channel.c: Channel SIP/staging-mediagw-00000035 setting write format path: alaw -> alaw
> [May 12 19:25:45] DEBUG[21084][C-00000039] channel.c: Scheduling timer at (0 requested / 0 actual) timer ticks per second
> [May 12 19:25:45] DEBUG[21084][C-00000039] res_fax.c: Negotiated T.38 for send on SIP/staging-mediagw-00000035
> [May 12 19:25:45] DEBUG[21084][C-00000039] res_fax.c: Requesting a new FAX session from 'Spandsp FAX Driver'.
> ...
> [May 12 19:25:45] DEBUG[21084][C-00000039] res_fax.c: channel 'SIP/staging-mediagw-00000035' using FAX session '46'
> [May 12 19:25:45] DEBUG[21084][C-00000039] res_fax.c: channel SIP/staging-mediagw-00000035 will wait on FAX fd 27
> [May 12 19:25:45] FAX[21084][C-00000039] res_fax.c: FLOW T.38 Tx     0: indicator no-signal
> [May 12 19:25:45] FAX[21084][C-00000039] res_fax.c: FLOW T.38 Tx     1: indicator cng
> ...
> [May 12 19:26:28] DEBUG[21084][C-00000039] res_fax.c: Channel 'SIP/staging-mediagw-00000035' did not return a frame; probably hung up.
> [May 12 19:26:28] FAX[21084][C-00000039] res_fax.c: FLOW T.30 Status changing to 'The call dropped prematurely'
> [May 12 19:26:28] DEBUG[21084][C-00000039] res_fax_spandsp.c: FAX session '46' entering phase E
> [May 12 19:26:28] DEBUG[21084][C-00000039] res_fax_spandsp.c: FAX session '46' completed with result: FAILED (The call dropped prematurely)
> [May 12 19:26:28] FAX[21084][C-00000039] res_fax.c: FLOW T.30 Changing from state 18 to 30
> [May 12 19:26:28] FAX[21084][C-00000039] res_fax.c: FLOW T.30 Changing from phase T30_PHASE_A_CNG to T30_PHASE_CALL_FINISHED
> [May 12 19:26:28] FAX[21084][C-00000039] res_fax.c: FLOW T.38T Set rx type 9
> [May 12 19:26:28] FAX[21084][C-00000039] res_fax.c: FLOW T.38T Set tx type 9
> [May 12 19:26:28] FAX[21084][C-00000039] res_fax.c: FLOW T.38T FAX exchange complete
> [May 12 19:26:28] FAX[21084][C-00000039] res_fax.c: FLOW T.30 Call completed
> [May 12 19:26:28] DEBUG[21084][C-00000039] res_fax_spandsp.c: FAX session '46' is complete.
> [May 12 19:26:28] DEBUG[21084][C-00000039] res_fax.c: channel 'SIP/staging-mediagw-00000035' - event loop stopped { timeout: 10000, remaining_time: 9990 }
> {noformat}
> Kindly request f you need more information.

--
This message was sent by Atlassian JIRA
(v6.2#6252)