| 01:22.01 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:22.01 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:58.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:31.03 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 06:28.38 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 07:30.14 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:30.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:46.33 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:88df:7859:875:e82b) |
| 08:42.00 | Stefan27 | how can i debug the cause of fd-leaks? core show fd outputs this: http://pastebin.com/seVbHerL what thread/function is supposed to close them? |
| 08:44.06 | Stefan27 | also core show locks is empty |
| 08:44.57 | coreyfarrell | Stefan27: what version of asterisk? |
| 08:46.14 | Stefan27 | 12.6.1 compiled with pjprojects but no pj modules loaded |
| 08:46.15 | coreyfarrell | and can I assume that no calls were active when you ran core show fd? |
| 08:46.23 | Stefan27 | yes |
| 08:46.38 | Stefan27 | module show does show: res_rtp_asterisk.so Asterisk RTP Stack 250 Running |
| 08:46.56 | Stefan27 | and there's indeed 500 open udp rtp ports (max) |
| 08:48.53 | coreyfarrell | are the open udp ports odd, even or both? |
| 08:50.05 | Stefan27 | both |
| 08:50.52 | Stefan27 | every single port from 12000 to 12499 + 5060 is open according to netstat |
| 08:51.18 | Stefan27 | opened by asterisk * |
| 08:53.33 | coreyfarrell | I think REF_DEBUG could be useful. the fact that the RTP and RTCP ports are both open tells me that the RTP instance is being held open by the chan_sip dialog, REF_DEBUG would should tell where the missing dialog unref (or extra ref) comes from |
| 08:53.58 | Stefan27 | is there any way to kill the res_rtp_asterisk.so module-instances (by force) in CLI? |
| 08:54.23 | Stefan27 | REF_DEBUG is a compilation flag? |
| 08:54.44 | WIMPy | So anything under 'sip show channels'? |
| 08:54.47 | coreyfarrell | no way to kill it, that wouldn't close the ports anyways. REF_DEBUG is a compilation flag in menuselect |
| 08:55.01 | Stefan27 | 0 active dialogs |
| 08:56.37 | coreyfarrell | that tells me that the dialog was unlinked from dialogs but still has references (and failed to be freed). |
| 08:57.28 | coreyfarrell | once you build with REF_DEBUG it will cause a 'refs' file to be placed in your logs file. after you reproduce the issue, run 'core stop gracefully'. |
| 08:58.20 | coreyfarrell | then from the asterisk source dir run: ./contrib/scripts/refcounter.py -f /var/log/asterisk/refs -n > /tmp/ref-leaks.txt |
| 08:58.54 | Stefan27 | do i have to add an entry in logger.conf corresponding to refs? |
| 08:59.07 | coreyfarrell | no, REF_DEBUG causes the file to be created |
| 08:59.49 | coreyfarrell | adding an entry to logger.conf would corrupt the refs file |
| 09:03.12 | Stefan27 | - refcounter MENUSELECT_UTILS too? |
| 09:04.03 | coreyfarrell | no, that util is for a previous version of REF_DEBUG |
| 09:04.52 | Stefan27 | - DEBUG_THREADS MENUSELECT_CFLAGS |
| 09:04.52 | Stefan27 | - DEBUG_FD_LEAKS MENUSELECT_CFLAGS |
| 09:04.53 | Stefan27 | - MALLOC_DEBUG MENUSELECT_CFLAGS |
| 09:04.53 | Stefan27 | - REF_DEBUG MENUSELECT_CFLAGS |
| 09:04.53 | Stefan27 | - AO2_DEBUG MENUSELECT_CFLAGS |
| 09:04.53 | Stefan27 | - BUSYDETECT_DEBUG MENUSELECT_CFLAGS |
| 09:04.55 | Stefan27 | but all of these? |
| 09:06.34 | coreyfarrell | no, I'd recommend just REF_DEBUG, none of those others. we're not trying to debug an FD leak, the problem is the ao2 object that owns it (REF_DEBUG will tell us about this) |
| 09:06.58 | coreyfarrell | and for the record I don't recommend any of these flags for normal production use |
| 09:07.12 | Stefan27 | Not DONT_OPTIMIZE either? |
| 09:07.57 | coreyfarrell | DONT_OPTIMIZE is ok... I was saying normally don't use any of the flags you posted to the channel |
| 09:09.27 | coreyfarrell | DONT_OPTIMIZE will slow down performance, but not as much as the DEBUG flags. if you have a performance need then you can disable DONT_OPTIMIZE but if you have a crash your backtraces would be less than helpful |
| 09:15.13 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 09:21.36 | Stefan27 | ok, im rebuilding. btw i noticed a lot of res_rtp_asterisk.c is affected by ifdef HAVE_PJPROJECT . i have pjprojects installed and asterisk decides to build with it. is there any nice way of turning this off (as a test-switch, since i dont use or load chan_pjsip atm)? |
| 09:22.43 | Stefan27 | some line in configure does:$as_echo "#define HAVE_PJPROJECT 1" >>confdefs.h but i dont wanna edit source since im not a master of the buildprocess |
| 09:23.44 | Stefan27 | is it enough to disable anything named *pj* in menuselect to make HAVE_PJPROJECTS false? |
| 09:25.12 | coreyfarrell | probably ./configure --without-pjproject - not sure though |
| 09:25.49 | Stefan27 | ill try that as well |
| 09:26.38 | coreyfarrell | I doubt it will change your results |
| 09:40.39 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 10:14.45 | wdoekes | Stefan27: do you have leaky sip dialogs? |
| 10:14.56 | wdoekes | (sip show objects) |
| 10:16.01 | wdoekes | those would keep those rtp sockets open, while you see 0 active calls, see review 4052 |
| 10:22.45 | coreyfarrell | wdoekes: that would only help if the dialogs were not unlinked from the dialogs container.. if they are unlinked but have a leaked reference I'm pretty sure the RTP would stay open but 'sip show objects' wouldn't show it |
| 10:34.39 | wdoekes | mm. right |
| 10:40.04 | Stefan27 | ill check sip show objects next time -- i should also mention that the source code is not entirely untouched 12.6.1 i added some patches for dialplan stuff and pattern-matching etc, i could try reproduce it with clean code so i can ticket it. |
| 10:43.35 | coreyfarrell | Stefan27: if you're having an issue it's always best to run with unmodified code, unless you know enough to fix the issue on your own :) |
| 10:45.04 | Stefan27 | youre right, i just thought none of my changes were relevant to dialog/RTP handling |
| 10:49.47 | coreyfarrell | your probably right, but if you need help then you will need to reproduce the issue with unmodified code. otherwise line numbers might not line up. also anyone trying to help should not be left second-guessing the unreviewed changes you've made |
| 10:50.36 | coreyfarrell | not saying your changes are bad, but they are an unknown to everyone except you |
| 10:51.20 | Stefan27 | yah, that's why i asked here for guidance instead of claiming it's a real issue to your jira. but if there's no quick fix, ill reproduce it cleanly and post logs |
| 10:51.52 | Stefan27 | it's just that my patches helps the set up of the test environment which produces the issue |
| 10:52.07 | Stefan27 | there's about 10-20 simultaneous calls, 100 sip devices |
| 11:17.28 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-xjxgioocbvjtpium) |
| 11:45.39 | tzafrir | asterisk 13 fails building on big endians? |
| 11:45.43 | tzafrir | https://buildd.debian.org/status/package.php?p=asterisk&suite=unstable |
| 11:48.42 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 11:53.54 | coreyfarrell | that would be a media formats conversion bug |
| 11:54.48 | tzafrir | https://issues.asterisk.org/jira/browse/ASTERISK-24458 |
| 11:55.03 | tzafrir | Should be simple. I'm just a bit busy now |
| 11:56.09 | hexanol | hey coreyfarrell |
| 11:56.33 | hexanol | I didn't have the time to test the patch you made for AST-24307 last week |
| 11:56.46 | coreyfarrell | tzafrir: should be a matter of replacing the line with: if (ast_format_cmp(frame->subclass.format, ast_format_slin) == AST_FORMAT_CMP_EQUAL) |
| 11:56.46 | hexanol | unfortunately |
| 11:56.54 | coreyfarrell | I don't have a way to test it though |
| 11:57.04 | hexanol | but I should be good to take a look on it today (I hope) |
| 11:57.23 | coreyfarrell | hexanol: I tested it last night, ran into an issue with the patch I had last week, fixed it and was successful (ran the full testsuite) |
| 11:59.34 | file | falls over |
| 12:00.00 | seanbright | props file up |
| 12:00.47 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:15.59 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:21.50 | *** join/#asterisk-dev dms1 (~dms1@2601:0:5480:1f7::1008) |
| 13:16.13 | *** part/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 13:20.00 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
| 13:32.55 | tm1000 | plays weekend at Bernie's with seanbright and file's body |
| 13:39.57 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-ojsbojlmjjrzvcmy) |
| 13:44.09 | file | tm1000, the players gonna play play play |
| 13:48.39 | leifmadsen | ohai |
| 13:50.12 | seanbright | o/ |
| 13:50.24 | seanbright | is still at the blackjack table |
| 13:50.33 | seanbright | i'm only down like $8k |
| 13:50.37 | seanbright | staging a comeback |
| 13:52.26 | leifmadsen | seanbright: nice moves! |
| 13:55.19 | Corydon76 | "only" |
| 13:57.49 | leifmadsen | seanbright: should have hung out with me, I made money :) |
| 14:00.19 | zerohalo | my liver hurts |
| 14:00.38 | Marquis42 | To quote Butthead (I think, maybe it was Beavis): "Ow my liver!" |
| 14:00.48 | zerohalo | hahahaha |
| 14:13.33 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jyvxssdruzrewnmf) |
| 14:24.21 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-brchqcszjddnidqh) |
| 14:30.38 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:30.38 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:30.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 14:42.48 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-psudlznpshrpmtfu) |
| 14:44.07 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-edjsqulfmfmykpnu) |
| 14:54.40 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 14:55.53 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:56.52 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
| 14:59.28 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-kmbbhuenafmhtnlc) |
| 15:12.44 | *** join/#asterisk-dev Devon__ (~Devon_@63.214.236.169) |
| 15:49.19 | dms1 | leedm777: So I'm wrapping my head around ARI and Stasis in the source . . and wether or not it makes sense to build a generic tts ari app that integrates with channel, etc. for playback with a registered stasis backend module that can do the heavy lifting with the audio frames. |
| 15:50.08 | dms1 | seems like a lot of levels of work to get the channel integration, and then to build something that tts stasis module backends can "register" to |
| 15:50.24 | dms1 | just wanted to check and make I wasn't missing something obvious |
| 15:50.30 | dms1 | *make sure |
| 15:52.30 | dms1 | file: I was thinking about modeling a quick and dirty tts module after the snoop module (seemingly a good example of frame level audio manipulation) |
| 15:52.37 | dms1 | (with stasis) |
| 15:52.58 | dms1 | but I'm still trying to determine how that bubbles up to being callable from ARI |
| 15:53.04 | dms1 | (if I were to do so) |
| 15:53.22 | dms1 | obviously the ARI modules all have the JSON handlers |
| 15:53.51 | file | they are defined in JSON, make ari-stubs is run, and boilerplate code is generated - then you write the functions they call (it won't write those) |
| 15:54.40 | dms1 | interesting . . is that process on the wiki? |
| 15:54.54 | dms1 | sounds like it'll make life easier . . which I'm always for |
| 15:55.00 | file | https://wiki.asterisk.org/wiki/display/AST/Create+a+new+resource+with+ARI |
| 15:55.19 | dms1 | sweet! :) |
| 15:55.20 | dms1 | thanks |
| 15:55.46 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-anhakjktrvbwnonq) |
| 15:57.40 | leifmadsen | +1 |
| 16:39.12 | gtjoseph | putnopvut: IOW, you still need an [identify] section to match the incoming invite to a specific endpoint, yes? |
| 16:40.35 | putnopvut | gtjoseph: yep |
| 16:40.56 | gtjoseph | ok, makes sense now |
| 16:41.03 | putnopvut | contact_user is most typically used if you don't want calls coming into the 's' extension by default. |
| 16:41.13 | putnopvut | Useful if you have multiple outbound registrations, for instance. |
| 16:41.51 | gtjoseph | got it, there was a similar capability in chan_sip in the registration line was there not? |
| 16:42.30 | putnopvut | There indeed was. |
| 16:42.50 | putnopvut | I think it was towards the end of the register line. |
| 16:43.14 | gtjoseph | got it |
| 16:49.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 17:14.19 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-iaywexzcernfgrdg) |
| 17:14.26 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:30.48 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:30.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:32.55 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:32.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:03.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 18:19.44 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 18:45.07 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 20:26.16 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:26.17 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:40.13 | file | rawr |
| 20:41.17 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:41.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:41.36 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-vvdyzhjzhiiqyhid) |
| 20:42.42 | tzafrir | seanbright, ping |
| 20:43.20 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-sohtndgwgiervtzk) |
| 20:43.26 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-bqtquwmjqqtkmvxe) |
| 20:44.18 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-yvnurbdjuytitqoe) |
| 20:46.13 | seanbright | tzafrir: yes sir |
| 20:46.16 | seanbright | i will revert |
| 20:46.20 | seanbright | :D |
| 20:47.34 | tzafrir | seanbright, what extra patch do you need for libopus support besides the changes in your review? |
| 20:48.17 | seanbright | https://github.com/seanbright/asterisk-opus |
| 20:48.29 | seanbright | but i haven't converted it to use the new format api yet |
| 20:54.00 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:00.50 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 21:00.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 22:42.03 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 22:42.03 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:09.56 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-yvnurbdjuytitqoe) |
| 23:21.41 | leifmadsen | I just used this image in our internal JIRA system to refute Asterisk being the issue with DTMF: https://c2.staticflickr.com/8/7066/6887097487_93159517cf_z.jpg |
| 23:56.29 | Marquis42 | lawl |
| 23:57.18 | *** join/#asterisk-dev datachomper (~russ@user-24-96-72-18.knology.net) |
