| 00:34.12 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 02:47.42 | *** join/#asterisk-dev AH2 (uid409542@gateway/web/irccloud.com/x-yjvinjolcdbggyoz) |
| 04:03.15 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.102) |
| 07:17.47 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:28.38 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:44.40 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.61) |
| 08:47.40 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:47.40 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 13:51.36 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 13:51.55 | seanbright | has anyone put any thought into what a new realtime system would look like? |
| 13:52.04 | seanbright | or is it one of those things that we want to die off? |
| 13:57.19 | gtjoseph | seanbright: don't even think about removing the sanitizers. the leak sanitizer is my best friend. |
| 13:59.19 | seanbright | ugh, so jealous that you have a working compile |
| 14:00.10 | seanbright | (i'm being passive aggressive - it's kinda my thing) |
| 14:03.28 | gtjoseph | heh |
| 14:03.32 | seanbright | so when you enable dev-mode, we build pjsua and the python bindings (i don't know why, i've never needed pjsua in my development work), and those fail to build/link with the thread sanitizer enabled |
| 14:03.53 | seanbright | same with libasteriskssl.so |
| 14:03.58 | gtjoseph | hmmm. we build them because the testsuite needs them |
| 14:04.11 | seanbright | --enable-dev-mode=test then maybe |
| 14:04.17 | seanbright | i don't really care as long as i can build them |
| 14:04.29 | file | seanbright: I wouldn't touch realtime, I'd just make sorcery modules directly, but still leverage res_odbc for the ODBC one |
| 14:04.46 | seanbright | file: gotcha. |
| 14:05.03 | seanbright | so i think about that a fair amount - "i'll convert module X over to sorcery" |
| 14:05.11 | seanbright | but then the sorcery modules become dependencies |
| 14:05.28 | seanbright | so if it's going to happen, it would have to be a master branch only thing |
| 14:05.40 | seanbright | (which is fine) |
| 14:05.49 | gtjoseph | what are you working on? |
| 14:05.57 | seanbright | nothing |
| 14:06.13 | seanbright | i am thinking |
| 14:06.22 | gtjoseph | good |
| 14:06.35 | seanbright | realtime sucks, how do we fix/replace it |
| 14:06.49 | seanbright | it's the stuff that i think about when trying to fall asleep at night |
| 14:07.26 | gtjoseph | HA! That's been one of my biggest things for a few years now. |
| 14:07.46 | file | I don't think fixing realtime is the answer |
| 14:08.01 | seanbright | i agree |
| 14:08.17 | file | I think improving any critical modules that use realtime to use something better is the answer, and that does probably mean altering dependencies |
| 14:08.41 | *** join/#asterisk-dev tmoore (~tmoore@2601:40e:8180:db80:cd09:7d0f:4650:996c) |
| 14:09.00 | file | and I think many things that do use realtime are old enough that they've grown organically, so it's really a combination of realtime + that which is problematic |
| 14:09.16 | gtjoseph | res_sorcery_pgsql, res_sorcery_mysql, res_sorcery_odbc. |
| 14:09.29 | seanbright | no |
| 14:09.33 | seanbright | not the first two |
| 14:10.11 | seanbright | as much as a hate odbc, i still prefer that over maintaining vendor-specific modules |
| 14:10.24 | seanbright | i hate* |
| 14:10.33 | gtjoseph | yes the first two. odbc is a convenience but not an optimally performing layer. |
| 14:10.42 | seanbright | yeesh |
| 14:10.50 | seanbright | then i shall tap out |
| 14:11.16 | gtjoseph | you could _start_ with odbc though :) |
| 14:11.45 | seanbright | i don't think sorcery is chatty enough that 'optimally performing' at the database layer is that important |
| 14:12.34 | file | it can be chatty in a way but I wouldn't expect the database layer to be that much in the grand scheme of things |
| 14:12.39 | file | dunno though |
| 14:12.54 | seanbright | it would need to be tested |
| 14:12.56 | seanbright | measured |
| 14:13.24 | seanbright | but i wouldn't expect a 10x speed-up from using the native drivers. |
| 14:14.17 | seanbright | and don't get me started with astdb and 'optimally performing' |
| 14:16.12 | *** join/#asterisk-dev sahmed (~sahmed@66.64.44.146) |
| 14:18.56 | seanbright | also - happy tuesday |
| 14:19.06 | seanbright | gtjoseph: i'll send you $100 to fix thread sanitizer in dev-mode |
| 14:19.40 | seanbright | that is literally my life's savings |
| 14:19.48 | gtjoseph | i'm on it. |
| 14:37.29 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-211.bstnma.fios.verizon.net) |
| 15:24.11 | *** join/#asterisk-dev spatel (~spatel@static-71-174-102-210.bstnma.fios.verizon.net) |
| 15:25.31 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-csowfrlkqfsivuhp) |
| 15:25.31 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:29.06 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-djvczrhkmuxoysrk) |
| 15:29.06 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 17:24.31 | *** join/#asterisk-dev electronic_eel (~quassel@HSI-KBW-46-223-65-185.hsi.kabel-badenwuerttemberg.de) |
| 18:55.31 | sahmed | Again with another confusion with Asterisk-16, "why asterisk sending zero media port in the last re-INVITE?" https://pastebin.com/G2XudVd8 |
| 18:56.06 | sahmed | Is that because of any wrong configuration in my system? |
| 18:57.51 | file | It removed the stream, the code to return it to audio may not be working |
| 18:58.30 | file | Returning to audio rarely matters for people so probably not noticed, unless an issue already exists in JIRA |
| 18:58.57 | sahmed | okay got it |
| 18:59.19 | sahmed | this re-invite doesn't make any problem with me |
| 18:59.37 | sahmed | just for the zero port getting some error with sipp test tools |
| 19:00.31 | sahmed | In sipp I can't find anything to disable that port check |
| 19:00.51 | sahmed | so, is there anything in asterisk to disable this re-invite? |
| 19:17.21 | file | No, if you see no option there generally isnt |
| 20:03.30 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 20:43.19 | seanbright | gtjoseph: could you update your comment on ASTERISK-28634 to indiciate what the fix was that you are referring to? |
| 21:02.10 | gtjoseph | seanbright: i could but i'm not exactly sure. :) All I know is that it was fixed between 17.0 and 17.1. |
| 21:02.15 | gtjoseph | I thought it was https://gerrit.asterisk.org/c/asterisk/+/13197 |
| 21:02.23 | gtjoseph | but I reverted that and it was still fixed. |
| 21:03.43 | gtjoseph | If you think you know which one, let em know. |
| 21:07.51 | file | https://gerrit.asterisk.org/c/asterisk/+/13685 ? |
| 21:08.26 | gtjoseph | that says it's only in the 17 branch |
| 21:08.45 | file | there's cherry picks against all branches for it |
| 21:08.50 | file | well, 13 was different |
| 21:08.50 | gtjoseph | and it was fixed in 17.1 |
| 21:09.14 | gtjoseph | yeah but i'm only testing 17 since that's what the reporter was using |
| 21:09.48 | file | ah |
| 21:09.53 | gtjoseph | and by only in 17, i meant that it's not in any 17 release branch for some reason. at least according to gerrit |
| 21:10.35 | gtjoseph | also, the call actually continued for 20 minutes so frames weren't being dropped |
| 21:18.45 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 22:07.40 | seanbright | i guess a git bisect would tell you? |
| 22:07.49 | seanbright | which granted is a non-trivial amount of work |
| 22:07.52 | seanbright | but it would still be nice to know |
| 22:09.54 | seanbright | file: are sorcery wizards privy to a type's metadata? |
| 22:10.16 | file | What metadata? |
| 22:10.28 | seanbright | its fields and their types |
| 22:11.07 | seanbright | or can that be queried given an ast_sorcery * and the type? |
| 22:11.35 | file | I don't think so at the moment |
| 22:11.38 | seanbright | ok |
| 22:13.46 | file | wrapping an ao2 iterator and adding accessors for the bits of info shouldn't be that bad |
| 22:13.59 | file | ditto by name if need be |
| 22:14.44 | seanbright | just trying to figure out if there is a sorcery analog for realtime's "require" stuff |
| 22:14.54 | seanbright | so i'll have to see about adding it in a non-horrible way |
| 22:19.38 | file | hrm |
| 22:24.19 | seanbright | the more i think about it, it may be unnecessary. in was thinking that it might be nice if asterisk and the "remote side" of a sorcery wizard didn't have to duplicate information |
| 22:25.08 | seanbright | but in order to provide useful information, the remote side would need to know everything anyway |
| 22:25.11 | seanbright | so it's moot |
| 22:25.21 | seanbright | a cow's opinion... moo |
| 22:27.44 | file | you can actually know stuff in the sorcery core, for example if a field is required and the data passed in doesn't contain it, then the (most likely wizard) didn't provide it |
| 22:27.54 | file | well, you don't know if it's strictly required yet |
| 22:28.24 | file | or were you thinking of something further on the wizard side? |
| 22:29.24 | seanbright | i was thinking of a hypothetical res_sorcery_http |
| 22:29.54 | seanbright | it makes an HTTP request to a URL and passes the id of the sorcery object to retrieve |
| 22:30.02 | file | right |
| 22:30.22 | seanbright | but the remote web application doesn't know what fields should be returned |
| 22:30.37 | file | ah |
| 22:30.41 | file | that's interesting |
| 22:30.51 | seanbright | and dumb :P |
| 22:31.06 | seanbright | for the web application to be useful, of course it needs to know what should be returned |
| 22:31.13 | file | generally yes |
| 22:31.15 | seanbright | both sides (asterisk and the remote) need the same knowledge |
| 22:31.31 | seanbright | there is no avoiding that, which is fine |
| 22:31.51 | seanbright | but if obviates the need for the 'require'-like functionality i was describing |
| 22:32.07 | seanbright | it* not if |
| 23:12.12 | *** join/#asterisk-dev offbeatwitch (~offbeatwi@platypus.offbeatwit.ch) |