| 00:34.01 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 01:04.35 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 02:52.53 | *** join/#asterisk-dev chigambamukoko (~chatzilla@fl-76-3-18-120.dhcp.embarqhsd.net) |
| 03:22.00 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 03:22.00 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:48.05 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 03:48.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 05:02.49 | *** join/#asterisk-dev Corydon76-home (twelve@c-69-137-80-31.hsd1.tn.comcast.net) |
| 05:02.49 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 07:09.23 | *** join/#asterisk-dev issa__ (~chatzilla@77.42.241.114) |
| 07:11.35 | issa__ | hi all, when I pass through multiple channels for the same call using IAX protocol, I get a log message that we have a long voice queue, and the call hangup eventually |
| 07:24.11 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 07:34.52 | *** join/#asterisk-dev irroot (~gregory@197.106.68.172) |
| 07:40.51 | *** join/#asterisk-dev issa__ (~chatzilla@77.42.241.114) |
| 08:16.07 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 08:45.31 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:48.23 | issa__ | hi all |
| 08:51.34 | issa__ | when i call traverse more than 4 IAX2 channel before attempt the destination ,some probleme in queue lenght appear and the voice call is so bad |
| 09:12.33 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 09:31.28 | *** join/#asterisk-dev irroot (~gregory@197.104.217.69) |
| 11:14.58 | *** join/#asterisk-dev irroot (~gregory@197.104.76.228) |
| 11:41.35 | *** join/#asterisk-dev irroot (~gregory@41.53.116.195) |
| 12:01.59 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 12:02.03 | schmidts | Hi Folks |
| 12:02.06 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:02.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:13.46 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 12:18.44 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 12:22.45 | *** join/#asterisk-dev irroot (~gregory@197.109.188.198) |
| 12:30.48 | *** join/#asterisk-dev irroot (~gregory@41.55.56.97) |
| 12:49.19 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 12:52.16 | issa__ | hi all |
| 12:52.38 | issa__ | when a call traverse more than 4 IAX2 channel before attempt the destination ,some probleme in queue lenght appear and the voice quality is so bad |
| 13:05.38 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 13:06.14 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 13:15.06 | schmidts | Issa__ which asterisk version do you use? |
| 13:23.02 | issa__ | this probleme exist in the two asterisk version 1.4 and 1.6 |
| 13:24.24 | schmidts | issa__ you know support for both versions is allready over? |
| 13:25.13 | schmidts | you should try to reproduce this with 1.8, if this problem still exists then you could ask in #asterisk for help cause this channel is normally only for code development discussions and not for support ;) |
| 13:26.32 | issa__ | but the cause for this probleme can be the iax2 protocole <developped> in asterisk |
| 13:27.41 | schmidts | issa__ yes thats true, but even there is a bug with iax2 there will not be a fix for version 1.4 or 1.6 |
| 13:28.10 | schmidts | as i said please try 1.8 and if this problem still exists there |
| 13:28.48 | issa__ | thanks , i will try that |
| 13:30.37 | schmidts | good luck |
| 13:34.46 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:34.46 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:48.51 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bhhlmkcezsgxrxpi) |
| 13:48.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:01.29 | schmidts | mjordan does this segfault comes from confbridge after this change was done? IMHO confbridge shouldnt be touched by this change at all |
| 14:01.38 | schmidts | only the state change when a user left a conference |
| 14:01.59 | mjordan | yup, it has nothing to do with the change in question |
| 14:02.09 | mjordan | I added a ConfBridge test to the testsuite, so this is a brand new test |
| 14:02.16 | schmidts | aaah ok good to know |
| 14:02.30 | schmidts | i have really checked this review deeply and i was sure everything looks fine |
| 14:02.56 | mjordan | np :-) The test went into the TestSuite at about the same time a lot of people were making commits, so it just "lucked out" that way |
| 14:03.15 | schmidts | ;) ok |
| 14:03.46 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:03.46 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:04.47 | kpfleming | schmidts: mjordan: yay testing! |
| 14:05.17 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-otkpowbdecqmftjf) |
| 14:05.52 | schmidts | kpfleming it helps a lot ;) |
| 14:06.23 | schmidts | btw does anyone (specially the guys @digium) knows if jrose is allready up&running? |
| 14:07.27 | mjordan | schmidts: just poked my head down, nope |
| 14:09.09 | schmidts | :D |
| 14:12.20 | leifmadsen | up & atom! |
| 14:14.36 | kpfleming | getting awfully close to ASTERISK-20000 |
| 14:14.48 | schmidts | kpfleming is this something we should celebrate? |
| 14:14.49 | mjordan | I know, kind of exciting in a weird way |
| 14:15.05 | kpfleming | of course, all the issue cloning makes that number kind of pointless anyway |
| 14:15.32 | mjordan | quick! Clone 899 issues |
| 14:18.44 | leifmadsen | ya, getting to 20000 will be quick because everytime you clone and move an issue, you use up a new ASTERISK number |
| 14:39.23 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 14:43.23 | *** join/#asterisk-dev irroot (~gregory@197.169.80.70) |
| 14:52.49 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 14:56.19 | schmidts | leifmadsen maybe you should link this issue ASTERISK-19095 to the blocker of 1.8.9 ;) |
| 14:58.04 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-mxdusrysoskcivrt) |
| 14:58.53 | pabelanger | we should consider 1.8.8.1 if we broke MoH in 1.8.8.0 |
| 14:59.29 | schmidts | pabelanger its not completly broken only for local bridged calls |
| 15:00.07 | pabelanger | schmidts: still, we have a policy about regressions |
| 15:00.26 | schmidts | ok didnt know this ;) |
| 15:01.09 | pabelanger | mjordan: ^ |
| 15:01.41 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:01.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:02.12 | mjordan | pabelanger: schmidts: the -.1 releases would only be for security releases |
| 15:02.22 | mjordan | i.e., the fourth minor version number |
| 15:02.30 | mjordan | if its a regression in 1.8.8, it will be a blocker for 1.8.90 |
| 15:02.38 | mjordan | not 90, 9.0 |
| 15:04.05 | pabelanger | mjordan: no, we use the 4 number for both regressions and security releases |
| 15:04.27 | pabelanger | see 1.8.4.x |
| 15:04.39 | pabelanger | both security and cisco regressions |
| 15:05.37 | mjordan | pabelanger: I'm not sure that's the case still. I'm not aware of plans to do specific releases to address a single regression. I'm not saying that hasn't been done in the past. |
| 15:06.03 | leifmadsen | mjordan: not necessary -- the .1 can be used for regressions too |
| 15:06.22 | leifmadsen | the forth spot is not security only |
| 15:06.44 | leifmadsen | I'm not aware of any discussion that changed that policy |
| 15:06.51 | pabelanger | mjordan: then his is a chance in policy from the past. Usually, if we find a regression for the previous release, we attempt to fix and release asap |
| 15:08.02 | leifmadsen | there is a weight on what the regression is and what it affects, but I would suggest a MOH regression falls into a heavier weight than say, chan_h323 |
| 15:09.58 | pabelanger | ack'd |
| 15:10.33 | pabelanger | we really should write the process down, and start tracking examples |
| 15:20.00 | schmidts | mjordan when i read the log of the confbridge crash i am not sure if it wasnt the change of rmudgett cause it happend on a statechange |
| 15:20.51 | mjordan | schmidts: are you talking about the statechange ami events? |
| 15:21.24 | mjordan | ah, nm |
| 15:21.25 | mjordan | you're not |
| 15:21.47 | schmidts | if you say so i will believe it ;) |
| 15:26.37 | schmidts | now to something different, does the pbx_run function knows which channel hangs up a call? |
| 15:27.29 | mjordan | schmidts: maybe, but I'm not sure. The only way rmudgett's change would have caused the behavior in confbridge is if it somehow could cause a deref of a channel to occur twice, and the change in how the ast_state_cb is destroyed doesn't seem to be able to do that. I'll discuss it with him, however. (The other reason I'm not sure is because there are a few other ConfBridge related issues that seem to point towards this same problem, |
| 15:28.16 | schmidts | mjordan ok i see, thats good to know then. |
| 15:35.43 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:35.43 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:50.31 | schmidts | about this tests, do they have to be written in python? |
| 15:53.02 | schmidts | forget it, doing a simple ls in the tests dir answers this question ;) |
| 15:58.16 | Qwell | There is a framework in there for LUA, but yeah, python is the way to go. |
| 15:59.00 | schmidts | Qwell thanks, my problem is understand neither LUA nor python ;) |
| 15:59.46 | Qwell | welcome to the club |
| 16:00.12 | schmidts | so normal easy and fast tests written in C will be ignored? |
| 16:00.29 | Qwell | well, there are some tests inside of Asterisk, which are C, of course. |
| 16:00.35 | Qwell | it just depends on what it's testing. |
| 16:00.54 | Qwell | We'd like to keep external tests in one language, for maintenance reasons. |
| 16:01.30 | schmidts | Qwell i understand this |
| 16:03.22 | schmidts | wish all a very nice christmas, a lot of gifts, time to relax and a great time with your family!!! |
| 16:31.13 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:31.14 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:08.33 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 17:08.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:09.44 | seanbright | ast_test_flag(flags, SOMETHING | ELSE) |
| 17:10.01 | seanbright | that will return non-zero if either of those flags is set, right? |
| 17:11.39 | kpfleming | yes |
| 17:15.27 | seanbright | thanks |
| 17:17.21 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:17.22 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:53.31 | kpfleming | seanbright: nice patch! |
| 17:53.53 | kpfleming | although you should probably update your installation of repotools to generate the new-style merge commit messages |
| 17:57.03 | seanbright | will do |
| 18:00.00 | seanbright | chanspying on a call was causing the spied-on call to start chopping up |
| 18:00.10 | seanbright | this was an attempt to reduce that... although i'm not sure it was 100% effective yet |
| 18:00.12 | kpfleming | too much CPU consumption? |
| 18:00.41 | seanbright | i think it was just taking too much time working through the hooks that were attached to the channel |
| 18:00.53 | kpfleming | ahh.. and delaying packet forwarding. |
| 18:01.23 | seanbright | again this is purelys speculative as i haven't done the necessarry instrumentation |
| 18:01.32 | kpfleming | hook up the EKG, etc. |
| 18:01.38 | seanbright | right |
| 18:19.31 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:24.54 | seanbright | so reading the code again... if a whisper or manipulate hook are on a channel, then frames are transcoded to slin and back even if the hooks aren't running |
| 18:28.54 | kpfleming | ouch |
| 18:29.02 | kpfleming | that could be expensive |
| 18:29.33 | kpfleming | and that could explain why we've had bizarre reports of excess G.729 encoders/decoders in use on systems where Chanspy/Mixmonitor are being used |
| 18:29.53 | Qwell | that doesn't seem ideal |
| 18:31.45 | kpfleming | my lack of lunch is also not ideal |
| 18:49.32 | jrose_atDigium | Hey, are multiple passes through a config file during reload something we generally allow? I'm looking at this patch for chan_sip that basically adds an option to not purge the peers created with autocreatepeer enabled, but the peer destruction and evaluating the conditions for destruction are handled at the beginning of the reload phase before actually checking the config file for the variable that sets whether or not we should |
| 18:49.33 | jrose_atDigium | be deleting those peers. The only simple ways I can think to resolve it would be to either move the peer destruction to after the general section of the config file is read or to read the general section specifically for that variable before deleting the peers. |
| 18:50.36 | jrose_atDigium | https://issues.asterisk.org/jira/browse/ASTERISK-16507 |
| 18:51.07 | mjordan | jrose_atDigium: I would expect at the least that we wouldn't want to pass through all of the configuration information twice |
| 18:51.27 | jrose_atDigium | Not all of the configuration information, just the general section, but that does still seem less than ideal. |
| 18:52.08 | jrose_atDigium | At the same time though, reload isn't something that happens with any frequency, so from a performance standpoint it's more or less irrelevant. |
| 18:52.14 | mjordan | given that the config API lets you look up a specific variable, that seems unnecessary as well. Ideally you wouldn't blow out the previous configuration information / peers until you had read in the new ones, but that may be beyond the scope of what you're looking at |
| 18:52.26 | mjordan | I don't think its irrelevant |
| 18:52.36 | mjordan | there are people who reload sip peers a lot. |
| 18:52.50 | jrose_atDigium | Yeah, but the whole thing takes like a second. |
| 18:52.52 | *** join/#asterisk-dev moy (~moy@189.172.62.190) |
| 18:52.55 | mjordan | if that takes a long time, then during that period their system is in something of an unknown state, particularly if we remove the peers at the beginning |
| 18:53.04 | jrose_atDigium | True. |
| 18:53.04 | mjordan | the answer isn't to make that take longer |
| 18:53.07 | mjordan | :-) |
| 18:53.18 | jrose_atDigium | Though I would say that this wouldn't increase the length of that window. |
| 18:53.32 | jrose_atDigium | Since the additional read would be occuring before the removal of peers. |
| 18:53.43 | jrose_atDigium | Though I think the peers might be locked during that time... |
| 18:54.02 | mjordan | I'm not going to be a fan of something that increase risk during a reload, given the number of issues we've had with reload problems. |
| 18:54.51 | jrose_atDigium | I'm a little more worried about doing it the other way though. Changing when we delete peers seems like it could carry some risk. |
| 18:55.49 | mjordan | it does. Hence the "beyond the scope of what you're looking at" :-) |
| 18:57.32 | jrose_atDigium | I guess I could just not worry about it. Hopefully people won't be wanting to really change between the different autocreate peer modes during runtime. |
| 18:59.04 | jrose_atDigium | I'll just document the quirk and add some quirky behavior comments to the surrounding area of code. |
| 18:59.29 | Qwell | why don't we just read general first, then do peer stuffs? |
| 19:00.03 | jrose_atDigium | That was the other option I was talking about. I was just worried it could cause some errant behavior. |
| 19:00.35 | jrose_atDigium | Actually though, it might be better overall. I'll try that real quick. |
| 19:01.51 | Qwell | There's already a bunch of stuff done between the two |
| 19:34.31 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 19:57.22 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 20:51.58 | seanbright | kpfleming: is there a simple way to detect processor support for mmx? |
| 20:52.07 | seanbright | i feel like you'd know these things |
| 20:53.08 | WIMPy | /proc/cpuinfo? |
| 20:54.32 | seanbright | i'm looking for a build time check |
| 20:56.48 | WIMPy | You can probably copy it from things like mplayer, if you don't like to grep. |
| 20:57.33 | seanbright | don't like to grep? how do you mean? |
| 20:58.39 | WIMPy | if [ grep -q " mmx " /proc/cpuinfo ] |
| 20:58.46 | seanbright | ah |
| 20:59.06 | seanbright | that wouldn't work for cross compiling i don't think |
| 20:59.29 | WIMPy | No, that would be th host CPU. |
| 20:59.58 | WIMPy | But if you have another target, you need to specify that anyway. |
| 21:05.08 | seanbright | might just not auto detect and force an --enable-mmx configure option or something |
| 21:14.26 | kpfleming | you can't detect something at build time if you are cross-compiling :-) |
| 21:14.37 | seanbright | you make a good point |
| 21:15.10 | kpfleming | occasionally, but i try not to make a habit of it |
| 21:15.46 | WIMPy | :-) |
| 21:15.49 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 21:16.06 | kpfleming | but really, there are exceedingly few x86 processors in the real world today that don't have MMX support. certainly everything being currently sold has it. |
| 21:21.54 | seanbright | alrighty |
| 22:04.38 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-bhhlmkcezsgxrxpi) |
| 22:05.52 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-qyzzgsggcbfwumnr) |
| 22:08.25 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-ubdatliymnwibjci) |