| 00:02.58 | frieze | thanks |
| 00:03.13 | frieze | right now it seems to crash before calling load_module, which make me somewhat suspicious |
| 00:03.19 | seanbright | one problem is that it might not be linking against libbluetooth |
| 00:04.25 | frieze | hcitool built and runs fine, so it looks like configuration exploration time for me |
| 00:04.33 | seanbright | hmmm |
| 00:04.34 | seanbright | ok |
| 00:04.43 | seanbright | compile with DONT_OPTIMIZE turned on |
| 00:04.49 | seanbright | so you can get backtraces |
| 00:07.10 | frieze | making addons or asterisk |
| 00:07.32 | seanbright | oh right... hrmm |
| 00:10.04 | *** join/#asterisk-dev stevie_ramjet (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 00:10.04 | *** mode/#asterisk-dev [+o stevie_ramjet] by ChanServ |
| 00:13.51 | frieze | plus the bluetooth library is right where it is supposed to be in /usr/lib/libbluetooth.so |
| 00:14.46 | kpfleming | what does 'ldconfig chan_mobile.so' report? |
| 00:16.04 | frieze | weird |
| 00:16.09 | frieze | <PROTECTED> |
| 00:16.11 | frieze | there we go |
| 00:16.22 | kpfleming | umm? |
| 00:17.26 | frieze | i mostly meant that it was weird that i couldn't paste. then I realized i was trying to do a /sbin command |
| 00:17.32 | kpfleming | sorry, wrong command |
| 00:17.50 | kpfleming | i meant 'ldd chan_mobile.so' |
| 00:18.10 | frieze | linux-vdso.so.1 => (0x00007fff88bfe000) |
| 00:18.11 | frieze | <PROTECTED> |
| 00:18.11 | frieze | <PROTECTED> |
| 00:18.20 | kpfleming | that's it? |
| 00:18.32 | frieze | yup |
| 00:18.39 | kpfleming | it did not get linked to libbluetooth |
| 00:18.44 | seanbright | its not linking libbluetooth |
| 00:18.47 | seanbright | woops |
| 00:18.48 | kpfleming | right |
| 00:18.49 | seanbright | what he said |
| 00:18.50 | frieze | looks like there's something wonky with the makefile somewhere |
| 00:18.58 | frieze | or the includes |
| 00:20.11 | kpfleming | not the includes... then it wouldn't compile |
| 00:20.17 | kpfleming | hang on, i'll look in a minute |
| 00:20.22 | kpfleming | what branch/version are you building? |
| 00:20.36 | seanbright | he's using a custom backport with trunk |
| 00:20.43 | kpfleming | umm. oh |
| 00:20.47 | seanbright | yeah |
| 00:20.48 | kpfleming | can't help with that then |
| 00:20.51 | seanbright | i wrote it |
| 00:20.51 | seanbright | heh |
| 00:20.56 | seanbright | or patched it, anyway. |
| 00:22.17 | seanbright | ahhh |
| 00:22.18 | seanbright | got it |
| 00:22.36 | seanbright | frieze: i'll have another patch in a moment |
| 00:22.50 | frieze | thanks |
| 00:23.06 | frieze | I can never remember how the whole recursive makefile deal works |
| 00:23.15 | frieze | it's been 2 years since I've had to do one |
| 00:23.41 | seanbright | actually |
| 00:23.45 | seanbright | the only difference is this |
| 00:23.51 | seanbright | line 29 |
| 00:23.56 | seanbright | change to: |
| 00:24.03 | seanbright | <depend>bluetooth</depend> |
| 00:24.11 | frieze | in which file? |
| 00:24.16 | seanbright | chan_mobile.c |
| 00:24.41 | seanbright | run ./configure again |
| 00:24.46 | seanbright | make clean |
| 00:24.47 | seanbright | make |
| 00:24.55 | seanbright | err |
| 00:25.10 | seanbright | try: make NOISY_BUILD=yessir |
| 00:25.17 | seanbright | and you should see something like: |
| 00:25.26 | lmadsen | yessir, lol |
| 00:25.31 | lmadsen | I love that argument :) |
| 00:25.34 | seanbright | gcc -o chan_mobile.so -shared -Xlinker -x chan_mobile.o -lbluetooth |
| 00:25.44 | seanbright | (note the -lbluetooth at the end) |
| 00:25.48 | seanbright | goes to smoke |
| 00:26.17 | frieze | worked |
| 00:26.29 | frieze | seemed faster to just try it and restart asterisk |
| 00:26.34 | frieze | loaded anyway |
| 00:26.50 | frieze | I have to do some config file writing before I can test if it actually works works |
| 00:26.52 | frieze | thanks a ton |
| 00:27.12 | seanbright | no problem, let me know |
| 00:48.12 | seanbright | codefreeze-lap: i really need a way to exercise these CDR changes i am making. do you have anything in your bag of tricks that i can throw at my dev server that will generate tons and tons of CDRs? |
| 00:48.45 | codefreeze-lap | seanbright: Most Certainly! use sipp! |
| 00:48.58 | codefreeze-lap | You can generate millions of calls that way. |
| 00:49.35 | codefreeze-lap | still very much wishes he had an iax version of sipp!! sigh... |
| 00:49.54 | seanbright | codefreeze-lap: sipp doesn't work out of the box right? you need "dial plan" type stuff? |
| 00:52.35 | codefreeze-lap | Just a little. See the trunk file doc/chan-sip-perf-testing.txt |
| 00:52.48 | seanbright | great. thank you, sir. |
| 00:53.18 | codefreeze-lap | bows, and says, "at your service, sir!" |
| 00:53.30 | seanbright | wow... |
| 00:53.35 | seanbright | ./sipp -sn uac 192.168.134.252 -s 12 -d 100 -l 256 |
| 00:53.37 | seanbright | that's it?! |
| 00:54.00 | codefreeze-lap | after you have the dialplan stuff in place.... yes! |
| 00:54.06 | seanbright | *hot* |
| 00:54.15 | codefreeze-lap | Oh, and a little good stuff in sip.conf! |
| 00:54.21 | seanbright | right |
| 00:54.38 | seanbright | i thought you had to write strategies for sipp |
| 00:55.05 | codefreeze-lap | I usually use sipp from a diff machine than one asterisk is running on. The setup gets different if you want to do it on the same machine |
| 00:55.24 | seanbright | i'm going to run it from my win32 machine |
| 00:55.42 | codefreeze-lap | Well, there are some simple default strategies built in |
| 00:59.19 | seanbright | works for me |
| 00:59.20 | seanbright | thanks again |
| 00:59.48 | codefreeze-lap | bows again! |
| 01:29.38 | seanbright | codefreeze-lap: getting this: [Jun 23 21:27:23] NOTICE[22919]: chan_sip.c:17712 handle_request_invite: Call from '' to extension '12' rejected because extension not found. |
| 01:30.32 | stevie_ramjet | seanbright, do you have extension 12 in your dialplan? |
| 01:30.40 | codefreeze-lap | hold on, saw that today.... a typo in sip.conf for your asterisk02 entry? |
| 01:30.41 | seanbright | stevie_ramjet: indeed. |
| 01:31.14 | seanbright | codefreeze-lap: just copied and pasted from your doc |
| 01:32.42 | seanbright | hmmm |
| 01:32.45 | codefreeze-lap | asterisk02 says to use test11 for a context |
| 01:32.55 | codefreeze-lap | it matches via the host= |
| 01:32.58 | seanbright | right, i made it testcdr |
| 01:33.28 | codefreeze-lap | if some other entry matches first/better, you get those errors |
| 01:33.39 | seanbright | ah |
| 01:34.37 | codefreeze-lap | Just for a few runs, you might comment out possible contenders, or even just save the original, and hack out everything but your testcdr entry |
| 01:35.04 | codefreeze-lap | or whatever you called it |
| 01:35.18 | codefreeze-lap | asterisk02 in my desc |
| 01:35.55 | seanbright | yeah, asterisk02 |
| 01:36.01 | seanbright | still no go |
| 01:36.03 | seanbright | i'll figure it out |
| 01:39.52 | seanbright | No user 'sipp' in SIP users list |
| 01:39.52 | seanbright | No matching peer for 'sipp' from '127.0.0.1:5061' |
| 01:40.24 | seanbright | i have host=127.0.0.1 and user=sipp |
| 01:40.32 | seanbright | what the hell do you want from me!?!? |
| 01:40.33 | seanbright | heh |
| 01:42.56 | seanbright | got it |
| 01:43.03 | seanbright | changed [asterisk02] to [sipp] and voila1 |
| 01:43.07 | seanbright | voila! ever |
| 01:43.11 | seanbright | even* |
| 01:43.15 | seanbright | sheesh |
| 01:46.50 | seanbright | doh! #0 0x00446bc0 in _ao2_ref@plt () from /usr/lib/asterisk/modules/res_timing_pthread.so |
| 01:48.19 | seanbright | on the upside i got 2300 calls logged via cdr_tds before the kaboom |
| 01:51.34 | stevie_ramjet | seanbright, ooh... |
| 01:51.38 | stevie_ramjet | M12917 |
| 01:51.40 | MuffinMan | [assigned] [Asterisk] Core/General 0012917: It crashses every 4 minutes reported by falves11 (Karma: -5.75) http://bugs.digium.com/view.php?id=12917 |
| 01:51.51 | stevie_ramjet | That bug is about the crash in res_timing_pthread |
| 01:52.01 | stevie_ramjet | Do you have a good bt of the crash? |
| 01:52.50 | seanbright | yeah |
| 01:52.52 | seanbright | i'll upload |
| 01:53.17 | stevie_ramjet | The one on the bug for some reason has no information for that thread. |
| 01:53.47 | stevie_ramjet | Thanks :) |
| 01:53.53 | seanbright | hmmm |
| 01:54.05 | seanbright | thread apply bt full |
| 01:54.08 | seanbright | returns squat |
| 01:54.20 | seanbright | ah... nm |
| 01:56.05 | seanbright | how do i dump that to a file without copy/paste? |
| 01:56.41 | stevie_ramjet | in gdb set logging file blah |
| 01:56.45 | stevie_ramjet | then run the command |
| 01:56.51 | stevie_ramjet | It will be dumped to blah. |
| 01:57.08 | stevie_ramjet | oh, wait. |
| 01:57.11 | stevie_ramjet | set logging file blah |
| 01:57.13 | stevie_ramjet | set logging on |
| 01:57.16 | stevie_ramjet | Then run the command. |
| 01:57.51 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:57.51 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 01:57.55 | seanbright | just in time |
| 01:58.01 | stevie_ramjet | aw smack, it's russellb! |
| 02:00.01 | seanbright | uploaded. |
| 02:00.51 | stevie_ramjet | Yep, I'm looking at it. |
| 02:01.09 | stevie_ramjet | It actually crashed in a different spot than in falves11's multiple crashes. |
| 02:01.28 | seanbright | this is in a developer branch... the only thing i've changed is cdr_tds though |
| 02:04.39 | russellb | i do not exist |
| 02:04.49 | file | raises eyebrow |
| 02:05.01 | stevie_ramjet | seanbright, hmm, the bt doesn't show anything obvious. Valgrind may be required to track ze problem. |
| 02:09.14 | russellb | hm, is this crash happening after a lot of load? |
| 02:09.21 | seanbright | russellb: it is, yes. |
| 02:11.19 | russellb | found a mem leak .. |
| 02:11.32 | putnopvut | ooh |
| 02:11.41 | putnopvut | awaits the commit |
| 02:11.42 | seanbright | well it's about time... what has it been? 4 and a half minutes? |
| 02:11.47 | seanbright | :) |
| 02:12.00 | russellb | what are the bugs on this |
| 02:12.03 | russellb | or is it just one |
| 02:12.11 | seanbright | just M12917 |
| 02:12.12 | putnopvut | just 12917 |
| 02:12.16 | seanbright | that i am aware of |
| 02:12.42 | russellb | M12917 |
| 02:12.43 | MuffinMan | [assigned] [Asterisk] Core/General 0012917: It crashses every 4 minutes reported by falves11 (Karma: -5.75) http://bugs.digium.com/view.php?id=12917 |
| 02:12.46 | file | wow SVN works... |
| 02:13.20 | seanbright | file: did you happen to update muffin man with the viewvc change i added to repotools? |
| 02:13.28 | file | no |
| 02:13.45 | file | and I can't for a bit |
| 02:13.50 | seanbright | no sweat |
| 02:13.57 | file | probably... Friday |
| 02:14.07 | seanbright | i don't have that kind of time, i turn into a pumpkin on thursday |
| 02:14.27 | file | just the way it is |
| 02:14.32 | seanbright | fair enough |
| 02:14.38 | seanbright | remind me to fist fight you |
| 02:14.53 | russellb | compile, damnit |
| 02:14.57 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 02:15.41 | file | russellb: you should ask if that place is acceptable... |
| 02:15.56 | russellb | no response from sb |
| 02:16.02 | russellb | js said he's game |
| 02:16.12 | seanbright | works for sb |
| 02:16.18 | file | motion carried |
| 02:16.53 | seanbright | is going to have to wear pants |
| 02:16.58 | putnopvut | nah |
| 02:17.09 | russellb | commit asterisk 124798 |
| 02:17.15 | MuffinMan | [124798] Committed by russell on 2008-06-24T02:16:59.560207Z: fix a memory leak. |
| 02:17.15 | MuffinMan | .. |
| 02:17.15 | MuffinMan | ..(inspired by, and potentially fixes issue #12917) |
| 02:18.09 | seanbright | goes to beat on it like a red-headed step child |
| 02:20.12 | seanbright | i wonder if that fixes codefreeze's problem |
| 02:20.15 | seanbright | codefreeze-lap: ping |
| 02:20.45 | seanbright | russellb: we were leaking fds? |
| 02:21.05 | putnopvut | no, leaking timer references apparently. |
| 02:21.15 | seanbright | hmm |
| 02:22.01 | seanbright | so far so good |
| 02:22.12 | file | may your reference counts always go back zero. |
| 02:22.16 | russellb | probably fixes it |
| 02:22.25 | file | I forgot the word "to" in that... |
| 02:25.46 | seanbright | i wish i was alive when apollo 11 landed |
| 02:28.11 | seanbright | of course i'm glad i am not almost 40 yet |
| 02:28.29 | russellb | o.o |
| 02:28.38 | russellb | is it fixed?! |
| 02:29.00 | seanbright | sipp has been running non-stop since i updated |
| 02:29.03 | seanbright | so i'd say yes |
| 02:29.06 | russellb | w00t |
| 02:29.06 | putnopvut | fixed like neutered dog. |
| 02:29.26 | seanbright | and cdr_tds hasn't killed anything yet |
| 02:29.31 | seanbright | so that's good for me |
| 02:29.42 | russellb | :) |
| 02:29.56 | seanbright | SELECT COUNT(*) FROM [cdr] WHERE src = 'sipp' AND dst = '12' |
| 02:29.59 | seanbright | 5652 |
| 02:30.00 | seanbright | woo |
| 02:30.32 | russellb | whewt |
| 02:33.26 | seanbright | hmmm |
| 02:33.39 | seanbright | running under valgrind getting a ton of sip lock warnings/errors |
| 02:34.02 | seanbright | [Jun 23 22:33:49] ERROR[2297]: chan_sip.c:19519 handle_request_do: We could NOT get the channel lock for SIP/sipp-047c2870! |
| 02:34.05 | seanbright | [Jun 23 22:33:49] ERROR[2297]: chan_sip.c:19520 handle_request_do: SIP transaction failed: 77-2324@10.0.0.29 |
| 02:34.09 | seanbright | rinse and repeat |
| 02:34.18 | seanbright | might be my thing though |
| 02:34.27 | russellb | under load? |
| 02:34.30 | seanbright | yessir |
| 02:34.31 | russellb | probably just maxed out cpu .. |
| 02:34.41 | seanbright | yes indeed |
| 02:34.44 | seanbright | 112% |
| 02:34.45 | seanbright | heh |
| 02:34.59 | seanbright | according to top, anyway. |
| 02:43.24 | tzanger | join #unichrome |
| 02:43.27 | tzanger | oops |
| 02:43.28 | tzanger | heh |
| 02:52.00 | seanbright | join #unicorns |
| 02:52.33 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 02:52.46 | lmadsen | lol |
| 02:53.46 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 02:57.04 | seanbright | well sipp rox |
| 02:58.33 | russellb | does it r0x0r your s0x0rz? |
| 02:58.42 | seanbright | i'll let that one slide |
| 03:00.00 | file | oh good song |
| 03:00.02 | *** part/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 03:00.06 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 03:00.07 | seanbright | heh |
| 03:00.10 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 03:00.12 | file | ...whoops |
| 03:00.21 | russellb | nub |
| 03:01.37 | russellb | this hotel is scary :( |
| 03:02.03 | file | yes |
| 03:02.05 | file | yes it is |
| 03:04.43 | seanbright | gets in his car... |
| 03:04.55 | russellb | orly? |
| 03:05.00 | russellb | that's even scarier |
| 03:05.05 | seanbright | precisely |
| 03:05.11 | seanbright | i'll bring the hookers and blow |
| 03:05.17 | seanbright | heh |
| 03:05.44 | russellb | heh |
| 03:05.56 | russellb | sillyness |
| 03:06.02 | russellb | (i mean, yes, please do) |
| 03:06.08 | file | and I'm off to the land of cookies |
| 03:06.12 | russellb | enjoy |
| 03:06.24 | JerJer | hmmm blow |
| 03:07.02 | Corydon76-dig | tickles seanbright |
| 03:09.55 | moy | howdy ... some zaptel/Dahdi guru around? ... I want advice about where to implement the following: sometimes, particularly in Brazil, it seems noisy lines can lead to false positives for ABCD CAS bit changes (ZT_EVENT_BITSCHANGED), I can certanly deal with this false positives in user space, but I was also considering implement a feature in zaptel where only changes that persist for more than x amount of milliseconds are reported to user space ... am I o |
| 03:09.55 | moy | n the right track? or does that should be definitely implemented in user space? or probably is already implemented? |
| 03:14.03 | seanbright | giggles like a wee school girl |
| 03:19.27 | russellb | moy: you mean adding some debouncing? that sounds reasonable. You may want to see if there is a specification around for a recommend amount ... |
| 03:19.30 | *** join/#asterisk-dev juanjoc (n=juanjoc@host223.190-225-200.telecom.net.ar) |
| 03:19.34 | russellb | i'm not an expert in that area, though. |
| 03:21.56 | moy | russellb, my english sucks quite a bit, but yeah, "debouncing" sounds like what I need :-) |
| 03:22.07 | russellb | you're doing just fine :) |
| 03:22.12 | russellb | have to go. good night! |
| 03:32.18 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 03:42.31 | *** join/#asterisk-dev jeffg (i=3b0Z29Ri@pdpc/supporter/active/jeffg) |
| 03:50.33 | JerJer | hmm |
| 03:50.47 | JerJer | wonders if Mark changed teams :) |
| 03:52.54 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 04:00.50 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-44.west.biz.rr.com) |
| 04:01.31 | Qwell | JerJer: O.o |
| 04:03.03 | Corydon76-dig | Uh, why would you think that? |
| 04:08.56 | lmadsen | ? |
| 04:09.15 | JerJer | ! |
| 04:10.44 | lmadsen | & |
| 05:43.14 | *** join/#asterisk-dev slavon_net (n=slavon@slavon.bigtelecom.ru) |
| 05:47.28 | slavon_net | <PROTECTED> |
| 05:58.57 | JerJer | ok, first lets put that pipe down |
| 05:59.05 | JerJer | zap is now DAHDI |
| 06:04.10 | slavon_net | yep... how to compile last 1.6.0 svn brunch with DAHDI if DAHDI is not released? |
| 06:06.17 | JerJer | what?! |
| 06:07.07 | JerJer | checkout DAHDI, checkout asterisk |
| 06:07.14 | JerJer | compile them both |
| 06:07.18 | JerJer | what's the problem ? |
| 06:09.56 | slavon_net | sorry if i mistaken... where i can see url for checkout DAHDI? i look to asterisk.org and not see this information... |
| 06:10.54 | slavon_net | i look in news, downloads and devlopers |
| 06:13.19 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 06:59.48 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 07:27.38 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:49.19 | *** join/#asterisk-dev RoyK (n=roy@box36.fortel.no) |
| 08:27.57 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 08:30.06 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 08:51.00 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.41) |
| 10:00.18 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-277899.home.otenet.gr) |
| 12:19.49 | *** join/#asterisk-dev stevie_ramjet (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 12:19.49 | *** mode/#asterisk-dev [+o stevie_ramjet] by ChanServ |
| 12:22.02 | *** join/#asterisk-dev floppp (n=flopp@nat-staff.b3g-telecom.com) |
| 12:33.46 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:33.46 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:42.25 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:59.26 | *** join/#asterisk-dev fenlander (n=fenlande@80.169.36.194) |
| 13:05.15 | *** join/#asterisk-dev jeffg (i=QLIQJmm9@pdpc/supporter/active/jeffg) |
| 13:07.46 | *** join/#asterisk-dev Mike8861 (i=Mike8861@221.124.81.21) |
| 13:08.00 | Mike8861 | hello all, I am new to asterisk |
| 13:08.29 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.140.193) |
| 13:09.11 | Mike8861 | hello anonymouz666, welcome to #asterisk-dev |
| 13:09.46 | anonymouz666 | hi |
| 13:10.11 | Mike8861 | can u help me ??? |
| 13:10.23 | Mike8861 | i got a headache with asterisk |
| 13:10.46 | lmadsen | Mike8861: note that this channel is for development of asterisk, not questions about how to implement asterisk |
| 13:13.38 | Mike8861 | lmadsen, which channel should I visit for installing patch on asterisk (trixbox 2.4.1 ISO image) ? |
| 13:13.51 | seanbright | ~trixbox |
| 13:13.51 | jbot | [~trixbox] trixbox is a full linux distro that includes FreePBX and other 3rd party add-ons. It is all this extra stuff which makes trixbox VERY difficult to support, and is not supported in #asterisk. Try asking in #trixbox or on their forums & wiki at http://www.trixbox.org |
| 13:13.56 | lmadsen | Mike8861: for trixbox, you have to use #trixbox |
| 13:14.49 | Mike8861 | thanks for the direction. I will visit trixbox. |
| 13:14.51 | Mike8861 | cya all |
| 13:14.55 | *** part/#asterisk-dev Mike8861 (i=Mike8861@221.124.81.21) |
| 13:17.18 | dlu_ | anyone seen matthew last hours? |
| 13:17.59 | lmadsen | we just told him that in #asterisk |
| 13:18.02 | lmadsen | he tried to sneak in here |
| 13:20.28 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 13:29.26 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-2864a8a799a7d75e) |
| 13:38.09 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 13:38.09 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 13:45.18 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:52.32 | *** join/#asterisk-dev jsmith (n=jsmith@72.21.36.138) |
| 13:52.32 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:13.21 | *** join/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 14:18.18 | *** join/#asterisk-dev smth (n=chatzill@CPE000d48380389-CM00195eda2522.cpe.net.cable.rogers.com) |
| 14:26.19 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 14:26.20 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:28.14 | seanbright | "Digium(r) caused a disruption" is right! |
| 14:33.52 | snuff-home | mm.. might have to try out my new 'union' patch tomorrow.. coded n compiled but no tests |
| 14:34.18 | snuff-home | is trying to break the translator_pvt :) |
| 14:34.45 | mvanbaak | <--- working on moving all the linebased stuff out of chan_skinny's build_device function |
| 14:35.12 | mvanbaak | build_device will call build_line instead of doing it all the logic itself |
| 14:35.30 | snuff-home | mm fun that help allow 'realtime' skinny? |
| 14:50.37 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:50.37 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:56.52 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 14:56.52 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 15:00.31 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582656.dsl.bell.ca) |
| 15:06.10 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:06.10 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:17.54 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:21.31 | *** join/#asterisk-dev ctooley (n=ctooley@rrcs-71-42-115-245.sw.biz.rr.com) |
| 15:21.31 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 15:29.20 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 15:37.41 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:57.30 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.115.150) |
| 15:59.02 | codefreeze-lap | Oh, wise ones! I seek your knowledge! Tell me, why is the channel struct's lock var called "lock_dont_use" ? |
| 15:59.37 | Qwell | ast_channel_lock(chan), rather than ast_mutex_lock(chan->lock_dont_use) |
| 15:59.42 | Qwell | I assume? |
| 15:59.54 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:59.56 | codefreeze-lap | I'm thinking the same, but wanted to be sure |
| 16:00.13 | Qwell | missed a & there |
| 16:01.06 | codefreeze-lap | is faced with a perplexing mystery! |
| 16:01.53 | seanbright | codefreeze-lap: did you see russellb's patch for res_timing_pthread last eve? |
| 16:02.26 | codefreeze-lap | seanbright: I saw he fixed and closed the issue. |
| 16:02.48 | seanbright | codefreeze-lap: did that fix your spiralling-fd-with-sip problem? |
| 16:03.22 | codefreeze-lap | Haven't checked that yet, seanbright, but will today. That'd be nice to have that cleared up. |
| 16:03.36 | codefreeze-lap | but it still leaves the mystery! |
| 16:03.48 | seanbright | codefreeze-lap: it resolved some problems i was seeing while stress testing with sip/sipp/cdrs. |
| 16:04.10 | codefreeze-lap | puts the mystery aside |
| 16:04.21 | seanbright | codefreeze-lap: what is your mystery now? the lock_dont_use bit? |
| 16:04.59 | seanbright | or the 300k ticks worth of locking going on in __ast_answer? |
| 16:06.04 | codefreeze-lap | Well, I'm putting the mystery on hold until I run the tests again. Yes, the 300k ticks is the mystery. I ran some tests to see what was holding the lock.... and found there was no lock. At least, I think... |
| 16:06.21 | seanbright | mysterious indeed... |
| 16:06.49 | codefreeze-lap | Indeed. Quite. Verily. |
| 16:07.06 | seanbright | do not try to free the lock... that's impossible... only try to realize the truth... |
| 16:07.25 | codefreeze-lap | ... that there is no lock? |
| 16:07.37 | seanbright | correct. |
| 16:07.43 | codefreeze-lap | lol |
| 16:07.58 | seanbright | yeah... i'm kinda a dork |
| 16:11.06 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 16:12.26 | codefreeze-lap | seanbright: you are in a large and auspicious club! :-D |
| 16:17.58 | *** join/#asterisk-dev CunningPike_ (n=arodgers@204.239.8.157) |
| 16:19.02 | Juggie | i dont know if the club is large |
| 16:19.06 | Juggie | its actually quite small |
| 16:24.21 | codefreeze-lap | seanbright: you are correct. That corrected the 498 call limit. Yay! russell rocks!! |
| 16:24.52 | codefreeze-lap | Juggie!!! Shhhhhh!!! |
| 16:27.41 | Corydon76-dig | seanbright: a cute dork, though |
| 16:28.10 | codefreeze-lap | seanbright: looking at the profile times; hmmm! well, now that did affect things a bit.... |
| 16:30.04 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-185-165.hsd1.wa.comcast.net) |
| 16:30.19 | codefreeze-lap | The __ast_answer channel lock now only takes 205 k clock ticks. and the channel lock in ast_waitfor_nandfds is at 35 k ticks. They still stick out terribly. |
| 16:40.48 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 16:41.19 | putnopvut | codefreeze-lap: aret these ticks the amount of time the channel remains locked or how long it takes to acquire the lock? |
| 16:42.05 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 16:42.32 | codefreeze-lap | It's how long it takes to get the lock; or more accurately put, the number of cpu ticks from the time you call the mutex lock, to the time control returns. |
| 16:42.56 | codefreeze-lap | I have no idea right now, how many microseconds per tick. |
| 16:42.56 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 16:43.15 | codefreeze-lap | probably depends a great deal on the cpu speed, etc |
| 16:49.32 | seanbright | ok, so the problem lies elsewhere |
| 16:49.43 | seanbright | something else holding on to the lock for an extended period of time |
| 17:05.38 | codefreeze-lap | Ah-ha! But the channel ***is*** locked... !! yay!! We just don't have the lock in the lock_infos!!! |
| 17:06.06 | codefreeze-lap | Wow, what a whodunit! |
| 17:06.28 | codefreeze-lap | who-dunnit? |
| 17:09.54 | putnopvut | that is strange. |
| 17:10.25 | putnopvut | Any idea why it's not in the lock_infos? |
| 17:11.06 | codefreeze-lap | yes, it is; since ast_channel_lock is called everywhere, with DEBUG_THREADS turned on, it should be in the list... hmmm! |
| 17:11.26 | codefreeze-lap | wonders if the lists are per-module or something... |
| 17:12.29 | seanbright | bets on chan_sip |
| 17:13.21 | seanbright | because that is an obvious guess |
| 17:13.22 | codefreeze-lap | I'd tend to agree! |
| 17:13.51 | codefreeze-lap | wonders why life can't be.... simple? |
| 17:14.25 | seanbright | codefreeze-lap: what fun would that be? |
| 17:14.51 | codefreeze-lap | looks like lock_info's are per-thread, not per-module. |
| 17:14.52 | putnopvut | codefreeze-lap: could it be that the channel that is "locked" has been locked but has not yet been inserted into the lock_infos? Or perhaps, you've reached the limit (64 I believe) of locks that a thr_lock_info can hold? |
| 17:15.01 | putnopvut | They are per-thread. |
| 17:16.06 | codefreeze-lap | seanbright: true, but every now and then....! |
| 17:16.12 | ctooley | codefreeze-lap, Sorry about being "away" for a few days, been traveling for work. |
| 17:16.46 | codefreeze-lap | Hmmm. per-thread is a hassle. |
| 17:16.49 | ctooley | But, I'm in the Austin office with the guys that are testing out routing. So coordinating a large scale test of SIP calls is easy if you'd like me to odo something. |
| 17:21.22 | codefreeze-lap | ctooley: I've not figured out why you are having probs with the mtxprof branch, as it's working great for me. So, I'm doing sipp work here to see if I can spot the prob. |
| 17:21.47 | codefreeze-lap | ctooley: might have something... |
| 17:22.30 | codefreeze-lap | putnopvut: is per-thread really the best way to store lock info? Doesn't that hide deadlocks between threads? |
| 17:22.55 | putnopvut | codefreeze-lap: it makes the most sense to me. The thread is the logical unit that holds a lock. |
| 17:23.29 | putnopvut | And the fact that it's per-thread is exactly what helps in showing which threads are deadlocked. |
| 17:24.35 | codefreeze-lap | putnopvut: but... hang on... I gotta look at the code that prints these things... |
| 17:25.04 | seanbright | frieze: any luck with the patch? |
| 17:26.26 | codefreeze-lap | ha, ok, the lockinfos are a list one per thread, so the list spans all the threads. |
| 17:26.45 | *** join/#asterisk-dev simond (n=simon@syria.uc.org) |
| 17:26.46 | codefreeze-lap | slaps self upside the head |
| 17:26.57 | seanbright | we should just take out all the locks |
| 17:27.03 | seanbright | they cause too many issues |
| 17:27.17 | codefreeze-lap | lol that'd do it! |
| 17:27.56 | putnopvut | seanbright: that kind of suggestion always brings up the contributed patch to ignore segfaults. |
| 17:28.03 | seanbright | heh |
| 17:28.32 | codefreeze-lap | segfault??? we don't need no stinking segfaults!! |
| 17:39.04 | mvanbaak | Qwell: ping |
| 17:39.20 | Qwell | pong |
| 17:40.02 | mvanbaak | I think we need to seperate the device and line building stuff in chan_skinny |
| 17:40.09 | mvanbaak | we now have build_device |
| 17:40.21 | mvanbaak | that does the config stuff for a device + all attached lines |
| 17:41.12 | mvanbaak | it assigns all device params directly, but all line params to global vars and put those global vars in the line config later |
| 17:41.57 | mvanbaak | I now have that code 3 times already in my realtime work |
| 17:42.00 | mvanbaak | it sux |
| 17:42.05 | mvanbaak | what you think ? |
| 17:43.08 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 17:44.53 | mvanbaak | we can have build_device simply ignore those values, and make it call build_lines with the config var |
| 17:45.15 | mvanbaak | and build_lines will only care about the line stuff and attach the lines to the device |
| 17:51.22 | mvanbaak | or maybe you just lost interest in the whole chan_skinny stuff ;) |
| 17:57.58 | Qwell | the way the config is written makes it kinda suck |
| 17:58.20 | outtolunc | sheesh, can't even compile asterisk on a 486sx <G> |
| 17:58.43 | mvanbaak | lol outtolunc |
| 17:58.49 | mvanbaak | Qwell: I know |
| 17:59.06 | Qwell | it definitely shouldn't use global vars |
| 17:59.13 | mvanbaak | Qwell: but like I said, chan_skinny already assigns all non-device items to global vars |
| 17:59.42 | mvanbaak | and use those globals later in the l->something = global_something |
| 17:59.46 | Qwell | you may have to split the parsing for realtime vs config |
| 17:59.57 | mvanbaak | yeah |
| 18:00.26 | Qwell | so, in the lines table, you'd need like label, name...other stuff. |
| 18:00.51 | mvanbaak | I already have this in my local copy: |
| 18:00.53 | mvanbaak | -return 0; |
| 18:00.53 | mvanbaak | +/* device not found in static config, look in realtime */ |
| 18:00.53 | mvanbaak | +d = load_realtime_device(req->data.reg.name); |
| 18:00.53 | mvanbaak | +if (!d) { |
| 18:00.55 | mvanbaak | +return 0; |
| 18:00.58 | mvanbaak | +} |
| 18:01.55 | mvanbaak | load_realtime_device will have a lot of code in common, because of the line handling |
| 18:02.27 | mvanbaak | and since the device only has a handfull of settings, that should be no problem |
| 18:02.35 | mvanbaak | but the lines is what worries me |
| 18:02.43 | Qwell | this config "inheritance" is just silly |
| 18:02.54 | mvanbaak | uhhuh |
| 18:03.36 | *** join/#asterisk-dev RoyK (n=roy@ti0002a380-0029.bb.online.no) |
| 18:03.48 | Qwell | so... |
| 18:04.16 | Qwell | in theory, somebody could have a device in skinny.conf, which references a line from realtime |
| 18:04.26 | mvanbaak | sure, no problem |
| 18:04.33 | mvanbaak | silly, but possible |
| 18:06.19 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 18:06.46 | Qwell | actually, no |
| 18:07.21 | mvanbaak | right now it's impossible |
| 18:07.33 | mvanbaak | but if we seperate the logic it would be no problem at all |
| 18:10.27 | mvanbaak | it would be like queues and agents |
| 18:10.48 | Qwell | the problem is, we can't force any config changes on anybody |
| 18:11.04 | lmadsen | sure we can! |
| 18:11.07 | lmadsen | who uses skinny? :) |
| 18:13.17 | mvanbaak | if we make build device ignore the line stuff noone will notice |
| 18:19.37 | mvanbaak | only the ppl who enable 'skinny_lines = something' in extconfig will notice :) |
| 18:20.00 | mvanbaak | lmadsen: I know like 6 or 7 companies in reallife that use it |
| 18:28.49 | mvanbaak | normal config file parsing will stay the same |
| 18:29.02 | mvanbaak | but internally we will have seperate functions to build a device and a line |
| 18:30.43 | mvanbaak | hhmm |
| 18:30.53 | mvanbaak | maybe I should come up with some code instead of ideas ;) |
| 18:31.18 | mvanbaak | I'll get back to you when I have some code to underline my ideas |
| 18:33.08 | mvanbaak | now it's movie time, and my 5 year old kitten is screaming for some attention |
| 18:33.12 | mvanbaak | latero all |
| 18:33.36 | mvanbaak | Qwell: and thanks for taking the time to have a look at my ideas |
| 18:46.25 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 18:56.38 | *** join/#asterisk-dev gitguy (n=diego@adsl-128-132.click.com.py) |
| 19:11.31 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 19:22.20 | Corydon76-dig | Qwell: ping |
| 19:22.39 | Corydon76-dig | M12162 |
| 19:22.41 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0012162: sipsock_read using unsafe structure reported by norman (Karma: -4) http://bugs.digium.com/view.php?id=12162 |
| 19:23.28 | Qwell | hmm? |
| 19:24.14 | Corydon76-dig | Final comment on the bug makes a reference to a question you asked |
| 19:27.27 | Corydon76-dig | So any idea what the question was? |
| 19:28.08 | Qwell | "does this look okay?" |
| 19:28.17 | Corydon76-dig | Ah |
| 19:34.59 | codefreeze-lap | putnopvut: I'm pulling my hair out here... is there any way a channel could get locked and not show up in the lock_info arrays?... There's only 2 locks in the lock_info stuff; one is not the same channel; it ended up locked in the ast_get_channel_by_name_prefix_locked() routine; the other is the sip netlock. The channel *is* locked, but not in the list... |
| 19:35.17 | codefreeze-lap | \me scratches head (where the hair got yanked out)... |
| 19:36.54 | putnopvut | codefreeze-lap: I've seen weird things before where locks will be stuck trying to lock the reentrancy lock. |
| 19:37.27 | putnopvut | So, for instance, pthread_mutex_lock(&t->mutex) will succeed, and then when it attempts to update lock info, it needs to lock the reentrancy lock and gets stuck there. |
| 19:38.39 | codefreeze-lap | but not stuck; just not in the list; hmmm, a trylock or something? |
| 19:40.35 | putnopvut | codefreeze-lap: that function (ast_get_channel_by_name_prefix_locked) does use a trylock. |
| 19:40.57 | putnopvut | have you looked at a backtrace to see what that thread is doing? |
| 19:42.28 | *** join/#asterisk-dev ZaVoid (n=zavoid@75.147.121.177) |
| 19:42.32 | ZaVoid | hey guys |
| 19:44.29 | Corydon76-dig | Afternoon |
| 19:44.45 | ZaVoid | hey cory |
| 19:44.48 | ZaVoid | got a theory question |
| 19:44.59 | Corydon76-dig | Okay |
| 19:45.34 | Corydon76-dig | The theoretical answer is 42. |
| 19:45.40 | ZaVoid | if i have allow=g723.1 on an incoming sip peer ... and allow=g723.1 on the outgoing peer..... why would i see in the SDP trace g723 in the inbound SDP message but not when its going outbound..(i never answer the call) |
| 19:45.48 | ZaVoid | yah i tried 42.. didn't seem to work |
| 19:46.14 | codefreeze-lap | putnopvut: which thread? the one that gets stuck waiting is doing an __ast_answer from an INVITE. The other two are the sip netlock, and a different channel getting locked via the ast_parse_device_state stuff. |
| 19:46.46 | Corydon76-dig | ZaVoid: I don't know, actually. |
| 19:46.56 | Corydon76-dig | ZaVoid: have a sip trace? |
| 19:47.11 | ZaVoid | yeah\ |
| 19:47.13 | ZaVoid | but not helpful |
| 19:47.17 | ZaVoid | it shows the g723 coming in |
| 19:47.20 | ZaVoid | and not g723 going out |
| 19:47.30 | putnopvut | codefreeze-lap: I was referring to the thread which supposedly holds a channel lock but does not appear in the lock_infos. |
| 19:47.34 | ZaVoid | the only thing i can think of.. is i'm using DIAL to go back out |
| 19:47.41 | ZaVoid | so i guess i'm answering the call technically? |
| 19:49.15 | putnopvut | ZaVoid: Dial() does not imply an answer. |
| 19:49.22 | ZaVoid | right thats what i thought |
| 19:49.29 | codefreeze-lap | putnopvut: Well, that's precisely what I need to know; all about the mystery lock. I know it exists, I've documented that. It's just not in the list. |
| 19:50.10 | putnopvut | codefreeze-lap: right, and if you know it exists, and you can find what that thread is actually attempting to do, you may see that it is attempting to lock the same channel over and over, or something. |
| 19:50.18 | ZaVoid | but why would asterisk nip g723 from the sdp? |
| 19:51.11 | putnopvut | ZaVoid: have you tried only allowing g.723 with no other allowed codecs? |
| 19:51.22 | putnopvut | Or is that what you're saying you're doing? |
| 19:51.36 | ZaVoid | no because i want g729 and g723... but i can try that... limit g723 on outbound |
| 19:54.56 | ZaVoid | let me try that |
| 19:55.45 | putnopvut | ZaVoid: it does seem weird to me that Asterisk wouldn't even offer g.723 in the outbound SDP. I guess that could be just one of those flaws in Asterisk's codec negotiation. |
| 19:59.56 | ZaVoid | one sec re-trying a few things |
| 20:03.29 | ZaVoid | so a=rtpmap:18 G729/8000 |
| 20:03.29 | ZaVoid | a=fmtp:18 annexb=no |
| 20:03.29 | ZaVoid | a=rtpmap:4 G723/8000 |
| 20:03.39 | ZaVoid | thats on my sip debug on inbound |
| 20:04.10 | ZaVoid | and outbound g723/8000 is missing... really strange |
| 20:04.19 | ZaVoid | any other debugs i can do to track down the issue? |
| 20:04.52 | putnopvut | ZaVoid: there's always the "core set debug 10 chan_sip.c" |
| 20:05.07 | putnopvut | It might print some info about how it's making the SDP. |
| 20:05.10 | ZaVoid | aight let me try that |
| 20:10.52 | ZaVoid | http://pastebin.ca/1055266 |
| 20:10.54 | ZaVoid | check it out |
| 20:12.08 | putnopvut | pastebin.ca is being slow :( |
| 20:13.45 | ZaVoid | damn canucks! |
| 20:14.44 | outtolunc | codec shell game |
| 20:15.01 | putnopvut | ZaVoid: something interesting I just noticed in chan_sip.c |
| 20:15.08 | ZaVoid | ? |
| 20:15.11 | putnopvut | Look at the function add_codec_to_sdp |
| 20:15.23 | putnopvut | There's a specific case for g.723 |
| 20:15.31 | ZaVoid | i thought [2008-06-24 20:07:25] DEBUG[23550] chan_sip.c: *** AST_CODEC_CHOOSE formats are 0x1 (g723) was interesting |
| 20:15.54 | ZaVoid | unless codec allow=g723.1 changed to allow=g723 and id din't notice :) |
| 20:16.22 | putnopvut | Sorry for the upcoming 3-line paste... |
| 20:16.25 | putnopvut | <PROTECTED> |
| 20:16.25 | putnopvut | <PROTECTED> |
| 20:16.25 | putnopvut | <PROTECTED> |
| 20:18.43 | ZaVoid | errr |
| 20:19.17 | ZaVoid | so it doesn't like the flavor of g723? |
| 20:20.42 | putnopvut | The "our joint capabilities are 0x0" seems odd to me. |
| 20:21.27 | ZaVoid | i'm lost... |
| 20:21.31 | putnopvut | You're kind of treading into an area I don't know so much about, but that would appear to be the case. |
| 20:22.27 | ZaVoid | hmm fun |
| 20:22.37 | ZaVoid | i'll dig in some more too |
| 20:22.45 | ZaVoid | looks strange though right? |
| 20:22.58 | putnopvut | Yeah. Here's something else that's a bit odd to me. |
| 20:23.05 | putnopvut | Asked to create a SIP channel with formats: 0x4 (ulaw) |
| 20:23.21 | putnopvut | Did you call in using ulaw? |
| 20:23.41 | ZaVoid | nah its sneding g729/g723/ulaw |
| 20:24.43 | putnopvut | ZaVoid: http://www.voip-info.org/wiki-Asterisk+G.723.1+Licensing |
| 20:24.58 | putnopvut | Wait, you're trying to do passthru, aren't you... |
| 20:25.05 | ZaVoid | i'm trying to do passthru :) |
| 20:28.46 | putnopvut | And here's another voip-info page... |
| 20:28.46 | putnopvut | http://chilli.nosignal.org/mirrors/voip-info/wiki/view/Asterisk+G-3.html |
| 20:28.54 | putnopvut | No idea if that'll help. |
| 20:33.49 | bkruse | where is tzafrir? |
| 20:33.54 | bkruse | checks jabber |
| 20:37.39 | ZaVoid | yeah thats fine putnopvut |
| 20:37.52 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 21:14.44 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 21:17.28 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 21:17.28 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 21:21.49 | file | runs in |
| 21:22.29 | ctooley | file runs into a wall? |
| 21:23.32 | outtolunc | figured it was then 'runs out with all the muffins' |
| 21:34.37 | frieze | if my dialplan has no patterns remotely starting in "10" why do I get a busy signal after typing the first 0 in "1000"? It's a polycom phone if that could possibly be relevant |
| 21:34.47 | frieze | oops |
| 21:34.49 | frieze | wrong chan |
| 21:34.54 | frieze | that's for #asterisk |
| 21:43.53 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 22:03.18 | *** join/#asterisk-dev ghenry (n=ghenry@ghenry.plus.com) |
| 22:04.23 | ghenry | Would someone be so kind to tell me how I can see DEBUG statements inside if (option_debug > 3) |
| 22:04.39 | ghenry | I'm trying to read some in app_voicemail.c on the console |
| 22:05.00 | ghenry | I have asterisk -d -c -r and debug set in logger.conf for the console |
| 22:05.04 | ghenry | and core set debug 10 |
| 22:05.17 | ghenry | I don't see the IMAP logging I should be |
| 22:06.31 | Corydon76-dig | ghenry: that seems correct |
| 22:06.42 | ghenry | Hmmm |
| 22:06.54 | Corydon76-dig | ghenry: did you do a 'logger reload' since the last time you changed logger.conf? |
| 22:07.12 | ghenry | I'm running on cli stopping and starting |
| 22:07.20 | ghenry | I can't see any parsing statements etc. |
| 22:07.24 | Corydon76-dig | and you have debug presumably for 'console', correct? |
| 22:07.35 | ghenry | I'm trying to see some ldap and res_ldap stuff for it too |
| 22:07.37 | ghenry | yeah |
| 22:07.48 | ghenry | console => notice,warning,error,debug |
| 22:07.50 | Corydon76-dig | Then that should work |
| 22:08.25 | Corydon76-dig | You don't have anything like a double context in logger.conf, do you? |
| 22:08.37 | Corydon76-dig | or an errant #include ? |
| 22:08.50 | ghenry | just a [logfiles] |
| 22:09.17 | ghenry | wanted to see things like the config parsing etc. |
| 22:09.49 | Corydon76-dig | Some of that config parsing is verbose, not debug |
| 22:10.25 | ghenry | ah that was missing, trying now |
| 22:13.31 | ghenry | Corydon76-dig: This is all I get http://nopaste.com/p/aNciW9pb2 |
| 22:14.08 | Corydon76-dig | What else are you expecting? |
| 22:15.48 | ghenry | things like ast_log (LOG_DEBUG,"Copied %s to %s\n",vmu->imapuser,vms_p->imapuser); |
| 22:16.46 | Corydon76-dig | And why would that happen during the load? |
| 22:16.51 | putnopvut | ghenry: did you select IMAP_STORAGE from in menuselect? |
| 22:17.02 | ghenry | yeah |
| 22:17.42 | seanbright | putnopvut: did codefreeze-lap ever figure out his locking problem? |
| 22:17.53 | putnopvut | seanbright: If he did, I didn't hear about it. |
| 22:18.14 | Corydon76-dig | ghenry: I don't see that line anywhere within app_voicemail.c |
| 22:18.32 | ghenry | 1.4.20.1 it's in |
| 22:18.35 | putnopvut | Corydon76-dig: it's in several places. |
| 22:18.40 | ghenry | anyway, I'm an idiot |
| 22:18.54 | Corydon76-dig | Oh, IRC client chopped off some at linewrap |
| 22:19.00 | ghenry | -with-imap was selected in configure |
| 22:19.07 | ghenry | never did IMAP_STORAGE |
| 22:19.08 | ghenry | ffs |
| 22:19.12 | ghenry | cheers putnopvut |
| 22:19.15 | putnopvut | ah, okay. That'll do it :) |
| 22:19.17 | ghenry | dumb user |
| 22:19.23 | ghenry | leave the devs alone. |
| 22:19.58 | Corydon76-dig | as long as you're working on LDAP, you're welcome to bug the developers |
| 22:20.09 | putnopvut | LDAP? |
| 22:20.20 | putnopvut | ah, I see above now. |
| 22:20.57 | Corydon76-dig | putnopvut: ghenry is probably the most involved guy in the LDAP realtime driver |
| 22:21.07 | putnopvut | oh, nice. |
| 22:21.23 | Corydon76-dig | and I'm rather happy that it's him and not me. |
| 22:21.23 | ghenry | ta |
| 22:22.14 | Corydon76-dig | I think I'd rather be forced to admin a MS SQL Server than to maintain an LDAP installation |
| 22:22.25 | ghenry | not fair |
| 22:22.28 | ghenry | ldap rules |
| 22:22.55 | Corydon76-dig | Like I said, better you than me. ;-) |
| 22:23.31 | ghenry | chat later Corydon76-dig bed tmie |
| 22:23.51 | Corydon76-dig | Already? It's only 6pm here |
| 22:24.04 | ghenry | 1123pm in scotland |
| 22:24.07 | putnopvut | ...if you set your clock 30 min ahead... |
| 22:24.17 | Qwell | putnopvut: he's in TN |
| 22:24.20 | putnopvut | Ooh, Scotland. I haven't been there in two years. |
| 22:24.35 | putnopvut | Qwell: so you're saying he's 30 minutes ahead? |
| 22:24.38 | Corydon76-dig | picks up his banjo |
| 22:24.42 | Qwell | it averages out |
| 22:24.46 | Qwell | yes |
| 22:25.08 | Qwell | ever looked a timezone map of TN? I'd use a :30 TZ too |
| 22:25.21 | putnopvut | At least Indiana isn't as confusing anymore. |
| 22:25.35 | seanbright | it is |
| 22:25.38 | seanbright | just for different reasons |
| 22:25.42 | putnopvut | heh |
| 22:25.52 | Qwell | Indiana scares me. |
| 22:25.52 | Corydon76-dig | Tennessee is bisectional |
| 22:25.52 | seanbright | has no idea what that means. |
| 22:26.01 | Qwell | look at it on google maps sometime |
| 22:26.02 | seanbright | Qwell: but you admit it exists |
| 22:26.08 | Qwell | IT'S BROWN. the whole state |
| 22:26.28 | seanbright | looks green to me |
| 22:26.35 | Corydon76-dig | What can brown do for you? |
| 22:26.58 | Qwell | they must've updated the maps. and I was mistaken - it was gray |
| 22:27.00 | putnopvut | If my butler were named brown, he could make me some fajitas. |
| 22:27.29 | seanbright | just had qdoba |
| 22:27.35 | Corydon76-dig | putnopvut: as it turns out your butler is named Imaginary Pete |
| 22:27.42 | seanbright | if they don't have those in the south, you guys should lobby for one |
| 22:28.05 | putnopvut | seanbright: oh we have them. |
| 22:28.17 | putnopvut | The one I knew of in Huntsville closed though. |
| 22:28.22 | putnopvut | There may yet be another. |
| 22:28.34 | seanbright | blinks |
| 22:28.41 | seanbright | Russellville, AL |
| 22:28.44 | seanbright | hah |
| 22:29.30 | putnopvut | wtf is russellville? |
| 22:29.36 | seanbright | no idea |
| 22:29.36 | Qwell | points |
| 22:29.42 | Corydon76-dig | There's a qdoba in Nashville, too |
| 22:29.55 | seanbright | i was panning around google maps and saw it |
| 22:30.03 | seanbright | my friend is in nashville right nowe |
| 22:30.07 | seanbright | s/nowe/now/ |
| 22:30.21 | Corydon76-dig | seanbright: is she? |
| 22:30.34 | seanbright | she went to the flying saucer draught emporium last night |
| 22:30.51 | Corydon76-dig | That place has really gone downhill |
| 22:30.59 | putnopvut | "draught emporium" has to be the most pretentious name for a bar I've ever heard. |
| 22:31.08 | Corydon76-dig | They no longer have 100 beers available |
| 22:31.09 | seanbright | it might be tongue-in-cheek |
| 22:31.28 | Corydon76-dig | They used to have the biggest selection in Nashville |
| 22:31.33 | Corydon76-dig | That was the draw |
| 22:31.46 | seanbright | and she went to graceland today |
| 22:31.50 | seanbright | god knows why |
| 22:32.00 | Qwell | ...graceland |
| 22:32.01 | Corydon76-dig | Ugh |
| 22:32.03 | Qwell | screw that place |
| 22:32.07 | seanbright | yeah |
| 22:32.09 | seanbright | agreed |
| 22:32.11 | Qwell | They owe me a new tire. |
| 22:32.22 | seanbright | i like gattlingburg |
| 22:32.28 | seanbright | all 2 1/2 miles of it |
| 22:32.37 | Corydon76-dig | I like what's just outside Gatlinburg |
| 22:32.53 | seanbright | dollyworld? |
| 22:32.57 | putnopvut | Corydon76-dig: Pigeon Forge? |
| 22:33.04 | Corydon76-dig | Great Smokey National Park |
| 22:33.17 | Qwell | don't like that place either |
| 22:33.27 | seanbright | Qwell: what place do you like? |
| 22:33.36 | Qwell | seanbright: not many |
| 22:33.38 | putnopvut | seanbright: he's fond of the jersey shore. |
| 22:33.46 | seanbright | for the skee ball |
| 22:33.53 | *** join/#asterisk-dev RoyK (n=roy@ip-183-25-149-91.dialup.ice.no) |
| 22:34.01 | putnopvut | until little hockey kids attack him. |
| 22:34.06 | putnopvut | (I'm a huge nerd) |
| 22:34.10 | Corydon76-dig | I hear he likes spooning at Rehoboth Beach |
| 22:34.13 | seanbright | heh |
| 22:34.20 | seanbright | he's a power little spoon |
| 22:35.38 | seanbright | probably has a summer home in provincetown, mass, too. |
| 22:35.40 | seanbright | heh |
| 22:35.47 | *** part/#asterisk-dev RoyK (n=roy@ip-183-25-149-91.dialup.ice.no) |
| 22:37.26 | Corydon76-dig | seanbright: and New Hope |
| 22:37.45 | putnopvut | The table of contents on RFC 3261 is just plain wrong with its page numbers. |
| 22:38.27 | Corydon76-dig | giggles as Qwell rolls his eyes. |
| 22:40.43 | seanbright | i'm trying to decide if a nap is a really bad idea or not |
| 22:43.14 | seanbright | i've decided its a bad idea |
| 22:55.26 | *** join/#asterisk-dev jeffg (i=c54v6X1i@pdpc/supporter/active/jeffg) |
| 22:55.50 | ctooley | codefreeze-lap, I think I found the MTX_PROFILE issue |
| 22:58.14 | codefreeze-lap | ctooley: excellent-- what is it? |
| 22:59.48 | ctooley | menuselect-tree didn't contain the entries, the "example" in menuselect/ directory had it. |
| 23:01.08 | codefreeze-lap | hmmm. Some of that stuff is generated, some comes with svn; which dir? |
| 23:01.27 | codefreeze-lap | asks dumb questions |
| 23:01.37 | ctooley | it's supposed to live in the root of the directory |
| 23:01.37 | codefreeze-lap | menuselect, right |
| 23:01.44 | ctooley | errr root of the checkout |
| 23:07.19 | codefreeze-lap | ctooley: just checked; mtxprof/menuselect-tree is not under svn control; it's a generated file |
| 23:07.34 | ctooley | codefreeze-lap, right, the example is though.... it's odd |
| 23:07.48 | ctooley | not sure what makes the decision of whether MTX is available or not. |
| 23:10.45 | codefreeze-lap | ctooley: mayhaps you can uncomment the NOISY_BUILD var in the top makefile and see the steps it takes in doing the make menuselect, that might be a clue |
| 23:19.58 | *** part/#asterisk-dev Mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 23:51.19 | *** join/#asterisk-dev shido6 (n=shido6@74-130-124-83.dhcp.insightbb.com) |