| 02:24.10 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 03:38.19 | *** join/#asterisk-dev w9sh (~skhenke@c-73-54-187-250.hsd1.ga.comcast.net) |
| 05:45.36 | *** join/#asterisk-dev goddva (~goddva@77.40.154.242) |
| 07:57.15 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:08.11 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:08.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:32.38 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:59.07 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-fjgzhxdrbdkkasxz) |
| 10:40.22 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 13:07.03 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:40.35 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:40.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:40.46 | mjordan | file: good morning |
| 13:40.54 | file | nope, absolutely not |
| 13:42.47 | mjordan | fair enough. |
| 13:43.00 | mjordan | So! Sorcery question for you :-) |
| 13:43.06 | file | oui |
| 13:43.25 | mjordan | When using the AstDB as a backend for PJSIP objects, I've found that outbound registrations aren't created when Asterisk starts |
| 13:43.43 | mjordan | That appears to be because the AstDB sorcery wizard doesn't implement the .load callback |
| 13:43.59 | mjordan | Is there a reason it shouldn't implement that callback? |
| 13:44.37 | file | well, that shouldn't be the reason - the outbound registration module should do a query for all objects of that type at startup |
| 13:44.52 | mjordan | hum. |
| 13:45.12 | file | are you sure that the impl for outbound registrations is sufficient to allow it to be persisted and then recreated? |
| 13:45.13 | mjordan | The only thing I see that would do that is this: |
| 13:45.17 | mjordan | ast_sorcery_load_object(ast_sip_get_sorcery(), "registration"); |
| 13:45.17 | file | it was never originally written that way |
| 13:45.49 | mjordan | It *should*, if for no other reason than accessing the object causes it to "work" |
| 13:45.50 | mjordan | i.e. |
| 13:45.53 | file | hrm! |
| 13:46.00 | mjordan | run a 'pjsip show registrations' and you magically get outbound registrations :-) |
| 13:46.09 | mjordan | since the apply handler gets called at that point |
| 13:46.28 | file | oh, the loaded observer is what does it |
| 13:46.32 | mjordan | I'll dig into it more; wanted to double check before I went down a wrong path |
| 13:46.38 | mjordan | ah |
| 13:46.43 | file | HRM |
| 13:46.44 | file | maybe |
| 13:46.50 | mjordan | and right now all the loaded observer does is purge old states |
| 13:47.02 | mjordan | it doesn't attempt to create states based on what is in the configuration |
| 13:47.15 | file | yeah |
| 13:47.47 | mjordan | I'm not sure how we'd do it in that observer, however, since we only have the object type and not the IDs |
| 13:47.57 | mjordan | we could do it in one of the observers possibly |
| 13:48.05 | file | hold |
| 13:48.14 | mjordan | instance_loaded |
| 13:49.26 | file | on load and reload if you call get_registrations it should load in and do stuff |
| 13:52.49 | mjordan | of course, we might be accessing the registrations multiple times if your backend is the static conf file |
| 13:53.13 | file | it won't do anything |
| 13:53.21 | file | well, I mean, it'll return a container of objects already in memory |
| 13:53.24 | mjordan | and actually, if I go down that road, I could just do it in the existing observer |
| 13:53.41 | mjordan | since that will get called during loading |
| 13:53.47 | file | you may be able to get away with it |
| 13:54.00 | mjordan | reload I kind of don't care about, since my backend is dynamic |
| 13:54.48 | mjordan | granted, I don't think there's enough observer implementations in res_pjsip_outbound_registration to pick up the changes in the backends, so that's a problem. But then again, I've never changed an outbound registration once it has been created. |
| 13:57.27 | mjordan | yay |
| 13:57.31 | mjordan | that does appear to do it. |
| 13:57.47 | file | yay for that |
| 13:58.15 | mjordan | doing the dynamic object thing definitely makes for interesting times. |
| 13:58.19 | mjordan | OTOH, super useful. |
| 13:58.33 | mjordan | and makes dockerized asterisk very easy. |
| 13:58.49 | file | magic! |
| 13:59.00 | mjordan | I'd put a gif in here of some sparkles, but alas, I can't |
| 14:00.01 | mjordan | I should probably "go to work" |
| 14:00.32 | file | no WFH for you |
| 14:18.49 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-abnsgpdgluiwkynb) |
| 14:18.49 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:03.36 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-vibjofivrzwivrdv) |
| 15:03.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:03.55 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ynohairdkogdlfgd) |
| 15:13.03 | *** join/#asterisk-dev chadxz (~Adium@2601:7c1:102:fa53:7c41:4df7:be45:6919) |
| 15:34.19 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-knntylqwbonipsbx) |
| 15:43.45 | *** join/#asterisk-dev DavidHuebner (~hubie@ip-69-178-218-71.far.ideaone.net) |
| 15:50.12 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-vbjukprjdwwvfeqt) |
| 15:58.35 | tzafrir | Is rmeyerriecks around? |
| 16:38.10 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:48.38 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-mthjxjkdyipwqwgr) |
| 16:57.47 | *** join/#asterisk-dev datachomper (russ@nat/digium/x-uzuniurjedzafldu) |
| 16:57.53 | datachomper | tzafrir: I've been summoned |
| 18:04.23 | Kobaz | so |
| 18:04.39 | Kobaz | remember all you guys are saying these lockups i'm having arent a bug in asterisk |
| 18:04.58 | Kobaz | well, my customer found a problem in their core. some routers were flip flopping |
| 18:05.11 | Kobaz | but at the same time, asterisk should handle poor network conditions |
| 18:05.25 | Kobaz | i think this is a good incentive for me to switch to pjsip, and port my stuffs to 13 |
| 18:19.11 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 18:19.12 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:22.01 | mjordan | Kobaz: While I'm sure 13/PJSIP will have some improvements, I'm not sure how that would impact the AstDB having writes that take a long time |
| 18:22.47 | file | yeah I'm not sure how a flip flopping router would cause that |
| 18:35.53 | mjordan | file: figured out what is up with the T.38 direct media test failure. Not sure the fix is going to work well however. |
| 18:36.11 | mjordan | It's the age old 'framehook causes native RTP bridge to be rejected problem' |
| 18:36.20 | mjordan | the PJSIP T.38 module uses a framehook to read/write udptl |
| 18:36.32 | mjordan | That framehook keeps the native bridge from being used when we're in audio only mode |
| 18:36.57 | mjordan | Only thing I can think to do is to only apply that framehook on an INVITE request that contains an image |
| 18:37.13 | file | mjordan, ah |
| 18:37.27 | mjordan | I'm not sure I feel comfortable about having it decline VOICE frames |
| 18:37.50 | mjordan | I could try that however... |
| 18:40.05 | file | whilst more invasive it may just be time to forego the framehook usage there, it was a nice attempt at making it pluggable but in practice has had its share of problems |
| 18:42.36 | mjordan | how else would we handle it? |
| 18:43.44 | file | that I'm not sure, it would require some way of injecting itself into chan_pjsip instead of relying on a framehook |
| 18:45.52 | mjordan | only way I can think to do that is to have chan_pjsip expose some API. |
| 18:46.04 | mjordan | I'll see how far I can get with the current design now that I understand the problem. |
| 18:46.09 | file | nods |
| 18:46.15 | mjordan | I'd rather not break all faxes just to try and keep a directmedia optimization working. |
| 18:46.28 | file | I would. DEATH TO FAX! |
| 18:46.36 | mjordan | It is unfortunate though that the framehook that does it is the pjsip T.38 one, as having that module loaded will pretty much toast any directmedia bridges |
| 18:47.14 | mjordan | that aside, since the module intercepts INVITE requests, I would think that I could apply it when that arrives. Adding the framehook *may* cause it to then re-evaluate the bridge (I think) |
| 18:47.27 | mjordan | that => an INVITE request with an image media type |
| 19:16.44 | *** join/#asterisk-dev Marquis42 (~mrbmw@d192-24-112-5.try.wideopenwest.com) |
| 19:27.27 | gtjoseph | jsmith: sucker |
| 19:27.40 | jsmith | gtjoseph: Yeah, that pretty much sums it up :-p |
| 19:27.53 | gtjoseph | :) |
| 19:28.57 | file | jsmith, I ordered the X250 :D |
| 19:29.04 | jsmith | file: Rock on! |
| 19:29.11 | jsmith | file: I think you'll be happy with it |
| 19:29.22 | file | jsmith, ditto |
| 19:38.07 | *** join/#asterisk-dev jonathanrose (jon@nat/digium/x-xoyxabkvswwapwdq) |
| 19:40.56 | Kobaz | mjordan: well there's other issues |
| 19:41.01 | Kobaz | oh he's come |
| 19:41.03 | Kobaz | gone |
| 19:41.13 | Kobaz | i'm having issues with longly held netlock |
| 19:41.22 | Kobaz | and dblock wasn't locked at the time |
| 19:41.29 | datachomper | hey the x250 went back to actual buttons for mice file, that's neat |
| 19:41.31 | Kobaz | i'm contending with multiple isusues |
| 19:41.36 | file | datachomper, indeed |
| 19:43.26 | datachomper | looks about the same as x240 otherwise |
| 19:44.44 | file | the X260 is coming out in January, but I was fine not waiting |
| 19:47.33 | datachomper | I suggest the extended battery as well <3 |
| 19:49.23 | file | yeah, I got the 6 cell |
| 19:49.36 | file | it was all of $5 more |
| 20:07.28 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 20:23.29 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 21:03.53 | Kobaz | https://raw.githubusercontent.com/docker/dockercraft/master/docs/img/dockercraft.gif |
| 21:19.33 | Kobaz | sooooo |
| 21:24.31 | *** join/#asterisk-dev sgriepentrog (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 22:09.51 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 22:09.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:40.02 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
