| 00:15.52 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 00:20.19 | *** join/#asterisk infobot (ibot@rikers.org) |
| 00:20.19 | *** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 13.16.0 (2017/05/30), 11.25.1 (2016/12/08), Standard: 14.5.0 (2017/05/30); DAHDI: DAHDI-linux 2.11.1 (2016/03/01), DAHDI-tools 2.11.1 (2016/03/01); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22 -=- Logs: bit.ly/1s4AKKu |
| 00:29.23 | *** join/#asterisk clarjon1 (~clarjon1@unaffiliated/clarjon1) |
| 01:23.04 | *** join/#asterisk [[thufir]] (~thufir@192.157.119.2) |
| 02:13.27 | *** join/#asterisk craigify (~craigify@ip184-186-18-123.no.no.cox.net) |
| 02:20.27 | *** join/#asterisk genpaku (~genpaku@107.191.100.185) |
| 02:30.34 | *** join/#asterisk anpi (~crr@unaffiliated/anpi) |
| 02:55.20 | *** join/#asterisk tuxd00d_ (~tuxd00d@ip68-106-11-138.ph.ph.cox.net) |
| 03:02.07 | *** join/#asterisk [[thufir]] (~thufir@192.157.119.2) |
| 03:42.48 | *** join/#asterisk cmendes0101 (~cmendes01@24.114.224.36) |
| 04:28.52 | *** join/#asterisk bmg505 (~leon@196-210-25-24.dynamic.isadsl.co.za) |
| 04:31.28 | *** join/#asterisk Dovid (~dovid@74.123.202.218) |
| 05:27.20 | *** join/#asterisk jdgirard (~quassel@252.79.90.202.dsl.dyn.mana.pf) |
| 05:29.49 | *** join/#asterisk Dovid (~dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 05:49.26 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 06:07.59 | *** join/#asterisk pdugas (~retentive@c-73-82-30-193.hsd1.ga.comcast.net) |
| 06:29.43 | *** join/#asterisk aness (~aness@cm-84.209.155.137.getinternet.no) |
| 06:54.31 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 06:59.20 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 07:26.18 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 08:01.01 | *** join/#asterisk stefanauss (~stefanaus@95.142.177.153) |
| 08:01.52 | *** join/#asterisk Samael28 (~Samael28@46-133-44-225.dialup.umc.net.ua) |
| 08:28.28 | *** join/#asterisk Kaian (~kaian@212.81.221.228) |
| 08:37.51 | *** join/#asterisk Dovid (~dovid@74.123.202.218) |
| 08:48.54 | *** join/#asterisk Samael28 (~Samael28@80.78.45.158) |
| 08:51.21 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 09:04.53 | *** join/#asterisk jkroon (~jkroon@165.16.204.41) |
| 09:19.00 | *** join/#asterisk dpes (d9a88dc2@gateway/web/freenode/ip.217.168.141.194) |
| 09:20.06 | dpes | hi all, where can I find info about >>proper<< firewall settings for asterisk 14.4.1 ? |
| 09:20.20 | dpes | there is a lot tutorials in net... but not consistent |
| 09:20.39 | dpes | or where in config could I control ports |
| 09:36.37 | *** join/#asterisk sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 10:02.11 | *** join/#asterisk Dirk23 (Dirk23@diehildebrands.de) |
| 10:19.54 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 10:33.13 | *** join/#asterisk DanB (~DanB@clt-195.192.204.224.ip-anschluss.net) |
| 11:06.48 | wdoekes | dpes: udptl.conf, sip.conf/pjsip.conf, rtp.conf, assuming you'll be doing sip/rtp/t38 |
| 11:28.09 | *** join/#asterisk sekil (~sekil@109-93-199-144.static.isp.telekom.rs) |
| 11:34.41 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 11:35.05 | *** join/#asterisk ketas- (~ketas@0011-0000-0000-0000-35dc-8408-07d0-2001.dyn.estpak.ee) |
| 11:47.13 | dpes | wdoekes: thx! |
| 12:01.38 | *** join/#asterisk Samael28 (~Samael28@80.78.45.158) |
| 12:04.33 | *** join/#asterisk dacod (~dacod@186.249.206.29) |
| 12:14.41 | *** join/#asterisk Samael28 (~Samael28@80.78.45.158) |
| 12:20.34 | *** join/#asterisk ketas (~ketas@200-62-46-176.dyn.estpak.ee) |
| 12:28.39 | *** join/#asterisk cervajs2 (~cervajs2@178.148.broadband4.iol.cz) |
| 12:29.32 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-xuvqsrwedkrzaleu) |
| 12:30.02 | cervajs2 | hi. i have problem with pjproject cflags %configure --without-tds --without-portaudio --with-pjproject-bundled PJPROJECT_CFLAGS='-DPJ_GRP_LOCK_DEBUG=1 -DPJ_LOG_MAX_SIZE=4500 -DPJ_HAS_IPV6=0' is this syntax correct? or do i need some semicolon? |
| 12:34.51 | *** join/#asterisk samwierema (~samwierem@82.169.225.211) |
| 12:43.22 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 12:54.18 | *** join/#asterisk scgm11_ (~scgm11@r186-52-183-170.dialup.adsl.anteldata.net.uy) |
| 12:57.29 | *** join/#asterisk DivideBy0x0 (~DivideBy0@unaffiliated/divideby0x0) |
| 12:57.30 | *** mode/#asterisk [+o DivideBy0x0] by ChanServ |
| 12:58.30 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:16.28 | *** join/#asterisk Samael28 (~Samael28@80.78.45.158) |
| 13:36.48 | cervajs2 | what is for pjproject set log level X ? |
| 13:37.44 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 13:43.49 | *** join/#asterisk newtonr (RustyNewto@nat/digium/x-ubeeuddovtpkrcyy) |
| 13:43.49 | *** mode/#asterisk [+o newtonr] by ChanServ |
| 13:48.35 | *** join/#asterisk putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:48.35 | *** mode/#asterisk [+o putnopvut] by ChanServ |
| 13:58.02 | *** join/#asterisk kharwell (kharwell@nat/digium/x-lapcfzujaqrkkuup) |
| 13:58.02 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:09.17 | *** join/#asterisk daniel_phonism (2fce67e5@gateway/web/freenode/ip.47.206.103.229) |
| 14:12.06 | *** join/#asterisk Samael28 (~Samael28@46-133-86-158.dialup.umc.net.ua) |
| 14:14.40 | *** join/#asterisk sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 14:14.47 | *** join/#asterisk daniel_phonism (~daniel_ph@static-47-206-103-229.tamp.fl.frontiernet.net) |
| 14:27.23 | *** join/#asterisk Samael28 (~Samael28@46-133-86-158.dialup.umc.net.ua) |
| 14:27.28 | *** join/#asterisk eric_hill (~eric_hill@wsip-184-180-163-60.ks.ks.cox.net) |
| 14:32.08 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-gsuzhrnhpjjpctye) |
| 14:32.09 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 14:44.53 | *** join/#asterisk scgm11_ (~scgm11@r186-50-100-145.dialup.adsl.anteldata.net.uy) |
| 14:54.31 | *** join/#asterisk daniel_phonism (~daniel_ph@static-47-206-103-229.tamp.fl.frontiernet.net) |
| 15:22.20 | *** join/#asterisk Oatmeal (~Suzeanne@c-68-45-30-44.hsd1.nj.comcast.net) |
| 15:37.51 | *** join/#asterisk gswain (uid91227@gateway/web/irccloud.com/x-jpehnmhwuwblzhgo) |
| 15:47.27 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 15:51.34 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:51.34 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 15:54.49 | *** join/#asterisk Dovid (~dovid@ool-4573a525.dyn.optonline.net) |
| 15:55.38 | *** join/#asterisk sawgood (~sawgood@unaffiliated/sawgood) |
| 16:06.23 | *** join/#asterisk UncleKiwi (~UncleKiwi@unaffiliated/unclekiwi) |
| 16:09.41 | *** join/#asterisk defsdoor (~andy@cpc120600-sutt6-2-0-cust177.19-1.cable.virginm.net) |
| 16:12.15 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 16:26.12 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 16:28.28 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 16:54.57 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:07.40 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 17:19.34 | *** join/#asterisk eric_hill (~eric_hill@wsip-184-180-163-60.ks.ks.cox.net) |
| 17:29.38 | *** join/#asterisk ChannelZ (~bobm@burner.com) |
| 17:30.52 | ChannelZ | Hrrm. Did anyone have any problems with * 13.16 segfaulting on launch while trying to load various ari modules? |
| 17:31.24 | ChannelZ | I just built it on two different machines and it crashes. Rebuild 13.14 and it's fine. |
| 17:33.39 | file | ChannelZ: https://issues.asterisk.org/jira/browse/ASTERISK-27026?jql=text%20~%20"ari.conf" |
| 17:36.04 | ChannelZ | hmmm interesting, thanks file! |
| 17:50.54 | *** join/#asterisk danjenkins (danjenkins@gateway/shell/firrre/x-jwqorccfxjtjkrqi) |
| 17:50.55 | *** mode/#asterisk [+o danjenkins] by ChanServ |
| 17:51.46 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
| 17:55.13 | *** join/#asterisk cmendes0101 (~cmendes01@172.56.35.152) |
| 17:58.15 | *** join/#asterisk jrun (~jrun@unaffiliated/glphvgacs) |
| 17:58.54 | *** join/#asterisk Jesterboxboy (~Thunderbi@80-109-194-26.cable.dynamic.surfer.at) |
| 18:11.38 | qakhan | hi all, is there any good reference for asterisk HA |
| 18:11.46 | *** join/#asterisk DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:11.46 | *** mode/#asterisk [+o DivideBy0] by ChanServ |
| 18:14.32 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 18:17.36 | *** join/#asterisk sekil (~sekil@cable-89-216-231-235.dynamic.sbb.rs) |
| 18:22.40 | lvlinux | What's the default timeout for Read()??? The Wiki doesn't say, nor does core show application Read, but they both make mention of a "default timeout" |
| 18:25.27 | lvlinux | Sorry let me correct myself: the wiki doesn't mention a default timeout, but says that if a timeout isn't specified, it will finish when # is pressed. |
| 18:25.52 | lvlinux | But the built in help does mention the default timeout. |
| 18:27.01 | *** join/#asterisk salviadud (~ralfalfa@189-211-190-134.static.axtel.net) |
| 18:31.41 | tuxd00d | qakhan: How many ways can you prepare an egg? Which is your favorite way to prepare an egg? Asterisk HA is the same with many ways to do it and it comes down to a matter of preference. Also, are we talking about a small deployment with two servers, or something much larger? |
| 18:34.16 | [TK]D-Fender | lvlinux, looks like 6s |
| 18:34.56 | lvlinux | k thanks. Was mainly just curious as it's no problem to set whatever I want. |
| 18:35.26 | qakhan | tuxd00d i will start with 2 servers |
| 18:39.50 | tuxd00d | qakhan: What are you trying to protect against? What are you trying to make redundant? How much downtime can you afford? How many endpoints? There are many questions, so if youâre looking for advice here, youâll have to be very explicit on what youâre trying to accomplish. |
| 18:43.09 | qakhan | tuxd00d i want to setup redundant asterisk so if server A goes down Server B automatically take over. i am use SIP Trunk. which can be move to active server accordingly. |
| 18:48.36 | *** join/#asterisk EnrgySmth (d8eba101@gateway/web/freenode/ip.216.235.161.1) |
| 18:48.45 | tuxd00d | A simple âheartbeatâ method would work for that. But what to you mean by going down? Asterisk crash, os crash, someone turned off the light switch the server was plugged into? |
| 18:50.28 | qakhan | yes anythign can happend to server. asterisk crash, OS crash. Network port goes bad. physical machine crash etc.... |
| 19:00.31 | tuxd00d | qakhan: A heart beat program would satisfy that. Something like http://clusterlabs.org/ |
| 19:08.12 | tuxd00d | qakhan: Alternatively, using a SIP proxy (such as #Kamailio) may work better for you (to load balance between two or more Asterisk), but youâd need a deep understanding of SIP. |
| 19:08.45 | tuxd00d | qakhan: Then youâre not âwastingâ hardware on an utilized spare. |
| 19:10.01 | tuxd00d | qakhan: *nonutilized spare |
| 19:30.41 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 19:45.49 | *** join/#asterisk dviola (~diego@unaffiliated/diegoviola) |
| 19:48.52 | *** part/#asterisk dviola (~diego@unaffiliated/diegoviola) |
| 20:15.32 | *** join/#asterisk dviola (~diego@unaffiliated/diegoviola) |
| 20:16.43 | *** part/#asterisk dviola (~diego@unaffiliated/diegoviola) |
| 20:19.57 | Kobaz | this is really bad |
| 20:20.06 | Kobaz | i have a pretty important machine that's locking up on === ---> Waiting for Lock #0 (db.c): MUTEX 276 ast_db_get &dblock 0x807c40 (1) |
| 20:20.44 | Kobaz | asterisk 1.8 |
| 20:20.57 | Samot | Upgrade. |
| 20:21.01 | Kobaz | can't |
| 20:21.11 | Kobaz | 11 has major performance problems on this customer |
| 20:21.13 | Samot | There's not support for 1.8 |
| 20:21.15 | Kobaz | choppy audio, delayed audio |
| 20:21.16 | Kobaz | i know |
| 20:21.19 | Samot | 11 is SFO |
| 20:21.22 | Kobaz | right |
| 20:21.23 | Samot | And dead in 3 months |
| 20:21.25 | Samot | 13 or 14 |
| 20:21.30 | Kobaz | and that's not an option |
| 20:21.54 | Samot | Then you're digging through Google searches. |
| 20:22.23 | Kobaz | not really, it's not a common problem, there's almost zero information on it |
| 20:22.36 | Samot | Well... |
| 20:22.37 | Kobaz | the main public issues around astdb lockups are media based |
| 20:22.45 | Kobaz | slow media, etc... but this astdb is on a ramdisk |
| 20:23.40 | Samot | So an way outdated version of Asterisk and the AstDB runs on a RAMDisk?! |
| 20:23.49 | Samot | Yeah, you're pretty much on your own. |
| 20:24.00 | Kobaz | of course |
| 20:24.14 | Kobaz | you need to run astdb on a ramdisk on 11 as well, otherwise you'll get lockups too |
| 20:24.18 | Samot | Well you have an option. |
| 20:24.24 | Kobaz | on any kind of high load system... |
| 20:24.30 | Samot | Build a real server, not use RAMDisk and upgrade to 13 or 14. |
| 20:24.38 | Kobaz | thanks for your worthless advice |
| 20:24.43 | Kobaz | looks like a repeat of last time |
| 20:24.50 | Samot | I'm not sure how that's worthless. |
| 20:24.56 | Samot | That's actually a real solution. |
| 20:25.06 | Kobaz | because like i said, that's not an option right now, this needs to get resolved in minutes not days |
| 20:25.18 | Samot | It's not going to be solve in minutes. |
| 20:25.26 | Kobaz | right exactly |
| 20:25.32 | Samot | It's an uncommon deployment of a way out of date system. |
| 20:25.34 | Kobaz | that's why 13/14 is a no go |
| 20:25.46 | Samot | Build a new 1.8 box |
| 20:25.51 | Kobaz | that's not an option |
| 20:25.57 | Samot | So what is an option? |
| 20:25.57 | Kobaz | please be realistic |
| 20:26.02 | Kobaz | fixing the root cause |
| 20:26.07 | Samot | A magical solution for a problem no one has had? |
| 20:26.08 | Kobaz | as with most issues |
| 20:26.15 | Samot | What is the root cause? |
| 20:26.16 | Kobaz | you're not helping, please stop |
| 20:26.19 | Kobaz | if i knew, i would fix it |
| 20:26.28 | Samot | How will we figure that out? |
| 20:26.46 | Kobaz | this is more of a developer discussion anyway |
| 20:26.54 | Samot | Lol. |
| 20:26.55 | Kobaz | you would need to understand the internals of astdb in order to help |
| 20:26.55 | Samot | OK |
| 20:27.11 | Samot | You mean sqllite3? |
| 20:27.44 | Kobaz | astdb |
| 20:27.45 | Kobaz | main/db.c |
| 20:27.57 | Samot | AstDB runs on SQLlite3 |
| 20:28.01 | Kobaz | right |
| 20:28.02 | Samot | That's what it is. |
| 20:28.07 | Kobaz | this isn't an sqlite issue |
| 20:28.13 | Kobaz | this is a mutex lock in astdb |
| 20:28.44 | Samot | https://www.sqlite.org/c3ref/mutex_alloc.html |
| 20:28.47 | Samot | ^^ You mean those? |
| 20:28.50 | Kobaz | no |
| 20:28.58 | Kobaz | i mean this: Waiting for Lock #0 (db.c): MUTEX 308 db_get_common &dblock 0x815460 (1) |
| 20:29.05 | Kobaz | i'm talking about asterisk |
| 20:30.38 | lorsungcu | i thought 1.8 wasn't sqlite |
| 20:30.47 | Kobaz | er, well. i have problems with bolt |
| 20:30.49 | Kobaz | both |
| 20:30.50 | rmudgett | Samot: AstDB used an old berkley db in 1.8. Was switched to sqlite3 in v11 |
| 20:30.52 | Kobaz | 1.8 is still astdb |
| 20:30.59 | lorsungcu | yes but not sqlite |
| 20:32.40 | Kobaz | i fixed the locking problem |
| 20:33.00 | Kobaz | put a 10 attempt trylock in the ast_db functions |
| 20:33.17 | lorsungcu | that is adequately hackish |
| 20:33.18 | lorsungcu | lol |
| 20:33.21 | Kobaz | yes |
| 20:33.22 | Kobaz | haha |
| 20:33.42 | Samot | rmudgett: That's right. I remember berkley in 1.4 |
| 20:34.04 | Samot | I thought sqllite came earlier.. |
| 20:34.18 | Kobaz | nope |
| 20:34.21 | Kobaz | sqlite is new-ish |
| 20:34.34 | Kobaz | some module is stuck loading, can't figure out what |
| 20:35.26 | *** join/#asterisk tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 20:35.26 | Kobaz | console stops at -- Loaded provisioning template 'default' |
| 20:36.35 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 20:37.18 | Kobaz | the only asterisk that's working right now is 11, but with aforementioned quality problems |
| 20:37.20 | *** join/#asterisk pchero (~pchero@109.70.54.56) |
| 20:37.25 | Kobaz | i'm gonna pull trunk and see if that's any better |
| 20:37.54 | lorsungcu | Kobaz: what quality problems? |
| 20:38.17 | jrun | how do i stop chan_sip from offering m=video in sdp negotiations? |
| 20:38.20 | Kobaz | choppy audio, delayed audio |
| 20:38.30 | Kobaz | asterisk running at 300% cpu according to top |
| 20:38.40 | lorsungcu | Kobaz: how many concurrent calls? |
| 20:38.41 | Kobaz | which is insane |
| 20:38.43 | Kobaz | 25 |
| 20:38.44 | lorsungcu | transcoding? |
| 20:38.49 | Kobaz | no transcoding |
| 20:38.49 | lorsungcu | that's not a lot |
| 20:38.58 | lorsungcu | what codec? |
| 20:39.04 | Kobaz | nope. it's not a lot... ulaw |
| 20:39.10 | Kobaz | and doing mixmonitor recording |
| 20:39.22 | lorsungcu | so 25 with mixmonitor or 25 + mixmonitor |
| 20:39.29 | Kobaz | if i map out the threads in asterisk to real processes, i get 3-5% per mixmonitor thread |
| 20:39.39 | Kobaz | 25 with mixmonitor to a ramdisk |
| 20:39.40 | Samot | What type of CPU? |
| 20:39.54 | Kobaz | dual Intel(R) Xeon(R) CPU E31240 @ 3.30GHz |
| 20:40.19 | Samot | Sounds like an I/O problem with the RAMDisk. |
| 20:40.27 | lorsungcu | or any disk |
| 20:40.46 | Samot | DB locks, CPU usage... |
| 20:40.48 | jrun | chan_sip seems to be offering m=video dispite videosupport=no |
| 20:40.49 | Samot | All related. |
| 20:40.58 | Samot | jrun: Which side of the call? |
| 20:41.00 | lorsungcu | jrun: what codecs are you offering |
| 20:41.05 | Kobaz | well, db locks is logic flow |
| 20:41.15 | Kobaz | it's locking and not releasing |
| 20:41.25 | Samot | DB requests are based on I/O |
| 20:41.30 | Kobaz | well, which can be io under the hood, if the lower level op isn't finishing |
| 20:41.35 | lorsungcu | Kobaz: it's locking and not releasing in time |
| 20:41.35 | Samot | It might not be unlocked because of an I/O issue. |
| 20:41.41 | Kobaz | lorsungcu: exactly |
| 20:41.44 | lorsungcu | Kobaz: it is eventually releasing |
| 20:41.50 | Kobaz | Timing buffered disk reads: 1384 MB in 3.00 seconds = 461.33 MB/sec |
| 20:42.02 | jrun | lorsungcu: ulaw |
| 20:42.11 | lorsungcu | jrun: show the invites |
| 20:42.13 | jrun | Samot: inbound |
| 20:42.15 | lorsungcu | ?pb |
| 20:42.18 | Kobaz | io wait is incredibly low, 1-2% |
| 20:42.21 | lorsungcu | whoops lol |
| 20:42.27 | Samot | ~pb |
| 20:42.27 | infobot | pastebin is probably a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few: http://pastebin.ca, http://channels.debian.net/paste, http://paste.lisp.org, http://bin.cakephp.org/; or install pastebinit with yum or aptitude. |
| 20:42.46 | Kobaz | Samot: please stop |
| 20:43.11 | lorsungcu | Kobaz: that was for me :p |
| 20:43.20 | lorsungcu | i think |
| 20:44.29 | Kobaz | so the mixmonitors are chewing like 15-20% cpu, each |
| 20:44.31 | Kobaz | on occasion |
| 20:46.54 | Kobaz | any ideas why mixmonitor cpu usage would be so high? |
| 20:46.58 | Kobaz | (without transcoding) |
| 20:47.10 | Kobaz | i'm going right to sln |
| 20:47.50 | jrun | lorsungcu: INVITES: |
| 20:47.57 | jrun | https://gist.github.com/7171478f824634e046d7f4e3e631043c |
| 20:48.08 | lorsungcu | Kobaz: what's the mixmonitor command you're using that causes it |
| 20:48.24 | Kobaz | MixMonitor(/rec/1497300248.269.sln,b) |
| 20:49.13 | Samot | jrun: That's the Yealink offering video |
| 20:50.03 | Samot | m=video 0 RTP/AVP 97 98 99 110 117 <-- That means port 0 for video media |
| 20:50.04 | lorsungcu | sho nuf |
| 20:50.05 | Samot | No port |
| 20:50.07 | Samot | No video |
| 20:50.28 | Samot | Asterisk is answering back saying "I don't support video" |
| 20:51.04 | jrun | Samot: yealink ACK's that but keeps ringing! |
| 20:51.11 | Kobaz | merging my local 11 branch with the latest 11.25 |
| 20:51.19 | Kobaz | it was based previously on 11.20 |
| 20:51.27 | jrun | Samot: i see. |
| 20:51.42 | jrun | Samot: it happens only on their phones with video cap. |
| 20:51.48 | Samot | Right |
| 20:51.54 | jrun | it works with pjsip though |
| 20:52.01 | Samot | Because video cap = I should be using video |
| 20:52.17 | Samot | You can allow/disallow codecs per driver |
| 20:52.18 | jrun | and the only diff i've seen is the Contact: (between chan_sip and res_pjsip) |
| 20:52.25 | Samot | Are you allowing video in PJSIP? |
| 20:53.21 | jrun | i'm not disabling it... video_support is commented. |
| 20:54.23 | Samot | You need to look at the individual endpoint settings for those phones and make sure they aren't allowed codecs just for them that aren't globally allowed for others. |
| 20:54.41 | Samot | It's the only way those vid cap phones on PJSIP can have video between them. |
| 20:54.53 | Samot | Unless those phones are calling each other directly |
| 20:58.18 | jrun | how do you disable video in pjsip ? |
| 20:58.34 | jrun | i'm looking at pjsip.conf.sample and there is no video_support |
| 21:01.40 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 21:01.49 | Kobaz | lorsungcu: run of the mill..... right |
| 21:02.02 | lorsungcu | yeah ntohing special |
| 21:02.09 | drmessano | Check your RAM |
| 21:02.15 | lorsungcu | yeah thats next |
| 21:02.21 | drmessano | Something is fucky |
| 21:02.26 | lorsungcu | either memtest or just reseat/replace |
| 21:02.34 | lorsungcu | its cheap enough nowadays anyway |
| 21:02.38 | drmessano | Replace it |
| 21:02.54 | Kobaz | ram is happy.. i'm at my normal peak usage and it's a little tight but there's room |
| 21:02.55 | drmessano | Since the need is critical |
| 21:03.00 | drmessano | No dude |
| 21:03.01 | Kobaz | yeah |
| 21:03.13 | Kobaz | not that it couldn't use some more |
| 21:03.15 | lorsungcu | Kobaz: has it done this all along, for years |
| 21:03.18 | lorsungcu | or is this new |
| 21:03.18 | Kobaz | you can always use more ram |
| 21:03.18 | drmessano | Not usage |
| 21:03.27 | drmessano | Replace it |
| 21:03.31 | Kobaz | yeah? |
| 21:03.33 | drmessano | Like, investigate for failure |
| 21:03.40 | Kobaz | memtest... |
| 21:03.51 | lorsungcu | if you have a spare, just replace it and be done |
| 21:03.55 | Kobaz | should throe like 64 gigs in there |
| 21:03.57 | Kobaz | yeah |
| 21:03.57 | drmessano | How much RAM is in the box? |
| 21:03.59 | Kobaz | 8 gigs |
| 21:04.02 | drmessano | HA |
| 21:04.03 | drmessano | Yeah |
| 21:04.05 | lorsungcu | wat |
| 21:04.06 | Kobaz | it was an old install, keep upgrading it here and there |
| 21:04.13 | drmessano | Thats like $10 worth |
| 21:04.17 | Kobaz | i don't have physical access |
| 21:04.17 | drmessano | Put 32GB in there, NEW |
| 21:04.21 | Kobaz | right, yeah |
| 21:04.31 | Kobaz | that's in the plans, need customer approval and all that |
| 21:04.38 | drmessano | Do that next |
| 21:04.47 | lorsungcu | appears you have that, given that they want it resolved.. |
| 21:05.03 | Kobaz | yeah |
| 21:05.06 | Kobaz | i will now |
| 21:05.13 | Kobaz | it wasn't an issue a day ago |
| 21:05.22 | drmessano | Kobaz: and nothing changed? |
| 21:05.25 | Kobaz | nope |
| 21:05.25 | drmessano | and its an older box? |
| 21:05.27 | Kobaz | yeah |
| 21:05.36 | drmessano | Replace+Upgrade the RAM |
| 21:05.38 | Kobaz | i have this problem every so often with various installs |
| 21:05.38 | drmessano | 100% |
| 21:05.45 | Kobaz | asterisk will run fine for *years* |
| 21:05.51 | Kobaz | and then start to mysteriously crash |
| 21:05.57 | drmessano | Youre letting sample bias affect your troubleshooting of this one box |
| 21:06.00 | Kobaz | the last big one was a null pointer in chan_sip |
| 21:06.01 | drmessano | This box is sick |
| 21:06.01 | lorsungcu | normally we blame that on systemd |
| 21:06.15 | Kobaz | yeah my bias is asterisk |
| 21:06.22 | Kobaz | but yeah it could very well be a hardware oddity |
| 21:06.53 | drmessano | Your bias is that "This happens sometimes on other boxes".. This box is giving every indication of a failure |
| 21:07.03 | drmessano | Work it from that angle |
| 21:07.03 | Kobaz | except it's not |
| 21:07.08 | drmessano | Yeah it is |
| 21:07.08 | Kobaz | that's the thing |
| 21:07.17 | drmessano | Thats a performance issue |
| 21:07.25 | drmessano | Sudden, inexplicable |
| 21:07.30 | drmessano | Replace the RAM |
| 21:07.45 | Kobaz | i agree that it should get replaced |
| 21:07.47 | Kobaz | i'm not arguing that |
| 21:07.55 | Kobaz | i'm talking about root case, i think is something else |
| 21:08.18 | Kobaz | 32 gigs would be a nice buffer and all that, sounds great, but what can we do _now_ is the question |
| 21:08.19 | drmessano | heh ok |
| 21:08.27 | drmessano | Nothing |
| 21:08.34 | Kobaz | and maybe the ram is flakey, *but* |
| 21:08.40 | *** join/#asterisk xochilpili (~xochilpil@unaffiliated/xochilpili) |
| 21:08.41 | xochilpili | hi all |
| 21:08.45 | Kobaz | apache's not crashing, postgres is not crashing, ssh is not crashing |
| 21:09.28 | xochilpili | im using a pstn cisco spa3102, and i have configured with asterisk, everything works (out-going and incoming calls) but when i use it for a phone call, disconnects the internet :D |
| 21:09.32 | Kobaz | etc etc etc.... so if the machine is chugging along processing everything it's supposed to, and asterisk is the only thing having a problem.... what do you blame? |
| 21:09.34 | xochilpili | any idea how to fix this? |
| 21:09.46 | Kobaz | do you see the rationalle ? |
| 21:09.48 | drmessano | Kobaz: How many sticks of RAM? |
| 21:09.53 | Kobaz | two, it's ddr |
| 21:10.11 | Samot | How much is allocated to RAMDisk? |
| 21:10.31 | Kobaz | recording ramdisk, 750 megs |
| 21:10.36 | Kobaz | at most, it's about 10% used |
| 21:10.45 | Samot | But it's on one stick? |
| 21:10.56 | Kobaz | astdb ramdisk, 100 megs, but that thing is tiny, it's like 2MB |
| 21:11.09 | Samot | And that portion of the stick is used just as a HD |
| 21:11.15 | Samot | Not for memory processes... |
| 21:11.16 | Kobaz | i don't have any stick affinity assigned to the ramdisk |
| 21:11.20 | drmessano | Ok, and you can't possibly fathom, whatsover, a degradation in one of those sticks, even partial, causing failures that are only seen in the one application that's basically the most sensitive to that sort of problem, which is your RAMDisk? |
| 21:11.20 | Samot | OK |
| 21:11.26 | Kobaz | i'm not sure if you can in linux |
| 21:11.37 | Kobaz | that would be interesting to look into |
| 21:11.55 | drmessano | Obviously you're not a hardware guy. I get that |
| 21:12.01 | Samot | Asterisk is having lock errors with the DB |
| 21:12.03 | Kobaz | drmessano: i can fatham... anything is possible.... but i think more likly it's software |
| 21:12.06 | drmessano | But you need to stop trying to patch around a hardware problem |
| 21:12.14 | Samot | That resides on your RAMDisk. |
| 21:12.26 | drmessano | Kobaz: I completely disagree with your rationale |
| 21:12.38 | Samot | If your RAM is bad/dying then it's going to cause I/O issues with RAMDisk |
| 21:12.41 | drmessano | This sounds like wishful thinking, and I don't understand why |
| 21:12.43 | Kobaz | Samot: true |
| 21:12.52 | Samot | Even non-Asterisk stuff could impact it. |
| 21:13.01 | drmessano | Swap the RAM.. It's fucking cheap. This is a waste of time |
| 21:13.02 | Kobaz | drmessano: it's not wishful, i'm putting the pieces together... a is happing, c, d, d, e are not |
| 21:13.04 | Samot | If the memory is bad and leaking it over to the RAMDisk. |
| 21:13.17 | Kobaz | drmessano: it's a 3 hour drive, it's not getting swapped today |
| 21:13.25 | drmessano | Kobaz: Then its not getting fixed today |
| 21:13.33 | Kobaz | could very well be |
| 21:14.40 | Kobaz | so, just curious |
| 21:14.55 | Kobaz | drmessano: what would be your explanation of bad ram causing mixmonitor to spike in cpu usage |
| 21:15.00 | Kobaz | drmessano: on multiple machines |
| 21:15.21 | Samot | That's two different things. |
| 21:15.25 | Kobaz | did the ram go bad in two (different build) machines, 500 miles apart from each other? |
| 21:15.28 | Kobaz | that's the thing i don't get |
| 21:15.44 | Samot | Is the other machine having the DB lock ups? |
| 21:15.45 | Kobaz | i've seen this exact issue before on another box, where we were unable to upgrade to asterisk-11 due to this cpu spike |
| 21:15.52 | Kobaz | yeah, all the same issues |
| 21:15.55 | Kobaz | but this was a while ago |
| 21:16.00 | Kobaz | i dont remember all the details |
| 21:16.04 | file | that's incorrect wording |
| 21:16.08 | Samot | So it's not happening now. |
| 21:16.13 | file | all the same symptoms, but does not necessarily mean same issues |
| 21:16.16 | Kobaz | right |
| 21:16.18 | Samot | So this just different happen on two machines at once. |
| 21:16.24 | Kobaz | which is why i'm in interested in root cause |
| 21:16.32 | Samot | How did you fix the other machine? |
| 21:16.38 | Kobaz | roll back to 1.8 |
| 21:16.51 | Samot | What was that machine running? |
| 21:16.58 | Kobaz | while we work on migrating our platform to something newer |
| 21:17.09 | Kobaz | it was running 1.8.12 for the longest time |
| 21:17.14 | Samot | No. |
| 21:17.16 | Samot | RAM/CPU |
| 21:17.21 | Samot | Actual resources.. |
| 21:18.14 | Kobaz | oh, the other box Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz. 8 gigs of ram |
| 21:18.36 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 21:19.02 | Kobaz | obviously not top of the line, but was pretty decent 6 years ago |
| 21:19.21 | Kobaz | and this box handles like maybe max 12 concurrent calls |
| 21:19.37 | Kobaz | it's not like these things are 1000 call clusters or anything |
| 21:20.25 | Kobaz | yes, these sites need better hardware |
| 21:21.25 | Samot | Sounds like underperforming and/or failing hardware in these cases. |
| 21:21.34 | Kobaz | underperforming i would agree |
| 21:21.40 | Kobaz | failing... no, not yet with the information i have so far |
| 21:21.45 | Samot | Oh this current box is sick and failing |
| 21:21.54 | Samot | You just haven't accepted it. |
| 21:22.01 | Samot | The RAM needs to be replaced. |
| 21:22.18 | Samot | Not should be, needs to be. |
| 21:22.25 | Kobaz | so what happens when i put a new machine in, switch to asterisk-11 and mixmonitor uses 15% cpu on a single channel |
| 21:23.02 | Samot | I don't know. I haven't run into that problem. |
| 21:23.13 | Kobaz | i'm giving it the benefit of the doubt that yes it could very well be a hardware problem |
| 21:23.19 | Kobaz | but all of my experience points to otherwise |
| 21:23.25 | Samot | I'm running VMs with 2 vCPU and 4GB RAM recording calls... |
| 21:23.39 | Kobaz | i've seen this time and time again with long running systems, the *use case* changes |
| 21:23.40 | Samot | Probably about 5-6 calls recording with another 15 happening... |
| 21:23.46 | Kobaz | and then bad things start happening |
| 21:24.17 | Kobaz | the crash i found with chan_sip... basically the customer had l2 networking problems... one of their core switches was on half dupluex and was dropping packets like mad |
| 21:24.39 | file | have you, I dunno, done any dd tests against the ramdisk? |
| 21:24.51 | Kobaz | the dropped packets caused a different envionment for asterisk, and the usage-flow changed, and all of a sudden asterisk was handling packets it wasn't coded to handle in that fashion |
| 21:25.16 | Kobaz | a few days of debugging found a problem in chan_sip |
| 21:25.20 | Samot | Wait.. |
| 21:25.27 | Samot | So their network shit the bed.. |
| 21:25.27 | Kobaz | i know this is specific, and anecdotal |
| 21:25.34 | Samot | Sent stuff to Asterisk it shouldn't |
| 21:25.40 | Kobaz | right |
| 21:25.43 | Kobaz | and asterisk shat the bed |
| 21:25.44 | Samot | But some how it was Chan_SIP's fault? |
| 21:25.51 | Kobaz | right |
| 21:25.53 | Kobaz | chan_sip shouldn' |
| 21:25.53 | Samot | OK |
| 21:26.00 | Kobaz | t crash if you throw something bad at it |
| 21:26.07 | Kobaz | that's DoS basically, security problems |
| 21:26.24 | Kobaz | i dont remember offhand the issue #, but it was fixed |
| 21:26.27 | Samot | You also shouldn't DoS your own systems within your network. |
| 21:26.46 | Kobaz | just saying... every single random issue i've found, that causes a) crashes, b) performance problems, c) crazy shit |
| 21:26.49 | *** join/#asterisk skywayskase (~skywayska@67.139.42.219) |
| 21:26.50 | Kobaz | so far has been 100% software |
| 21:26.56 | Samot | All Asterisk? |
| 21:26.59 | Kobaz | all asterisk |
| 21:27.01 | Samot | All the time over the years? |
| 21:27.05 | Samot | So why do you still use it? |
| 21:27.20 | Samot | If every problem you have is Asterisk based, why are you still running it? |
| 21:27.27 | Kobaz | because i love the platform, and when i hit a bug, i work on getting it fixed. or checking if someone already fixed it, and move on |
| 21:28.00 | file | whistles |
| 21:28.24 | Kobaz | Samot: you know i'm being over generaizing with 'all asterisk'... I'm saying *voip* issues, and where asterisk crashes.... has been asterisk related, of course |
| 21:28.34 | Samot | So when a network DoS's it's own Asterisk server, the answer is "fix Asterisk" not "fix the network"? |
| 21:28.39 | Kobaz | generalizing... |
| 21:28.45 | Kobaz | Samot: right exactly |
| 21:28.54 | drmessano | I dont mean to interrupt |
| 21:28.55 | drmessano | But |
| 21:28.57 | drmessano | 17:24:40 <@file> have you, I dunno, done any dd tests against the ramdisk? |
| 21:28.59 | Kobaz | Samot: asterisk should be able to not crash when it gets a malformed packet, just like apache |
| 21:29.06 | Kobaz | file: not yet... going to do that |
| 21:29.10 | Kobaz | drmessano: ^ |
| 21:29.17 | Samot | Well as you are talking about "finding root causes" |
| 21:29.28 | Samot | You should apply that to networks that DoS themselves. |
| 21:29.33 | Samot | And cause all other issues. |
| 21:29.37 | Kobaz | right |
| 21:29.39 | drmessano | Samot: Stop Please |
| 21:29.41 | Kobaz | 'other' issues asside |
| 21:29.44 | drmessano | Lets check this RAMDISK |
| 21:29.53 | drmessano | We can bitch about how Asterisk sucks later |
| 21:30.00 | drmessano | Theres plenty of time for that |
| 21:30.00 | Kobaz | do you agree, that asterisk should not crash, when getting a malformed packet |
| 21:30.03 | Kobaz | haha |
| 21:30.04 | Kobaz | okay okay |
| 21:30.06 | Kobaz | i'm dding |
| 21:30.17 | *** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme) |
| 21:30.51 | Samot | drmessano: Sorry. I know, priorities. |
| 21:31.28 | Kobaz | dd if=/dev/zero of=/rec/test bs=1M count=50... 52428800 bytes (52 MB) copied, 0.0159417 s, 3.3 GB/s |
| 21:31.48 | Kobaz | i'm gonna do some writes and checksums with generated files as well |
| 21:32.01 | file | that's not a very large file |
| 21:32.51 | drmessano | 52MB? I echo files larger than that from the cli |
| 21:34.13 | Kobaz | https://pastebin.com/xGg7vx3w |
| 21:34.14 | Kobaz | more testing |
| 21:34.35 | Kobaz | missed pasting in test3, same sum |
| 21:42.24 | *** join/#asterisk xochilpili (~xochilpil@unaffiliated/xochilpili) |
| 21:42.51 | xochilpili | im using a pstn cisco spa3102, and i have configured with asterisk, everything works (out-going and incoming calls) but when i use it for a phone call, disconnects the internet |
| 21:43.05 | xochilpili | any idea how to fix this? |
| 21:43.21 | Kobaz | drmessano: https://pastebin.com/7VSXETvb |
| 21:46.45 | drmessano | Sure, thats a function test and not a load test, though |
| 21:47.03 | Kobaz | right |
| 21:47.09 | Kobaz | but it's at least some sanity |
| 21:47.29 | drmessano | Not really.. it just means you don't have a catastrophic RAM failure |
| 21:47.33 | drmessano | those are rare |
| 21:47.39 | Kobaz | which is some sanity... |
| 21:47.56 | drmessano | How many boxes do you admin? |
| 21:48.36 | Kobaz | about two dozen |
| 21:48.37 | drmessano | Have you ever heard of the concept of pet vs cattle? |
| 21:49.03 | Kobaz | not specifically, but i can gather the meaning |
| 21:49.10 | drmessano | Ok, do tell |
| 21:50.02 | Kobaz | tendering something with special attention, versus treating a mass quantity as a unit |
| 21:50.55 | Kobaz | so, i had stress running 4 hdd hogs spinning on 250 meg files on the ramdisk with no noticable performance problems in asterisk that i can see |
| 21:52.57 | drmessano | In this case, we're talking more about the diminishing return of focused effort. Obviously somethin has failed. Start with a RAM upgrade/swap. If you want to waste your time running a 24 hour memtest on it later, go for it. Right now running small batches of basic tests are only exposing the obvious, that the box is still up and running to some extent. |
| 21:54.07 | Kobaz | right |
| 21:54.37 | Kobaz | well there's not much i can do at the moment |
| 21:54.56 | *** join/#asterisk Samael28 (~Samael28@176.104.56.91) |
| 21:54.57 | Kobaz | need to wait for some dialer calls to finish and then i can switch to my new build of asterisk-11 and do some load testing |
| 22:22.31 | Kobaz | i finally rebuilt without DONT_OPTIMIZE |
| 22:22.48 | Kobaz | haven't had a legit crash in a long time |
| 22:31.22 | *** join/#asterisk imcdona (~imcdona@2607:f0d8:20:1001:94fe:2a00:16b0:7ff2) |
| 22:44.19 | Kobaz | down to 8 calls, and 40% cpu |
| 22:58.01 | *** join/#asterisk Katty (uid62315@gateway/web/irccloud.com/x-rummgtfywavwuqdr) |
| 23:29.30 | *** part/#asterisk kharwell (kharwell@nat/digium/x-lapcfzujaqrkkuup) |
| 23:31.55 | *** join/#asterisk newtonr (RustyNewto@nat/digium/x-cpkkpcigljdqruut) |
| 23:31.55 | *** mode/#asterisk [+o newtonr] by ChanServ |
| 23:51.42 | *** join/#asterisk semitangent_ (b85acdb8@gateway/web/freenode/ip.184.90.205.184) |
| 23:57.49 | semitangent_ | I am seeing things like 'or''=' in my CDR reports or a number followed by 'or''=' or âhi'orâxâ='x' in my call sources. Is there anything I can do about this? |