| 00:25.35 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-uulywyemebvdkcld) |
| 00:53.40 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 00:57.30 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:10dd:9e67:f1db:6319:2f77:c405) |
| 01:51.21 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 01:57.02 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:10dd:9e67:f1db:6319:2f77:c405) |
| 01:57.19 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:10dd:9e67:f1db:6319:2f77:c405) |
| 02:32.01 | *** join/#asterisk sysgrammer_moe (~sysgramme@d50-117-130-220.yt.northwestel.net) |
| 04:23.43 | *** join/#asterisk carrar (~tim@osburn.jp) |
| 04:35.57 | igcewieling | zfs dedupe works great when you have a copy of the Polycom firmware for each "site" or "client" |
| 04:35.57 | igcewieling | NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT |
| 04:35.57 | igcewieling | tftpboot 63.5G 4.98G 58.5G - 40% 7% 21.42x ONLINE - |
| 04:36.18 | igcewieling | 21.42x "compression" |
| 05:16.26 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 05:38.03 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 05:45.48 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 06:15.40 | *** join/#asterisk yuljk (~yuljk@unaffiliated/yuljk) |
| 06:17.35 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 06:57.22 | *** join/#asterisk yuljk (~yuljk@unaffiliated/yuljk) |
| 07:11.33 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1099:620:425:4bd8:9d91:92cb) |
| 07:32.46 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 07:33.12 | *** join/#asterisk nickvsnetworking (~nickvsnet@103.31.113.82) |
| 07:40.57 | *** join/#asterisk ruben23 (~ruben@49.149.108.168) |
| 08:02.27 | ruben23 | guys any idea hwo to work around with this problem installing dahdi on my asterisk box it a container---> You do not appear to have the sources for the 5.3.18-3-pve kernel installed |
| 08:14.07 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 08:38.57 | TandyUK | ruben23: install the sources? |
| 08:39.54 | ruben23 | TandyUK: my kernel is uname -r ---> uname -r ------> 5.3.18-3-pve its on an LXC container |
| 08:44.09 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1099:620:425:4bd8:9d91:92cb) |
| 09:20.54 | *** join/#asterisk infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 09:20.54 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.33.0 (2020/04/30) 16.10.0 (2020/04/30) Standard: 17.4.0 (2020/04/20); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 |
| 09:24.40 | file | no. |
| 09:56.49 | Syco | a painful truth is better than a lie.. sometimes.. |
| 10:24.21 | *** join/#asterisk nickvsnetworking (~nickvsnet@103.31.113.82) |
| 10:46.50 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 11:26.54 | *** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-ljhznssehulucski) |
| 11:28.42 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 11:34.30 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 12:41.57 | *** join/#asterisk steinbach (~id4rk@reactos/tester/id4rk) |
| 12:42.52 | *** join/#asterisk derPlexus (~plexus@ip-176-198-128-59.hsi05.unitymediagroup.de) |
| 12:42.55 | *** join/#asterisk Psyb3rN4ut (~psybernau@185.32.179.134) |
| 13:01.09 | *** join/#asterisk javi404 (~quassel@unaffiliated/javi404) |
| 13:05.14 | *** join/#asterisk waldo323_ (~waldo323@12.239.4.120) |
| 13:08.18 | *** join/#asterisk javi404 (~quassel@unaffiliated/javi404) |
| 13:12.29 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 13:16.11 | *** join/#asterisk javi404 (~quassel@unaffiliated/javi404) |
| 13:18.55 | *** join/#asterisk chandoo (~chandoo@pool-100-1-166-161.nwrknj.fios.verizon.net) |
| 13:24.34 | *** join/#asterisk javi404 (~quassel@unaffiliated/javi404) |
| 13:43.25 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 13:43.43 | Kobaz | igcewieling: what about symlinks? |
| 13:48.05 | igcewieling | Kobaz: complicated and error prone |
| 13:48.22 | Kobaz | really? |
| 13:49.44 | Kobaz | is: ln -s /var/tftpboot/firmware-4.0/sip.ld /var/tftpboot/customer/foobar/sip.ld that much more complicated than cp /var/tftpboot/firmware-4.0/sip.ld var/tftpboot/customer/foobar/sip.ld |
| 13:50.21 | Kobaz | And then you don't have the extra IO churn of having to deduplicate, and then deployments/updates would be much easier because you can scan for everyone using version x quite quickly |
| 13:51.13 | igcewieling | Yes, I think making a symlink for every firmware file for every customer is more complicated than a simple CP. |
| 13:51.22 | Kobaz | it's literally the same |
| 13:51.43 | Kobaz | just replace cp with ln -s |
| 13:52.32 | igcewieling | You know Polycoms have more than one firmware file, right? One for each model. |
| 13:52.39 | Kobaz | in my experience, things seem complicated and error prone when there is a lack of understanding |
| 13:52.46 | Kobaz | right |
| 13:52.58 | Kobaz | i'm just giving a simple combined firmware example |
| 13:54.14 | Kobaz | cd /var/tftpboot/customer/foobar; for i in /var/tftpboot/firmware-4.0/*; do ln -s $i; done |
| 13:54.44 | Kobaz | okay, so, slightly more complicated to do multiple symlinks, but that executes in about 100ms |
| 13:55.50 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-dbhljpqrcclzycld) |
| 13:55.50 | *** mode/#asterisk [+o bford] by ChanServ |
| 13:57.34 | Kobaz | you could link certain models to certain firmware versions on a case by case basis, so if customer X for IP-330 needs version 4.1 or whatever, and everything else is 4.0, you can still accomplish that |
| 13:57.45 | igcewieling | for me is it rsync -avvP /tftpboot/template /tftpboot/customer_account_number |
| 13:57.56 | Kobaz | right, sure |
| 13:58.01 | Kobaz | but, rsync can also copy symlinks |
| 13:58.23 | igcewieling | then I never have to worry about a change in the template messing up dozens of customers. |
| 13:58.34 | Kobaz | just saying, it seems to be a sledgehammer solution when a screwdriver is a better tool |
| 13:59.09 | Kobaz | but, if you like it this way, with dedup, that's okay for sure, but, symlinks are the way to go if you want to avoid the extra disk space |
| 13:59.10 | Samot | Why do you need to have the same firmware files copied into multiple directories? |
| 13:59.26 | Kobaz | Samot: he wants to have different customers on different versions |
| 13:59.30 | Samot | OK |
| 13:59.36 | Kobaz | but you can just as easily symlink to the main firmwares |
| 13:59.39 | Samot | So again, why do you need that per customer? |
| 13:59.47 | Samot | Why do you even need symlinks? |
| 13:59.54 | Kobaz | Samot: i use symlinks |
| 14:00.04 | Kobaz | because different customers have different requirements |
| 14:00.15 | Samot | OK. |
| 14:00.18 | Kobaz | you might want to blast out firmware upgrade X to only customers A, B, and C |
| 14:00.25 | Samot | So I'm going to take a 200MB firmware file and copy it 100x's |
| 14:00.32 | Samot | So I have 200MB x100 on my server of space |
| 14:00.48 | Kobaz | haha, right. well. that's the zfs-dedup "fixes" that |
| 14:00.55 | Kobaz | the other solution, which i'm going to be migrating to |
| 14:00.55 | Samot | So then change where the profile points. |
| 14:01.06 | Samot | It's a setting in the profile.. |
| 14:01.08 | Kobaz | is even better than symlinks, is yes, actually have the xml point to the proper locatio |
| 14:01.28 | Samot | I don't need to copy version 6.2 of Poly UC for all my customers. |
| 14:01.31 | Kobaz | i started building a per-tenant defaults configuration system |
| 14:01.39 | Samot | I just update their profile to point to where the firmware is. |
| 14:01.50 | Kobaz | so i could stick default firmare version X for the customer and it will just point to the right files |
| 14:01.55 | Kobaz | Samot: right, that's the ideal way |
| 14:02.12 | Samot | I keep my tenant profiles in their own locations.. |
| 14:02.19 | Samot | But shared stuff like firmware files... |
| 14:02.22 | Kobaz | right |
| 14:02.26 | Samot | I don't need to copy it for every tenant. |
| 14:02.28 | Samot | That's a waste. |
| 14:02.48 | Kobaz | igcewieling: something to think about... |
| 14:03.32 | Kobaz | ighttp://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ |
| 14:03.33 | Samot | Just like I don't copy default MoH files for everyone. |
| 14:03.39 | Samot | All their default goes to the same place. |
| 14:03.41 | Kobaz | right |
| 14:03.42 | Kobaz | hehe |
| 14:03.48 | igcewieling | Kobaz: I'm just imagining all the work of managing it your way. |
| 14:04.03 | Kobaz | Pets - Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and âhand fedâ. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on. |
| 14:04.17 | Kobaz | igcewieling: it's all tradeoffs, right |
| 14:04.47 | Kobaz | igcewieling: it's typically.... you can improve thiings by 1) adding more resources, or 2) investing time |
| 14:05.06 | Kobaz | in this case, zfs is your added resource, sure it dedupes and saves you space, but at what cost |
| 14:05.13 | Kobaz | what IO cost, what memory cost, what maintenance cost? |
| 14:05.32 | Kobaz | balance that versus the time taken, to automate/centralize some behaviors |
| 14:05.40 | Kobaz | it might be worth it? it might not |
| 14:05.43 | igcewieling | It is a damn FTP server, it doesn't need to be a super server. |
| 14:05.59 | Kobaz | but! |
| 14:06.09 | Kobaz | of course there's some 'hidden costs' in there |
| 14:06.10 | igcewieling | It also, gasp, runs in a VM! |
| 14:06.24 | Kobaz | Now, imagine you have 5000 customer paths |
| 14:06.33 | Kobaz | And you want to upgrade firmware for everyone |
| 14:06.45 | igcewieling | I will NEVER want to upgrade the firmware for everyone. |
| 14:06.51 | Kobaz | you still need to write some code, rsync everyone over their new files or whatever... so there's the hidden cost of future maintenance |
| 14:06.59 | Kobaz | which only bites you waaaaay down the road |
| 14:07.06 | igcewieling | my god, the number of support calls alone would drive me insane. |
| 14:07.20 | Kobaz | igcewieling: you think that now... but, when a security issue affects all your customers.... |
| 14:07.46 | Kobaz | but... just trying to help with some constructive critisism |
| 14:07.46 | igcewieling | That happens often? |
| 14:07.53 | Kobaz | igcewieling: often enough... |
| 14:08.10 | Kobaz | once sucks badly enough to never want to have to manually handle that ever again |
| 14:08.38 | Kobaz | but ever have to do that twice? three times? you're going to wish you had a system for it |
| 14:08.44 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-jxwssbkeevwiwndf) |
| 14:08.44 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:08.44 | Kobaz | and not just random rsyncs |
| 14:08.52 | Samot | So |
| 14:09.02 | Samot | Just so I understand the two sides here... |
| 14:09.13 | Samot | 1) Copy everything per customer |
| 14:09.36 | Samot | 2) Keep firmware central but make N amount of symlinks per customer |
| 14:09.50 | Samot | Is that correct? |
| 14:10.02 | igcewieling | more or less |
| 14:10.03 | Kobaz | Without major scripting, those are the approaches |
| 14:10.23 | Kobaz | 3) is generate the xmls to point to the specific version needed |
| 14:10.24 | Samot | Or 3) Firmware central, just update profiles as needed to the new location |
| 14:10.31 | Kobaz | correct |
| 14:10.32 | Samot | Which is what I do. |
| 14:10.40 | Samot | Amazingly a single DB query fixes all that |
| 14:10.49 | Kobaz | Samot: if you already have the infrastructure, yes |
| 14:10.51 | Kobaz | many peopel don't |
| 14:11.01 | Samot | If you're doing 1 or 2 |
| 14:11.04 | Samot | You hae it. |
| 14:11.07 | Samot | have* |
| 14:11.25 | Kobaz | not necessarily |
| 14:11.45 | Kobaz | If you don't have a db-driven configuration system, you're hosed if you try and do 3) |
| 14:11.52 | Samot | OK |
| 14:11.58 | Samot | You use sed |
| 14:12.12 | Samot | Or some other find/replace logic |
| 14:12.19 | Kobaz | Sure, definitely possible |
| 14:12.27 | Kobaz | less infrastructure-ish, but yeah |
| 14:12.44 | Samot | You are neither then taking up hard drive space |
| 14:12.47 | Kobaz | But ongoing maintenance i'm sure you would agree would be a million percent easier if it was all db driven |
| 14:12.55 | Samot | Or managing upgodly amounts of symlinks |
| 14:13.17 | Kobaz | Samot: my short term solution for igcewieling was just to fix the disk/io/mem issue of having to dedup in the first place |
| 14:13.30 | Kobaz | it's literally a drop in replacement for cp/rsync |
| 14:13.33 | igcewieling | I never said there was an issue. |
| 14:13.47 | Kobaz | no, you didn't, but i saw it as a red flag |
| 14:13.51 | Kobaz | and suggested some alternatives |
| 14:15.11 | Kobaz | but anyway, definitely consiser the alternatives, you'll thank us in the end :) |
| 14:15.28 | Kobaz | 3) is definitely the best approach overall |
| 14:15.55 | igcewieling | If I ever rebuild our provisioning system, it will use a DB and http provisioning |
| 14:19.22 | Kobaz | If i had to do this all over |
| 14:19.30 | Kobaz | i dont' even know |
| 14:19.54 | Kobaz | probably use freepbx and write tons of modules for it... all this in-house stuff is a metric crap ton of work |
| 14:20.07 | igcewieling | If I had to do it all over, I'd probably open a bakery. 8-| |
| 14:20.10 | Kobaz | true |
| 14:20.25 | Kobaz | coffee shop and book store |
| 14:20.52 | Kobaz | and then, at night it'll be a whiskey bar |
| 14:21.52 | Kobaz | well, time to work on my quadrants |
| 14:21.58 | Kobaz | Urgent and Important is up next |
| 14:26.46 | Kobaz | Seems like that category is never-ending |
| 14:36.33 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 14:37.40 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 14:37.49 | *** join/#asterisk spatel (~spatel@70.42.54.42) |
| 15:12.37 | *** join/#asterisk Psyb3rN4ut (~psybernau@185.32.179.134) |
| 15:36.01 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:101b:386f:7eef:e824) |
| 15:51.31 | *** join/#asterisk lbazan (~lbazan@fedora/LoKoMurdoK) |
| 15:57.56 | igcewieling | From one of our most senior sales people "I have a client that wants to go Hosted. They want to be able to put calls in Que. Do we need to have a server on site? " |
| 16:11.48 | drmessano | Hah |
| 16:12.38 | drmessano | One of our ISPs emailed our senior sales exec and a few other across the region, asking if we were customers of their business service. |
| 16:12.58 | drmessano | 1. Wouldn't they check first |
| 16:13.08 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 16:13.10 | drmessano | 2. See #1 |
| 16:13.37 | drmessano | I replied back and told her we had been a customer at one time but the service was terrible. |
| 16:14.29 | drmessano | I guess everyone is getting back to work and they want to form partnerships in their feelgoodedness |
| 16:16.01 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:101b:386f:7eef:e824) |
| 16:23.04 | *** join/#asterisk ashka (~postmaste@pdpc/supporter/active/ashka) |
| 16:25.37 | *** join/#asterisk GoldenBear (~gb@104.200.131.10) |
| 16:31.01 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 16:37.55 | *** join/#asterisk irrgit (~ch33se@192.241.175.183) |
| 16:57.12 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 17:00.23 | *** join/#asterisk iq (~iq@47.185.92.236) |
| 17:02.42 | *** join/#asterisk GoldenBear (~gb@104.244.208.38) |
| 17:06.03 | *** join/#asterisk pchero_work (~pchero@2a02:a210:2241:6480:101b:386f:7eef:e824) |
| 17:18.18 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1099:620:d109:cc59:8e2a:4163) |
| 17:38.40 | *** join/#asterisk davlefou (~davlefou@unaffiliated/davlefou) |
| 17:56.23 | *** join/#asterisk sysgrammer (~sysgramme@d50-117-157-138.yt.northwestel.net) |
| 18:13.45 | *** join/#asterisk miralin (~Thunderbi@195.209.246.194) |
| 18:14.23 | *** join/#asterisk defsdoor (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 18:14.53 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 18:21.08 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 18:26.13 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 18:31.02 | *** join/#asterisk eharris (~eharris@unaffiliated/eharris) |
| 18:56.21 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 19:03.40 | *** join/#asterisk miralin (~Thunderbi@94.233.240.149) |
| 19:04.16 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 19:47.21 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1099:620:3d47:34f1:b176:8d7a) |
| 20:31.22 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 20:44.28 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1099:620:3d47:34f1:b176:8d7a) |
| 20:50.20 | *** join/#asterisk TandyUK2 (~admin@TandyUK/staff/James) |
| 20:59.37 | *** join/#asterisk Typhon (~Typhon@dslb-088-066-110-134.088.066.pools.vodafone-ip.de) |
| 21:25.14 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 21:40.36 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1099:620:3d47:34f1:b176:8d7a) |
| 21:41.37 | froy | AMI PJSIPShowEndpoints includes a 'Contacts' with the list of contact URLs, and while EndPointDetail has lots of details, it does not have that detail. I have to list all of them with PJSIPShowEndpoints to get Contacts. |
| 21:42.25 | froy | I guess since "manager show event EndpointList" does not document "Contacts:" that "Contacts:" must be a hack? :D |
| 22:06.27 | *** join/#asterisk zaf (~zaf@104.254.192.70) |
| 22:06.46 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 22:08.05 | *** join/#asterisk spatel (~spatel@70.42.54.42) |
| 22:12.43 | *** join/#asterisk wonderworld (~wonderwor@unaffiliated/wonderworld) |
| 22:15.23 | *** join/#asterisk adeel (~adeel@2602:ffc1:1:face:b49f:6a1e:e591:5e9d) |
| 22:17.21 | Samot | froy: You should probably try the right event that is raised from PJSIPShowEndpoints |
| 22:17.38 | Samot | It doesn't raise _an event_ it raises _multiple_ |
| 22:17.44 | Samot | These events include EndpointDetail, AorDetail, AuthDetail, TransportDetail, and IdentifyDetail. |
| 22:18.36 | Samot | AorDetail has the data field: ContactsRegistered - The number of non-permanent contacts associated with this AoR. |
| 22:18.58 | Samot | Oh I read that field wrong. |
| 22:19.02 | Samot | That's just the total number. |
| 22:20.23 | *** join/#asterisk spatel (~spatel@70.42.54.42) |
| 22:23.07 | Samot | froy: Are you just trying to get all the contacts or the contacts of a specific AOR? |
| 22:42.55 | froy | I'm trying to maintain state outside of asterisk (in-memory tables in a database) for other applications to hammer without putting load on Asterisk -- because app_queue incurs plenty of mutex load on its own. |
| 22:43.49 | froy | I can _query_ contacts easy. It's just that when a ContactStatus comes down the pipe, any Endpoint updates don't include that Contact list. I was going to keep the endpoint list in there, but I guess I'll just remove it. |
| 22:44.41 | froy | I'll just let them do a relational query to get the current contacts. |
| 22:46.04 | froy | I was mostly just wondering about the inconsistency -- why put an undocumented "Contacts:" in there? It'd be nice to have everywher if it is in one place. It's basically the same thing as the PJSIP_DIAL_CONTACTS() dialplan function. |
| 22:50.48 | froy | Looks liek AorDetail does have "Contacts:" but that is undocumented in the "manager show event AorDetail" too. |
| 22:51.51 | *** join/#asterisk nickvsnetworking (~nickvsnet@103.31.113.82) |
| 22:58.58 | wonderworld | i try to build a mechanism to mp3-stream a confbridge conference to a larger audience. the only solution i have come up with yet is recording the conference with the built-in recording function and stream that growing file somehow. i was wondering if there is a more clean way to do it? |
| 22:59.11 | jsmith | froy: Please feel free to upon tickets on issues.asterisk.org for anything that isn't documented there... |
| 22:59.43 | jsmith | wonderworld: I don't know if it's still supported, but at one point there was an Ices() dialplan application that would stream to Icecast. |
| 23:00.26 | wonderworld | jsmith: that sounds interesting. but how would i attach this to confbridge? |
| 23:00.46 | jsmith | wonderworld: Originate a call between your confbridge extension and your Ices() extension. |
| 23:01.02 | wonderworld | i see. let me check if Ices() is still there... |
| 23:01.17 | jsmith | Or use ARI to put the Ices() extension in a particular bridge. |
| 23:01.22 | jsmith | Lots of ways to skin that particular cat. |
| 23:01.57 | jsmith | jsmith: Just thinking outside the box, you could probably get Janus to bridge between Asterisk and gstreamer and go that route as well... |
| 23:02.04 | wonderworld | thank you. i think i can fiddle something that way... |
| 23:03.50 | wonderworld | ICES: Encode and stream using 'ices'. It's there in 16.9.0 |
| 23:09.52 | Samot | I have been in the taco bell drive thru for 20 minutes |
| 23:12.05 | wonderworld | corona jam? |
| 23:15.41 | froy | thank you jsmith |
| 23:16.07 | jsmith | Samot: I'm both jealous and not jealous at the same time... |
| 23:16.33 | jsmith | had his fill of Latin American comfort food for dinner, but it wasn't Taco Bell |
| 23:24.48 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 23:31.57 | *** join/#asterisk matrix1233 (~matrix123@2a04:cec0:1099:620:3d47:34f1:b176:8d7a) |
| 23:53.40 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |
| 23:58.44 | *** join/#asterisk verzo (~verzo@gateway/tor-sasl/verzo) |