| 00:16.09 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:16.09 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 06:10.15 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:27.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:12.45 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:13.12 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:56.08 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.119) |
| 08:01.20 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 08:34.56 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 08:38.09 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 10:34.55 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 10:34.55 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 10:57.34 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.101) |
| 11:53.47 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 12:17.23 | tsearle | hello, has anybody here seen an asterisk crash caused by the first / last list pointers of the frame_cache point to invalid memory locations? |
| 13:11.14 | *** join/#asterisk-dev spatel (~spatel@pool-98-118-124-216.bstnma.fios.verizon.net) |
| 13:20.39 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-sivobgvmytlmrwpp) |
| 13:20.39 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 13:27.45 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-240-156.dialup.adsl.anteldata.net.uy) |
| 13:37.41 | coreyfarrell | wow, I didn't know jenkins would fail the build if the review wasn't against current HEAD of the branch. is that a new thing? |
| 13:38.11 | file | it'll fail if merge stuff doesn't go right, not strictly if it's not against HEAD |
| 13:38.18 | file | been like that for a long time |
| 13:40.38 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:41.29 | coreyfarrell | but git rebase on the branch worked fine. no commit even touched main/stasis.c between the parent of my review and the current HEAD. |
| 13:42.34 | gtjoseph | it doesn't have to be "against" the current head. it just has to merge cleanly into the current head. |
| 13:44.55 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-240-156.dialup.adsl.anteldata.net.uy) |
| 14:01.56 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-240-156.dialup.adsl.anteldata.net.uy) |
| 14:16.31 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-cvxuvcyivarumoej) |
| 14:16.31 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:18.07 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.101) |
| 14:40.22 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@68-114-57-249.dhcp.davl.vt.charter.com) |
| 14:40.23 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 15:22.26 | seanbright | file: it's seán, not sean |
| 15:22.29 | seanbright | don't confuse me |
| 15:22.43 | file | I didn't do it on purpose just to see what would happen |
| 15:22.44 | file | cough |
| 15:23.09 | seanbright | mission accomplished |
| 15:28.40 | gtjoseph | And it's ǴêÅÅǵê from now if. |
| 15:28.48 | gtjoseph | And it's ǴêÅÅǵê from now on. |
| 15:30.16 | gtjoseph | and thank you seanbright for updating my jira post :) |
| 16:01.34 | seanbright | gtjoseph: no problem. attachment formatting is sexy. |
| 16:01.49 | gtjoseph | :) |
| 16:01.51 | seanbright | it's kinda dumb that when you comment while attaching that there is no automatic reference to the file you attached |
| 16:05.48 | bford | seanbright: in case you were curious, that loop for queues just cycles through all agents that have the same metric and calls all of them (for RINGALL) |
| 16:05.48 | bford | essentially, lowest penalty wins as long as it's within the allowable penalty range |
| 16:05.48 | bford | also, QUEUE_RAISE_PENALTY doesn't exist even though it's in the documentation :P |
| 16:06.31 | file | I see it in the code |
| 16:06.41 | bford | where? a grep search didn't produce any results |
| 16:06.58 | file | https://www.irccloud.com/pastebin/9Pt50CNv/ |
| 16:07.57 | bford | what version? i'm on 13 branch and it did not show anything |
| 16:08.05 | file | 16 |
| 16:08.12 | bford | uh oh |
| 16:08.47 | file | someone has been looking at documentation for a newer branch... |
| 16:08.48 | file | :P |
| 16:09.12 | bford | maybe the sample files were generated on 16 lol |
| 16:09.12 | file | https://www.irccloud.com/pastebin/XTlVNiFI/ |
| 16:09.17 | file | tada. |
| 16:09.26 | bford | yep, there we go |
| 16:09.37 | bford | my sample files are probably generated on 16 |
| 16:10.32 | bford | so... |
| 16:28.51 | seanbright | bford: we're going to have to let you go |
| 16:28.56 | seanbright | you'll thank us later |
| 16:31.09 | bford | i thought that was what we were doing when i got assigned an app_queue issue |
| 16:35.02 | seanbright | heh |
| 17:46.00 | seanbright | i'm very confused, re: ASTERISK-28521 |
| 17:46.21 | seanbright | 71160 kByte = 69.49MB |
| 17:46.45 | seanbright | 72084 kByte = 70.39MB |
| 17:47.06 | seanbright | is the latter really "significantly higher" than the former? |
| 17:47.13 | seanbright | or am i missing something |
| 17:48.21 | file | to me it isn't |
| 17:51.44 | seanbright | maybe he obly has 80MB in his system |
| 17:55.15 | seanbright | and i assume that with the upgrade from pjsip 4.8 to pjsip 4.9 there are other things that might take more memory |
| 17:55.55 | file | seanbright: I read it opposite |
| 17:55.59 | file | new takes less, old takes more |
| 18:01.12 | seanbright | doh |
| 18:01.20 | seanbright | has some egg on his face |
| 18:08.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 18:23.36 | kharwell | seanbright: potential silly question regarding your moh stuff. eventual playback will support http? |
| 18:23.48 | seanbright | i don't follow |
| 18:25.12 | kharwell | moh currently plays from files only. You're now allowing an http url to be in the "files" vector. the code will loop over that vector eventually to play those "files". I guess the underlying playback stuff already handles http:// vs file://? |
| 18:25.25 | seanbright | yes |
| 18:26.43 | kharwell | thanks for the confirmation |
| 18:26.58 | seanbright | asterisk 14 added URL support |
| 18:27.14 | seanbright | you just can't do it in MoH unless you use mode=custom |
| 18:27.23 | seanbright | my patch is trying to address that |
| 18:27.38 | kharwell | aah cool so been in a while then |
| 18:27.55 | seanbright | if there is already a way to play a URL with MoH without an external app, i don't know what it is |
| 18:30.13 | seanbright | i thought i could do something hacky, like: |
| 18:30.19 | seanbright | cd /var/lib/asterisk/moh |
| 18:30.21 | seanbright | touch http:\\\\seanbright.com\\test.ulaw |
| 18:30.50 | seanbright | but that doesn't work because MoH forces the path to be absolute |
| 18:33.14 | seanbright | i thought about making is so that you would specify a playlist "file" |
| 18:33.18 | seanbright | so: |
| 18:33.20 | seanbright | mode=playlist |
| 18:33.22 | kharwell | been kinda neat if that had worked |
| 18:33.24 | seanbright | file=something.plist |
| 18:33.35 | seanbright | but then you're just configuring things in two different places |
| 18:33.41 | kharwell | yeah |
| 18:34.01 | seanbright | i like this method for two reasons: it's explicit ordering, and you can use URLs |
| 18:34.51 | seanbright | the only way it could be better would be if asterisk media cache streamed the audio rather than downloading the whole thing first, but it's minor |
| 18:34.54 | seanbright | networks are fast |
| 18:35.36 | kharwell | don't worry file can work on that part over the weekend |
| 18:35.41 | seanbright | oh nice |
| 18:35.43 | seanbright | thanks file |
| 18:35.52 | file | kharwell: pfft |
| 18:35.57 | file | I'm working on an email |
| 18:36.06 | file | kthx |
| 18:36.09 | seanbright | curl's non-blocking mode is non-trivial |
| 18:36.16 | seanbright | at least the last time i looked |
| 18:52.16 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-1-9707-146.w86-236.abo.wanadoo.fr) |
| 19:11.35 | gtjoseph | coreyfarrell: are yu going to fix the mwi leaks? ASTERISK-28546? |
| 19:12.28 | coreyfarrell | gtjoseph: unclear. I've looked into it and I'm not sure how/where to fix. |
| 19:13.26 | gtjoseph | ok. i'm going to acknowledge it and assign it to you for now. if you decide to not work it, just ping me and i'll create an internal issue for it. |
| 19:14.23 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-240-156.dialup.adsl.anteldata.net.uy) |
| 19:35.48 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-240-156.dialup.adsl.anteldata.net.uy) |
| 19:56.53 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.101) |
| 20:59.54 | coreyfarrell | what is the expected outcome of setting `mailboxes=1234@default` to a pjsip endpoint when app_voicemail is being used and 1234@default has not been added to voicemail.conf? |
| 21:08.17 | kharwell | not sure if the current expected is correct, but I think pjsip mwi will go through it machinations and create it's data objects, app_voicemail of course won't have a matching mailbox, so don't thinking any would be published from app_voicemail to that mailbox. However, if polling is enabled I think it will loop over all mailboxes in stasis_cache (<=16), or stasis_state (>=17) and and publish mailbox info |
| 21:08.48 | kharwell | for that mailbox, which I am guessing would be zero'd out (i.e. new/old messages=0) |
| 21:11.47 | coreyfarrell | ok fair enough. so for the polling situation it results in a leak. not sure if that's a bug or configuration error. |
| 21:12.01 | coreyfarrell | ^^ at least in 17 it results in a leak |
| 21:12.39 | coreyfarrell | I suspect that it wouldn't leak repeatedly and stasis_state would just keep reusing the same structures? |
| 21:13.11 | kharwell | aah you mean it would publish, but then in app_voicemail delete it never calls publish_remove? |
| 21:13.26 | kharwell | and yeah I believe you are correct in that it would not repeat repeatedly |
| 21:13.44 | kharwell | should only be one stasis_state managed object/topic per pool |
| 21:14.43 | coreyfarrell | yes app_voicemail calls ast_publish_mwi_state_channel but never calls ast_delete_mwi_state_full because it doesn't have a user associated with the mailbox. |
| 21:15.05 | kharwell | are you seeing a leak now? If things init to zero in app_voicemail with zero for new/old mailbox info then if that is the same as the old it might not publish anything since nothing officially changed |
| 21:16.14 | coreyfarrell | yeah tests/apps/voicemail/polling/poll_same_mailbox leaks unless you configure 1234@default in voicemail.conf for the test |
| 21:17.25 | coreyfarrell | the debug logs show "Queueing event for mailbox 1234@default New: 1 Old: 0" followed by "Queueing event for mailbox 1234@default New: 0 Old: 0". |
| 21:18.31 | coreyfarrell | it's the stasis_state object which leaks because ast_publish_mwi_state_channel adds the default eids |
| 21:28.28 | kharwell | yup that sounds like it'll do it. Another good catch |
| 21:28.35 | kharwell | not sure the best fix for that .... |
| 21:30.25 | kharwell | Might be easiest to just not call publish for any stasis state "mailbox" not configured in app_voicemail |
| 21:30.48 | kharwell | Then the implicit publisher from app_voicemail would never be created |
| 21:30.57 | coreyfarrell | I'm running the full testsuite against 17 right now, once I capture a list of the tests that leak I'll check them for missing voicemail.conf entries |
| 21:31.38 | coreyfarrell | would that be a breaking change though? I think it would cause at least some of the voicemail polling tests to fail. |
| 21:33.30 | kharwell | I suppose in a way yeah. It'd break the tests. |
| 21:35.12 | rmudgett | but those tests wouldn't be configured correctly |
| 21:35.44 | rmudgett | ...unless that was the purpose of the test :P |
| 21:36.32 | coreyfarrell | I'm thinking that the tests were configured incorrectly and due to a bug it still worked. so end users might do the same thing and fixing the bug would be a breaking change. |
| 21:38.21 | kharwell | I'm guessing the tests were just taking a "short cut" in configuration. Although maybe in some way the endpoint doesn't care about the backend. Just wants to subscribe to mailboxes. Could be app_voicemail, or something else. Should app_voicemail publish "dummy" mailbox info for "mailboxes" it doesn't have? |
| 21:38.51 | file | we did that originally and it broke FreePBX, thus why the aliases functionality was added |
| 21:58.06 | coreyfarrell | I think for now I'm going to identify tests which use mailboxes that don't exist and fix the test configuration. I'm not going to attempt to change the asterisk code without guidance of how app_voicemail should deal with it. |
| 22:00.00 | kharwell | sounds good |
| 22:15.18 | rmudgett | ..unless that is the purpose of the test of course. :P |