Summary:	ASTERISK-27294: res_pjsip: Asterisk has to be restarted to apply new external settings
Reporter:	Aaron J Spetner (AaronJSpetner)	Labels:
Date Opened:	2017-09-26 03:37:30	Date Closed:	2017-12-13 11:43:56.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Resources/res_pjsip
Versions:	14.6.2	Frequency of Occurrence	One Time
Related Issues:
Environment:	Linux ip-10-0-10-176 4.9.43-17.39.amzn1.x86_64 #1 SMP Fri Sep 15 23:39:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux	Attachments:
Description:	After changing the public ip of the server, updating external_signaling_address and external_media_address to the new ip, and doing a "core reload", we started seeing calls drop about 30 seconds in. It turned out that the server was not receiving an ACK from endpoints (Bria softphones and a SNOM phone all behind NAT) after sending the 200 OK. Wireshark showed that the softphone was receiving the 200 OK from (and therefore sending the ACK to) the old IP address. Restarting the asterisk service fixed this problem. I'm assuming this is a bug since just about everything else only needed a "core reload".
Comments:	By: Asterisk Team (asteriskteam) 2017-09-26 03:37:32.115-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]. By: Rusty Newton (rnewton) 2017-09-26 18:39:01.673-0500 Aaron I'm supposing you saw this happen in a production environment a single time? Have you been able to reproduce the behavior on a test system with a basically default, but minimum configuration of the options in question? It does sound buggy, or at least I don't think it is documented that the option requires a restart. By: Aaron J Spetner (AaronJSpetner) 2017-09-27 01:12:32.110-0500 Correct. Unfortunately I did not have the time to try to reproduce the issue. The system in question was a brand new setup intended to replace an older server. We took a fresh Amazon Linux EC2 instance, built Asterisk from source, and configured a very basic pjsip.conf file. Once it was tested and working, we changed the public IP and then the issue started occurring. By: Sean Bright (seanbright) 2017-12-13 11:28:18.253-0600 Transports are not reloadable unless you specify {{allow_reload=yes}} on the transport itself (the first time it is loaded). Did you have that set on the affected transport? By: Aaron J Spetner (AaronJSpetner) 2017-12-13 11:41:23.357-0600 It's been a while, so I don't remember 100%. However, I just checked the config and don't see allow_reload there (and it is unlikely that it was ever there). Well I guess that explains things!