IRC log for #asterisk on 20210515

00:05.28*** join/#asterisk akp55 (~akp55@pool-71-115-0-190.rcmdva.fios.verizon.net)
00:36.57*** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net)
01:16.28*** join/#asterisk silverwhitefish (~hidden@47.203.212.155)
01:52.07*** join/#asterisk Enitin (enitin@gateway/vpn/privateinternetaccess/enitin)
01:52.27*** join/#asterisk tsal (~tsal@i59F4D8CC.versanet.de)
01:54.25*** join/#asterisk mr44er1 (~mr44er@dynamic-046-114-003-254.46.114.pool.telefonica.de)
01:59.08*** join/#asterisk akp55 (~akp55@pool-71-115-0-190.rcmdva.fios.verizon.net)
03:03.11*** join/#asterisk infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net)
03:03.11*** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 18.4.0, 16.18.0 (2021/05/06) Final Bugfix: 13.38.2, 17.9.3 (2021/03/04); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22
03:44.36*** join/#asterisk ghoti (~paul@dsl-rb-64-118-20-57.wtccommunications.ca)
05:07.08*** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54)
05:12.21*** join/#asterisk pppingme (~pppingme@unaffiliated/pppingme)
06:19.10*** join/#asterisk akp55 (~akp55@pool-71-115-0-190.rcmdva.fios.verizon.net)
06:21.50*** join/#asterisk Ravenheart (Ravenheart@95-43-79-254.ip.btc-net.bg)
06:38.01*** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm9050cadd5190.cpe.net.cable.rogers.com)
06:52.36*** join/#asterisk thansen (~thansen@192.74.130.86)
10:21.04*** join/#asterisk akp55 (~akp55@pool-71-115-0-190.rcmdva.fios.verizon.net)
11:26.56*** join/#asterisk tsal (~tsal@i59F4A05F.versanet.de)
11:35.13*** join/#asterisk HannaM (~quassel@p54849510.dip0.t-ipconnect.de)
11:43.40*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
12:00.52*** join/#asterisk andrewyager (~andrewyag@114.141.97.1)
12:51.15*** part/#asterisk ldm (~ldm@hacksoc/member)
13:27.25*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
13:33.24*** join/#asterisk mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak)
13:46.59*** join/#asterisk Bullit (~Bullit01@042-236-158-163.dynamic.caiway.nl)
14:06.38*** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net)
14:44.04*** join/#asterisk rpifan_ (~rpifan@p200300d2670b9500bf2835dac112de5e.dip0.t-ipconnect.de)
15:23.43*** join/#asterisk jayjo (~jayjo@unaffiliated/jayjo)
15:42.45*** join/#asterisk akp55 (~akp55@pool-71-115-0-190.rcmdva.fios.verizon.net)
15:52.00*** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm9050cadd5190.cpe.net.cable.rogers.com)
16:03.36*** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm9050cadd5190.cpe.net.cable.rogers.com)
16:13.32*** join/#asterisk chitholian (~chitholia@2400:ca03:f065:c0b0::70b)
16:14.30chitholianhello
16:26.33*** join/#asterisk lankanmon (~LKNnet@cpeb4fbe4e331bd-cm9050cadd5190.cpe.net.cable.rogers.com)
16:35.03*** join/#asterisk _0x5eb_ (~seb@69.63.121.78.rev.sfr.net)
16:40.32*** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at)
16:41.37chitholianHow can I handle 600 concurrent calls with 22.8GHz (6 x 3.8GHz) server (12 vCPUs) with g729 pass-thru mode ? Currently I am running 100 calls (200 channels) with PJSIP Asterisk 18.2.0, It consumes 35% CPU (7.9GHz out of 22.8GHz).
16:42.45BullitOver the last couple of W we have heard so much about you astrix and I cant make you rotate your inability to have 100-200 contained transistorvibrationsensors seems to be related to previous topics with 220+ reactions
16:43.22sibiriachitholian: then you are clearly transcoding
16:43.27chitholianI need to create at least 4 VPS in the 3.8 GHz 6 CPU Xeon machine (VMWare ESXi) each running at least 150 concurrent calls.
16:43.41sibiriawith just passthrough even a Raspberry Pi can manage over 100 calls
16:44.34BullitNoble al White
16:44.40chitholianBut how can I know if asterisk is transcoding ? I only allowed g729 and g723 and all INVITE have both codecs ?
16:44.42BullitMaersk Resolute
16:44.48sibiriamy test platform is a Pine64 with 1GB RAM - roughly as powerful as the old RPi 3 - and it can manage about 150 calls without transcoding channels
16:45.31BullitTechTalk Scatter OR Alice and Bob
16:45.40BullitVos Tracker
16:45.42igcewielingpjsip show channelstats should show you the codecs of the channels at least
16:45.43BullitVos Trapper
16:45.47BullitVos Trader
16:46.02sibiriawhy are you using g.729 and g.723 by the way?
16:46.07igcewielingHmm.  we appear to have a troll.
16:46.14sibiriaare you terribly bandwidth-constrained?
16:46.17Bullitis that the standard for the amount of electrical interference over coms
16:46.24Bullitwhat length are you expecting
16:47.52Bullitasteri><? respond asterisk* we don´t have this problem in the relation between the amount of consultants to a job in the harbor but the problem in satelite management teams kicking off before actually starting
16:48.23chitholiansibiria: Using g729 and g723 are used becaused only these are allowed in my termination (outgoing) trunks.
16:49.41chitholian"pjsip show channelstats" shows all channel using g729
16:51.39sibiriareally, only g729 and g723... seems like an odd VoIP provider
16:51.54sibiriaboth of those codecs are, well, terrible
16:52.38chitholianBut, does codec matters in pass-thru mode ?
16:53.47sibiriaif you do nothing but pass audio frames between two ends then no
16:53.52sibiriabut that's not what's happening here
16:54.03chitholianHere is my dialplan.
16:54.08chitholian[general]
16:54.09chitholianstatic=yes
16:54.11chitholianwriteprotect=no
16:54.12chitholianautofallthrough=yes
16:54.13chitholianclearglobalvars=no
16:54.15chitholian[globals]
16:54.17chitholian[dialer]
16:54.18chitholianexten => _X.,1,Goto(f1context,${EXTEN},1)
16:54.19sibiriano...
16:54.20chitholian[f1context]
16:54.21chitholianexten => _X.,1,NoOp(${CALLER_USERNAME} from ${CHANNEL(pjsip,remote_addr)})
16:54.22chitholian<PROTECTED>
16:54.24chitholian<PROTECTED>
16:54.26chitholian<PROTECTED>
16:54.27chitholian<PROTECTED>
16:54.28chitholian<PROTECTED>
16:54.30chitholian<PROTECTED>
16:54.32chitholianexten => h,1,AGI(agi://127.0.0.1/cdr.php,${CDR(uniqueid)})
16:54.33chitholian[answer]
16:54.34chitholianexten => s,1,Set(theCallID=${ARG1})
16:54.36chitholian<PROTECTED>
16:54.38chitholian<PROTECTED>
16:57.32chitholianNo other process (mysql, fast-agi) consumes too much CPU as asterisk.
16:58.09sibiriainspect the SDP of both ends when establishing a call, and enable full logging with debug info, to see if asterisk is letting you know something about the transcoding
16:58.54chitholianCondition goes worse when call per second increases (e.g. 8-10 CPS) although most of the calls get CONGESTION dial status. Only around 100 calls are active at a time.
17:00.28sibiriafor fastagi, are you using some sort of "slow agi" wrapper?
17:00.35sibiriabecause PHP is incredibly slow at starting up
17:01.04sibiriahow is the fastagi listener invoking those PHP scripts?
17:05.14chitholianWith xientd
17:05.17chitholianservice fastagi
17:05.18chitholian{
17:05.20chitholian<PROTECTED>
17:05.21chitholian<PROTECTED>
17:05.23chitholian<PROTECTED>
17:05.25chitholian<PROTECTED>
17:05.26chitholian<PROTECTED>
17:05.28chitholian<PROTECTED>
17:05.29chitholian<PROTECTED>
17:05.30chitholian<PROTECTED>
17:05.32chitholian<PROTECTED>
17:05.33chitholian<PROTECTED>
17:05.35chitholian<PROTECTED>
17:05.36chitholian}
17:07.39chitholianIf AGI (php program) is slow will the slowness go to asterisk ? Shouldn't it go to xinetd or PHP ?
17:10.53chitholianIf asterisk is consuming more CPU for blocking FastAGI will AMI (async AGI) or ARI client solve the problem ?
17:18.36sibiriaproper fastagi would solve the problem - or slowagi with a faster interpreter like lua or perl
17:18.56sibiriaphp, just like python, takes a very long time to start up. they're bad choices for slowagi applications
17:19.28sibiriabut i'd start with looking at the SDP of all the call legs first, and debug info from the log
17:28.22*** join/#asterisk chithol97 (~Android@2400:ca03:f065:c0b0:dd0a:c803:ceb2:ad6f)
17:30.28chithol97Is there any difference (as CPU usage) Between FastAGI and Async AGI?
18:06.08*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
18:18.17*** join/#asterisk rpifan (~rpifan@p200300d2670b950003e715f232381e72.dip0.t-ipconnect.de)
18:20.21*** join/#asterisk silverwhitefish (~hidden@47.203.212.155)
18:24.41*** join/#asterisk InterLinked (~ambassado@cpe-24-209-155-151.wi.res.rr.com)
18:29.36InterLinkedIs there a debugging method that allows tracing the code up to/through a crash in an easily readable way? I dumped the core but when I open up core-full.txt, I don't even see any mention of the function file that caused the crash. I'm getting constantly changing stuff, like smallbin double linked list corrupted, then a seg fault next time, and so on. Thanks!
18:30.16InterLinkedI have some ast_logs in my code to try to follow along with print statements, but that isn't getting me terribly far.
18:48.18*** join/#asterisk sinaowolabi (~Sina@160.152.55.235)
19:29.36*** join/#asterisk akp55 (~akp55@pool-71-115-0-190.rcmdva.fios.verizon.net)
20:20.25*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
20:47.14*** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt)
21:22.45*** join/#asterisk infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net)
21:22.45*** topic/#asterisk is #asterisk The Open Source PBX and Telephony Platform (asterisk.org) -=- LTS: 18.4.0, 16.18.0 (2021/05/06) Final Bugfix: 13.38.2, 17.9.3 (2021/03/04); DAHDI: 3.0.0 (2018/11/15); libpri 1.6.0 (2017/01/27) -=- Wiki: wiki.asterisk.org -=- Code of Conduct: bit.ly/1hH6P22
22:00.37*** join/#asterisk sinaowolabi (~Sina@160.152.55.235)
22:01.43*** join/#asterisk andrewya_ (~andrewyag@114.141.97.1)
22:09.10*** join/#asterisk Typhon (~Typhon@dslb-088-067-143-148.088.067.pools.vodafone-ip.de)
22:40.46*** join/#asterisk markong (~markong@37.120.141.114)
23:31.27*** join/#asterisk akp55 (~akp55@pool-71-115-0-190.rcmdva.fios.verizon.net)
23:38.47*** join/#asterisk pchero (~pchero@211.178.226.108)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.