Summary: | ASTERISK-28747: YES/NO attributes are not set properly when creating PJSIP sorcery objects via ARI | ||||
Reporter: | Andrés Alonso (andresag) | Labels: | |||
Date Opened: | 2020-02-17 10:17:31.000-0600 | Date Closed: | 2021-05-26 08:43:33 | ||
Priority: | Minor | Regression? | |||
Status: | Closed/Complete | Components: | Core/AstDB Core/Sorcery Resources/res_ari | ||
Versions: | 17.1.0 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
Environment: | - CentOS release 7.7.1908 (Core) kernel 3.10.0-1062.4.3.el7.x86_64 - mysql Ver 15.1 Distrib 5.5.64-MariaDB | Attachments: | ( 0) extconfig.conf ( 1) sorcery.conf | ||
Description: | When creating PJSIP object through the Sorcery API, *yes/no attributes* are not created according to the given payload data.
For instance, creating an AOR object passing: * max_contacts=1 * remove_existing=yes Request ends succesfully, but the resulting object has (pjsip show aor): * max_contacts: 1 (as expected) * remove_existing: *false* | ||||
Comments: | By: Asterisk Team (asteriskteam) 2020-02-17 10:17:32.493-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]. 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. By: Sean Bright (seanbright) 2020-02-17 16:08:28.386-0600 Can you please attach your {{sorcery.conf}} and {{extconfig.conf}} file (redact sensitive information but do not remove anything)? By: Sean Bright (seanbright) 2020-02-17 16:09:30.538-0600 My assumption is that you have {{aor}} s configured to come from MySQL and it is trying to put {{true}} into a column that is defined as {{enum('yes', 'no')}}. By: Andrés Alonso (andresag) 2020-02-18 01:11:58.292-0600 Attaching current sorcery and odbc configuration By: Andrés Alonso (andresag) 2020-02-18 01:17:47.354-0600 ??My assumption is that you have {{aor}} s configured to come from MySQL??... Correct ??...and it is trying to put true into a column that is defined as enum('yes', 'no').?? This seems to be the problem, yes. By: George Joseph (gjoseph) 2020-02-18 07:59:27.136-0600 We've had this issue before when sorcery writes to a database from ARI. Some of the database columns are defined as {noformat} YESNO_VALUES = ['yes', 'no'] {noformat} while others are defined {noformat} AST_BOOL_VALUES = [ '0', '1', 'off', 'on', 'false', 'true', 'no', 'yes' ] {noformat} [~andresag] If you change "true" to "yes" in your ARI call it should work. In the mean time, I'm opening an internal issue to fix the column definition. By: Andrés Alonso (andresag) 2020-02-18 10:00:22.794-0600 I was originally passing "yes" in the ARI call. These are the steps I'm following: 1) ARI HTTP PUT request to create an aor. remove_existng is set to "yes" {code} curl -k -v -X PUT -u <USER:PASS> -H "Content-Type: application/json" -d '{"fields": [{"attribute": "max_contacts", "value": "1"}, {"attribute": "remove_existing", "value": "yes"}]}' https://<PBX_IP>:8089/ari/asterisk/config/dynamic/res_pjsip/aor/test {code} 2) HTTP Response {code} < HTTP/1.1 200 OK < Server: Asterisk < Date: Tue, 18 Feb 2020 15:01:00 GMT < Cache-Control: no-cache, no-store < Content-type: application/json < Content-Length: 828 < [ { "attribute": "minimum_expiration", "value": "60" }, { "attribute": "default_expiration", "value": "3600" }, { "attribute": "qualify_timeout", "value": "3.000000" }, { "attribute": "mailboxes", "value": "" }, { "attribute": "support_path", "value": "false" }, { "attribute": "voicemail_extension", "value": "" }, { "attribute": "max_contacts", "value": "1" }, { "attribute": "authenticate_qualify", "value": "false" }, { "attribute": "contact", "value": "" }, { "attribute": "maximum_expiration", "value": "7200" }, { "attribute": "qualify_frequency", "value": "0" }, { "attribute": "remove_existing", "value": "true" }, { "attribute": "outbound_proxy", "value": "" } ] {code} See that remove_existing comes as "true" in the response 3) Check for the newly created PJSIP aor (_test_), {{pjsip show aor test}} {code} ParameterName : ParameterValue ===================================== authenticate_qualify : false contact : default_expiration : 3600 mailboxes : max_contacts : 1 maximum_expiration : 7200 minimum_expiration : 60 outbound_proxy : qualify_frequency : 0 qualify_timeout : 3.000000 remove_existing : false support_path : false voicemail_extension : {code} remove_existing is now "false" 4) Check the row created in mysql ps_aors table {code} +--------+---------+--------------------+-----------+--------------+--------------------+-----------------+-------------------+----------------------+ | id | contact | default_expiration | mailboxes | max_contacts | minimum_expiration | remove_existing | qualify_frequency | ... +--------+---------+--------------------+-----------+--------------+--------------------+-----------------+-------------------+----------------------+ | test | | 3600 | | 1 | 60 | | 0 | | +--------+---------+--------------------+-----------+--------------+--------------------+-----------------+-------------------+----------------------+ {code} remove_existing is empty Type definition of the column in mysql is {{enum('yes','no')}} Passing "true" instead of "yes" in the request gives exactly the same result. By: Sean Bright (seanbright) 2020-02-18 11:44:49.954-0600 [~andresag], can you attach the output of {{SHOW CREATE TABLE ps_aors}} please? By: Andrés Alonso (andresag) 2020-02-18 12:01:49.764-0600 Sure. {code} | ps_aors | CREATE TABLE `ps_aors` ( `id` varchar(40) NOT NULL, `contact` varchar(255) DEFAULT NULL, `default_expiration` int(11) DEFAULT NULL, `mailboxes` varchar(80) DEFAULT NULL, `max_contacts` int(11) DEFAULT NULL, `minimum_expiration` int(11) DEFAULT NULL, `remove_existing` enum('yes','no') DEFAULT NULL, `qualify_frequency` int(11) DEFAULT NULL, `authenticate_qualify` enum('yes','no') DEFAULT NULL, `maximum_expiration` int(11) DEFAULT NULL, `outbound_proxy` varchar(40) DEFAULT NULL, `support_path` enum('yes','no') DEFAULT NULL, `qualify_timeout` float DEFAULT NULL, `voicemail_extension` varchar(40) DEFAULT NULL, UNIQUE KEY `id` (`id`), KEY `ps_aors_id` (`id`), KEY `ps_aors_qualifyfreq_contact` (`qualify_frequency`,`contact`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | {code} By: George Joseph (gjoseph) 2020-02-18 12:19:55.665-0600 OK. I'm looking at it more. Just FYI...The HTTP response you're getting is echoing back the state of the internal sorcery object. It's not re-reading it back from the database. By: Andrés Alonso (andresag) 2020-02-19 05:06:15.709-0600 Goot to know, it makes sense actually. Thanks! I've been testing it a bit more and same thing happens with several other yes/no fields in ps_endpoints. I will probably try postgres integration, since I see the config sql scripts differ in many type definitions. By: Andrés Alonso (andresag) 2020-03-17 05:44:59.343-0500 Hello, I haven't yet been able to test postgres. Any updates on your side? By: Joshua C. Colp (jcolp) 2020-03-17 05:47:09.962-0500 This issue was accepted. It's not assigned or being worked on, and any updates or progress will be posted here. |