On Wed, Nov 8, 2017, at 08:13 AM, Floimair Florian wrote: > Hi guys! > > In my lab environment I ran into an issue with PJSIP endpoints created > via ARI with a realtime database as backend. > I'm using a MySQL database in my lab setup. > I noticed that some of the values of the endpoint object do not find > their way into the database. > > When creating the endpoint (and auth and aor before that) using cURL I > get the following JSON reply indicating that the attributes I set in the > request are successfully accepted by Asterisk: > > curl -X PUT -H "Content-Type: application/json" -u asterisk:asterisk -d > '{"fields": [{"attribute": "send_pai", "value": "yes"}, {"attribute": > "send_rpid", "value": "yes"}, { "attribute": "allow", "value": > "!all,g722,ulaw,alaw,h264"}, {"attribute": "ice_support", "value": > "yes"}, {"attribute": "force_rport", "value": "yes"}, {"attribute": > "rewrite_contact", "value": "yes"}, {"attribute": "rtp_symmetric", > "value": "yes"}, {"attribute": "context", "value": "default" }, > {"attribute": "auth", "value": "snom820" }, {"attribute": "aors", > "value": "snom820"} ] }' > http://localhost:8088/ari/asterisk/config/dynamic/res_pjsip/endpoint/snom820 > > I get the following JSON response (shortened to just show the attributes > set in the request): > > [..., > {"attribute":"send_rpid","value":"true"}, > {"attribute":"aors","value":"snom820"}, > {"attribute":"context","value":"default"}, > {"attribute":"rtp_symmetric","value":"true"}, > {"attribute":"force_rport","value":"true"}, > {"attribute":"ice_support","value":"true, > {"attribute":"allow","value":"(g722|ulaw|alaw|h264)"}, > {"attribute":"rewrite_contact","value":"true"}, > {"attribute":"auth","value":"snom820, > {"attribute":"send_pai","value":"true"},...] > > So at first glance everything seems to be OK. > However when looking at the database everything that is not a string > (namely all yes/no ENUMs) comes up empty, which in turn causes Asterisk > to use the default values for these settings. > > So the only rows correctly set in the dabase in case of the above values > are aors ,context, auth & allow. All the other rows come up empty. > > Verifying in the Asterisk CLI shows these values (again shortened): > > asterisk*CLI> pjsip show endpoint snom820 > > Endpoint: <Endpoint/CID.....................................> > <State.....> <Channels.> > I/OAuth: > > <AuthId/UserName...........................................................> > Aor: <Aor............................................> > <MaxContact> > Contact: <Aor/ContactUri..........................> <Hash....> > <Status> <RTT(ms)..> > Transport: <TransportId........> <Type> <cos> <tos> > <BindAddress..................> > Identify: > > <Identify/Endpoint.........................................................> > Match: <criteria.........................> > Channel: <ChannelId......................................> > <State.....> <Time.....> > Exten: <DialedExten...........> CLCID: <ConnectedLineCID.......> > ========================================================================================== > > Endpoint: snom820/unknown > Unavailable 0 of inf > InAuth: snom820/snom820 > Aor: snom820 10 > > > ParameterName : ParameterValue > ========================================================== > allow : (g722|ulaw|alaw|h264) > aors : snom820 > auth : snom820 > context : default > force_rport : true > ice_support : false > rewrite_contact : false > rtp_symmetric : false > send_pai : false > send_rpid : false > > After correlating these empty values in the database with their default > setting in the Asterisk code, I saw that only force_rport defaults to > true. > This leads me to believe that Asterisk at runtime takes the default > values for empty rows in the database as they do not reflect the values > that were in the JSON response. > > Finally, this leads me to my question: > > Is this a bug, or is there something wrong in my method of creating these > endpoints and the assumption that they should be properly transferred to > the database? > > If it is a bug I will file an issue, If it is not can someone please > point out what is wrong here.
I don't think anyone has used this with a realtime database like that. I only know of people using astdb itself. I'd consider it a bug though, probably in the realtime interaction. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev