[asterisk-dev] PJSIP endpoints created via ARI do not transfer some values into Realtime Database
Floimair Florian
f.floimair at commend.com
Wed Nov 8 06:46:31 CST 2017
Thanks Joshua!
I'll file an issue then and have a look into it. Maybe I can figure it out myself how to get this working.
With best regards
Florian Floimair
COMMEND INTERNATIONAL GMBH
A-5020 Salzburg, Saalachstraße 51
http://www.commend.com
Security and Communication by Commend
FN 178618z | LG Salzburg
-----Ursprüngliche Nachricht-----
Von: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] Im Auftrag von Joshua Colp
Gesendet: Mittwoch, 8. November 2017 13:21
An: asterisk-dev at lists.digium.com
Betreff: Re: [asterisk-dev] PJSIP endpoints created via ARI do not transfer some values into Realtime Database
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/s
> nom820
>
> 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: https://linkprotect.cudasvc.com/url?a=https://www.digium.com&c=E,1,ldZtsdjqc_3Y7UNmktgjHG69rnRp0U1G6J1JysKkMugD7EuyuOPmjxHzK64A0O_zpTSr3OOd1uXBkRnBH8fpynpsxB9jt5q4HVQt9n_ktGRw&typo=1 & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by https://linkprotect.cudasvc.com/url?a=http://www.api-digital.com&c=E,1,PD_2k9Tgi_P-x2WzVuMTOMchKQ_uCGoPp5MUZQfk-KBGNCfz6O_mOCeNlpaALFEoFyOl02dSgGAtB04u5JI0iB3VFjidyq-O8RYHxVsuXt2KdVzgsKi0aqrPAQ,,&typo=1 --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
https://linkprotect.cudasvc.com/url?a=http://lists.digium.com/mailman/listinfo/asterisk-dev&c=E,1,U1KyLMuTMWj2AhWx1dHdiOxE3xPXfkckXxgkMbBVHazANBEyJb2yhaPrLLHwIA2f-gnG0TN_m0uEI210AFXmWpcnq7VyqmfvFEPQ35RgFr1EDtOnIGyBEApM&typo=1
More information about the asterisk-dev
mailing list