| 00:22.11 | *** join/#asterisk infernix (nix@unaffiliated/infernix) |
| 00:22.17 | *** join/#asterisk AsteriskRoss_ (~AsteriskR@37.157.48.2) |
| 01:13.51 | *** join/#asterisk tsal (~tsal@i59F52702.versanet.de) |
| 01:27.50 | *** join/#asterisk infernix (~nix@unaffiliated/infernix) |
| 01:54.35 | *** join/#asterisk Maliuta (maliutamat@gateway/shell/matrix.org/x-yqozatocainmkali) |
| 02:09.38 | *** join/#asterisk mr44er (~mr44er@dynamic-046-114-005-019.46.114.pool.telefonica.de) |
| 03:39.20 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 04:33.15 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 04:51.01 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 04:52.44 | *** join/#asterisk FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net) |
| 06:18.14 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
| 06:58.27 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 06:58.32 | *** join/#asterisk TriJetScud (~TriJetScu@2602:fca7:1:6:5733:d000:1111:1111) |
| 07:44.30 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 08:50.31 | *** join/#asterisk sinaowolabi (~Sina@105.112.74.51) |
| 09:21.34 | jkroon | We just noticed a corner case bug in one of our call paths where we used ResetCDR(w) to first log an entry and then send early media to indicate the error that occurred. Obviously this was an old ast11 construct that we only just noticed now. Arguments about whether or not CDRs vs CELs is the way to go (I know the latter is but don't have that in place as of yet and ideally need a temp/quick fix), is there an equivalent or replacement for ResetCDR(w) |
| 09:21.34 | jkroon | in 13 onwards? |
| 09:24.58 | jkroon | previously we had ResetCDR(w); NoCDR() ... this now obviously fails, and need to log the fail reason (cdr_odbc) so that the call can be saved as FAILED else when the caller hangs up during error message it becomes NOANSWER. |
| 09:31.59 | jkroon | ForkCDR(e) seemingly. |
| 09:45.50 | *** join/#asterisk sa02irc (~mbax@155-079-043-212.ip-addr.inexio.net) |
| 10:02.18 | *** join/#asterisk drathir_tor (~drathir@gateway/tor-sasl/drathir) |
| 10:15.38 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d00ccf3f8923896b775.dip0.t-ipconnect.de) |
| 10:55.20 | *** join/#asterisk sinaowolabi (~Sina@105.112.74.51) |
| 11:12.36 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 11:13.37 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 11:36.24 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d00fadc106ed93ec58b.dip0.t-ipconnect.de) |
| 12:23.28 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 13:02.14 | *** join/#asterisk lbazan (~LoKoMurdo@fedora/LoKoMurdoK) |
| 13:47.20 | *** join/#asterisk CatCow97 (~mine9@c-73-96-109-206.hsd1.or.comcast.net) |
| 13:50.27 | *** join/#asterisk kharwell (uid358942@gateway/web/irccloud.com/x-rxgquvjyjlwbqhks) |
| 13:50.28 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 13:52.29 | *** join/#asterisk DodgeThis (~DodgeThis@246.102.90.149.rev.vodafone.pt) |
| 13:58.54 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 14:02.06 | igcewieling | jkroon: the changes to ResetCDR were not in UPGRADE*.txt ? |
| 14:06.28 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 14:08.36 | jkroon | igcewieling, it may have and I may have just missed it. |
| 14:09.34 | jkroon | they are, but poorly written. |
| 14:10.00 | igcewieling | jkroon: sometimes something is missed, but upgrade.txt is the place to look for important changes. |
| 14:11.29 | jkroon | generally it's all listed there yes. in this case it's there, but it doesn't point at replacements/alternatives, which I'm used to it normally does. |
| 14:13.22 | *** join/#asterisk gerhard7 (~gerhard7@86-87-238-48.fixed.kpn.net) |
| 14:16.55 | Samot | CDRs and CELs are not the same thing. |
| 14:18.09 | Samot | So there really isn't a CDRs vs CELs thing. |
| 14:18.33 | igcewieling | CDRs are the overly complex collection of cal records. CEL is an overly wordy log of other stuff. lol |
| 14:19.55 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 14:28.26 | Samot | jkroon: what version on you on now? |
| 14:33.36 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-clfyzphjfppjgdmy) |
| 14:33.36 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:34.52 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d0028f665d41267ec7c.dip0.t-ipconnect.de) |
| 15:12.53 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 15:19.57 | *** join/#asterisk Ner0Zer0 (~Ner0Zer0@87.253.63.54) |
| 15:21.17 | *** join/#asterisk gschanuel (~gschanuel@200-181-252-244.user3p.brasiltelecom.net.br) |
| 15:24.23 | jkroon | Samot, the cluster is currently mostly on 13, but we've got a few nodes on 16 already as part of testing. |
| 15:25.02 | jkroon | igcewieling, yea, the more involved with CDRs and CELs I get the more I realize it's very much a case of "pick your poison" |
| 15:25.28 | jkroon | Samot, i hear you, but they are very closely related. |
| 15:25.35 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 15:25.52 | Samot | CEL tracks events it is told to track. |
| 15:26.25 | Samot | And the CDR/CEL overhaul happened in Asterisk 12. So you need to read that changelog along with any others to the versions you have. |
| 15:26.28 | Samot | All the way up. |
| 15:26.30 | jkroon | I've realized off late that hard question really is "what is a call", as such, CEL makes sense because it's events on a *channel*. And a call potentially consists of many of these. |
| 15:29.56 | igcewieling | I stopped using Asterisk CDRs about a year ago. Every call runs an AGI at the start of a call and at the end of a call so I write my own CDRs to my own tables. I use CEL events generated in the dialplan and my AGIs to log the various events which happen as the call is processed. My CDR needs are very simple however. |
| 15:30.57 | file | jkroon: business logic within an environment really defines it, and business logic differs across businesses |
| 15:31.08 | igcewieling | *nod* what he said. |
| 15:31.09 | Samot | ^^^^ |
| 15:31.12 | Samot | That. |
| 15:37.52 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 15:46.13 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 16:10.10 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 16:20.25 | *** join/#asterisk Jesterboxboy (~Thunderbi@84-115-150-8.cable.dynamic.surfer.at) |
| 16:34.04 | *** join/#asterisk DanFromUK (sid21651@gateway/web/irccloud.com/x-hcjjdldimjefsjvp) |
| 16:35.05 | DanFromUK | Hi. I've got an issue with a stable Asterisk installation. I've got a few call examples where Asterisk froze for around 20-30 seconds while processing a dial-plan on an inbound call. |
| 16:35.14 | DanFromUK | Only that call froze. Others continued as normal. |
| 16:36.12 | DanFromUK | Q: Does the full log output before processing a command, or after? IE Would the freeze be occurring on the line in the logs timed immediately before or after the freeze? |
| 16:36.12 | Samot | Show it. |
| 16:38.36 | igcewieling | DanFromUK: one possible cause is DNS issue, easy to check too. |
| 16:40.07 | DanFromUK | Here is the logs... The inbound carrier appears to try to repeatedly get the call through at first, eventually succeeding.... https://pastebin.com/JwEFtzpK |
| 16:41.21 | DanFromUK | Here is the start of the dialplan which includes the section that gets stuck... |
| 16:41.42 | DanFromUK | https://pastebin.com/gPFT2Hcv |
| 16:42.17 | DanFromUK | So my question is, is the freeze occurring during execution of the EXECIF statement on line 10. Or is it occurring during the execution of line 9 ? |
| 16:43.53 | DanFromUK | Note that the CLI/full log output has not been doctored. The failed call attempts don't get hung up until later on in the logs. Potential for overflowing the system resources there I guess, if the carrier retries too many times, without Asterisk terminating the frozen call quickly. |
| 16:44.11 | file | 9. |
| 16:44.28 | file | the log message occurs before execution |
| 16:44.57 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 16:45.32 | DanFromUK | @file even though line 10 would require some form of initial evaluation of the IF condition in order to write the "0?" in the logs? |
| 16:45.52 | file | true, so maybe 10 |
| 16:46.33 | DanFromUK | Ok. Are there any limits that could be set here that would affect execution of simple statements like that? Thread count limits etc? |
| 16:47.42 | file | I'm not aware of any, but operations on the CDR are queued to CDR handling and block until completed, so if something is blocking in CDR land then it could impact dialplan probably |
| 16:49.32 | DanFromUK | The CDR uses cdr_adaptive_odbc. So from what you've said, if the local DB was running slowly for some reason, that could indicate why a CDR command got stuck? |
| 16:49.56 | file | I don't know if dispatching would impact things like that. |
| 16:56.34 | DanFromUK | Ok. Thanks. I'll see if I can do anything to optimise the dialplan and DB. |
| 17:06.41 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d00884abd0cffc6e83d.dip0.t-ipconnect.de) |
| 17:08.47 | DanFromUK | @file I can only see Asterisk inserting recording into the DB. I cannot see any UPDATE SQL commands on the CDR table. If it's line 9 or 10, they both involve CDR(), would either trigger an INSERT to be performed, or does the CDR write only occur later? |
| 17:09.05 | file | CDR writes occur at the end of life of a CDR |
| 17:09.52 | DanFromUK | Ok, so it cannot be the DB at this stage. Does the CDR handler have a set number of threads which could be adjusted, or does it work on queued one item at a time? |
| 17:10.17 | file | I don't remember |
| 17:10.55 | DanFromUK | No problem. Thanks for the assistance. I'll see what I can come up with. |
| 18:21.18 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 18:41.15 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 18:58.45 | *** join/#asterisk sinaowolabi (~Sina@102.134.114.1) |
| 19:06.36 | *** join/#asterisk netman (~netman@185.94.249.222) |
| 19:55.13 | *** join/#asterisk rpifan (~rpifan@p200300d2672b5d005ae82c325b78ca79.dip0.t-ipconnect.de) |
| 19:57.21 | *** join/#asterisk rpifan_ (~rpifan@p200300d2672b5d0067086eea192e76b5.dip0.t-ipconnect.de) |
| 20:17.47 | *** join/#asterisk Maliuta (maliutamat@gateway/shell/matrix.org/x-fpfldbqbkdxmssel) |
| 20:40.56 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 21:17.47 | *** join/#asterisk simplydrew_ (~simplydre@unaffiliated/simplydrew) |
| 21:53.26 | *** join/#asterisk simplydrew_ (~simplydre@unaffiliated/simplydrew) |
| 21:53.45 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |
| 23:11.11 | *** join/#asterisk sinaowolabi (~Sina@41.190.3.35) |