| Summary: | ASTERISK-28865: FAX T.38 re-Invite failed on '491 Another INVITE transaction in progress' | ||||
| Reporter: | Alexei Gradinari (alexei gradinari) | Labels: | fax pjsip | ||
| Date Opened: | 2020-04-30 14:26:43 | Date Closed: | |||
| Priority: | Major | Regression? | |||
| Status: | Open/New | Components: | Resources/res_pjsip_session Resources/res_pjsip_t38 | ||
| Versions: | 16.10.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) fax_491.txt | |||
| Description: | On call between 2 PJSIP endpoints when fax tone is detected simultaneously by both endpoints there may be a case when both endpoints send T.38 re-Invite to the asterisk.
One of this re-Invite is rejected by the asterisk with "491 Another INVITE transaction in progress". After that the asterisk no longer allows to negotiate T.38 on this session. There are strange reply/Invite from the asterisk with SDP line "m=audio 0 RTP/AVP 0 8" Attached SIP flow file 'fax_491.txt' | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2020-04-30 14:26:44.337-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: Kevin Harwell (kharwell) 2020-04-30 16:05:19.241-0500 The 491's look correct here as Asterisk initiated a re-invite to the endpoint while at the same time the endpoint initiated one to Asterisk. So both have transactions in progress. What's odd to me though, and I'm not sure what the correct or expected behavior is here is that the endpoint sends a subsequent re-invite attempting to renegotiate audio. Asterisk replies (200 OK) with a declined audio stream (m=audio 0 ....). Asterisk then attempts a similar re-invite to that endpoint renegotiating audio (using the declined stream again) which the endpoint essentially rejects. Again the issuing of re-invites is acceptable as the a UA should fire off a timer to issue another re-invite after receiving a 491. So the above is probably happening due to that. However, I'm not sure why both try to negotiated audio again? Also why the declined stream? Lastly it also appears during this no "trying" or anything is sent to the other endpoint so it re-transmits. So all that to say is given the 491's seem correct in this scenario, what is the expected behavior in a fax scenario when this occurs? On the subsequent re-invite try negotiating fax again? Audio as it's doing? By: Alexei Gradinari (alexei gradinari) 2020-04-30 17:21:46.871-0500 There is nothing wrong that asterisk sends 491. I see 2 issues with the next steps: 1. When FAX1 received 491 reply on T.38 re-Invite from the asterisk, the FAX1 sent a new re-Invite with audio SDP "m=audio 46082 RTP/AVP 0 8", but the asterisk rejected with reply 200 OK SDP "m=audio 0 RTP/AVP 0 8" Why? At the same time the asterisk didn't reply to FAX2 on T.38 re-INVITE, so FAX2 resent this re-Invite. 2. When the asterisk received resent T.38 re-INVITE from FAX2, the asterisk sent a new re-Invite to FAX1 with SDP "m=audio 0 RTP/AVP 0 8" What is it? The asterisk should send a new T.38 re-INVITE to FAX1. Of course FAX1 replied with "488 Not Acceptable Here" which the asterisk forwarded to FAX2. So FAX2 decided that the asterisk not supported T.38 and negotiated to SDP voice "m=audio 19449 RTP/AVP 0" I think this is related to ASTERISK-28811. and res_pjsip_session: Reduce (and improve) SDP renegotiation. https://gerrit.asterisk.org/c/asterisk/+/6576 The patch " fax: Fix crashes in PJSIP re-negotiation scenarios." https://gerrit.asterisk.org/c/asterisk/+/14298 fixed off-nominal re-negotiation cases, but maybe not all cases. This case with 491 led to crash and patch "stream: Enforce formats immutability and ensure formats exist." https://gerrit.asterisk.org/c/asterisk/+/14276 allows to avoid crash as empty format list always exists. May be because of empty format list the asterisk sends "m=audio 0". The best result in this scenario - asterisk should allow to renegotiate T.38. By: Kevin Harwell (kharwell) 2020-04-30 17:49:54.261-0500 {quote} The best result in this scenario - asterisk should allow to renegotiate T.38. {quote} I tend to agree. There appears to be a few issues here, with the foremost being why Asterisk responds with an "m=audio 0 ..." line. By: Alexei Gradinari (alexei gradinari) 2020-05-06 14:25:28.715-0500 Found another strange asterisk behavior. FAX1 INVITE (voice SDP) -> asterisk INVITE (voice SDP) -> FAX2 FAX2 200 OK (voice SDP) -> asterisk 200 OK (voice SDP) -> FAX1 FAX1 INVITE (fax SDP) -> asterisk INVITE (fax SDP) -> FAX2 FAX2 200 OK (fax SDP) -> asterisk 200 OK (fax SDP) -> FAX1 FAX2 BYE -> asterisk INVITE (m=image 0 udptl t38) -> FAX1 By: Alexei Gradinari (alexei gradinari) 2020-05-06 14:33:52.571-0500 The same case but when FAX1 sends BYE, the asterisk sends correct re-INVITE to FAX2, i.e. FAX1 INVITE (voice SDP) -> asterisk INVITE (voice SDP) -> FAX2 FAX2 200 OK (voice SDP) -> asterisk 200 OK (voice SDP) -> FAX1 FAX1 INVITE (fax SDP) -> asterisk INVITE (fax SDP) -> FAX2 FAX2 200 OK (fax SDP) -> asterisk 200 OK (fax SDP) -> FAX1 FAX1 BYE -> asterisk INVITE (voice SDP) -> FAX2 FAX2 200 OK (voice SDP) -> asterisk asterisk BYE -> FAX2 | ||||