| 00:24.53 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ujmzghzzxvyqoziy) |
| 00:56.01 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 05:04.50 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 05:39.28 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 06:12.12 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:24.37 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:41.36 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:53.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:55.49 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::152e) |
| 08:02.42 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 08:26.19 | *** join/#asterisk-dev tzafrir_ (~tzafrir@local.xorcom.com) |
| 08:26.19 | *** mode/#asterisk-dev [+o tzafrir_] by ChanServ |
| 10:01.02 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.149.50) |
| 10:27.36 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 12:39.22 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 12:39.43 | tsearle | good morning |
| 12:39.56 | tsearle | I found there is an error with the README file for the opus codec |
| 12:40.36 | tsearle | it says for manual install just place the .so in the modules directory |
| 12:40.52 | tsearle | however, if you don't also install the .xml documentation asterisk will not start |
| 12:40.58 | tsearle | [Feb 8 12:20:52] ERROR[10300]: codec_opus_config.c:532 codec_opus_config_initialize: Opus: failed to register sorcery object type 'opus' |
| 12:41.10 | file | that's been fixed already, but we're waiting for the latest 13 and 14 to get through release candidate before doing a release as it needs some fixes from Asterisk to work best |
| 12:41.29 | tsearle | fixed in what way? the README has been revised? |
| 12:41.36 | tsearle | or asterisk doesn't crash on missing docs? |
| 12:41.48 | file | the README has been revised |
| 12:41.54 | tsearle | ok, cool |
| 12:42.17 | file | <PROTECTED> |
| 12:42.17 | file | <PROTECTED> |
| 12:42.17 | file | <PROTECTED> |
| 12:42.30 | tsearle | yeah figured that out |
| 12:42.42 | file | that's the copy/paste from the new README |
| 12:42.46 | tsearle | I was just mentioning the READMe should be fixed so others don't share my grief |
| 12:43.09 | tsearle | but that is also incorrect |
| 12:43.20 | tsearle | there shouldn't be a hyphen in thirdparty |
| 12:43.45 | file | good point! |
| 12:46.22 | file | fixed |
| 12:46.53 | file | merci |
| 12:46.58 | tsearle | de rein! |
| 12:47.30 | tsearle | so I guess you released a new version of opus, any other new features? |
| 12:47.39 | file | it hasn't been released yet |
| 12:47.44 | tsearle | ha ok |
| 12:47.49 | file | it will be, once the new Asterisk is released |
| 12:48.13 | tsearle | ha, so then the new version will depend on code changes in asterisk to work? |
| 12:48.17 | file | some audio problems were fixed and FEC was added |
| 12:48.28 | file | it won't depend on it, but FEC when used with a jitterbuffer will |
| 12:48.58 | tsearle | ok, so to use FEC you need to force a jitter buffer |
| 12:49.05 | file | no |
| 12:49.22 | file | if you use a jitterbuffer and you have FEC in Opus enabled in older versions it won't work properly |
| 12:49.27 | file | a jitterbuffer in Asterisk, that is |
| 12:50.02 | tsearle | ok, so if you are doing sip to sip 711 to opus transcoding, FEC will still work |
| 12:50.07 | file | yes |
| 12:50.55 | tsearle | ok cool |
| 14:08.19 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-relyekkrkyliphlk) |
| 14:08.19 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:13.43 | file | hrmmmm |
| 14:16.35 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-symdtizrhugoxbop) |
| 14:16.35 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:47.13 | file | so I'm looking at the parking unit test failures and it seems to be because the staging snapshot flag is set on the channel when it's hung up, in both tests the flow is an ast_bridge_depart and then an ast_hangup but I've looked over all uses of the flag and can't see anything that would cause it... |
| 14:47.24 | file | quite odd |
| 14:53.51 | file | snapshot staging is also exactly what I'd expect in the working cases... |
| 15:16.12 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-wgwsuojiolevhkli) |
| 15:16.12 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:46.07 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:46.07 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:46.31 | tsearle | welcome home @cresl1n |
| 15:47.22 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:47.22 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:47.49 | cresl1n | hey tsearle! |
| 15:47.50 | cresl1n | Thanks |
| 15:47.59 | cresl1n | How are you doing today? |
| 15:48.29 | tsearle | allright, trying to craft a pjsip.conf |
| 15:48.36 | cresl1n | YESSSSSS |
| 16:05.16 | tsearle | ok got a call working |
| 16:05.29 | tsearle | just a Q, what's the equivalent of "sip set debug on" |
| 16:05.38 | tsearle | so you can see the sip messages on the console? |
| 16:08.24 | file | pjsip set logger on |
| 16:11.38 | tsearle | anyhow, I'm happy I managed to make my first pjsip call, I'm off! (thanks all!) |
| 16:35.09 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-hdkqcqqchvnyxvtq) |
| 16:35.09 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:39.24 | file | rmudgett: can you think of a reason why the stage snapshot flag would be set on a channel when its destructor is run? |
| 17:12.47 | rmudgett | file: Are you looking at the assert in the channel destructor? |
| 17:13.47 | file | Yes, that is what the parking unit test encountered |
| 17:15.35 | rmudgett | Probably a error exit path didn't complete the snapshot staging before leaving somewhere. |
| 17:16.17 | file | that's what I thought, but I looked and couldn't find anything... it's odd |
| 17:16.18 | file | https://jenkins.asterisk.org/jenkins/job/check-asterisk-64/4094/consoleFull is the bt |
| 17:17.42 | rmudgett | Probably should not "complete" the snapshot in the destructor either. It might bump the ref on the destructing channel. Which would be bad. |
| 17:18.11 | file | welllllll I was thinking... the flag could just be cleared explicitly |
| 17:18.14 | file | a snapshot happens directly after that |
| 17:18.36 | file | if we shouldn't be doing the snapshot there at all, that's not a road I'm going down :P |
| 17:20.50 | rmudgett | Oh. That snapshot is supposed to be the dying notification of the channel. |
| 17:22.28 | file | yes |
| 17:24.45 | rmudgett | That assert is pointing out a bug. Where I don't know. Someone staging a snapshot and didn't create the snapshot when done. |
| 17:25.18 | rmudgett | If the channel continues it would not create snapshots normally. |
| 17:25.26 | file | yeah, the question is... where... or how |
| 17:25.50 | rmudgett | Looks like an audit of snapshot staging is needed. |
| 17:26.03 | file | that's what I've been doing this morning and usage is actually really minimal |
| 17:26.16 | file | and they all follow the lock channel, stage, do stuff, mark done, unlock pattern |
| 17:26.32 | rmudgett | Are there any off-nominal paths that don't create the snapshot? |
| 17:26.33 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 17:26.51 | file | not that I can see, but I'm going to do another round |
| 17:27.07 | rmudgett | That would be where I'd expect it to happen. |
| 17:37.16 | *** join/#asterisk-dev tuxian (~tuxian@194.12.3.78) |
| 17:40.40 | file | andddddddd nothing |
| 17:50.22 | *** join/#asterisk-dev jkroon (~jkroon@154.73.32.13) |
| 18:15.28 | *** join/#asterisk-dev jkroon (~jkroon@vc-nat-gp-n-41-13-92-236.umts.vodacom.co.za) |
| 18:24.39 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.222.253) |
| 18:34.23 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00849ee2e72b5fe571.ipv6.abo.wanadoo.fr) |
| 19:04.21 | seanbright | any reason that the xfersound played in the bridging stuff would sould choppy? |
| 19:04.45 | seanbright | or do i have to do my own debugging again? |
| 19:31.11 | *** join/#asterisk-dev dan_j (sid21651@gateway/web/irccloud.com/x-nnbnwdbtmjzgsgxm) |
| 19:39.18 | cresl1n | seanbright: Ummm |
| 19:39.21 | cresl1n | lots of reasons? :-P |
| 19:46.10 | *** join/#asterisk-dev tzafrir_ (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 19:46.10 | *** mode/#asterisk-dev [+o tzafrir_] by ChanServ |
| 19:48.37 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 20:06.50 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-roeghghzwleauwtk) |
| 20:06.50 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:09.21 | *** join/#asterisk-dev file (uid178970@asterisk/developer-and-muffin-lover/file) |
| 20:09.21 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 20:21.54 | seanbright | cresl1n: thanks, i'll try that |
| 20:21.56 | seanbright | :D |
| 20:22.26 | seanbright | happening on a VM running on my local workstation, so i'm guessing a bug |
| 20:22.31 | seanbright | i'll figure it out (eventually) |
| 20:31.28 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-cfohophuhnfdyawa) |
| 20:31.28 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 21:04.48 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-mqlffqjwevnmuuwh) |
| 21:04.48 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:06.58 | *** join/#asterisk-dev spditner (~simon@45.72.151.70) |
| 21:38.58 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-smyftwngfbtbabda) |
| 21:38.58 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 21:40.57 | rmudgett | file: I think I know what happened for the parking unit tests. It's a case of modifying the channel flags without the channel lock held. |
| 21:41.11 | file | where was that done? (by what) |
| 21:41.55 | file | oh, wait, do you mean something setting a different flag without the channel lock and the snapshot flag being collateral damage? |
| 21:42.10 | rmudgett | yes |
| 21:42.16 | file | ah, yeah |
| 21:44.05 | rmudgett | The ast_waitfor() family is a big offender with the AST_FLAG_BLOCKING |
| 21:44.17 | rmudgett | Among others |
| 21:45.23 | rmudgett | And another audit is needed. Did a cursory look and could see a bunch of them. |
| 21:46.11 | rmudgett | Not necessarily related to the parking unit test scenario. Stasis is likely to be hit by it often. |
| 21:46.36 | rmudgett | if the asserts are enabled with do_crash |
| 21:48.14 | Demon_VoIP | Is there any difference in mysql/mariadb between longblob and BLOB(4294967295)? |
| 21:49.59 | Demon_VoIP | mariadb, odbc. VoicemailMan, I guess after SQLGetData(stmt, x + 1, SQL_BINARY, rowdata, 0, &colsize2) colsize2 is toooooo big. |
| 22:06.29 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 23:36.34 | *** join/#asterisk-dev WIMPy (~wimpy@85.183.149.50) |
| 23:40.24 | tm1000 | anyone know how to use extension_state on pjsip extensions? (https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_EXTENSION_STATE). My pjsip extension is disconnected. But when I check it with EXTENSION_STATE is gives back NOT_INUSE instead of UNAVAILABLE |
| 23:51.51 | gtjoseph | tm1000: do you have aor/qualify_frequency > 0 ? |