[asterisk-bugs] [JIRA] (ASTERISK-28441) fax: T38 fallback to voice does not change codec

Joshua C. Colp (JIRA) noreply at issues.asterisk.org
Mon Jun 17 05:26:47 CDT 2019


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

Joshua C. Colp commented on ASTERISK-28441:
-------------------------------------------

The log message has "G.711" hard coded because it never expected to have to renegotiate to G.711, and the ability to do that didn't exist until recent versions. What you are trying to do just isn't supported and never has been. If you do not plan on implementing such functionality I can accept this as a bug, but there is absolutely no time frame on when it would get looked into and it would only be supported on Asterisk 16. Versions prior to that do not have the ability to have an application such as res_fax renegotiate.

> fax: T38 fallback to voice does not change codec
> ------------------------------------------------
>
>                 Key: ASTERISK-28441
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28441
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Resources/res_fax
>    Affects Versions: 13.26.0, 13.27.0
>            Reporter: Simone Freddio
>            Assignee: Unassigned
>            Severity: Minor
>              Labels: fax, pjsip
>         Attachments: ast13-27-ata-t38-verso-ata-no-t38.cap
>
>
> Enviroment: Same problem on customer site, i have replicated the same issue in my lab:
> Linksys SPA112 (t38 enabled) <—> asterisk 13.27.0 <—> Linksys SPA112 (t38 disabled)
> The t38 disabled linksys mean disabled by the web interface, the pjsip endpoint still has t38_udptl=true.
> Initial call phase goes up with g729 on first and second leg, first leg (t38 enabled ata) send a reinvite to start t38, asterisk forware the invite to the t38 disabled ata that refuse it. Asterisk forward the 488 unacceptable here to first leg that after a while send a reinvite with g711 (was g729); at this point asterisk didn't forward the reinvite to the second leg that remain in g729. The call fail.
> I have also tried with FAXOPT(gateway)=yes and in this case, after 488 i have no audio at all; in 'core debug' i find:
> starting T.38 gateway for T.38 channel PJSIP/dev6004-00000007 and G.711 channel PJSIP/dev6005-00000008
> but channel PJSIP/dev6005 is still in g729! After a while i have a lot of:
> DEBUG[5497][C-00000001] translate.c: Sample size different 160 vs 1280



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



More information about the asterisk-bugs mailing list