| 00:18.50 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:18.50 | *** topic/#asterisk-dev is 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 |
| 02:19.12 | *** join/#asterisk-dev zopsi_ (~zopsi@2607:5300:60:9f36::) |
| 02:40.23 | *** join/#asterisk-dev tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 06:42.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:9c82:c83:bdc4:793c) |
| 06:43.10 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:40.26 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:57.11 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:9c82:c83:bdc4:793c) |
| 12:29.56 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:17.21 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-148-182.dialup.adsl.anteldata.net.uy) |
| 13:26.46 | *** join/#asterisk-dev vipul20 (uid64067@gateway/web/irccloud.com/x-pdyagpcrltpgeyno) |
| 13:51.12 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-148-182.dialup.adsl.anteldata.net.uy) |
| 13:58.17 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:06.13 | *** join/#asterisk-dev joshelson (~joshelson@151.181.77.18) |
| 14:18.02 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-toibhkcxolzdyamv) |
| 14:18.02 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:29.03 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:29.03 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:40.21 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:48.18 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-yfmhaonmbvscqjqo) |
| 14:48.18 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:55.24 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-qjvsnunyoycdmcbe) |
| 14:55.24 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:18.39 | file | cresl1n: so we're actually gaining more data points that we could use to better refine/tweak REMB... not just gathering |
| 15:18.47 | file | cresl1n: RTCP report information, and NACK information |
| 15:18.52 | cresl1n | ooooh |
| 15:18.59 | cresl1n | like loss data and NACK counts? |
| 15:19.12 | file | yes |
| 15:19.36 | cresl1n | How do you think we would use it? |
| 15:20.20 | file | well REMB gives us control over the video encoding... so we can drop it down some be it sender or receiver... and that might help... |
| 15:20.44 | file | dunno, not my area of expertise to that degree currently :P |
| 15:20.50 | cresl1n | Don't we do something like that right now? |
| 15:21.05 | cresl1n | with the REMB report aggregation? |
| 15:21.16 | file | that's based on what the endpoints provide us, aggregated down |
| 15:21.28 | cresl1n | gotcha |
| 15:21.35 | file | so yes to a degree, but we're reliant on those reports |
| 15:22.17 | file | anyway - just a thought |
| 15:22.25 | cresl1n | good thought! |
| 15:23.14 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-148-182.dialup.adsl.anteldata.net.uy) |
| 15:23.17 | cresl1n | Like we could calculate our own REMBs from Asterisk's perspective |
| 15:23.45 | file | I like to think of it more as a quality of link |
| 15:24.01 | file | but yeah |
| 15:24.15 | cresl1n | It can't be that hard, I would think.... |
| 15:24.25 | file | it could even be used to alter the weighting of the aggregation of the REMB |
| 15:24.27 | *** join/#asterisk-dev scgm11__ (~scgm11@r186-52-148-182.dialup.adsl.anteldata.net.uy) |
| 15:24.40 | cresl1n | at that point, would we need to even aggregate REMBs? |
| 15:24.43 | cresl1n | ponders |
| 15:25.08 | file | I think so yes, because that gives you an actual bandwidth estimate... unless you want to get into that world |
| 15:25.32 | file | (one day we probably will) |
| 15:26.10 | cresl1n | does REMB calculation apply to an SSRC, or to all RTP streams received aggregated together? |
| 15:26.23 | file | REMB is for the RTP session and all streams in it |
| 15:26.34 | file | it's how much bandwidth the endpoint thinks it can handle in total across all |
| 15:26.40 | cresl1n | ok |
| 15:27.09 | file | gives cresl1n a project to do the above |
| 15:27.28 | cresl1n | So Asterisk generating a REMB *might* be one of the most important REMBs to do |
| 15:27.40 | cresl1n | since it's the first line of defense |
| 15:28.06 | file | your statement doesn't quite parse |
| 15:28.09 | cresl1n | yeah |
| 15:28.10 | cresl1n | sorry |
| 15:28.18 | cresl1n | it didn't come out quite clear |
| 15:28.31 | cresl1n | I don't know if it's right |
| 15:28.47 | cresl1n | I guess probably not |
| 15:29.26 | cresl1n | So the REMB originated from Asterisk would only cover one stream being sent by a browser |
| 15:29.30 | cresl1n | simplest case |
| 15:29.33 | rmudgett | file: kharwell: gtjoseph: T.38 tests updated fixing the typo file found. |
| 15:29.41 | cresl1n | the REMB originated from the browser covers the bundle of streams received |
| 15:29.49 | gtjoseph | heh, YOU had a typo :) |
| 15:30.14 | file | cresl1n: since it's the case where we only accept 1 video stream from the browser - yes - it effectively just covers that stream |
| 15:30.17 | rmudgett | A few do escape every so often. |
| 15:30.27 | cresl1n | so figuring out how to make the two "fit" sounds like a hardish problem |
| 15:30.30 | cresl1n | for all users |
| 15:30.43 | file | I don't know what two you are referring to |
| 15:30.49 | cresl1n | well, those two perceptions |
| 15:31.12 | file | I'm lost :P |
| 15:31.26 | cresl1n | Maybe I'm over thinking it |
| 15:31.45 | cresl1n | But if the last mile is usually the weakest link in bandwidth land |
| 15:32.03 | cresl1n | Well let me correct that statement |
| 15:32.10 | file | I think the simplest mechanism to incorporate RTCP/NACK statistic information would be the weight like I said in aggregation - because the average doesn't take into account that it may still be too much for an endpoint |
| 15:32.24 | file | so if you see NACKs increase or more out of order packets, their REMB report should hold higher weight in the aggregation |
| 15:32.24 | cresl1n | yes.... |
| 15:32.28 | cresl1n | I think we're talking about the same thing |
| 15:32.35 | cresl1n | but in different ways |
| 15:32.38 | file | maybe? |
| 15:32.41 | file | :D |
| 15:32.56 | cresl1n | pulls the ripcord and calls file |
| 16:10.15 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-148-182.dialup.adsl.anteldata.net.uy) |
| 17:05.34 | coreyfarrell | people with +2: can we get the testsuite python3 changes merged? Asterisk (master) gate has been successfully run multiple times so it shouldn't cause any breakage unless something in 13 or 15 was missed. |
| 17:08.30 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00005e8f7b47e64a83.ipv6.abo.wanadoo.fr) |
| 17:09.58 | gtjoseph | coreyfarrell: i'm setting time aside to get it through. |
| 17:10.03 | gtjoseph | this afternoon |
| 17:16.16 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-148-182.dialup.adsl.anteldata.net.uy) |
| 17:23.01 | cresl1n | coreyfarrell: sorry for the delay on it |
| 17:23.04 | cresl1n | it's a big patch |
| 17:36.33 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LFbn-1-5358-11.w90-105.abo.wanadoo.fr) |
| 17:37.59 | coreyfarrell | gtjoseph / cresl1n: thanks. I know it's a big patch and understand it takes a while, I'd just like to be done with this first phase patch. |
| 17:38.52 | coreyfarrell | once merged it'll be possible to run some tests with python3, smaller patches will be able to address any remaining python3 issues in much smaller patches. |
| 17:49.15 | *** join/#asterisk-dev pabelanger (pabelanger@redhat/pabelanger) |
| 17:49.15 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:49.19 | pabelanger | o/ |
| 17:50.27 | pabelanger | is https://zuul.asterisk.org/ still a thing or did you migrate away from it? |
| 17:55.18 | file | we don't use Zuul |
| 17:55.38 | file | Jenkins and Gerrit talk to each other directly |
| 17:55.59 | pabelanger | file: any history on why it was dropped? |
| 17:56.18 | file | it didn't provide us anything worthwhile in what we needed, was something extra to maintain |
| 17:56.34 | file | if we have to spend more time maintaining infrastructure and such than actually working on Asterisk, that's no good |
| 17:56.42 | pabelanger | right |
| 17:57.33 | pabelanger | are you doing container things yet? |
| 17:57.46 | file | define container things |
| 17:57.54 | cresl1n | chroot's file |
| 17:58.02 | file | gtjoseph is working to transition things to run in containers to improve what can be done simultaneously |
| 17:58.13 | file | but we aren't producing/shipping container images or anything |
| 17:58.22 | pabelanger | yah, if you are running jobs in containers |
| 17:58.25 | pabelanger | over VMs |
| 17:58.37 | cresl1n | coreyfarrell: speaking of python 3 migration |
| 17:58.48 | file | work underway currently |
| 17:59.02 | cresl1n | would you be interested in doing a blogs.asterisk.org post about the fun you've found working on it? |
| 17:59.22 | pabelanger | okay, mostly curious if there was an issue with zuul not providing features or problems maintaining it |
| 18:04.54 | gtjoseph | pabelanger: with gerrit and jenkins talking directly, there was no need to keep it. |
| 18:06.49 | pabelanger | gtjoseph: right, but zuul offers things like gating, which jenkins doesn't. But I admit I am unsure what asterisk is testing these days |
| 18:07.10 | gtjoseph | define "gating" |
| 18:07.42 | pabelanger | parallel testing for example, also: https://zuul-ci.org/docs/zuul/user/gating.html |
| 18:08.20 | pabelanger | but I don't think zuul was ever used for that before, IIRC you still clicked merged button in gerrit |
| 18:09.16 | gtjoseph | it's all automated now. jenkins keeps track of the jobs that were triggered by an event from gerrit and replies to gerrit with a funal vote |
| 18:09.26 | gtjoseph | s/funal/final/ |
| 18:09.43 | gtjoseph | if the vote is "verified +2" an automatic merge id sone |
| 18:09.54 | gtjoseph | s/id sone/is done/ |
| 18:10.15 | file | the only time it doesn't is if a bouncy test fails, or a legit test fails |
| 18:10.50 | pabelanger | gtjoseph: no, I understand that. Zuul has the ability to test a series of changes, kick out the one that failed, then retest and merge. |
| 18:11.13 | pabelanger | file: right, in the case of zuul, it would remove that patch from the series, rebase and test, if passed code merged |
| 18:11.36 | file | ok |
| 18:11.51 | pabelanger | but, yah, mostly didn't want to start a zuul is better then jenkins thing. Wanted to understand why moved away from zuul :) |
| 18:11.58 | pabelanger | and chance to catch up |
| 18:12.30 | pabelanger | no anonymous access to https://jenkins2.asterisk.org/ ? |
| 18:13.18 | gtjoseph | not atm. |
| 19:12.05 | gtjoseph | anyone have thought on whether we can drop 32-bit unit tests? |
| 19:26.56 | seanbright | i have no thoughts about that, no |
| 19:34.58 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-143-17.dialup.adsl.anteldata.net.uy) |
| 19:53.22 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-143-17.dialup.adsl.anteldata.net.uy) |
| 19:56.38 | coreyfarrell | cresl1n: I'll try to put some thoughts together. I'll probably draft something in github markdown, I assume it won't be too difficult to convert to whatever the blog uses? It won't be much formatting anyhow. |
| 19:56.51 | cresl1n | That'd be awesome! |
| 19:59.59 | coreyfarrell | gtjoseph: I don't think running every change through 32-bit tests is worth the build agent resources. If extra resources are available I'd rather see periodic testing with REF_DEBUG or coverage enabled. |
| 20:00.25 | gtjoseph | yeah, that's where i'm at as well. |
| 20:00.58 | coreyfarrell | gtjoseph: how often do 32-bit find errors which aren't caught by 64-bit anyways? |
| 20:01.45 | gtjoseph | in the 7 years i've been doing asterisk stuff... i can't actually remember one but there were probably one or 2 |
| 20:06.35 | coreyfarrell | so does 32bit become an extended platform? if 13.23.0 is released and has a failure in 32-bit only does that trigger 13.23.1? |
| 20:07.43 | gtjoseph | i'm not suggesting deprecating 32-bit. if it's a legitimate 32-bit problem i'd say yes. |
| 20:07.55 | seanbright | we have to deprecate dialplan first |
| 20:08.06 | gtjoseph | heh |
| 20:17.25 | coreyfarrell | is it even possible to catch inbound calls from ARI or other API before they reach dialplan? |
| 20:18.49 | seanbright | i don't think so |
| 20:19.14 | seanbright | i vaguely remember someone talking about adding 'application' support for endpoints |
| 20:19.22 | seanbright | maybe it was just a wish list thing |
| 20:19.25 | seanbright | dan_j: |
| 20:19.40 | seanbright | err, sorry. was going to ask danjenkins but then i realized i didn't care. |
| 22:50.56 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-toibhkcxolzdyamv) |