[asterisk-bugs] [JIRA] (ASTERISK-27754) res_fax_spandsp: Asterisk getting "stuck" on T.38 NSF from specific vendor gateway

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-27754:
-----------------------------------

    Summary: res_fax_spandsp: Asterisk getting "stuck" on T.38 NSF from specific vendor gateway  (was: Asterisk getting "stuck" on T.38 NSF from specific vendor gateway)

> res_fax_spandsp: Asterisk getting "stuck" on T.38 NSF from specific vendor gateway
> ----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27754
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27754
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_fax, Resources/res_fax_spandsp
>    Affects Versions: 15.2.0
>            Reporter: Nabeel Jafferali
>            Assignee: Unassigned
>            Severity: Minor
>              Labels: fax
>         Attachments: capture.pcap, debug_27754.txt
>
>
> I am using Asterisk 15.2.0 as a T.38 gateway, with a local non-T.38 capable IAX client (iaxmodem) making calls through Asterisk to T.38 capable SIP gateways. It works quite well, except for one specific scenario that I have spent some time isolating.
> Basically, if Asterisk makes a call through a specific vendor's SIP-PSTN gateway (Metaswitch UMG), it appears Asterisk gets "stuck" after receiving a NSF packet in the T.38 stream. What I mean by stuck is that, listening to the audible fax tones generated by Asterisk, I hear the normal training, followed by a *constant* high-pitched fax tone that does not stop. This is despite the fact that, looking at the T.38 stream, I see "no-signal", followed by a second v21-preamble, NSF, CSI, etc.
> In our upstream network, I tried re-routing the same PSTN phone number to other SIP-PSTN gateways (Audiocodes), and the problem does not persists, even though the T.38 traffic seems similar (i.e. v21-preamble, NSF, CSI, etc.). In fact, when I just listen to the audio being generated in this case, I can hear the difference (normal traning, followed by non-constant fax tone, followed by silence).
> Also note that other fax calls out the same Metaswitch UMG gateway, where the remote fax machine does not send NSF message, are successful.
> So, it would seem the issue only occurs when the remote fax machine sends a NSF message, which the Metaswitch UMG gateway packetizes into T.38, and is received by Asterisk for demodulation.
> I have opened a ticket with the gateway vendor, but since it appears that Asterisk (or whatever library it uses) is demodulating the T.38 stream incorrectly, I am trying to see if we can pursue it here.
> I trying setting "core set verbose 100", "udptl set debug on" and "core set debug 100", but I see no difference in the Asterisk CLI logs between the good and bad cases.



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