[asterisk-bugs] [JIRA] (ASTERISK-27754) 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:comment-tabpanel&focusedCommentId=243685#comment-243685 ] 

Joshua Colp commented on ASTERISK-27754:
----------------------------------------

Asterisk uses the spandsp library for this. We give it the T.38 (or audio), and it gives us T.38 (or audio) in return essentially. All the fax part is handled by it. The spandsp library is not something we really support ourselves or have expertise in, so this issue may not be fixable by us.

> 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
>    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)