| Summary: | ASTERISK-26609: chan_sip: Wrong handling of 488 Not Acceptable Here during reINVITE | ||||
| Reporter: | Andrzej Marchlewski (amarch) | Labels: | |||
| Date Opened: | 2016-11-17 05:03:10.000-0600 | Date Closed: | 2020-01-14 11:13:56.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling | ||
| Versions: | 11.12.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) fwd_to_vmail_fail_in_lab.pcap | |||
| Description: | When r option is used in Dial application asterisk always issues re-Invite after initial dialog setup. If UA responds with 488 Not Acceptable Here asterisk will hangup the call immediately. Due to rfc3261 this behavior is incorrect. In section 14.1 it stands:
If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. Also section 4 of mentioned rfc it says: If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. 488 response is handled in handle_response_invite function in chan_sip.c and causes execution of ast_queue_hangup_with_cause function We tested this behavior in version 11.12 however I can see in chan_sip.c that this scenario is handled in the same way in trunk and also in v13 branch. | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2016-11-17 05:03:12.337-0600 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]. By: Andrzej Marchlewski (amarch) 2016-11-17 05:13:31.839-0600 Attached pcap file contains 4 calls. Scenario described in this bug is shown in the call from 2025@192.168.230.9 to 2001@192.168.230.10 192.168.230.9 is asterisk By: Morten Tryfoss (mtryfoss) 2016-11-22 01:46:04.642-0600 I think I've discovered a similar (or related) issue in Asterisk 13 when using T.38 (using native bridging). After fax is sent Asterisk sends a reINVITE to go back to normal audio, but this fails. Then Asterisk seems to think that the channel is hung up - but the other side keeps the call going. By: Rusty Newton (rnewton) 2016-11-22 15:59:31.402-0600 Thanks, can you additionally provide an Asterisk debug log captured during a reproduction of the issue? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Oh, please capture this with Asterisk 13 or greater, as 11 no longer receives bug fixes and there are many major differences between 11 and 13.. Thanks! By: Asterisk Team (asteriskteam) 2016-12-07 12:00:02.824-0600 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 | ||||