| 00:15.53 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 00:23.17 | *** join/#asterisk-dev asteriskmonkey (~Tardis@74-51-38-204.telnetcommunications.com) |
| 00:23.48 | asteriskmonkey | are you taking bugs for v10 of asterisk? |
| 00:43.41 | coreyf1513 | asteriskmonkey: security fixes only.. see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions |
| 00:44.27 | asteriskmonkey | thank you kindly.. i was going to report a bug with realtime, guess i have to check with 11 now... |
| 00:44.32 | asteriskmonkey | bug is here > http://pastebin.com/9kUGk7bw |
| 00:44.44 | asteriskmonkey | basically exten/callerid isnt being matched in realtime |
| 00:45.24 | asteriskmonkey | ill test 11, if someone wants to test 12 |
| 00:45.47 | asteriskmonkey | or if anyone knows about this one in general :/ i saw it as an issue back in 2006, perhaps its an age old bug that needs sorting |
| 01:02.46 | asteriskmonkey | issue is in Asterisk 11.4.0 aswell |
| 01:13.24 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:13.24 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:44.52 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zmzfjualthsdebah) |
| 01:44.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:49.21 | *** join/#asterisk-dev serafie (~erin@24.214.173.250) |
| 02:43.58 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:43.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:07.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.215) |
| 05:19.12 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 05:40.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.82) |
| 06:11.16 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 06:18.37 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 06:28.23 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 06:48.09 | wdoekes | asteriskmonkey: realtime dialplans are not heavily used and may have more bugs / missing features than you'd like |
| 06:48.35 | wdoekes | is my observation at least. |
| 07:53.52 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 08:30.43 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:30.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:34.27 | oej | Hello folks! |
| 10:09.18 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 10:09.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:32.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.97) |
| 10:44.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.97) |
| 11:19.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 11:32.10 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 11:47.34 | oej | Anyone around? Got questions about silence detection |
| 11:58.26 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 11:59.06 | oej | I want to delete chan_iax2.c |
| 12:01.23 | wdoekes | no problem, never used it |
| 12:02.35 | oej | I was just checking if I was alone in here :-) |
| 12:03.24 | wdoekes | so, your people detection works |
| 12:03.56 | oej | Yep. But there's too much silence in here. |
| 12:04.01 | wdoekes | unfortunately I've got 0 clue about silence detection |
| 12:04.02 | oej | Where are we going after 12? |
| 12:04.10 | oej | Then we're two :-) |
| 12:04.21 | oej | I need to finalize my work on comfort noise and silence suppression. |
| 12:04.30 | oej | Reading all kind of modules to understand. |
| 12:27.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 12:27.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:58.08 | oej | Astricon will be filled with Kamailio users, developers and speakers! |
| 13:08.34 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:08.34 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:08.47 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-uznptsxjnetnuxrs) |
| 13:12.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 13:33.44 | WIMPy | I have a core dump but I'm not sure where I should go from there. Seems to be in the channel, but what action is going on there? http://wimpy.yeti.dk/pastebin Can someone point me in some direction? |
| 13:35.41 | opticron | hmmm |
| 13:36.10 | WIMPy | This only happens when using call files. |
| 13:37.00 | opticron | it's trying to get the channel's private data from a channel pointer that looks very invalid |
| 13:37.03 | opticron | 0xf |
| 13:39.20 | WIMPy | But where does it come from at that point? pbx_extension_helper seems to be what executes the dial, right? |
| 13:40.03 | WIMPy | Where is the channel created? |
| 13:40.20 | WIMPy | Or is that while trying to create it? |
| 13:41.14 | opticron | hard to say, it feels like some information is missing between frame 1 and frame 2 |
| 13:41.46 | WIMPy | Er, what frames? |
| 13:42.44 | opticron | in the backtrace |
| 13:42.55 | opticron | #1 and #2 |
| 13:43.25 | WIMPy | Oh. Hmm. |
| 13:43.51 | WIMPy | Meaning I'm not the only one who wonders where the channel is created? |
| 13:46.23 | opticron | take a look in pbx_spool since that handles call files |
| 13:53.37 | WIMPy | No changes to pbx_spool since the last working version. |
| 13:58.07 | oej | Seems like soemone wants to indicate "proceeding" from the dialplan |
| 13:58.18 | oej | And the channel is missing in return chan->tech_pvt. |
| 13:58.28 | oej | The pointer to chan doesn't seem correct. |
| 13:58.54 | opticron | oej, right, but explain the jump from #2 to #1, I can't find that code path on a cursory reading |
| 13:59.31 | *** join/#asterisk-dev asteriskmonkey (~darlek@server.xcel.on.ca) |
| 13:59.50 | oej | agree, it looks fishy |
| 14:02.08 | opticron | whoa...the channel pointer provided is equal to the value of the proceeding |
| 14:02.20 | opticron | AST_CONTROL_PROCEEDING == 15 == 0xf |
| 14:02.35 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:02.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:03.09 | oej | ouch |
| 14:03.17 | WIMPy | still wonders what that means. |
| 14:03.32 | opticron | so something has the fixup function pointer as its indicate function pointer |
| 14:03.39 | WIMPy | Calling the same extension from any channel is fine. |
| 14:03.39 | opticron | blech |
| 14:03.45 | oej | So how did that end up as newchan in ast_unreal_fixup. |
| 14:03.50 | opticron | looks for copypasta errors |
| 14:07.25 | opticron | nothing obvious :/ |
| 14:07.55 | asteriskmonkey | Dear devs, ive posted this on JIRA https://issues.asterisk.org/jira/browse/ASTERISK-22345 , I appologies if i f'd up the formatting, let me know if I should can it or add more information |
| 14:08.03 | oej | Which version are we using, WIMPy? |
| 14:08.56 | WIMPy | trunk r396712 |
| 14:08.59 | opticron | oej, likely trunk given the unreal stuffs |
| 14:10.20 | WIMPy | I.e. the one before the bridge was removed from the channel structure. |
| 14:13.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-oainydwhygqsrmyg) |
| 14:13.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:14.01 | WIMPy | BTW: How are tech specific bridges handled now? |
| 14:14.45 | file | they are implemented as bridging technologies |
| 14:16.37 | WIMPy | Sounds like a whole lot of new fun. Any pointers to more information? |
| 14:16.51 | mjordan | heh |
| 14:17.00 | mjordan | mostly just development wiki pages right now |
| 14:17.12 | mjordan | we haven't translated the ramblings into coherent architecture discussions yet :-) |
| 14:17.22 | mjordan | but if you'd like to peruse the ramblings you're more than free to :-) |
| 14:17.24 | file | plus it depends on what information you seek |
| 14:17.51 | WIMPy | Just how to make it work again :-) |
| 14:18.21 | file | there is no guide to writing a module, but the ones that have been created can be used as a base |
| 14:18.35 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-lwfqirxkpzcxuivq) |
| 14:18.37 | mjordan | which one are you thinking of? |
| 14:18.42 | oej | File: WIMPy has a core dump to fix... |
| 14:18.49 | mjordan | ah |
| 14:18.55 | mjordan | WIMPy: pb? |
| 14:19.16 | opticron | http://wimpy.yeti.dk/pastebin |
| 14:19.20 | WIMPy | And on a completely unrelated story: I don;t knwo when it happens, but with the new bridging stuff, I sometimes get one-way-audio on sip2sip calls when Asterisk needs to transcode. |
| 14:19.25 | WIMPy | http://wimpy.yeti.dk/pastebin |
| 14:19.47 | file | oej, yes... |
| 14:20.20 | mjordan | well, that crash isn't really due to native bridging, from what I can tell |
| 14:20.29 | file | right. |
| 14:20.44 | WIMPy | No, that crash only happens when using call files. |
| 14:21.48 | mjordan | WIMPy: Can you create an issue with the pb and the call file that reproduces it? That's very odd |
| 14:23.11 | opticron | it sounds like the dialplan might be important as well |
| 14:23.44 | WIMPy | I just mentioned native bridging becase I use the last revision before the bridge was removed from the channel structure and I was wondering what needs to be done about that then. |
| 14:26.22 | file | BASICALLY instead of having a callback on the channel structure you write a self contained module which the bridging core will call into when native bridging can occur, it's up to you to return a yes/no for the decision process, and if yes then you will become the bridging technology in use |
| 14:26.46 | file | once that occurs you do whatever technology specific stuff needs to happen when the various bridging callbacks are invoked (channel joining, leaving) |
| 14:27.46 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:29.17 | mjordan | Slightly out of date UML diagram here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project#Asterisk12BridgingProject-Design |
| 14:29.43 | mjordan | A native bridging technology would be one of those that "inherit" from ast_bridge_technology, similar to simple_bridge or softmix_bridge |
| 14:29.53 | mjordan | (multiplexed is gone :-() |
| 14:42.51 | mjordan | WIMPy: there's also some good doxygen documentation of the APIs (bridge.h and to a lesser extant, bridge_channel.h) |
| 14:43.29 | mjordan | but writing a bridging module is a bit trickier than using the APIs in another module. You basically have to write a very special kind of module that fits within the overall larger framework, which really does need some additional architecture explanation that we haven't cleaned up from the notes on the wiki page yet |
| 14:45.24 | WIMPy | Sounds like it's getting complicated. |
| 14:46.45 | mjordan | It is complicated. Bridging is *hard* |
| 14:46.57 | mjordan | Doing it so that it is extensible and doesn't involve masquerades is *very* hard |
| 14:47.15 | mjordan | Doing it so that it also reasonably preserves backwards compatibility from a user's perspective, quite frankly, sucked :-) |
| 14:48.06 | mjordan | But it is extensible. You should take a look at app_agent_pool, which nuked the always-crashing-and-never-quite-worked-right chan_agent. It makes use of the bridging stuff in some rather creative ways |
| 14:48.14 | mjordan | and does so such that agents actually work |
| 15:06.59 | WIMPy | I don;t really need creative things. Actually it's more about the simples possible thing. Just that the channel knows so it can forward metadata. |
| 15:09.01 | Corydon76-work | WIMPy: on the contrary, you need it to work, no matter what the code complexity is |
| 15:10.02 | WIMPy | It would be nice if that worked again. I don't like things getting worse. |
| 15:13.51 | mjordan | well, the crashing Local channel is just bad, so that's obviously going to get fixed |
| 15:13.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.186.188.110) |
| 15:15.59 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:15.59 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:17.24 | tm1000 | file: can I pm you? |
| 15:17.28 | file | yes |
| 15:18.38 | tm1000 | mjordan: ping |
| 15:21.54 | mjordan | tm1000: rut roh |
| 15:21.58 | mjordan | tm1000: pong? |
| 15:22.06 | tm1000 | lol |
| 15:22.07 | file | don't worry, he just wants reviewboard access |
| 15:22.11 | mjordan | oic |
| 15:22.13 | mjordan | np! |
| 15:22.16 | tm1000 | mjordan: was going to see if the schmooze account had rb |
| 15:22.19 | tm1000 | but I think it does |
| 15:22.25 | mjordan | e-mail me your preferred username and credentials |
| 15:22.27 | mjordan | hm |
| 15:22.39 | mjordan | usually it's on a person by person basis, but we can create a generic schmooze account if you want |
| 15:24.09 | tm1000 | mjordan: tm1000 |
| 15:24.12 | tm1000 | thats my personal one |
| 15:24.22 | tm1000 | Ive already signed the license agreement a long time ago |
| 15:24.38 | mjordan | looks |
| 15:24.48 | mjordan | at rb, not the license stuff |
| 15:26.23 | mjordan | tm1000: do you want your e-mail address to be the same one in JIRA? |
| 15:26.49 | tm1000 | yeah |
| 15:26.58 | tm1000 | mjordan: its @schmooze? |
| 15:27.16 | tm1000 | ah |
| 15:27.16 | tm1000 | andrew.nagy@the159.com |
| 15:27.19 | tm1000 | ^ thats fine |
| 15:28.27 | mjordan | yup |
| 15:30.54 | tm1000 | mjordan: do I need to do a patch against svn |
| 15:31.05 | tm1000 | if/when submitting a patch.. |
| 15:33.51 | mjordan | tm1000: if it is a bug fix, then the patch should be made against the oldest supported branch |
| 15:33.58 | mjordan | tm1000: if it is a new feature, it should be made against trunk |
| 15:34.56 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Subversion+Usage#SubversionUsage-BranchMergingOrder and https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies for more info |
| 15:40.37 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 15:43.55 | asteriskmonkey | is michael young in dev? sorry dont know his alias |
| 15:49.23 | tm1000 | mjordan: can you get someone to approve my Digium License Agreement I thought I did it?? but I guess not.... |
| 15:57.18 | mjordan | sure |
| 15:58.06 | mjordan | may still take a bit, I'm not the one who does that :-) |
| 15:59.27 | tm1000 | yeah I know |
| 16:01.47 | Qwell | I wonder if I have to sign a new one... |
| 16:02.31 | file | now that's a good question |
| 16:22.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.186.188.110) |
| 16:27.46 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:27.46 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:46.19 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 17:23.58 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 17:23.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:24.09 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 18:21.17 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 18:25.30 | tzafrir | I seem to have a problem with SIP/TLS session getting rejected, |
| 18:26.22 | tzafrir | and I suspect that this is because the reader chan_sip.c:sip_tls_read() does not handle fragmented packets |
| 18:27.14 | tzafrir | I see that the sibling function sip_tcp_read() is much simpler. I wonder why is sip_tls_read() so complex |
| 18:47.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.230) |
| 19:01.27 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:01.27 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:07.24 | *** join/#asterisk-dev rmeyerriecks (~datachomp@nat/digium/x-uehxnpaglzsdtqju) |
| 20:31.43 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:31.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:32.08 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:32.08 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:34.53 | *** join/#asterisk-dev rmeyerriecks (~datachomp@nat/digium/x-bancpmboifdagqjf) |
| 20:50.49 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:48.35 | WIMPy | Oh, nice. Just got a core dump in sqlite when stopping asterisk. |
| 22:30.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.230) |
| 22:59.57 | coreyf1513 | WIMPy: how did you initiate asterisk shutdown? |
| 23:00.23 | WIMPy | ^C from "asterisk -gc" |
| 23:04.47 | coreyf1513 | I think that's not SHUTDOWN_NICE or better, so modules are never shutdown and dundi tried accessing ast_db after it was shutdown |
| 23:06.16 | coreyf1513 | 'thread apply all bt' would be helpful to confirm |
| 23:08.00 | WIMPy | is just eating. Will do in a few minutes. |
| 23:10.06 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-oainydwhygqsrmyg) |
| 23:21.25 | WIMPy | coreyf1513: output added |
| 23:24.04 | WIMPy | (wouldn't it be nice if you could rename files?) |
| 23:30.27 | coreyf1513 | WIMPy: yeah it's what I thought. SHUTDOWN_FAST skips module shutdown, then calls items registered with ast_register_atexit (this includes astdb shutdown). |
| 23:31.55 | *** join/#asterisk-dev asteriskmonkey (~Tardis@74-51-38-204.telnetcommunications.com) |
| 23:37.46 | coreyf1513 | WIMPy: I think this is actually a bug in asterisk core and astdb rather than dundi. dundi just exposed the bug |
| 23:41.40 | WIMPy | Well, not sure if it could matter on shutdown. But do you think there's a chance it could happen on some sort of reload? |
| 23:42.11 | coreyf1513 | on restart yes, but no way on reload |
| 23:42.48 | WIMPy | I guess it wouldn't restart it it happened on a restart. |
| 23:45.57 | coreyf1513 | depends on your init scripts. safe_asterisk should protect you i would think |