[Home]

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-0600Date Closed:2021-05-26 08:43:33
Priority:MinorRegression?
Status:Closed/CompleteComponents:Core/AstDB Core/Sorcery Resources/res_ari
Versions:17.1.0 Frequency of
Occurrence		Constant
Related
Issues:
duplicatesASTERISK-27272 res_config_pjsql, contrib: Invalid input value for enum yesno_values: "true"
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-MariaDBAttachments:( 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.