| Summary: | ASTERISK-28539: Failed t.38 negotiation when B leg sends t.38 re-invite | ||||
| Reporter: | John Cahill (jcahill) | Labels: | fax pjsip | ||
| Date Opened: | 2019-09-17 07:24:08 | Date Closed: | 2019-10-15 12:00:03 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Resources/res_pjsip_t38 | ||
| Versions: | 16.5.0 16.5.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Debian 10.0, 4.19.0-5-amd64 2GB RAM, 4 VCPUs, Xen 4.4 Dell PowerEdge R430 | Attachments: | ( 0) endpoints.txt ( 1) extensions-excerpt.conf ( 2) failed-t.38-fax.pcap ( 3) full | ||
| Description: | Failed t.38 negotiation when B leg sends t.38 re-invite | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2019-09-17 07:24:09.803-0500 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. By: Joshua C. Colp (jcolp) 2019-09-17 08:06:02.010-0500 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected and the location of documentation that led you to that expectation. 3. The behavior you actually encountered. To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines [2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: John Cahill (jcahill) 2019-09-17 09:56:38.347-0500 Please find attached full asterisk log file By: John Cahill (jcahill) 2019-09-17 09:57:09.911-0500 full asterisk log file By: John Cahill (jcahill) 2019-09-17 09:57:23.260-0500 pcap By: John Cahill (jcahill) 2019-09-17 10:01:52.355-0500 T.38 Fax is sent from t.38 enabled asterisk machine using chan_sip using a call file ---> asterisk 16.5.1 (PJSIP) t.38 enabled --> Sonus SBC Colt Telecom -->PSTN --> Landline --> Hayes accura modem --->Hylafax Fails solidly every time. By: John Cahill (jcahill) 2019-09-17 10:03:49.297-0500 Before I upgraded from chan_sip to pjsip on the asterisk 16.5.1 machine this scenario worked fine. By: Kevin Harwell (kharwell) 2019-09-17 16:00:36.373-0500 If I am interpreting things correctly (No. 2072 in [^failed-t.38-fax.pcap] xxx.xxx.210.228->xxx.xxx.246.209) the negotiation fails due to Asterisk sending a re-invite with a declined udptl stream. Looks like when initiating, Asterisk doesn't have media session at the time, so zeroes it out. According to the log there are some re-invite collisions, and a duplicate answer dropped. Not sure if those are relevant though. Can you also please post/attach the relevant configuration for the endpoints involved (_pjsip.conf_) and dialplan (_extensions.conf_). As well if possible, the initiating call file too. Thanks! By: John Cahill (jcahill) 2019-09-25 03:46:54.709-0500 relevant endpoints By: John Cahill (jcahill) 2019-09-25 03:50:22.154-0500 Call file for fax: Channel: SIP/carrier-out/01865251758 MaxRetries: 0 WaitTime: 30 Application: SendFax Data: /var/spool/asterisk/T38_TEST_PAGES_3_page.tiff,sdfz CallerID: +441869222503 setvar: FAXID=00441869222503 setvar: FAXOPT(ecm)=no setvar: FAXOPT(minrate)=2400 setvar: FAXOPT(maxrate)=14400 setvar: FAXOPT(localstationid)=00441869222503 By: John Cahill (jcahill) 2019-09-25 03:51:49.827-0500 Relevant part of extensions.conf in extensions-excerpt.conf By: John Cahill (jcahill) 2019-09-26 07:58:25.739-0500 Hi Kevin/Joshua, Are there any patches etc I can try to fix this issue? I'm Happy to test and provide feedback. I have a system that is not currently in service so I can test now. Thanks. Regards, John By: Joshua C. Colp (jcolp) 2019-09-26 08:00:57.403-0500 This issue is still in triage. Once it passes it'll remain open until someone works on it. There is no time frame on when such a thing will occur, and if the individual who does take this on has any patches/etc to try they'll provide them or they will go up for review and been commented here. By: George Joseph (gjoseph) 2019-10-01 06:29:50.514-0500 Looking at the log and pcap, it looks like there were two calls, one that worked and another that didn't. Can you elaborate on what the differences were between the two? Can you also provide the full output from {{pjsip show endpoint}} for the endpoints of both calls? Can you also re-create the issue with only the failed call and provide the log and pcap? It'll be easier to debug with only 1 call in progress. It looks like in the failed call, 1ms after the re-INVITE comes in for the switch to t.38, Asterisk sends a re-INVITE of its own keeping the audio session. By: Asterisk Team (asteriskteam) 2019-10-15 12:00:02.584-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines | ||||