[asterisk-bugs] [JIRA] (ASTERISK-28982) res_pjsip_t38: Does not resume as audio when negotiation fails

Christian Berger (JIRA) noreply at issues.asterisk.org
Tue Jul 7 08:14:25 CDT 2020


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

Christian Berger updated ASTERISK-28982:
----------------------------------------

    Attachment: pjsip.conf
                extensions.conf
                messages
                bugreport.pcap

If you filter the pcap for ip.dst==213.167.160.122, you will see that the voice stream stops after packet 249. This is just as the T.38 invite is being sent in packet 252. Even when this INVITE is rejected in packets 257 and 258 the RTP-stream does not resume.

> res_pjsip_t38: Does not resume as audio when negotiation fails
> --------------------------------------------------------------
>
>                 Key: ASTERISK-28982
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28982
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_fax, Resources/res_pjsip_t38
>    Affects Versions: 13.32.0, 16.11.1
>            Reporter: Christian Berger
>            Assignee: Christian Berger
>            Severity: Minor
>         Attachments: bugreport.pcap, extensions.conf, messages, pjsip.conf
>
>
> We operate Asterisk as a B2Bua in our network. It's task is to transcode, write CDRs and act as a T38 gateway. We are currently trying to move over to PJSIP from the legacy SIP stack.
> We have noticed the following potential bug: When T38 is negotiated on a call leg, voice traffic to it will stop. However even if T38 is rejected it will not send anything via RTP.
> This issue sounds like ASTERISK-28441, however the patch there does not appear to change the problem. In fact the changed function does not seem to be called at all.
> We have, however, found one potential bug in t38_fallback_response_cb. Provisional Response codes 1xx are handled as failures. However this doesn't seem to solve the problem.



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



More information about the asterisk-bugs mailing list