16:32:45 <ruel> mc_ is parley server down again lol?
16:33:57 <ruel> It says "Waiting for server reconnection"
16:38:57 <mc_> ruel: its been dead for a while, i'm stuck in limbo waiting for our web-based conferencing app to support public links
16:39:15 <mc_> once the frontend team gets the bugs worked out, we will resume community calls
16:42:59 <ruel> ah ok 
16:43:41 <ruel> Well, while you're here, (if you remember how it works) can you give me a bit of insight on how features are added to numbers?
16:44:38 <ruel> I was able to sortof trick the system I think by putting some stuff in pvt_features in the number document, but I get the feeling that's the wrong way to go about it :)
16:57:47 <mc_> https://docs.2600hz.com/dev/applications/crossbar/doc/phone_numbers/#update-public-fields-of-a-number
16:57:52 <mc_> is the best i have atm
17:01:49 <ruel> lol k yeah I saw that but it wasn't too clear---I assume the "public fields" are just anything other than what's specified---that's why I tried just PATCHing the features array on the number doc but it didn't seem to like that. It looked right when querying the individual number but didn't show up on the crossbar listing. Checking the CouchDB view I found that the crossbar listing populated the "features" 
17:01:55 <ruel> array with the "pvt_features" field and that's where I got the idea to manually add it to the couch doc. But still doesn't seem right.
17:02:38 <mc_> ruel: for instance, the cnam in the request gets processed and the `features` array gets inbound/outbound cnam added
17:02:49 <mc_> but i don't have a listing of those "public fields" to add on the request
17:03:04 <mc_> will look around to see if its described elsewhere
17:05:11 <ruel> There's also that _read_only object which has a "features" object with a "settings" object in it, and looking at the MonsterUI code it appears that is used for something or other, but I haven't yet found what populates that _read_only object, or what should go in the "settings" (and how to get it there).
17:05:39 <mc_> ruel: _read_only is settings from the server that you can't modify directly
17:08:18 <ruel> Yeah I figured that but since MonsterUI looks at the features.settings object in there I was trying to figure out what populates that _read_only object in order to determine where I should add that info.
17:11:59 <ruel> apps/common/submodules/numberMessaging/numberMessaging.js checks for sms/mms features on a number, and if found, returns whether it's enabled and also whether it's configured. And it decides if it's "configured" by that _read_only.features.settings{} object. 
17:13:03 <mc_> what feature are you trying to add to a number?
17:13:10 <ruel> SMS
17:13:43 <mc_> ah, probably something in cb_sms adds to the features array on the number when configured
17:14:15 <ruel> I'm mostly trying to experiment and get a feel for how Kazoo deals with messaging, but the first step seems to be enabling (correctly) messaging on a number, so that has kept me from going further.
17:15:52 <ruel> My intent is to mess with the AMQP bus and deal with messages sent/received. But getting messaging properly enabled on the number has prevented me from getting to a place to be able to experiment with that. :)
17:16:26 <ruel> I thought I checked cb_sms and it seemed to be only for sending/receiving/retrieving but I'll check again...
17:22:08 <ruel> Yeah looks like cb_sms only has GET/PUT/DELETE for a listing of SMS, get one SMS, Send (PUT), and delete an SMS.