| 05:04.04 | *** join/#asterisk-dev infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 05:04.04 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 07:44.30 | wdoekes | > Given the earlier discussions, under what conditions is it desirable to use a different codec in one direction than the other on the same call leg? |
| 07:44.37 | wdoekes | I can only think of hypothetical ones where bandwidth is limited in one direction; either because of async line speeds (adsl/satellite) or because one party has more data to send (a conference hub?).. |
| 07:44.44 | wdoekes | in practice I have not encountered any such case. but then again, I operate in a region where internet is abundant. |
| 07:50.56 | snuff-work | possibly cpu limitations of one end? though u'd think if a device can support a codec it should be able to do both ways fine |
| 10:58.45 | wdoekes | file: any particular reason why res/res_sip_messaging.c includes "pjsua-lib/pjsua.h" instead of <pjsip_ua.h> ? |
| 10:59.00 | file | nothing comes to mind |
| 11:21.38 | wdoekes | ok, I'll push a change to gerrit then |
| 11:22.22 | wdoekes | also, I have a question in ASTERISK-28951 |
| 12:02.25 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.109) |
| 14:05.25 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-mztpyjgxevkpvxwl) |
| 14:05.25 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:23.13 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-fiqnrfxsrcrbtjlw) |
| 14:23.13 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:43.58 | kharwell | I'm not seeing how https://gerrit.asterisk.org/c/asterisk/+/14537 caused https://gerrit.asterisk.org/c/asterisk/+/14553? |
| 15:44.20 | file | it didn't cause it, the problem existed before 14537 |
| 15:44.26 | kharwell | seems like the setting of the uniqueid at the start has been in there for a while |
| 15:44.38 | file | right. |
| 15:44.56 | file | before variables support was added the body was parsed before entering that function entirely |
| 15:44.57 | kharwell | aah I was under the impression it was a regression |
| 15:45.04 | file | with variables added, it is parsed after the function is entered |
| 15:45.16 | file | or to be more specific - with support for variables added |
| 15:46.01 | gtjoseph | i probably should have said... the fix was incomplete |
| 15:46.19 | kharwell | when were the variables added? I thought those had been there a while too? |
| 15:46.46 | file | nope, this is the first release with it |
| 15:47.32 | kharwell | I must be thinking of another command then. Okay so is a regression of sorts |
| 15:47.40 | file | yes. |
| 16:26.08 | *** join/#asterisk-dev a_heber (~a_heber@p200300eacf08490068e6be4b2285a425.dip0.t-ipconnect.de) |
| 16:32.27 | a_heber | hello |
| 16:35.56 | a_heber | I've started asterisk with valgrind (valgrind --suppressions=/usr/src/asterisk/contrib/valgrind.supp --leak-check=yes --log-fd=9 asterisk -vvvvcg 9>valgrind.txt) and found a lot of memory leaks. For example in sorcery.c in the function "ast_sorcery_object_fields_register" where an object is calloced but not freed. I would write a patch for this, but would first ask if this is necessary. Maybe it's |
| 16:35.56 | a_heber | a false error. What do you think? |
| 16:37.28 | file | parts of Asterisk don't clean up at shutdown, some work was done to improve this but there's still parts |
| 16:37.39 | file | they aren't leaks at runtime |
| 16:38.22 | a_heber | nice to hear |
| 16:38.51 | a_heber | but I think this is in the way if I want to develop and test my own stuff |
| 16:39.17 | file | cleaning up the known universe at shutdown is not easy |
| 16:39.18 | a_heber | so are patches okay or would it be seen as unnecessary? |
| 16:39.43 | file | we review all patches that go up and provided they pass review then they'll go in |
| 16:40.53 | a_heber | ok, I see |
| 16:56.07 | kharwell | https://issues.asterisk.org/jira/browse/ASTERISK-28943 is sounding like it might be an improvement vs a bug? |
| 17:01.09 | kharwell | seanbright: sounds like you're thinking any changes needed would have to occur down in the astdb core code itself too |
| 17:25.59 | *** join/#asterisk-dev rmudgett (~rmudgett@170.249.191.178) |
| 17:25.59 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 17:30.32 | seanbright | probably |
| 17:31.00 | seanbright | one thing that would be better, but probably more difficult to do in a backwards compatible way... |
| 17:31.16 | seanbright | right now, the main media cache entries are written under a /MediaCache/... prefix |
| 17:31.35 | seanbright | but the individual entries are not... they are just a SHA1 like /abcdefg.../ |
| 17:31.55 | seanbright | if you put the individual entries under a common prefix, like /MediaCacheEntry/abcdefg.../ |
| 17:32.01 | seanbright | you could query everything at once |
| 17:32.16 | seanbright | rather than querying each thing individually. |
| 17:32.49 | seanbright | deleting would still be slow, but that would speed up the initialization part |
| 17:33.59 | kharwell | does it have to block at start up? |
| 17:35.46 | kharwell | I'm guessing if it just loaded and then later tried to access unavail media it'd just error out then? Could then remove at that point vs trying to sync at startup? |
| 17:36.09 | kharwell | or had a "garbage collector" thread running? |
| 17:36.52 | kharwell | eh yeah I guess all these are just improvements still |
| 17:37.17 | kharwell | to a working system. Albeit one that is not working most efficiently |
| 17:39.39 | kharwell | seanbright: agreed though. I think altering how things are stored would improve things. I think overall that's part of the problem with how we use astdb in general for various subsystems |
| 17:59.01 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-nan-1-1998-4.w90-105.abo.wanadoo.fr) |