| 00:05.54 | Micc | whats this new thing I see in 1.8 now ? ast_set_owners_and_peers: setting peeraccount to 2091 for SIP/20910-00000483 from data on channel SIP/360-outbound-00000484 |
| 00:06.14 | Micc | I wonder if I need to look into that to figure out this parking problem. |
| 00:06.32 | Micc | inbound calls can park fine. outbound calls that are parked don't have a parkinglot so it uses the default. |
| 00:07.02 | Micc | parking is all messed up in 1.8 but I can't see much difference in the code yet. |
| 01:09.00 | Micc | in 1.8 is it by design that each parking lot must have their own parkexten that is unique? |
| 01:09.36 | Micc | I suppose it makes sense, but I'll have to reprogram a bunch of phones if thats the case. |
| 02:03.35 | Micc | parking is definately leaking ref counts. |
| 02:03.39 | Micc | in 1.8.5.0 |
| 02:11.31 | *** join/#asterisk-dev seraphie (~erin@207.98.195.107) |
| 04:17.07 | *** join/#asterisk-dev aimka (~aimka@unaffiliated/aimka) |
| 04:42.54 | Micc | I don't need to spend a bunch of time seeing if ao2_callback is doing things right do I? I would assume its pretty solid and the problem is somewhere in the way the ao2 functions are being called. Is that a safe assumption? |
| 04:45.11 | snuff-work | yes |
| 05:04.37 | Micc | could not decrementing a ref count on an object cause a deadlock? |
| 05:05.22 | Micc | I've fixed the ref count problem but I have no repro case for the dead lock so I have no idea if that would fix it or not. |
| 05:16.48 | Micc | I think I'm ready to give up on 1.8.5.0. Time to go back to 1.6.2.19 with the less frequent device_state_change hint dead lock. |
| 05:29.46 | *** join/#asterisk-dev Micc (~Micc@c-98-232-41-66.hsd1.wa.comcast.net) |
| 05:40.35 | *** join/#asterisk-dev Micc_ (~Micc@c-98-232-41-66.hsd1.wa.comcast.net) |
| 05:57.49 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:8ddb:5359:c423:d468) |
| 06:12.20 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:12.22 | schmidts | good morning |
| 06:13.22 | Micc | it'll be morning here in another hour. |
| 06:21.48 | schmidts | Micc its allways a point of view ;) |
| 06:28.08 | jmls | guys, in 1.8 and above, the demo dialplan uses option 2 to switch to french. However, it looks like the function LANGUAGE has long since gone, replaced by set(channel(language)=fr) |
| 06:28.12 | jmls | or is it just me ? |
| 06:30.29 | schmidts | do you really want an answer to this question jmls? :D |
| 06:30.38 | schmidts | but you are right ;) |
| 06:30.52 | schmidts | i guess the demo dialplan wasnt touched since 1.4 |
| 06:32.50 | wdoekes2 | Micc: see M18136 if you're going to run 1.6.2.19 |
| 06:33.49 | schmidts | wdoekes2 i have downgrade to 1.6.2.18.2 yesterday cause i had around 5 locks per day |
| 06:34.05 | wdoekes2 | try undoing only that specific rev |
| 06:35.11 | schmidts | i will try to do this on a test machine, couldnt put it again on this production machine or my customer will kill me |
| 06:38.16 | Micc | wdoekes2, any idea how to fix it yet? |
| 06:39.20 | Micc | I had locks in 1.6.2.18.2 too. |
| 06:46.58 | Micc | I had a lock every hour and a half today |
| 06:47.12 | Micc | I was shaking all day long. 100 customers on that server. |
| 06:47.23 | Micc | couldn't even go to the bathroom. |
| 06:51.35 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 06:53.40 | Micc | wdoekes2, do you have a core show locks when that deadlock happened? |
| 06:54.05 | wdoekes2 | no, I don't build with debug-locks |
| 06:55.42 | Micc | there were a bunch of useful fixes in 1.6.2.19 that I liked, but I suppose I'll have to go back to 1.6.2.17 or something. |
| 06:55.55 | Micc | or 18.2 |
| 06:56.13 | wdoekes2 | I went back to 1.6.2.17.3 + the two security fixes from 18 |
| 06:56.17 | Micc | I think I was on 18.2 for a while without any issues except for a once a week lock in blf. |
| 06:56.20 | wdoekes2 | + a shitload of patches |
| 06:56.25 | wdoekes2 | most of which went into 19 |
| 06:56.38 | Micc | why wouldn't you just use 18.2? |
| 06:56.44 | wdoekes2 | because of the Via issue |
| 06:57.23 | wdoekes2 | I waited for someone to fix that before I tested a new version |
| 06:57.28 | Micc | wouldn't it be easier to use 18.2 and just fix the via issue? |
| 06:58.09 | wdoekes2 | hardly: (1) I haven't run 18, so I'm not going to anymore, (2) there are no fixes I need in 18 (except for the two security fixes) |
| 07:01.06 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:01.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:01.54 | Micc | what does the via issue break? |
| 07:02.47 | wdoekes2 | some devices that don't accept traffic back on the port they send from |
| 07:03.48 | wdoekes2 | with nat=no, expected behaviour is for asterisk to send to the port in the Via, but .18 doesn't |
| 07:04.06 | Micc | I don't have 1.6.2.17.3, but I have 1.6.2.17.2, is there anything important in the .3? |
| 07:04.25 | wdoekes2 | don't know off-hand.. security fix, I suppose :) |
| 07:05.00 | wdoekes2 | tcp/tls socket hogging |
| 07:05.29 | Micc | oh, well I don't care about that. |
| 07:06.12 | Micc | now if I can find those two security patches and apply them to 1.6.2.17.2 I think I'll be good. |
| 07:06.25 | wdoekes2 | http://downloads.asterisk.org/pub/telephony/asterisk/old-releases/asterisk-1.6.2.17.3-patch.gz |
| 07:07.43 | wdoekes2 | there is a permissions check for originate too (that you need system permissions for some applications), but that shouldn't affect sane setups |
| 07:08.37 | Micc | can I get the 1.6.2.18.2 security patches by themselves? |
| 07:10.12 | Micc | I found the security bulletin, but not sure where I can get the patch. |
| 07:11.07 | Micc | Oh, nevermind I found it. |
| 07:11.39 | Micc | says the file isn't found. |
| 07:11.55 | Micc | nevermind, they spelled it wrong. |
| 07:21.23 | Micc | I'm starting to think I need to start my own branch of asterisk. |
| 07:21.41 | Micc | only include the patches I need. |
| 07:52.25 | Micc_ | I can finally sleep back on 1.6.2 now. |
| 07:52.46 | Micc_ | good night. |
| 07:56.32 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 10:27.59 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 10:39.30 | *** join/#asterisk-dev fulcan (~root@li345-191.members.linode.com) |
| 11:56.28 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:56.28 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:13.39 | *** join/#asterisk-dev t_dot_zilla (~t_dot_zil@firewall-a.buf.ny.i-evolve.net) |
| 12:54.16 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:13.56 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 13:31.01 | *** join/#asterisk-dev luminforce (~luminforc@rrcs-71-42-183-54.sw.biz.rr.com) |
| 14:04.58 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:04.58 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:11.42 | irroot | putnopvut greets ... |
| 14:11.54 | putnopvut | hello irroot |
| 14:11.58 | irroot | race condition perhaps in app_queue and pickup |
| 14:12.18 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:12.18 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:12.59 | irroot | if pickup picks up a call that is gone the channel sits there and cant be killed |
| 14:13.29 | irroot | looks like there might not be a pbx runing on it |
| 14:13.42 | irroot | or no autoservice started |
| 14:15.55 | irroot | but not sure |
| 14:35.00 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:35.00 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:36.18 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:36.18 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:39.51 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-amgdchiweqdbgqma) |
| 14:59.36 | *** join/#asterisk-dev dms (~Adium@nat/digium/x-maogqgptmuzbmwip) |
| 14:59.51 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:59.52 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:00.49 | *** join/#asterisk-dev bklang (~bklang@c-67-165-218-19.hsd1.co.comcast.net) |
| 15:07.48 | irroot | ok if a pickup completes can we kill a chan if there is no pbx/autoservice or should we start it .... re channels been orphaned and not be able to be killed |
| 15:19.51 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:19.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:36.50 | *** part/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 15:48.44 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 16:04.22 | luminforce | should this Via header be considered valid, specifically the 5060=5060 for the port? Via: SIP/2.0/UDP vendor.address:5060=5060;... |
| 16:05.49 | kpfleming | vendor.address is some sort of extension, and thus the format of it is up to that vendor |
| 16:06.11 | kpfleming | unless those are placeholders... in which case no, 5060=5060 is not valid |
| 16:09.38 | luminforce | yes, i replaced their ip address 1.2.3.4 (whatever) with vendor.address. |
| 16:09.59 | kpfleming | ok |
| 16:10.04 | luminforce | thank you. |
| 16:10.07 | kpfleming | sure! |
| 16:25.37 | tzafrir | I wonder if the following is useful for the general public: |
| 16:26.22 | tzafrir | we test new versions of dahdi using live_dahdi. Which means we generate a new config each time we load the system |
| 16:29.08 | kpfleming | who is 'we'? |
| 16:36.49 | Kobaz | we be codin |
| 16:40.56 | tzafrir | "we" is testing internally in Xorcom |
| 16:41.24 | kpfleming | well, i suppose that then depends on how you define 'useful' and how you'd plan to make such a statemetn |
| 16:41.29 | tzafrir | anyway, some of the systems we test with are FreePBX ones, |
| 16:42.06 | tzafrir | and this means we need to generate configuration for the FXS extentions that should be managed by FreePBX, |
| 16:42.23 | tzafrir | Sadly FreePBX does not provide you a sane way to do that automatically, |
| 16:43.06 | tzafrir | So I now wrote an extra perl module for dahdi_genconf to generate the extra astdb entries required for the FreePBX dialplan |
| 16:43.21 | tzafrir | to identify the new FXS extensions |
| 16:43.44 | tzafrir | that is: by running 'dahdi_genconf freepbx' (asterisk needs to be running) |
| 16:44.00 | tzafrir | Does that module sound useful? |
| 16:44.22 | kpfleming | i couldn't begin to guess, not being a FreePBX user myself |
| 16:45.14 | tzafrir | I ended up using astcli rather than asterisk -rx, as asterisk -rx is plain slow |
| 16:45.38 | tzafrir | 0.5 second per command |
| 16:46.32 | tzafrir | I still wonder if it won't be simpler to write directly to the asterisk control socket |
| 16:47.13 | kpfleming | for asterisk 1.10, you will able to just update the astdb directly, although you'd need to restart asterisk to get it to see the changes |
| 16:48.08 | tzafrir | restart asterisk? isn't there a simple 'database refresh' or something? |
| 16:48.29 | kpfleming | i don't think that was added, no. it would be a good idea though. |
| 16:48.44 | tzafrir | (and no: 1.10 is not practical for me ATM) |
| 17:00.41 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |
| 17:06.25 | *** join/#asterisk-dev moy (~moy@CPE002719f00364-CM0026f3a1701d.cpe.net.cable.rogers.com) |
| 17:30.29 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:30.29 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:49.49 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:49.49 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 17:50.18 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 18:19.49 | *** join/#asterisk-dev JonathanRose (~jonathan@nat/digium/x-nrvfquzofqiewjod) |
| 18:19.55 | JonathanRose | join #asterisk-social canada |
| 18:28.26 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:28.27 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 18:50.57 | pabelanger | JonathanRose: fail |
| 18:54.20 | JonathanRose | More like... |
| 18:54.25 | JonathanRose | <PROTECTED> |
| 19:15.34 | *** join/#asterisk-dev irroot (~irroot@197.168.155.9) |
| 19:15.54 | irroot | evening |
| 19:16.22 | irroot | any objections to starting autoservice on the channel after pickup |
| 19:24.06 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:24.06 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:31.20 | irroot | this floating channel is driving me nuts |
| 19:33.25 | *** part/#asterisk-dev t_dot_zilla (~t_dot_zil@firewall-a.buf.ny.i-evolve.net) |
| 19:34.56 | *** join/#asterisk-dev suzie_needsdoosh (~t_dot_zil@firewall-a.buf.ny.i-evolve.net) |
| 19:43.35 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 19:43.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:58.30 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 20:03.51 | irroot | ping russellb |
| 20:04.48 | irroot | dude managed to hook up some time to sort pickup problem out with orphaned channels |
| 20:05.04 | irroot | no thread is running on the picked up channel |
| 20:07.31 | kpfleming | is the channel in autoservice? |
| 20:07.53 | irroot | nope |
| 20:08.12 | irroot | no "pbx" or "autoservice" thread |
| 20:08.14 | kpfleming | that is ungood |
| 20:08.18 | irroot | thats the proble |
| 20:08.22 | irroot | m |
| 20:08.47 | irroot | its staying locked in the channel list and only a kill sorts it out [-9] |
| 20:10.05 | irroot | this is introduced with the pickup fixups |
| 20:10.14 | irroot | esp with app_queue |
| 20:11.18 | irroot | kpfleming should autoservice be started after masq to ensure this or should it be ripped out at this point |
| 20:11.38 | kpfleming | i can't say, i'd have to see the sequence of operations on the various channels involved |
| 20:11.52 | kpfleming | but i was asking because any channel that isn't dead should be serviced by *some* thread |
| 20:11.59 | kpfleming | otherwise it's an orphan, as you say |
| 20:12.38 | kpfleming | even a 'dead' channel should be in the process of being cleaned up by a thread |
| 20:14.28 | irroot | im testing starting autoservice at the end of the pickup atleast this way it will be cleared |
| 20:15.46 | irroot | its happening daily on various sites so will be able to gage any problems and report back |
| 20:27.35 | mickecarlsson | leifmadsen notes added to ASTERISK-18103 |
| 20:30.55 | jmls | ouch |
| 20:31.03 | jmls | just downloaded 1.10 head |
| 20:31.09 | jmls | compiled no errors |
| 20:31.22 | jmls | starting up, get several messages like " Error loading module 'format_sln16.so': /usr/lib/asterisk/modules/format_sln16.so: undefined symbol: ast_format_unregister" |
| 20:31.30 | jmls | wait |
| 20:31.37 | kpfleming | yep.. old modules |
| 20:31.39 | jmls | didn't clear out the modules |
| 20:31.42 | russellb | correct |
| 20:31.44 | jmls | heh |
| 20:32.00 | kpfleming | it's a good thing we don't rename modules very often, it's painful |
| 20:32.07 | jmls | wtf does that always happen the second I hit the ENTER key ? |
| 20:32.30 | kpfleming | russellb: probably should have the 1.10 makefile explicitly remove format_sln16 if it's in the modules directory.. we've done that sort of thing before |
| 20:32.44 | jmls | it's like my brain goes "wait .. wait ... wait ... yup. posted. Now remember why. Bing!" |
| 20:33.10 | irroot | i use a /moudules-1.4 .... scheme |
| 20:33.21 | kpfleming | jmls: did 'make install' not warn you about the module being present? it should have. |
| 20:33.23 | irroot | on the distro i ship |
| 20:33.33 | jmls | whassa moudule ? ;) |
| 20:33.44 | irroot | hehe |
| 20:33.45 | jmls | kpfleming: nope. don't think so. Will check |
| 20:34.20 | irroot | not a bad idea to maybe put it in the UPGRADE file ... "clean out old module directory" |
| 20:34.25 | russellb | yeah, it should have ... |
| 20:34.28 | jmls | nope. no message |
| 20:34.29 | russellb | irroot: that's true for any upgrade |
| 20:34.38 | kpfleming | jmls: well, that's ungood. |
| 20:34.38 | russellb | it's also in the book :-p |
| 20:34.47 | jmls | yay! my first 1.10 bug ! |
| 20:34.52 | jmls | jsmith: take note :) |
| 20:35.03 | jmls | I'm baaaaaaaaaacccckkkk |
| 20:35.21 | irroot | has not been prone to reading manuals .... |
| 20:35.52 | *** part/#asterisk-dev luminforce (~luminforc@rrcs-71-42-183-54.sw.biz.rr.com) |
| 20:36.37 | jmls | mmm. dinner. laters. |
| 20:37.02 | irroot | teleport me some ... |
| 20:41.12 | kpfleming | confirmed; i installed 1.8, then 1.10, and did not receive a warning about extra modules |
| 20:43.27 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 20:43.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:43.45 | russellb | jmls: well please file a bug when you get a chance |
| 20:43.53 | kpfleming | i'm alreadying fixing it :-) |
| 20:43.57 | kpfleming | wait... already |
| 20:44.33 | russellb | heh k |
| 20:48.54 | kpfleming | it's the double-quote stuff that was put around DESTDIR references some time ago... $(wildcard ...) doesn't like it |
| 21:16.35 | kpfleming | russellb: ping |
| 21:16.39 | russellb | pong |
| 21:16.44 | russellb | otherwiseguy did it |
| 21:17.33 | kpfleming | tilghman's revision 299794 was a partial solution to handling spaces in paths (specifically DESTDIR)... however, it does not work completely (much at all, really) and it breaks the Makefile logic that tries to remove stale headers and warn about stale modules |
| 21:17.52 | kpfleming | my suggestion is that we revert it, since there's not an overwhelming cry for support DESTDIR paths with spaces in them |
| 21:17.58 | russellb | works for me |
| 21:18.53 | kpfleming | gnu make has a *lot* of problems handling spaces in pathnames. making it work properly would cost someone a couple of days, i expect. |
| 21:19.19 | russellb | and not worth it |
| 21:25.47 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 21:25.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:55.05 | Corydon76-home | kpfleming: The standard paths on Mac OS X have spaces in the PATH. |
| 21:55.30 | kpfleming | i know |
| 21:55.37 | kpfleming | but that stuff was still not able to work properly |
| 21:55.53 | kpfleming | i tried it on my system with DESTDIR containing spaces, and it was broken all over the place. |
| 21:55.57 | Corydon76-home | I think I eventually coded around it by creating symlinks |
| 21:56.04 | kpfleming | i spent half an hour starting to clear i up, but some stuff still failed. |
| 21:56.23 | Corydon76-home | and then using the symlinks for the Makefile logic |
| 21:57.36 | Corydon76-home | I think if we generalize that approach, we might be able to create a usable framework to work with paths with spaces |
| 21:57.58 | Corydon76-home | Maybe remove the symlinks after Makefile logic is done? |
| 21:58.03 | kpfleming | well, 'we' will have to be someone else. i can't spend the time to do it, and there are very few users having trouble with it right now, it seems. |
| 21:58.43 | Corydon76-home | Well, the OSX test system relies upon those spaces-in-paths... so if you revert the fix, you will break the build |
| 21:59.35 | kpfleming | it's already done, so it may be broken |
| 22:00.02 | kpfleming | but i don't understand how it could have worked before. i couldn't even get 25% into 'make install' with a path that contained spaces. |
| 22:01.30 | Corydon76-home | It was designed around the "Application Support" path in OS X, and it was not tested against any other path |
| 22:02.02 | Corydon76-home | "/Library/Application Support/Asterisk" is the specific path |
| 22:02.22 | kpfleming | well, i don't mean to be harsh, but that's really not acceptable. either the build system supports paths with embedded spaces, or it doesn't. |
| 22:02.51 | kpfleming | it did not work with DESTDIR containing spaces at all, which is what i tested |
| 22:02.51 | Corydon76-home | Fair enough. |
| 22:04.00 | kpfleming | i could support some sort of 'pre-install' and 'post-install' mechanism that could run platform-specific scripts to setup and teardown symlinks, if that would work around the majority of the issues |
| 22:04.04 | Corydon76-home | You reverted all 3 maintained branches? |
| 22:04.08 | kpfleming | yes |
| 22:05.22 | Corydon76-home | Okay, I'll look at fixing it with a better patch, then. Olle will probably be complaining about the breakage in another 3-5 days |
| 22:05.30 | kpfleming | probably so |
| 22:31.04 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 22:31.04 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 23:25.26 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |