IRC log for #asterisk on 20210420

00:38.38*** join/#asterisk forgotmynick (uid24625@gateway/web/irccloud.com/x-zrveaxymxvlgkvhx)
01:16.32*** join/#asterisk tsal (~tsal@i59F4A786.versanet.de)
01:41.30*** join/#asterisk cptmorgan (~smorgan@c-71-205-175-34.hsd1.co.comcast.net)
01:43.50cptmorganis it possible to setup the voicemail for a phone number as a different phone numbers mailbox? basically want to share the same voicemail for two phone numbers
01:53.27SamotSure, you're just pointing to the mailbox in the dialplan anyways.
02:16.52*** join/#asterisk mr44er1 (~mr44er@x527162e8.dyn.telefonica.de)
02:43.50*** join/#asterisk guerby (~guerby@april/board/guerby)
02:50.55*** join/#asterisk aness (~aness@2a02:fe1:3103:b800:a16f:47d:5390:55f3)
02:52.17igcewielingcptmorgan: "core show application voicemail"
02:52.30cptmorganSamot: not as an extension. I want two different numbers to ring but both numbers go to the same mailbox
02:53.29Samotcptmorgan: I understood. What I said holds true.
02:53.52Samotcptmorgan: You can send calls from both numbers to the same mailbox
02:55.40cptmorganSamot: can you point me to some documentation? im new to asterisk and took over managing a office with an old asterisk server
02:57.46Samotwiki.asterisk.org
02:58.38Samothttps://github.com/asterisk/asterisk/tree/master/configs/samples
03:04.01cptmorganexten => 1234567890,1,Voicemail(u${different_voicemail}) ? something like this
03:09.11SamotWell the u option comes after.
03:10.20*** join/#asterisk opal (~wowaname@volatile/founder/wowaname)
03:30.49cptmorganthis looks like really old version of asterisk. im seeing an old config in here that show exten => 1234567890,1,Voicemail(u123456780). Is that older syntax or something? version 1.6.2.24 :/
03:34.29SamotOh man. 1.6 is beyond old and unsupported.
03:34.54drmessanoOnly like 12 years old or so
03:40.03SamotSo old that I would have to refresh on things.
03:42.05drmessanoSo old, I told it to act its age and it segfaulted
03:42.35cptmorganthis old config has multiple sections. does it matter what section this is in? i could technically put this under [default] and it would be used? they have multiple sections under default.
03:43.16SamotThis is real honest advice...
03:44.02SamotAs they manager of this office, manage yourself an Asterisk person.
03:44.14SamotIt will save you a lot of headache.
03:44.46cptmorganfuck, i got reading to do. thanks for the direction :)
03:45.24SamotThat version of Asterisk is really unsupported.
03:45.38SamotAnd wasn't 1.6.2 kinda buggy?
03:46.28SamotI mean if I recall, we skipped all of 1.6.x
03:52.47*** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br)
04:09.52cptmorganSamot: well its been running for 11 years without a hitch :/
04:11.34cptmorganSamot: can you help me with one last thing? do i need to create a section for the peer the call is coming from? like [peer_name] and have the dialplan under that?
04:24.19*** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos)
04:48.51*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
04:52.18*** join/#asterisk mr44er1 (~mr44er@x527162e8.dyn.telefonica.de)
05:31.16*** join/#asterisk Janos (~textual@201.204.94.76)
05:47.02*** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net)
07:03.33*** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54)
07:20.57*** join/#asterisk jkroon (~jkroon@165.16.204.109)
07:25.53*** join/#asterisk THECobra (a2ffe1fe@vpn01.dfw02.servax.net)
07:31.16*** join/#asterisk Dovid (~dovid@213.207.159.187)
07:37.53*** join/#asterisk Dovid (~dovid@216.66.65.171)
08:33.32*** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt)
08:51.21*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
09:28.14*** join/#asterisk HannaM (~quassel@p54849510.dip0.t-ipconnect.de)
09:31.31*** join/#asterisk sinaowolabi (~Sina@105.112.148.28)
09:33.51*** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net)
09:43.52*** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos)
09:59.44*** join/#asterisk sinaowolabi (~Sina@105.112.148.28)
10:00.55*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
10:06.59*** join/#asterisk Milos (~Milos@pdpc/supporter/student/milos)
11:11.38*** join/#asterisk altker128 (~vr@107-142-158-219.lightspeed.sndgca.sbcglobal.net)
11:12.04altker128Hey guys.  I the "97 to access voicemail "standard" Asterisk or is this something FreePBX inserted into a dial plan?
11:12.10altker128*is the
11:13.04filethere is no standard, it's completely up to the configured dialplan - which would be FreePBX
11:15.07altker128From the Asterisk CLI how would I see whatever special *xx codes might be defined?
11:15.14altker128Would it show up in show dialplan ?
11:15.44fileyes.
11:31.27*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
11:35.05sibiriawhen issuing 'core stop when convenient', asterisk will eventually stop waiting for calls to finish and just return with exit code 0 without terminating the main asterisk instance
11:35.14sibiriais there a way to control this behavior?
11:37.34sibiriaand once it gives up, the main asterisk instance seems to forget what it was told to do
11:37.48sibiria(new calls can again start up)
11:39.58sibiriaonce it has given up, re-issuing 'core stop when convenient' will return instantly with exit code 0. none of the waiting that happens the first time
11:40.15sibiriaas if the state is pending and lingering somewhere, despite not having any effect
11:45.55sibiriasorry, i mean "gracefully"
11:55.22filewhen convenient doesn't stop new calls
11:55.30filegracefully stops new calls
11:58.10*** join/#asterisk sinaowolabi (~Sina@105.112.148.28)
12:08.27*** join/#asterisk AsteriskRoss (~AsteriskR@37.157.48.2)
13:00.02*** join/#asterisk Dovid (~dovid@213.207.159.187)
13:03.30igcewielingany idea what might cause this? [2021-04-20 08:45:46] WARNING[6274]: db.c:304 db_execute_sql: Error executing SQL (COMMIT): database is locked
13:03.48SamotYour database is locked.
13:03.57igcewielingWhere is the key?
13:04.04SamotGo look at the database.
13:04.37igcewielingThey are pretty.  astdb.sqlite3
13:04.53igcewielingassuming that IS the database they are talking about.
13:05.31SamotI don't know. What was being done when that happened?
13:05.50igcewielingthe most recent is playing voicemail
13:06.47sibiriasqlite is not write-concurrent between separate processes. if you're doing any of this for example in AGI scripts then you'll face this problem
13:07.04sibiria(assuming plenty of write access)
13:07.05SamotWell I'm guessing your sqlite db is messed up.
13:10.38nbjoergand read-concurrent only if it is WAL-mode
13:12.13*** join/#asterisk waldo323 (~waldo323@d149-67-45-83.clv.wideopenwest.com)
13:12.42sibiriafor reads-only it is always fully concurrent across any number of processes, but WAL provides concurrency for processes that only read while another process is writing
13:13.36sibiriait's overall a better operational mode
13:14.32Samotigcewieling: you can try copying it to a backup. Thst will remove the lock.
13:14.47SamotThe try copying it back over.
13:14.54SamotThen*
13:19.33igcewielingI stopped freepbx, copied astdb.sqlite3, deleted the original, then copied the copy to the original name, started freepbx
13:19.46*** join/#asterisk overyander (~overyande@216.163.21.11)
13:22.06SamotMight need two restarts. Is it working?
13:24.19*** join/#asterisk Dovid (~dovid@216.66.65.171)
13:24.50igcewielingat this point, I'll have to wait until they complain.   too many active calls now.
13:29.07sibiriayou can try enable WAL on the database
13:29.31sibiriait's a permanent change that will be reflected onto each process accessing it
13:31.09SamotWell
13:31.17SamotAre you seeing lockup errors in the logs?
13:31.23SamotI mean, you did check that right?
13:32.26seanbrightastdb has some known performance problems, so if anyone wanted to take a shot at fixing them, that would be great
13:32.37seanbrightpatches welcome, as the kids are saying
13:34.45igcewielingI've never head of WAL
13:35.01igcewielingI'm using freepbx.  I'm not doing anything.
13:36.05sibiriayou don't have to alter the application for it. it's a setting in the sqlite db file itself
13:36.31sibiriahttps://sqlite.org/wal.html
13:38.22igcewielingwhile there were no active calls, I dumped the databsse, deleted the original and recreated the db from the backup
13:38.46SamotAnd are the lock errors gone?
13:39.56igcewielingthat did not work at all.
13:40.23SamotWell I said it could take up to two restarts.
13:40.38SamotSo you're still getting the lock errors?
13:41.52igcewielingSorry, I just fixed the "astdb is not a databse" error which was caused by the databsse I created by the restore.
13:42.01igcewielingnow I'm waiting for lock errors
13:43.16igcewielingno errors so far, but no more calls yet
13:44.06sibiriais there a journal file stuck there?
13:44.06igcewielingA call came in and no error so far.
13:44.18sibiriai.e. a file with -journal suffix
13:44.19igcewielingsibiria: what might such a file be named?
13:44.28igcewielingnope
13:44.42*** join/#asterisk AsteriskRoss (~AsteriskR@37.157.48.2)
13:46.12igcewielingstill no more errors
13:56.08*** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net)
14:04.14igcewielingSamot: why two restarts?  Does asterisk only fix the issue half way on the first startup?
14:04.53SamotHonestly, I really don't know. Not something I have to deal with a lot so I just did some quick googling.
14:05.38igcewieling*nod* I've never seen any issues with astdb on FreePBX since the switch to sqlite.
14:08.23*** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-aklqvuzruzrtielh)
14:08.23*** mode/#asterisk [+o kharwell] by ChanServ
14:15.08sibiriashutting down asterisk and anything else that may hold a file lock - and removing eventual journal/wal files relating to the astdb file - is all that it takes
14:17.59nbjoergyou shouldn't remove journal/wal files
14:18.07nbjoergthat in fact can corrupt the database
14:18.41*** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-ncqykxmsohwyxsww)
14:18.41*** mode/#asterisk [+o bford] by ChanServ
14:20.21*** join/#asterisk sinaowolabi (~Sina@105.112.148.28)
14:33.57sibiriacan happen only with a hot journal if sqlite crashes or is killed in the middle of it
14:34.18sibiriabut that is a risk nevertheless
14:35.14sibiriacorrupt data in the wal/journal, which sqlite will try to "replay" and then corrupt the db, is a bigger risk
14:35.43sibiriavery tiny risk, but the technical possibility is there
14:36.10nbjoergsibiria: if you remove the wal it will not be able to correctly rollback the pending transactions
14:36.38SamotWell, it could just be me but I have had astdb mess up more in pure Asterisk than FreePBX
14:36.41nbjoergthat's a much higher chance of data corruption than a process writing to the db writing garbage
14:37.19sibiriait goes without saying that you should never fiddle with the wal/journal files while something is operating on the db file
14:37.48nbjoergthe way to clean it up would be using the sqlite cli
14:38.19*** part/#asterisk TehRabbitt (~TehRabbit@unaffiliated/tehrabbitt)
14:52.01igcewielingSamot: I don't really use astdb on non-freepbx boxes.
14:52.44SamotYou sure?
14:54.40igcewielingI have 2 entries on "database show".   One for pbx/UUID and my single registered device.    All other devices are static IPs and don't register.
14:54.52igcewielingso, yes, I'm sure.
14:55.16SamotWell I say that because it's what is used by Asterisk.
14:55.25SamotSo sure, you have a very minimal install.
15:00.09igcewielingMy vanilla Asterisk boxes just route calls.
15:00.56*** join/#asterisk Janos (~textual@201.204.94.76)
15:03.06*** join/#asterisk eXistenZ (~pectic@bzq-79-177-145-229.red.bezeqint.net)
15:56.06*** join/#asterisk Janos (~textual@201.204.94.76)
16:00.51*** join/#asterisk djhankb (~djhankb@208.113.164.68)
16:12.14*** join/#asterisk THECobra (a2ffe1fe@vpn01.dfw02.servax.net)
16:12.58*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
16:28.43*** join/#asterisk life_of_e (~life_of_e@108-95-189-245.lightspeed.irvnca.sbcglobal.net)
16:36.37*** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br)
16:58.07*** join/#asterisk sinaowolabi (~Sina@41.190.30.15)
17:11.46THECobrahaving an issue with an AGI script dialing a new call, the flow is - agi calls number1 and then we set some vars in the dialplan and then make an agi call to initialize the call within our system and then that same AGI script makes a second call to number2 when the call is answered it destroys the second call and sends it to the bridge which in
17:11.46THECobraturn invokes the channel hangup. The problem i am facing is i need to follow calls2 to the real hangup and then return the total call time variable this was a change within asterisk around version 11/12 this works as it is in 1.6 but not in 16 due to the change
17:12.15THECobradoes anyone have any ideas on how to implement this so that i can see the totalcall time for call2
17:16.15SamotI've read that three times and I'm still a bit lost.
17:16.35igcewielingsounds like you are calling an agi from inside another agi?
17:19.19THECobrasorry was trying to be as brief as possible
17:20.07THECobraok so step on i have a perl script that checks for new calls that need to happen in a database if  a call is there it uses AMI to originate a call
17:21.28THECobrathen the dialplan sets variables and calls out to AGI  initialize the call internally so it sets what trunk to use and what callerid to set to the second call etc
17:22.10THECobraafter the agi script does all that it calls a go sub which dials the second channel to number2
17:22.59THECobrasince gosub is not async it waits for the dial to be completed to move on in the agi script itself and then tries to collect the variables like totalcaltime
17:24.07THECobra$self->agi->get_variable("DIALEDTIME") is currently returning null because based on what i have read that channel essentially disappears once its put in the simple_bridge
17:24.18*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
17:24.28THECobraso that var is returned null and the AGI script continues
17:25.09THECobradoes that make more sense?
17:25.30igcewielingSet a shared variable containing the timestamp of the start of the call.
17:26.08igcewielingYou can also set a hangup handler which might help.
17:27.20THECobratried that, the issue is that when the dial plan dials and the end party answers it moves the call into the bridge and that original channel is i guess for a better word abandoned it will run the hangup hadler but the call is still on going
17:28.06THECobraeven when i push a hangup handler to the channel it is not carried to the newly created channel that is in the simple_bridge
17:28.26igcewielingthe my first suggestion might be better
17:29.44THECobrai can set the variable but not sure how i would be able to access it since the agi script moved past that point with a null variable since the dial completed
17:31.12THECobrawhen that second call is disconnected it doesnt run a hangup handler that i can set because once its moved to the bridge all of that is lost
17:32.53THECobrai even tried dynamically creating ConfBridge'sand moving calls into it but the result appears to be the same the call details for the second call are not accessible
17:34.00igcewieling"Implements a shared variable area, in which you may share variables between
17:34.00igcewielingchannels.The variables used in this space are separate from the general namespace of the
17:34.00igcewielingchannel and thus ${SHARED(foo)} and ${foo} represent two completely different
17:34.00igcewielingvariables, despite sharing the same name."
17:34.07igcewielinghmm..that formatted poorly.
17:36.28THECobrahttps://pastebin.com/HZC4z5sF
17:36.53THECobrathat is the dialplan the that the go sub for call2 uses
17:38.56THECobrathe dial should stall the dialplan until hangup so the variables are available on hangup but since it this is a second call and the asterisk core moves it to a bridge it immediately calls the hangup with null variables
17:41.27igcewielingSorry, I check things like DIALEDTIME in hangup handlers.
18:17.26*** join/#asterisk sinaowolabi (~Sina@41.190.30.15)
18:22.01*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
18:22.54*** join/#asterisk sinaowolabi (~Sina@102.134.114.1)
18:50.00*** join/#asterisk Dovid (~dovid@nbl10-102.static.cytanet.com.cy)
18:52.33*** join/#asterisk segnior (segnior@gateway/shell/xshellz/x-cnotbrvdbtydrqpk)
18:59.02*** join/#asterisk Janos (~textual@201.204.94.76)
19:10.29*** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net)
20:13.01*** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir)
21:05.57*** join/#asterisk Dovid (~dovid@nbl10-102.static.cytanet.com.cy)
22:36.56*** join/#asterisk Dovid (~dovid@nbl10-102.static.cytanet.com.cy)
22:57.29*** join/#asterisk yuljk (~yuljk@unaffiliated/yuljk)
23:36.37*** join/#asterisk THECobra (a2ffe1fe@vpn01.dfw02.servax.net)

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