Summary:	ASTERISK-26782: res_pjsip: URI requirement for fields is not consistently documented and error does not provide indication
Reporter:	Peter Sokolov (peterdoo)	Labels:
Date Opened:	2017-02-09 12:27:25.000-0600	Date Closed:	2017-02-28 13:33:25.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Documentation Resources/res_pjsip Resources/res_pjsip_outbound_registration
Versions:	14.2.1	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	In chan_sip the outbound proxy could be entered as IP address. Howewer with PJSIP when outbound_proxy=80.x.x.152 is used, the registration section will not load. Using URI as proxy, the problem is solved: outbound_proxy=sip:80.x.x.152:5060 While this requirement is valid and partially documented, there are the following problems: # The other items in pjsip.conf that have to contain URI have _uri in their name, so they are self-explanatory. For outbound_proxy, the URI requirement is only documented for endpoint in the pjsip.conf.sample, but not for registration and aor. # The error end debug messages generated when an IP instead of URI is used does not really give any hint about the problem and makes solving this very difficult: {noformat} [Feb  5 15:58:27] DEBUG[3957]: res_pjsip_outbound_registration.c:1289 sip_outbound_registration_apply: Applying configuration to outbound registration 'sip_via_proxy' [Feb  5 15:58:27] DEBUG[3957]: res_pjsip_outbound_registration.c:962 sip_outbound_registration_state_destroy: Destroying registration state for registration to server 'sip:80.x.x.104' from client 'sip:12345@80.x.x.104' [Feb  5 15:58:27] ERROR[3957]: res_sorcery_config.c:307 sorcery_config_internal_load: Could not create an object of type 'registration' with id 'sip_via_proxy' from configuration file 'pjsip.conf' {noformat} # Registration/endpoint/aor item is not (re)loaded when the IP is used as outbound_proxy. However on PJSIP reload the old configuration for the Registration/Endpoint remains active and no changes from pjsip.conf are applied for this Registration/Endpoint. On restart of asterisk, the whole Registration/Endpoint is not loaded. This gives an inconsistent behavior. Depending whether reload or restart is done, the registration/endpoint/aor is there or not. I would expect in both cases the complete Registration/endpoint/aor to be removed from the active configuration instead of keeping the old state in the case of reload with errors in pjsip.conf.
Comments:	By: Asterisk Team (asteriskteam) 2017-02-09 12:27:26.191-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: Joshua C. Colp (jcolp) 2017-02-09 12:33:51.301-0600 3 is on purpose so that the system is not left in an unworking state if a user makes a mistake and then corrects it. In the case of a complete restart there is no existing state, so it is not preserved. From a user experience perspective I personally value that behavior over being technically correct by removing the registration or endpoint. By: Peter Sokolov (peterdoo) 2017-02-09 12:45:54.454-0600 I can understand your point. However in my case, it was the initial configuration. The registration was not working correctly yet and I was trying to get it working modifying its configuration. At certain state any configuration changes in pjsip.conf that I made, did not have any effect on the behavior. It took me quite some time until I found out that registration has not been reloaded because of problems with some change done already some time ago (outbound_proxy as IP or line=false with endpoint still present). Also in the case that you have described, if the administrator has not noticed the problem in pjsip.conf because the system is still working correctly, the big surprise will come on next asterisk restart, which might be at a time, the person that made changes is not there or does not remember anymore, what has been changed, so it may take longer to fix the problem. Just my opinion. By: Joshua C. Colp (jcolp) 2017-02-09 12:49:16.003-0600 There's certainly a trade-off, but this behavior is not something we would change midstream and has existed for the lifetime of 13. A separate config option could be added to make it work the other way. By: Friendly Automation (friendly-automation) 2017-02-28 13:33:26.113-0600 Change 5083 merged by zuul: config: Improve documentation and behavior of outbound_proxy option. [https://gerrit.asterisk.org/5083|https://gerrit.asterisk.org/5083] By: Friendly Automation (friendly-automation) 2017-02-28 14:18:59.717-0600 Change 5084 merged by Joshua Colp: config: Improve documentation and behavior of outbound_proxy option. [https://gerrit.asterisk.org/5084|https://gerrit.asterisk.org/5084] By: Friendly Automation (friendly-automation) 2017-02-28 14:45:32.876-0600 Change 5085 merged by Joshua Colp: config: Improve documentation and behavior of outbound_proxy option. [https://gerrit.asterisk.org/5085|https://gerrit.asterisk.org/5085]