| Summary: | ASTERISK-27727: Asterisk not sending BYE packet to correct socket | ||
| Reporter: | Milan Stanojevic (milan08239) | Labels: | |
| Date Opened: | 2018-03-08 08:22:47.000-0600 | Date Closed: | 2020-01-14 11:13:27.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | 14.6.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Ubuntu 14.04.5 LTS | Attachments: | |
| Description: | Hello,
I'm running into next issue: I have SIP clients registered to OpenSIPS server which forwards calls to Asterisk instance and Asterisk will route call either to external PSTN trunk or it will route back to OpenSIPS instance for internal calls (so for internal calls flow would be client A ---> Opensips --> Asterisk --> Opensips --> Client B ). Asterisk will communicate with OpenSIPS over one socket in the beginning but after two minutes OpenSIPS closes initial socket and sends packets over another socket (this is default behavior of OpenSIPS - to close TCP socket after 120 seconds) . So when BYE comes to Asterisk after few minutes it is not able to return it back over new socket, rather it tries to send it back via old socket which is closed and sending of that BYE packet fails. 1. Here is beginning of INVITE packet coming to Asterisk (asterisk gets this iINVITE from OpenSIPS port 46911): <--- SIP read from TCP:$<OpenSIPS_IP>:46911 ---> INVITE sip:... ..... 2. 100 Trying is returned to that same socket which is fine: <--- Transmitting (NAT) to $<OpenSIPS_IP>:46911 ---> SIP/2.0 100 Trying .... 3. 180 Ringing also sent to same socket which is fine: <--- Transmitting (NAT) to $<OpenSIPS_IP>:46911 ---> SIP/2.0 180 Ringing 4. 200OK also sent to same socket which is fine: <--- Reliably Transmitting (NAT) to $<OpenSIPS_IP>:46911 ---> SIP/2.0 200 OK 5. Now call lasts for few minutes (more than 120 seconds after which openSIPS closed initial socket/connection over port 46911) and client B wants to Hangup call : Asterisk receives this BYE packet from new socket: <--- SIP read from TCP:$<OpenSIPS_IP>:33586 ---> BYE .... And I see this line on Asterisk CLI : Sending to $<OpenSIPS_IP>:33586 (NAT) But after that it does not actually send it to new socket (port 33586), rather it tries to send it to old/non-existing socket: Reliably Transmitting (NAT) to $<OpenSIPS_IP>:46911: BYE ... And Asterisk console throws this warning and error (which is obvious since socket with port 46911 does not exist anymore): [2018-03-01 20:57:20.731] WARNING[359][C-00000284]: chan_sip.c:3790 __sip_xmit: sip_xmit of 0x7f7ce0032950 (len 562) to $<OpenSIPS_IP>:46911 returned -2: Broken pipe [2018-03-01 20:57:20.731] ERROR[359][C-00000284]: chan_sip.c:4279 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data My sip.conf settings related to OpenSIPS peer: [$<name>] type=friend insecure=port,invite host=<$DNS_of_OpenSIPS> port=<$port> context=<$context_name> disallow=all allow=alaw qualify=yes canreinvite=no nat=force_rport,comedia transport=tcp Can someone please advice how I can solve this issue (so that Asterisk route BYE message to new socket instead to try using old/closed one) ? Thanks, Milan | ||
| Comments: | By: Asterisk Team (asteriskteam) 2018-03-08 08:22:48.584-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: Asterisk Team (asteriskteam) 2018-03-08 08:22:49.714-0600 The module you are reporting the issue against is no longer supported as a core module but your issue is in the queue. Your patience is appreciated as a community developer may work the issue when time and resources become available. Asterisk is an open source project and community members work the issues on a voluntary basis. You are welcome to develop your own patches and submit them to the project.[1] If you are not a programmer and you are in a hurry to see a patch provided then you might try rallying support on the Asterisk users mailing list or forums.[2] Another alternative is offering a bug bounty on the asterisk-dev mailing list.[3] Often a little incentive can go a long way. [1]: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process [2]: http://www.asterisk.org/community/discuss [3]: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties By: Joshua C. Colp (jcolp) 2018-03-08 08:30:09.640-0600 Asterisk 14 is also no longer supported for bug fixes. If a change does result from this then it would only go into Asterisk 13 and 15. By: Joshua C. Colp (jcolp) 2018-03-12 08:12:42.610-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: Asterisk Team (asteriskteam) 2018-03-26 12:00:00.972-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 | ||