Summary:	ASTERISK-30401: res_pjsip: Addition of endpoint/AOR requires notification for qualify/contact status
Reporter:	Jonathan Rose (JonathanRRose)	Labels:
Date Opened:	2023-01-20 12:13:01.000-0600	Date Closed:	2023-01-20 12:49:18.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_pjsip
Versions:	GIT 18.9.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Prod: RHEL 8 (some Kubernetes thing that I couldn't possibly describe) Test: Ubuntu 22.04 on Intel NUC Skull Canyon with 16GB of RAM and a simple SSD	Attachments:	( 0) extconfig.conf ( 1) mysql_output.txt ( 2) pjsip.conf ( 3) res_odbc.conf ( 4) sorcery.conf
Description:	Realtime PJSIP endpoints/aors have a bit of a crippling problem right now... if I have a pair of endpoint/aor present at the point when res_pjsip.so is loaded and register afterwards, registration works fine and device state is set to 'Not In Use' as you would expect it to. If, however, I add a new pair of endpoint/aor to the realtime backend and register *that* user, the registration will appear to work correctly from a SIP perspective, but within Asterisk the device state will be locked to unavailable. I can unregister and reregister any number of times at that point and the device state will remain unavailable. Issuing 'module reload res_sip.so' from the CLI will 'fix' the issue, but this is realtime... that's not really an acceptable workaround. I'd argue that it violates the whole concept of Realtime and I'm kinda shocked I couldn't find any reports of this happening already. I've confirmed that this problem seems to be backend agnostic, having used both odbc and curl as the realtime backends. I will provide minimalist configuration for reproducing the issue. Confirmed within 18.9.0-cert1 as well as the current (as of 1/20/2023) master branch of github.
Comments:	By: Asterisk Team (asteriskteam) 2023-01-20 12:13:03.659-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. 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. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Jonathan Rose (JonathanRRose) 2023-01-20 12:27:11.895-0600 Attached relevant configuration on test system as well as a text log of output for mysql commands that describe the relevant parts of the database used for the odbc connection. By: Joshua C. Colp (jcolp) 2023-01-20 12:29:06.038-0600 This is on purpose, and a trade-off in having things work in a performant fashion. It was previously attempted to do otherwise within the qualify implementation and it yielded extremely bad results. I ended up having to rewrite the implementation from scratch and landed on this. To allow it to work an AMI action and CLI command was added so that an external entity could inform Asterisk that the AOR has been created and that it needs to be aware of it. There could be improvements done in the area potentially, but it's not a bug and any changes would need serious consideration and review or else we end up in a situation where non-realtime usage returns to performing 1000 times slower. By: Jonathan Rose (JonathanRRose) 2023-01-20 12:33:02.510-0600 Reproduction method * Start Asterisk with the provided configuration (if odbc isn't configured that will need to be done and you all have better advice on that particular nuisance than I do) * Add a new endpoint and matching aor to the mysql database. Example: mysql> use asterisk; mysql> insert into ps_endpoints (id, transport, aors, context, disallow, allow, direct_media) values ("testuser5", 'transport-udp', "testuser5", 'default', 'all', 'ulaw', 'no'); mysql> insert into ps_aors (id, max_contacts) values ("testuser5", 1); * Have any SIP device register that endpoint/aor * Use 'pjsip show endpoints CLI' command to see that the device state remains 'Unavailable'. * at this point, if you use 'module reload res_pjsip.so', the device will switch state to 'Not In Use'. Any new endpoints/aors added at this point will of course experience the same issue. And it works the exact same way in curl. I can provide an example extconfig that uses CURL as well, but I'm not sure how helpful that is without the accompanying spring application that I wrote to mock out the CURL backend we use in prod. By: Jonathan Rose (JonathanRRose) 2023-01-20 12:33:40.602-0600 Ah, thanks Josh. I guess I'll look into that AMI action. EDIT: If it isn't too much trouble, could you tell me which AMI action it is? By: Joshua C. Colp (jcolp) 2023-01-20 12:37:39.762-0600 Actually it looks like I didn't add an AMI action, just a CLI command that can be executed via AMI. There's "pjsip reload qualify endpoint" and "pjsip reload qualify aor". By: Jonathan Rose (JonathanRRose) 2023-01-20 12:41:02.740-0600 Ah, ok, thanks. By: Jonathan Rose (JonathanRRose) 2023-01-20 12:49:00.343-0600 A recommendations to help other people maybe avoid the headache I've been dealing with the for the past couple weeks: Add some notes to the wiki about this situation / method of circumvention to these pages: https://wiki.asterisk.org/wiki/display/AST/Asterisk+PJSIP+Troubleshooting+Guide https://wiki.asterisk.org/wiki/display/AST/Setting+up+PJSIP+Realtime By: Asterisk Team (asteriskteam) 2023-01-20 12:49:00.530-0600 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.