| 00:02.04 | kpfleming | yes, that's it |
| 00:02.10 | kpfleming | random data in a bad, bad place |
| 00:04.25 | russellb | i hate ... bugs ... |
| 00:15.39 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 00:15.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:32.42 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 00:32.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:56.06 | JunK-Y | wow, running * on itouch! |
| 01:00.21 | Corydon76-dig | Boy, that was a waste of effort... |
| 01:02.24 | JunK-Y | its in progress, isnt running yet |
| 01:02.30 | JunK-Y | its just fun. |
| 01:05.58 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 01:13.08 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 01:13.08 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 01:14.20 | russellb | JunK-Y: hey, could you test a chanspy fix for me? |
| 01:15.11 | russellb | in any case, it's committed whenever you're ready to verify if it fixes it |
| 01:15.15 | russellb | please reopen the bug if not |
| 01:15.38 | JunK-Y | i dont have the setup here, since im at university, the setup is at aheeva |
| 01:16.12 | russellb | ok, whenever, then |
| 01:16.16 | russellb | pretty sure i got it though |
| 01:16.42 | JunK-Y | if yes, i deserve you 1 beer at astricon :) |
| 01:17.13 | russellb | :) |
| 01:17.15 | russellb | we'll see ... |
| 01:17.43 | JunK-Y | if not, YOU owe me 1 beer :P |
| 01:18.24 | russellb | heh |
| 01:18.29 | russellb | ok, brain is fried |
| 01:18.30 | russellb | i'm out |
| 01:18.37 | JunK-Y | see ya |
| 01:18.38 | JunK-Y | doh! |
| 01:28.55 | *** part/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 01:41.00 | *** join/#asterisk-dev jameswf-home (n=james@166.128.198.184) |
| 01:55.38 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 01:58.30 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 03:02.41 | *** join/#asterisk-dev moy (n=moyhu@189.169.154.118) |
| 03:14.08 | *** join/#asterisk-dev jeffg (i=utf1Wmqr@pdpc/supporter/active/jeffg) |
| 03:16.14 | jeffg | joed! |
| 03:16.20 | jeffg | heh oops |
| 03:20.51 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:20.51 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:39.28 | *** join/#asterisk-dev ecto (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 03:41.38 | ecto | hey, I'm taking tilghman's C class... and I'm getting really excited about learning the asterisk API... |
| 03:42.43 | Qwell | w00t |
| 03:43.52 | russellb | w00t, indeed |
| 03:44.02 | ecto | took me a bit to get my head wrapped around it, but it's really, really cool |
| 03:44.08 | russellb | Asterisk <3 |
| 03:44.10 | ecto | (I'm Trey btw) |
| 03:45.27 | ecto | I'm too tired tonight, but got any suggestions on which janitor project I should begin looking into? |
| 03:46.34 | ecto | ...hmm... looks like the replace strncat, et al. with ast_build_string might be fairly straightforward... |
| 03:46.40 | russellb | heh |
| 03:46.43 | russellb | that page is so out of date |
| 03:46.47 | russellb | i need to remove it ... |
| 03:46.59 | russellb | ast_build_string() doesn't even exist anymore :-/ |
| 03:47.29 | ecto | should it be ast_str_set, etc.? |
| 03:47.33 | russellb | yes |
| 03:47.45 | ecto | OK, cool |
| 03:49.22 | Qwell | janitor project: fix the janitor project page |
| 03:49.26 | russellb | Qwell: yes! |
| 03:49.47 | russellb | Qwell: i think I would rather replace the page with a link to svn.digium.com/view/asterisk/trunk/doc/janitor-projects.txt |
| 03:49.52 | russellb | and then we can maintain it there |
| 03:49.55 | Qwell | totally |
| 03:50.00 | russellb | much more likely it will be current that way |
| 03:50.03 | Qwell | indeed |
| 03:50.06 | file | that's a good idea |
| 03:50.06 | Qwell | do it |
| 03:50.12 | Qwell | OMG you're alive! |
| 03:50.17 | file | am I? |
| 03:50.24 | russellb | of course, that means the file should exist |
| 03:50.35 | russellb | (it can be a placeholder for now) |
| 03:50.39 | russellb | i just want to make sure the link works |
| 03:50.52 | Qwell | I wonder if my checkouts are from origsvn |
| 03:51.07 | Qwell | hmm, yep |
| 03:51.31 | russellb | mine always are if it's my own box |
| 03:52.03 | *** join/#asterisk-dev jpeeler (n=jpeeler@adsl-065-005-230-151.sip.lft.bellsouth.net) |
| 03:52.12 | russellb | file: stop talking about jpeeler ! |
| 03:52.15 | russellb | jpeeler: OH HI |
| 03:52.20 | file | russellb: but but but |
| 03:52.31 | jpeeler | oh you guys |
| 03:52.39 | Qwell | done, if svn will let it finish |
| 03:52.42 | russellb | jpeeler: card installed?!?!?!?! |
| 03:52.54 | jpeeler | well... yeah, but not working |
| 03:53.05 | jpeeler | do the lights come on only if configured? |
| 03:53.14 | russellb | maybe? |
| 03:53.27 | russellb | on the analog cards, i think so ... |
| 03:53.27 | jpeeler | i'm pretty sure i have my zaptel.conf correct |
| 03:53.31 | russellb | on the T1 cards, they freak out |
| 03:53.33 | ecto | you know, I've never seen the lights on any digium card documented... |
| 03:53.43 | russellb | ecto: heh, me neither |
| 03:53.54 | lmadsen | random is hard to document :) |
| 03:53.58 | russellb | on the T1 cards, they reflect alarm ... |
| 03:54.06 | JunK-Y | russellb: thx for the fix btw, u quit rapidly earlier. |
| 03:54.08 | russellb | red == red alarm ... green == happy |
| 03:54.09 | jpeeler | i guess lspci would not find a digium card though if it didn't have power? |
| 03:54.18 | Qwell | jpeeler: it would |
| 03:54.19 | russellb | JunK-Y: you're welcome, it was just time for me to leave work :) |
| 03:54.20 | file | jpeeler: it should |
| 03:54.27 | russellb | should, yes ... |
| 03:54.29 | Qwell | if lspci isn't finding it, then...yeah |
| 03:54.34 | ecto | russellb: I never trust it though, I always put my faith in zttool... which may be a mistake, I guess... |
| 03:54.38 | russellb | though it's questionable as to whether it would say digium, though |
| 03:54.42 | JunK-Y | russellb: i was looking at code for a mutex. |
| 03:54.50 | russellb | it may show up as an ethernet adapter of some kind |
| 03:54.55 | jpeeler | no lspci is finding it, are you saying it could possibly not have power? |
| 03:55.02 | Qwell | jpeeler: possibly |
| 03:55.09 | russellb | i don't know if we have an ethernet adapter that lets us program the device id ... actually, i know we do ... nevermind |
| 03:55.11 | Qwell | see what ztscan says about it |
| 03:55.13 | jpeeler | crap, i don't even know if it has power |
| 03:55.22 | russellb | does it have power plugged in? |
| 03:55.29 | Qwell | err, wait, is it more than just fxo? |
| 03:55.42 | ecto | what card is this? |
| 03:55.48 | jpeeler | yes more than fxo |
| 03:55.53 | jpeeler | tdm411 |
| 03:56.00 | jpeeler | one fxo, one fxs |
| 03:56.06 | ecto | tdm400 or tdm410 based? |
| 03:56.10 | jpeeler | tdm410 based |
| 03:56.24 | jpeeler | i had quite a difficult time pressing in the power connector (which i forgot the first time) |
| 03:56.45 | ecto | dmesg should tell you if it's a power problem related to the fxs |
| 03:56.55 | lmadsen | jpeeler: maybe try reseating it? I actually had that work for a customer the other day when lspci didn't show the card |
| 03:57.09 | jpeeler | lmadsen, lspci does show the card though, still try that? |
| 03:57.23 | lmadsen | oh, it does? then that should be ok... |
| 03:57.28 | Qwell | russellb: commit failed, but file now exists :p |
| 03:57.29 | ecto | jpeeler: what does dmesg say? |
| 03:57.32 | JunK-Y | lmadsen: do you have some paper written on TBCT (RLT) by chance? |
| 03:57.42 | Qwell | "failed".. I think the post-hook just never returned |
| 03:57.53 | lmadsen | JunK-Y: I don't understand what your acronyms mean |
| 03:58.03 | JunK-Y | two b channel transfer |
| 03:58.52 | jpeeler | here comes a small flood |
| 03:58.54 | jpeeler | Zapata Telephony Interface Registered on major 196 |
| 03:58.55 | jpeeler | Zaptel Version: SVN-branch-1.4-r3883 |
| 03:58.55 | jpeeler | Zaptel Echo Canceller: MG2 |
| 03:58.55 | jpeeler | ztdummy: Trying to load High Resolution Timer |
| 03:58.55 | jpeeler | ztdummy: Initialized High Resolution Timer |
| 03:58.55 | jpeeler | ztdummy: Starting High Resolution Timer |
| 03:58.58 | jpeeler | ztdummy: High Resolution Timer started, good to go |
| 03:59.07 | russellb | Qwell: commit failed? |
| 03:59.13 | Qwell | I kill -9'd it |
| 03:59.17 | russellb | Qwell: i don't see it in viewvc ... |
| 03:59.24 | Qwell | it finished |
| 03:59.37 | Qwell | it sat there for like 5 minutes. post-hook wasn't happy |
| 03:59.39 | russellb | rev 3? |
| 03:59.42 | Qwell | eh? |
| 03:59.46 | russellb | rev #? |
| 03:59.51 | Qwell | 104418 |
| 03:59.55 | russellb | the post hook handles the mirroring, you know. |
| 03:59.56 | file | Qwell: it did that to me earlier |
| 04:00.03 | ecto | jpeeler: you should see something about the TDM410 in dmesg... what card driver do you have installed? |
| 04:00.12 | Qwell | russellb: it still goes - it just doesn't let the client return |
| 04:00.25 | russellb | ok |
| 04:00.28 | Qwell | killing the client is like "whatever, I don't care anymore. finish your thing" |
| 04:00.31 | ecto | jpeeler: wctdm or wctdm24xxp? |
| 04:00.53 | file | this delay because of the mirror sync is botherful |
| 04:01.01 | Qwell | file: mmhmm :( |
| 04:01.11 | Qwell | soon that should be fixed though |
| 04:01.15 | jpeeler | ecto, wctc4xxp |
| 04:01.17 | russellb | one of these days |
| 04:01.27 | russellb | jpeeler: wrong driver, sir |
| 04:01.28 | jpeeler | ooh |
| 04:01.29 | jpeeler | ye |
| 04:01.31 | ecto | jpeeler: that's the TC400 transcoder driver |
| 04:01.31 | jpeeler | p |
| 04:01.36 | jpeeler | man i make so many mistakes |
| 04:01.49 | jpeeler | i notice of course right when i send it... |
| 04:01.50 | ecto | you want the wctdm24xxp |
| 04:01.59 | russellb | Qwell: file ... janitor projects page updated |
| 04:02.04 | jpeeler | are you sure? |
| 04:02.08 | Qwell | w00t |
| 04:02.13 | file | russellb: that's hawt |
| 04:02.29 | ecto | jpeeler: for the TDM410P? Yes! |
| 04:02.49 | russellb | that driver was originally only for the 24 port analog card |
| 04:02.59 | russellb | but then we made an 8 port, and now a 4 port derivative of the same hardware |
| 04:03.09 | russellb | and thus ... the confusing name |
| 04:03.13 | jpeeler | hmm, menuselect needs to be updated |
| 04:03.15 | Qwell | wctdm41xp would probably be an alias |
| 04:03.22 | russellb | jpeeler: you can do it :) |
| 04:03.25 | file | next up is the 42 port DS3 card |
| 04:03.26 | Qwell | in fact, if it isn't... |
| 04:03.30 | russellb | jpeeler: vim zaptel.xml or something |
| 04:03.45 | Qwell | let's see! |
| 04:03.46 | ecto | do what? |
| 04:03.49 | jpeeler | that's hardcore |
| 04:04.00 | russellb | jpeeler: what's hardcore? |
| 04:04.11 | jpeeler | editing an xml file |
| 04:04.14 | russellb | oh, lol |
| 04:04.18 | Qwell | only one alias... |
| 04:04.19 | russellb | in asterisk it's even better |
| 04:04.28 | Qwell | funky |
| 04:04.29 | russellb | that XML file is automatically generated |
| 04:05.03 | Qwell | russellb: what do you think about making wctdm41xp, wcaex8xxp, and wcaex24xxp aliases of wctdm24xxp? |
| 04:05.18 | *** part/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 04:05.19 | russellb | certainly fine with me |
| 04:05.21 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 04:05.21 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 04:05.26 | russellb | you might want to run it by the zaptel powers that be |
| 04:05.31 | Qwell | ^W != delete |
| 04:05.32 | russellb | which is not really us .... |
| 04:05.32 | Qwell | ... |
| 04:05.35 | Qwell | yeah |
| 04:06.39 | jpeeler | looking better... Found a Wildcard TDM: Wildcard TDM410P (4 modules) |
| 04:06.51 | Qwell | yay |
| 04:06.58 | ecto | w005 |
| 04:07.00 | ecto | um |
| 04:07.02 | ecto | yeah |
| 04:07.25 | jpeeler | so i wasn't watching... but the lights are on now |
| 04:07.37 | russellb | yep |
| 04:07.41 | russellb | because you loaded the driver |
| 04:07.43 | jpeeler | so the lights must be dependent on the correct driver |
| 04:07.43 | russellb | which initialized the hw |
| 04:07.49 | jpeeler | that's good to know |
| 04:08.21 | file | leds are fun |
| 04:08.42 | russellb | you know ... it's so funny that we're all on here |
| 04:08.47 | russellb | we work our asses off all day in the office ... |
| 04:08.48 | ecto | blinkenlights is good |
| 04:08.48 | russellb | and then ... |
| 04:08.58 | russellb | we get on IRC and keep working on stuff at night |
| 04:08.58 | russellb | heh |
| 04:09.10 | Corydon76-dig | It's an obsession |
| 04:09.13 | russellb | you guys are hardcore |
| 04:09.13 | jpeeler | i thought that was the true open source way |
| 04:09.14 | ecto | I'm not even salaried! |
| 04:09.24 | russellb | Corydon76-dig: it is ... |
| 04:09.35 | russellb | Corydon76-dig: you know, i got fired from my previous job for being addicted to asterisk :-p |
| 04:09.45 | Corydon76-dig | What? |
| 04:09.53 | Qwell | at Digium, you get hired :p |
| 04:09.55 | jpeeler | haha |
| 04:10.01 | russellb | sort of a long story ... |
| 04:10.07 | ecto | it always is |
| 04:10.09 | Corydon76-dig | I've got the time |
| 04:10.09 | russellb | but i ended up here, so all is good :) |
| 04:10.11 | russellb | lol |
| 04:10.20 | russellb | i'll tell you in person sometime |
| 04:10.27 | file | it's a good story |
| 04:10.32 | file | even has pirates |
| 04:10.36 | russellb | i'm forgetting details over time, though ... |
| 04:10.42 | ecto | but no ninja |
| 04:10.43 | Qwell | blog it |
| 04:11.13 | ecto | russellb: those are the best kinds of stories... just make the parts you forget as you go along... |
| 04:11.34 | ecto | embellish it... my stories always get better over time (-; |
| 04:13.58 | ecto | is that the insanity banana? |
| 04:14.21 | Corydon76-dig | file: are you saying he acts like Ringo? |
| 04:14.23 | jpeeler | but what kind of banana is it? |
| 04:14.32 | jpeeler | is it a speckled one or slightly green ... |
| 04:15.13 | jpeeler | (somebody was talking about that a couple days ago) |
| 04:15.36 | file | I'm not telling. |
| 04:16.22 | russellb | dwayne. |
| 04:16.36 | jpeeler | ah, right |
| 04:16.42 | jpeeler | and mark too i think |
| 04:17.17 | Corydon76-dig | Which Mark? |
| 04:17.23 | file | M |
| 04:17.26 | jpeeler | correct |
| 04:18.25 | russellb | moo |
| 04:18.59 | Corydon76-dig | Oink |
| 04:20.20 | JunK-Y | how can code stops at gtalk = ASTOBJ_CONTAINER_FIND(>alk_list, name); ??? the head is locked when calling: ASTOBJ_CONTAINER_TRAVERSE() ? |
| 04:21.07 | russellb | if you have a deadlock, i would recommend getting "core show locks" output |
| 04:21.13 | russellb | as it can usually show you the exact problem |
| 04:21.52 | JunK-Y | == Thread ID: 1081112896 (pbx_thread started at [ 2627] pbx.c ast_pbx_start()) |
| 04:21.56 | JunK-Y | === ---> Lock #0 (chan_gtalk.c): MUTEX 274 find_gtalk &(>alk_list)->_lock 0x2aaac4d03c40 (1) |
| 04:22.49 | russellb | that's just like ... 25% of the picture :) |
| 04:23.10 | JunK-Y | no mutex are waiting, but i put an ast_log before the ASTOBJ_CONTAINER_FIND() and after and the one after is never printed. |
| 04:23.13 | JunK-Y | wait |
| 04:23.44 | JunK-Y | http://pastebin.ca/920042 |
| 04:23.54 | Qwell | it could be an infinite loop over the list |
| 04:24.21 | JunK-Y | deadlocks are only when i see waiting in the core show locks, right? |
| 04:24.26 | russellb | incredibly doubtful |
| 04:24.36 | russellb | but you could add debug in the macro to find out i guess |
| 04:24.46 | snuff-work | russ.. nice on the jantior thing :) |
| 04:24.56 | russellb | thanks |
| 04:25.09 | russellb | JunK-Y: attach with gdb and see what the thread is doing |
| 04:26.36 | JunK-Y | <PROTECTED> |
| 04:26.39 | JunK-Y | <PROTECTED> |
| 04:26.43 | JunK-Y | <PROTECTED> |
| 04:27.08 | russellb | wtf is it running select for?! |
| 04:27.17 | JunK-Y | all the other are select(), poll() , nanosleep() and pthread_cond_wait() |
| 04:27.21 | JunK-Y | ive no idea! |
| 04:27.22 | russellb | that is some f'd up code |
| 04:28.20 | russellb | it's not. |
| 04:28.23 | russellb | DONT_OPTIMIZE ? |
| 04:28.45 | russellb | there is no possible call to select from find_gtalk() ... |
| 04:28.54 | russellb | or from any function that find_gtalk() calls |
| 04:29.19 | Qwell | that's 2 diff threads, no? |
| 04:29.34 | russellb | oh, right |
| 04:29.42 | JunK-Y | no DONT OPTIMIZE, just DEBUG_THREADS and DETECT_DEADLOCKS |
| 04:29.49 | russellb | get the backtrace _only_ from the thread in find_gtalk |
| 04:31.33 | JunK-Y | http://pastebin.ca/920050 see the end. |
| 04:32.27 | russellb | i f'ing hate complicated macros |
| 04:33.05 | *** join/#asterisk-dev bkw_ (n=brian@adsl-70-234-184-1.dsl.tul2ok.sbcglobal.net) |
| 04:34.46 | russellb | i guess it is possible that it's in an infinite loop ... |
| 04:34.55 | russellb | if it was stuck on a lock, the locks output should show it |
| 04:35.19 | Qwell | wouldn't surprise me that much ;/ |
| 04:35.35 | JunK-Y | i will add print, wait |
| 04:45.37 | snuff-work | mm interesting janitor project would be change all code to have braces req by new coding guidelines.. the svn stats would look impressive after that :) |
| 04:46.43 | russellb | that would be the worst janitor project ever |
| 04:47.01 | russellb | let's change 50 thousand lines of code for no benefit! |
| 04:47.06 | russellb | all manually, of course |
| 04:47.15 | JunK-Y | yes, infinite loop |
| 04:47.16 | Qwell | I could sed it |
| 04:47.29 | Qwell | JunK-Y: which means your list is endless.. |
| 04:47.33 | snuff-work | yep it would be.. but interesting stat |
| 04:47.49 | Qwell | one ->next pointer (or whatever the equiv in AST_OBJ is) is pointing backward in the list |
| 04:53.12 | russellb | now you get to figure out which element(s) are broken |
| 04:53.13 | russellb | and then why |
| 04:53.26 | russellb | whether it's improper usage of the macros, or the macros themselves |
| 04:53.30 | russellb | oh joy |
| 04:54.11 | Qwell | bed |
| 04:54.15 | JunK-Y | i know how exactly, i can reproduce this really easily. |
| 04:58.54 | JunK-Y | i will report this on mantis I think |
| 05:03.46 | jpeeler | so if the phone line from the wall was plugged into the fxs port, would it damage the card? |
| 05:06.12 | jpeeler | You never want to plug a phone line into an FXS port, because both are supplying power. If you do so you will probably damage your FXS device and possibly cause problems with your phone company as well. |
| 05:06.26 | jpeeler | good enough |
| 06:55.39 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 06:55.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:03.53 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:10.18 | jmls_work | dammit - had that segfault again |
| 07:11.41 | jmls_work | #0 0x08100338 in ast_copy_string (dst=0xb776f325 "", src=0x0, size=80) at /usr/src/asterisk/include/asterisk/strings.h:168 |
| 07:11.48 | jmls_work | heh |
| 07:12.22 | jmls_work | in fact, got it over 25 times between 23:19 and 01:51 |
| 07:12.40 | jmls_work | I think I can say I can reproduce it ;) |
| 07:27.17 | *** join/#asterisk-dev techie (n=techie@adsl-76-214-12-55.dsl.lsan03.sbcglobal.net) |
| 07:27.54 | *** part/#asterisk-dev techie (n=techie@adsl-76-214-12-55.dsl.lsan03.sbcglobal.net) |
| 07:32.48 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 07:32.48 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:42.00 | *** join/#asterisk-dev oej (n=olle@213.89.171.130) |
| 07:42.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:52.08 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:38.46 | snuff-work | jmls_work: you use lot of mixmon/recording? |
| 08:43.34 | *** join/#asterisk-dev bkw_ (n=brian@adsl-70-234-184-1.dsl.tul2ok.sbcglobal.net) |
| 08:49.25 | snuff-work | if u do.. |
| 08:49.28 | snuff-work | M11962 |
| 08:49.29 | MuffinMan | [new] [Asterisk] Resources/res_monitor 0011962: [patch] Simple file recording buffer - great performance gain reported by garlew http://bugs.digium.com/view.php?id=11962 |
| 09:04.36 | *** join/#asterisk-dev qdk_ (n=qdk@85.235.253.139) |
| 09:21.45 | jmls_work | snuff-home: yup |
| 09:35.23 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 10:08.53 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:31.02 | *** part/#asterisk-dev jmls_work (n=jmls@mail.tessera.co.uk) |
| 10:36.39 | *** join/#asterisk-dev RoyK (n=roy@213.160.242.90) |
| 11:12.52 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-117347.home.otenet.gr) |
| 11:17.00 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 11:43.25 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 11:47.59 | *** join/#asterisk-dev jmls (n=jmls@mail.tessera.co.uk) |
| 11:48.49 | jmls | what did I miss ? |
| 11:52.18 | atis_work | jmls, nothing |
| 11:52.42 | atis_work | only join of snuff-home, RoyK and puzzled |
| 11:53.17 | atis_work | jmls, whats following lines of that crash |
| 11:53.27 | atis_work | ast_copy_string usually tells nothing |
| 11:56.21 | jmls | atis_work: http://www.pastebin.ca/919727 |
| 11:58.00 | atis_work | jmls, rt_handle_member is part i know very well.. are you using any patches or it's clean 1.4 branch? |
| 11:58.16 | atis_work | s/rt_handle_member/rt_handle_member_record/ |
| 11:59.06 | atis_work | can you grep -B 30 "Asterisk Event" /var/log/asterisk/full |
| 11:59.36 | steliosk | hi all ! |
| 12:00.15 | steliosk | Does anyone if any of the Digium cards use DMA to transfer data ? |
| 12:00.30 | steliosk | s/anyone/anyone knows |
| 12:01.45 | jmls | atis_work: I think it was the patched version you sent me |
| 12:02.01 | jmls | I have reverted back to clean, and rerunning the stress test to check |
| 12:03.07 | atis_work | jmls, whitch patch |
| 12:03.28 | jmls | the realtime member update one |
| 12:03.47 | atis_work | from mantis? |
| 12:03.58 | jmls | jeez, I think so .. |
| 12:04.03 | atis_work | M11896 |
| 12:04.04 | MuffinMan | [assigned] [Asterisk] Applications/app_queue 0011896: Optimized update_realtime_member_field function reported by atis http://bugs.digium.com/view.php?id=11896 |
| 12:04.14 | jmls | that's the puppy |
| 12:05.21 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:05.23 | atis_work | jmls, i would appreciate log before crash, with debug and verbose =3 |
| 12:05.40 | atis_work | core set debug 3 |
| 12:05.42 | atis_work | core set verbose 3 |
| 12:07.00 | jmls | crap, I've already reverted |
| 12:07.03 | jmls | sorry |
| 12:07.07 | atis_work | also dump from your queue_members after crash would be useful |
| 12:07.16 | atis_work | well, but do you have full log enabled? |
| 12:07.26 | atis_work | just grep on it |
| 12:07.27 | jmls | yeah, but not debug |
| 12:08.47 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 12:08.51 | atis_work | jmls, maybe you had some empty records in queue_members? |
| 12:08.57 | jmls | I'll see how this run goes - I'll reapply the patch and try to break it again ;) |
| 12:08.59 | atis_work | if using curl, it could be empty line? |
| 12:09.21 | atis_work | well, if it's not too much effort for you |
| 12:09.22 | jmls | atis_work: No, I specifically check to make sure that the member has a interface before sending out the data |
| 12:09.46 | atis_work | i was planning to put this all into production this weekend |
| 12:09.48 | jmls | However, if that were the problem, then asterisk should also take into account that the data may be zero |
| 12:10.03 | atis_work | yes, it should |
| 12:10.06 | jmls | it was easy to break before, so I don't think that it will be a problem to break again |
| 12:11.11 | atis_work | this is line that worries me: interface=0xb66be8b8 "", rt_uniqueid=0x0, membername=0xb66be8b8 "", penalty_str=0x0, paused_str=0x0 |
| 12:11.18 | atis_work | all empty |
| 12:13.05 | atis_work | jmls, aren't you using first version of that patch? |
| 12:13.22 | atis_work | i see there's rt_uniqueid not rt_uniqueid_str |
| 12:13.58 | atis_work | so that would be the part you wanted - to have string uniqueid instead of int |
| 12:15.29 | atis_work | aaah, sorry... nope, that's fine - i renamed it |
| 12:17.44 | *** join/#asterisk-dev tzafrir_home (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 12:17.44 | *** mode/#asterisk-dev [+o tzafrir_home] by ChanServ |
| 12:17.46 | atis_work | jmls, you could search for two occurances of using rt_handle_member_record and replace one line in them |
| 12:17.50 | atis_work | ast_variable_retrieve(member_config, interface, "uniqueid"), |
| 12:18.16 | atis_work | S_OR(ast_variable_retrieve(member_config, interface, "uniqueid"),"0"), |
| 12:18.43 | atis_work | or better with S_OR(ast_variable_retrieve(member_config, interface, "uniqueid"),""), |
| 13:02.05 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.111.94) |
| 13:06.47 | *** join/#asterisk-dev jeffg (i=DdGviR68@pdpc/supporter/active/jeffg) |
| 13:08.22 | *** join/#asterisk-dev dandre (n=daniel@was59-3-82-236-48-30.fbx.proxad.net) |
| 13:20.39 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:24.22 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 13:34.19 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 13:56.01 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 14:03.10 | *** join/#asterisk-dev _Krieger_ (n=krieger@193.39.118.158) |
| 14:06.44 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 14:07.23 | *** join/#asterisk-dev seanbright (i=seanbrig@65.207.74.18) |
| 14:08.09 | _Krieger_ | what should i do if i want to get at least an exitcode of sth i ran by ast_safe_system()? |
| 14:25.35 | Corydon76-dig | _Krieger_: eh? |
| 14:27.21 | _Krieger_ | Corydon76-dig: i meant to get exitcode, or even output of a binary i ran by ast_safe_system(). i see that is impossible in current implementation, so i`m doing a trick with saving output to disc |
| 14:28.02 | Corydon76-dig | What are you talking about? The exit status is the return value of ast_safe_system |
| 14:28.36 | _Krieger_ | 00457 execl("/bin/sh", "/bin/sh", "-c", s, NULL); |
| 14:28.37 | _Krieger_ | 00458 _exit(1); |
| 14:28.46 | _Krieger_ | http://www.asterisk.org/doxygen/1.2/ |
| 14:28.57 | Corydon76-dig | And? |
| 14:29.44 | Corydon76-dig | 1.2 is unsupported |
| 14:30.24 | _Krieger_ | 00461 res = wait4(pid, &status, 0, &rusage); // <=== ah, this gets exitcode. thanks |
| 14:36.46 | seanbright | so are the standard text documents in doc/ no longer maintained? should any new documentation be done in doc/tex? |
| 14:37.01 | seanbright | i notice there are some that are in doc/tex that don't exist in doc/ |
| 14:38.27 | Corydon76-dig | seanbright: we accept all forms of documentation |
| 14:38.43 | Corydon76-dig | Well, in open formats, anyway |
| 14:38.47 | seanbright | right |
| 14:38.48 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:38.48 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:39.03 | seanbright | but were i to author new documentation, what is the process? plain text? tex? |
| 14:39.29 | Corydon76-dig | If you want to maintain parity between the two as a personal project, you're welcome to, although we'd prefer more documentation to parity of documentation |
| 14:39.48 | Corydon76-dig | seanbright: whatever suits your fancy |
| 14:58.14 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 14:58.14 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:07.47 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 16:02.22 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 16:20.54 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:20.54 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:23.23 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 16:23.23 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 16:29.49 | *** join/#asterisk-dev elguero (n=elguero@207.154.34.162) |
| 16:30.55 | *** join/#asterisk-dev miguel3239 (n=elguero@207.154.34.162) |
| 16:38.22 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:40.22 | *** join/#asterisk-dev oej (n=olle@cust-IP-11.data.tre.se) |
| 16:40.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:44.16 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:44.58 | *** join/#asterisk-dev Simon-- (n=sim@staff-nat.netnation.com) |
| 16:50.42 | Simon-- | any race/locking fixes that would fix crashes in ast_channel_free() since the release of 1.4.18? |
| 16:50.57 | russellb | doubt it |
| 16:51.23 | Simon-- | woohoo :) debug build time, I guess ;) |
| 16:53.51 | *** join/#asterisk-dev elguero (n=elguero@207.154.34.162) |
| 16:57.05 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 17:05.04 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 17:05.04 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 17:05.21 | file | well hello there Cresl1n |
| 17:05.27 | Cresl1n | hey file! |
| 17:05.58 | oej | file: I saw a lot of issues with sip/devicestate today. Will have to spend a day going through that stuff again for 1.4. |
| 17:06.24 | oej | file: If you have hints that points to multiple phones, lamps doesn't turn off properly. |
| 17:07.17 | file | yucky. |
| 17:07.40 | russellb | if i had like 7 brains and could work 120 hours a day, i would totally rip out device state and start over |
| 17:07.53 | russellb | but i guess that thought isn't very helpful. :) |
| 17:08.05 | file | russellb: ditto |
| 17:08.24 | tzanger | russellb: which are you missing 7 brains or 120 hours in a day? |
| 17:08.35 | russellb | some combination of the 2 |
| 17:10.21 | jsmith | (not that it would help) |
| 17:10.25 | tzanger | jsmith: well he'll still need 7 brains :-) |
| 17:10.34 | tzanger | yours can keep the others company though |
| 17:29.10 | puzzled | hi all |
| 17:29.13 | puzzled | oej: ping |
| 17:29.31 | jsmith | Hey puzzled |
| 17:29.40 | puzzled | hi jsmith. how's life? |
| 17:30.17 | puzzled | is http://tools.ietf.org/html/rfc3329 supposed to work with 1.4? |
| 17:31.04 | puzzled | I'm looking at wireshark and it seems 1.4 and a Nokia N95 are a bit confused when I turn on security on the N95 |
| 17:32.07 | file | nope. |
| 17:32.31 | puzzled | ok thanks |
| 17:32.34 | *** join/#asterisk-dev bkw__ (n=brian@76.211.64.159) |
| 17:33.15 | jsmith | puzzled: Not too bad... lots of travel, lots of talking, but other than that I can't complain |
| 17:33.30 | puzzled | going places. nice :) |
| 17:34.05 | jsmith | puzzled: I hope so... I'd hate to just be running around in circles. |
| 17:34.13 | puzzled | heheh |
| 17:44.10 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 17:48.18 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 17:48.58 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:07.30 | *** join/#asterisk-dev qdk_ (n=qdk@195.242.194.42) |
| 18:19.13 | *** part/#asterisk-dev dandre (n=daniel@was59-3-82-236-48-30.fbx.proxad.net) |
| 18:38.03 | caio1982 | is there any obvious reason for DYNAMIC_FEATURES to work only after a Dial()? |
| 18:38.29 | russellb | yes |
| 18:38.36 | russellb | that code only works in a bridge |
| 18:38.44 | russellb | (it would also work in Queue) |
| 18:39.26 | caio1982 | hmmm ok :) |
| 18:39.55 | russellb | it doesn't _have_ to be that way |
| 18:39.59 | russellb | but that's why it only works that way now |
| 18:40.51 | caio1982 | i don't know how spy works right now, but maybe that would work also? that's a bridge anyway, isn't it? |
| 18:46.23 | jmls | here's a loaded question: |
| 18:46.52 | file | caio1982: you mean the underlying api that chanspy/mixmonitor uses? |
| 18:47.00 | *** join/#asterisk-dev Dovid (n=Dovid@bzq-79-181-108-212.red.bezeqint.net) |
| 18:47.00 | caio1982 | file: yep |
| 18:47.08 | Dovid | can I offer a vounty here to have this fixed ? |
| 18:47.09 | Dovid | http://bugs.digium.com/view.php?id=11181 |
| 18:47.19 | file | caio1982: it acts on channels, doesn't care about bridges |
| 18:47.21 | russellb | M11181 |
| 18:47.22 | MuffinMan | [assigned] [Asterisk] Core/ManagerInterface 0011181: Manager API hangs on "Command: show channels" reported by acunningham http://bugs.digium.com/view.php?id=11181 |
| 18:47.28 | jmls | for realtime queues, how hard would it be to make a realtime engine request for the next available member, rather than querying the in-memory member list ? |
| 18:47.34 | russellb | Dovid: did you post "core show locks" output? |
| 18:47.57 | jmls | i.e. ask the realtime engine to determine the member / interface to put the call through to |
| 18:48.01 | russellb | Dovid: digium developers do not accept money to fix bugs, just to be clear |
| 18:48.05 | russellb | anyone else here is fair game :) |
| 18:48.14 | caio1982 | file: but when you start spying a given channel it does create a bridge between you and the target channel, doesn't it? |
| 18:48.22 | Dovid | russelb: are they not allowed ? |
| 18:48.29 | russellb | not allowed, correct |
| 18:48.30 | file | caio1982: not really |
| 18:48.41 | caio1982 | ops |
| 18:49.40 | Dovid | russelb: ngn2*CLI> core show locks |
| 18:49.40 | Dovid | No such command 'core show' (type 'help' for help) |
| 18:50.01 | Dovid | if u use tabing i can get to core show but there is no locks there |
| 18:50.46 | russellb | Dovid: build with DEBUG_THREADS turned on |
| 18:51.01 | Dovid | argh !! production server |
| 18:51.22 | russellb | ok |
| 18:51.26 | russellb | then do it after hours ... |
| 18:51.30 | Dovid | russelb: can you post that on the ticket ? |
| 18:51.36 | Dovid | the submiter is the coder. |
| 18:51.42 | russellb | i can't right now, no |
| 18:51.42 | Dovid | he has a test machine. i dont |
| 18:51.46 | caio1982 | people should use embedded modules for production servers, so it'd be easier to change versions quickly for testings like this :D |
| 18:51.50 | russellb | you can though :) |
| 18:51.54 | Dovid | ok |
| 18:52.09 | *** part/#asterisk-dev jmls (n=jmls@mail.tessera.co.uk) |
| 18:52.20 | *** join/#asterisk-dev jmls (n=jmls@mail.tessera.co.uk) |
| 18:52.55 | jmls | eek |
| 18:53.16 | jmls | putnopvut: ping |
| 18:53.29 | jmls | jbot: hug putnopvut |
| 18:53.30 | jbot | ACTION gets a running start and tackle-hugs putnopvut |
| 18:54.21 | Dovid | russelb: thanks. I will have the coder update it. |
| 18:54.29 | russellb | k |
| 18:56.41 | JunK-Y | russellb: even the latest version doesnt solve my issue for chanspy |
| 18:57.25 | JunK-Y | <PROTECTED> |
| 18:57.28 | JunK-Y | <PROTECTED> |
| 18:57.30 | JunK-Y | <PROTECTED> |
| 18:57.40 | JunK-Y | its hangup the other channel |
| 18:57.51 | JunK-Y | localhost*CLI> core show channels |
| 18:57.51 | JunK-Y | Channel Location State Application(Data) |
| 18:57.51 | JunK-Y | IAX2/1000-2 AH1000@agents:2 Up AgentLogin(1000|s) |
| 18:57.51 | JunK-Y | 1 active channel |
| 18:57.51 | JunK-Y | 1 active call |
| 18:57.58 | JunK-Y | and im still bridge! |
| 18:58.45 | putnopvut | jmls: pong |
| 18:58.55 | JunK-Y | i also tried some rev to maybe find between which Rev, the real problem occurs. |
| 18:58.59 | JunK-Y | 99923 = lock |
| 18:59.01 | JunK-Y | 98972 = lock |
| 18:59.04 | JunK-Y | 75078 = segfault |
| 18:59.04 | jmls | using realtime queues, and members |
| 18:59.31 | russellb | JunK-Y: rar! ... if it was happening that long ago, then i didn't cause it .... |
| 18:59.34 | jmls | I was returning only members that were available |
| 19:00.00 | jmls | but, if there were calls already in the queue, the new members would not get a call |
| 19:00.09 | jmls | new == now available |
| 19:00.21 | JunK-Y | russellb: its probably not ur audiohook in fact |
| 19:00.56 | putnopvut | jmls: How were they unavailable before? Paused? On the phone? Not logged in? |
| 19:01.08 | jmls | they had taken a call, thus became unavailable |
| 19:01.18 | jmls | after the call ends, they wrap up for a while |
| 19:01.30 | jmls | I was thinking for realtime queue members only, how hard would it be to make a realtime engine request for the next available member, rather than querying the in-memory member list |
| 19:02.17 | jmls | so, when attempting to place a call, app_queue checks realtime for the interface to dial |
| 19:02.23 | putnopvut | jmls: I guess it wouldn't be too difficult, it would just be a matter of having to store the status in realtime instead of in memory. |
| 19:02.26 | JunK-Y | russellb: on ur side its working fine with the q option? |
| 19:02.46 | russellb | seemed to be with a quick test |
| 19:02.56 | russellb | i'll test again in a bit |
| 19:03.21 | jmls | why store the status: app_queue gets the interface, places the call. If the call fails, try another request |
| 19:03.27 | putnopvut | jmls: but the thing is there are measures taken which should prevent what you're seeing from happening. |
| 19:04.00 | putnopvut | So what you're saying is that a member is unavailable, then becomes available, and then never can receive calls from people who joined the queue when the member was unavailable? |
| 19:04.01 | jmls | putnopvut: if I "show queue foo" then the new members get called |
| 19:04.41 | jmls | yeah, because the member list only gets refreshed when a call joins the queue, or a "show queue foo" or something along those lines |
| 19:05.05 | putnopvut | The member list gets refreshed also when a caller attempts to call a member but is unsuccessful. |
| 19:05.26 | jmls | that's the issue - I only have available members in the member list |
| 19:05.59 | putnopvut | Oh, I see, so you want a more immediate refresh of the queue members. |
| 19:06.04 | jmls | yup |
| 19:06.20 | jmls | but that is very bad performance wise |
| 19:06.55 | jmls | that's why I got to thinking of the queeu asking the engine for the next member, not loading / refreshing member list all the time |
| 19:07.12 | putnopvut | Yeah, reading from the realtime backend is really the only viable solution with what's in place right now. |
| 19:07.44 | jmls | the member list only exists there to |
| 19:07.58 | jmls | a) determine the next agent to call (priority / round robin etc) |
| 19:08.09 | jmls | b) determine the interface to call |
| 19:08.46 | jmls | so, could we not have a queue strategy that is "realtime". IOW ask the engine for a) and b) |
| 19:09.03 | jmls | it;s the engine's issue to return a valid member and interface |
| 19:09.14 | jmls | no data returned == no available agents |
| 19:10.12 | jmls | sorry - I've gotta run. I was expected home 20 minutes ago. I work 80 minutes from home ... |
| 19:10.29 | jmls | I've kept this window opn though. |
| 19:10.39 | putnopvut | jmls: it's entirely possible, but it's a matter of whether it should be done or not...the performance hit would be noticeable, I'd think. |
| 19:10.50 | putnopvut | jmls: all right. I'll talk to you later :) |
| 19:13.07 | *** join/#asterisk-dev elguero (n=elguero@207.154.34.162) |
| 19:21.26 | jsmith | jmls: It's not too hard to do that from the dialplan, in all actuality |
| 19:21.48 | jsmith | jmls: And then have the dialplan query your "call distribution engine" |
| 19:25.53 | *** join/#asterisk-dev AdamWest (n=Leif@CPE001d7e2f9574-CM0012c9db3d2e.cpe.net.cable.rogers.com) |
| 19:34.12 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 19:42.28 | russellb | JunK-Y: chanspy is working fine for me ... do you have modifications to asterisk? |
| 19:42.37 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 19:43.55 | JunK-Y | not in that part, ive custom apps. |
| 19:44.51 | JunK-Y | and you're calling Chanspy(,q) too? |
| 19:45.20 | russellb | yes, exactly Chanspy(,q) |
| 19:46.21 | JunK-Y | from iax2 and you're dialing a remote machine ? |
| 19:48.08 | russellb | no |
| 19:48.23 | russellb | just using SIP phones |
| 19:48.29 | russellb | but if it's a crash in chanspy, it shouldn't matter |
| 19:48.41 | JunK-Y | let me test ur scenario. |
| 19:49.20 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:54.22 | *** join/#asterisk-dev docelmo (n=vircuser@h74.196.180.12.cable.rstb.cablerocket.net) |
| 19:54.41 | *** part/#asterisk-dev docelmo (n=vircuser@h74.196.180.12.cable.rstb.cablerocket.net) |
| 19:59.38 | JunK-Y | even if a local sip is calling meetme, a local iax2 calling chanspy() with or without q cant hear that channel, i dont see any message attaching channel x to y. |
| 20:10.53 | JunK-Y | russellb: quick questions, when you do info threads in gdb, how can i know which thread has done a mutex lock, since i see a pthread_mutex_trylock on another thread |
| 20:19.30 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 20:20.35 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:54.35 | snuff-work | mmm had interesting problem today.. if a call is flagged with 'privacy:id' in sip header.. when i try to send the call off to another user changing the callerid it fails and just leaves it as unknown <unknown> |
| 20:55.24 | snuff-work | now if i redirect the call into a queue and get agent to answer it.. i can successfully get my right callerid |
| 20:55.29 | snuff-work | that i set |
| 21:04.10 | jmls | I'm baaaaaackkkk :p |
| 21:04.33 | jmls | oh. |
| 21:04.37 | jmls | none |
| 21:04.39 | jmls | :) |
| 21:04.56 | file | jmls: all of that is done in private of course |
| 21:05.00 | jmls | heh |
| 21:05.16 | jmls | jsmith: like the idea. It's, like, so obvious. |
| 21:05.28 | jmls | Local channel, I presume. |
| 21:05.31 | jmls | with/n |
| 21:05.39 | jmls | and ringinuse set ? |
| 21:05.58 | jmls | I also presume that autofill would work just fine. |
| 21:08.01 | jmls | can you have realtime queues, but static queue members ? |
| 21:08.25 | putnopvut | You can. |
| 21:08.55 | jmls | ___cooool___ |
| 21:09.14 | Corydon76-dig | Cool is what the weather is right now here |
| 21:09.36 | putnopvut | Yes it definitely is not warm. |
| 21:09.48 | Corydon76-dig | Thankfully, the ground is still warm, though, or else the snow would stick |
| 21:10.02 | jmls | not as cool as some "cryogenic healing" some horse jockey had over here. |
| 21:10.10 | jmls | 3 minutes at -140 C |
| 21:10.16 | jmls | <PROTECTED> |
| 21:10.36 | Juggie | could someone yell @ it to fix svn ? :) |
| 21:10.40 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 21:10.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:10.52 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 21:10.59 | Corydon76-dig | jmls: that's about the point in Minnesota when residents don a winter jacket |
| 21:11.20 | jmls | lol |
| 21:11.53 | Corydon76-dig | I don't see how anybody lives there... |
| 21:12.07 | jmls | so, here's the interesting part. How do you know when to add a static member to a realtime queue ;) |
| 21:12.30 | jmls | persistent members *may* help I suppose .. |
| 21:21.26 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 21:25.48 | lmadsen | jmls: I use a view and add them to the view based on a flag.... |
| 21:30.39 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583194.dsl.bell.ca) |
| 21:30.43 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 21:34.41 | russellb | svn mirror is getting fixed |
| 21:35.59 | *** join/#asterisk-dev oej (n=olle@212.17.143.194) |
| 21:35.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:37.07 | JunK-Y | when calling iax2 calling a remote iax2 channel, if you spy on local sip, no rtp is send. |
| 21:38.01 | file | wait until the SVN mirror is up to date so you can get my changes... |
| 21:38.02 | *** join/#asterisk-dev qdk_ (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 21:38.49 | seanbright | any thoughts on when 1.4.19 will get cut? |
| 21:39.20 | jmls | lmadsen: that's a problem though |
| 21:39.31 | lmadsen | oh? |
| 21:39.35 | jmls | there is a period of time where a realtime member may be available in the view, |
| 21:39.38 | russellb | seanbright: whenever we feel like it |
| 21:39.43 | russellb | seanbright: is there a good reason? |
| 21:39.50 | jmls | but the queue does not refresh the members until |
| 21:39.51 | seanbright | russellb: the chanspy fixes |
| 21:39.59 | jmls | a) a show queue foo is performed |
| 21:39.59 | russellb | they haven't settled down enough yet |
| 21:40.04 | jmls | b) a new call comes in |
| 21:40.13 | file | russellb: your original changes didn't make a release did they? |
| 21:40.16 | russellb | we need a least a week to make sure those fixes are ok |
| 21:40.20 | russellb | no, they did not |
| 21:40.22 | jmls | so you can have available members, waiting calls, and nothing happening :) |
| 21:40.25 | file | didn't think so |
| 21:40.49 | seanbright | hmmm, i thought i saw problems with chanspy and 1.4.18 |
| 21:40.57 | seanbright | maybe i just have my head up my bum |
| 21:40.57 | jmls | or c) you do a addqueuemember through the ami when your view changes |
| 21:41.26 | seanbright | and by "saw problems" i mean "saw issues in mantis" |
| 21:41.31 | tzafrir | russellb, you're the one to ask about renewing certificates? |
| 21:41.38 | jmls | awww, gotoif doesn't have extensions or contexts |
| 21:42.47 | russellb | tzafrir: yep, i'm about to email it to you |
| 21:43.05 | seanbright | so there is 11782 |
| 21:43.07 | seanbright | M11782 |
| 21:43.09 | MuffinMan | [feedback] [Asterisk] Applications/app_chanspy 0011782: chanspy - crashes Asterisk reported by kowalma http://bugs.digium.com/view.php?id=11782 |
| 21:43.10 | russellb | tzafrir: sent! |
| 21:43.16 | seanbright | which was for 1.4.17 |
| 21:43.28 | tzafrir | bah. there goes my excuse about not commiting to Zaptel |
| 21:43.44 | snuff-work | hello oej |
| 21:43.52 | file | when did I fix that slinfactory bug... |
| 21:44.04 | seanbright | and the reporter says on 2/19 that "still chan spy has a problem in asterisk-1.4.18 as well" |
| 21:44.15 | russellb | wouldn't hurt to try svn |
| 21:44.38 | seanbright | sure it would |
| 21:44.40 | seanbright | heh |
| 21:44.53 | lmadsen | jmls: sorry, got busy with something, so I can't participate in the conversation anymore :( |
| 21:45.18 | lmadsen | asterisk-urgent? |
| 21:45.20 | lmadsen | heh |
| 21:45.21 | seanbright | russellb: so minimum another weak before a possible .19 release |
| 21:45.25 | lmadsen | oh... I know what you mean now |
| 21:45.26 | seanbright | russellb: aye? |
| 21:45.38 | seanbright | and by "weak" i mean "week" |
| 21:46.04 | oej | Hello |
| 21:46.26 | tzafrir | russellb, works, thanks |
| 21:46.34 | oej | Gotta fix a few more bugs in SIP subscriptions before 1.4.19... |
| 21:47.48 | jmls | yikes. wtf is this ? |
| 21:47.51 | jmls | [Feb 27 21:47:33] WARNING[20738]: file.c:503 fileexists_core: buffer too small, allocating larger buffer |
| 21:47.51 | seanbright | fine, fine, fine |
| 21:48.00 | seanbright | i'll just go into production with 1.2 |
| 21:48.02 | seanbright | heh |
| 21:48.13 | russellb | seanbright: aye |
| 21:48.15 | file | jmls: yeah... a change today did that, I'm poking at it |
| 21:48.28 | jmls | heh. 100 lines of that ... |
| 21:48.31 | seanbright | russellb: cool. |
| 21:48.49 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:49.07 | tzafrir | Both the 2 and the 4 there remain magic values in that fix |
| 21:49.09 | jmls | file, can it be ignored for the meantime, or should I revert ? |
| 21:51.27 | tzafrir | Do you suppose anybody actually uses torisa ? |
| 21:51.56 | tzafrir | we had a crash bug with tor2.c and some users complained pretty quickly. |
| 21:52.29 | tzafrir | Now I noticed something that I think should have broken torisa. And nobody complained |
| 21:53.14 | outtolunc | i said 'waves byebye to tor2' when you did it couple weeks ago |
| 21:53.35 | outtolunc | i thought it was on purpose <G> |
| 21:53.51 | tzafrir | hmm.. my mistake. It didn't actually break anything |
| 21:58.03 | snuff-work | oej.. have issue with callerid setting and 'privacy:id'.. if i try standard sip-sip calling side with privacy:id.. if i change the callerid() when it dials other peers still leaves unknown <unknown> on the outgoing sip packet |
| 21:58.42 | tzafrir | outtolunc, actually no - there were users. And they did complain |
| 21:58.45 | jmls | jsmith: ping |
| 21:58.54 | tzafrir | So it should not be dropped. |
| 21:59.03 | jsmith | jmls: Pong-ish |
| 21:59.10 | tzafrir | Kevin even found hardware to test with :-) |
| 21:59.15 | jmls | your "single-interface" idea |
| 21:59.21 | jmls | can't get it working |
| 21:59.41 | jmls | the calls in the queue get stacked up waiting for the first call to finish |
| 22:00.56 | jsmith | jmls: What are you adding as a queue member? |
| 22:01.27 | jsmith | Here's what I've done in the past |
| 22:01.38 | jsmith | First of all, make a context called [queuemembers] |
| 22:01.51 | jmls | ypu |
| 22:01.56 | jmls | (yup even) |
| 22:01.56 | jsmith | Inside that context, either make individual entries for each "agent", or a pattern match |
| 22:02.00 | jmls | yup |
| 22:02.03 | jsmith | Eitehr way, those extensions call a macro |
| 22:02.10 | jmls | yup |
| 22:02.13 | jsmith | The macro contains the logic |
| 22:02.16 | jmls | yup |
| 22:02.34 | jsmith | Then, use AddQueueMemeber to add Local/1234@queuemembers/n to the queue |
| 22:02.43 | jmls | yup |
| 22:02.57 | jmls | (well, realtime member with the same interface) |
| 22:03.25 | jmls | it works - just until the first call is finished, no other calls are put through |
| 22:03.56 | jsmith | Wow... |
| 22:04.07 | jsmith | What's your queue strategy? |
| 22:04.10 | jmls | when the first call is connected to an agent, I get "Single Member Interface (realtime) (In use) has taken no calls yet" |
| 22:04.21 | jmls | rrobin |
| 22:04.53 | jsmith | Hmmmn... wonder why it's saying "In Use" |
| 22:05.00 | jsmith | Local channels never have, for me |
| 22:05.04 | russellb | queues are a pain in the ass |
| 22:05.06 | russellb | that is all. |
| 22:05.25 | russellb | what asterisk version are you guys talking about? |
| 22:05.32 | russellb | i think in 1.6, local channel state got chanted |
| 22:05.36 | jmls | 1.4 svn as of two hours ago |
| 22:05.39 | putnopvut | jmls: sorry I haven't been chatty much today, I've been frustrated as all hell by voicemail branch that needs to get finished up. |
| 22:05.41 | russellb | oh. |
| 22:05.47 | jmls | putnopvut: no worries ! |
| 22:06.21 | file | I suspect that in 1.4 the devicestate core will see that a channel exists beginning with Local/<etc> and consider it in use, and since /n is used it won't go away until hungup... at which time it is not in use |
| 22:06.24 | file | if I had to guess. |
| 22:06.31 | russellb | file: correct sir |
| 22:07.18 | JunK-Y | just found another segfault |
| 22:07.29 | JunK-Y | related to chanspy, i will report it. |
| 22:07.31 | jmls | even if I have ringinuse=yes in the queue config ? |
| 22:08.09 | jmls | hey! so how comes jsmiths works for him ?? |
| 22:08.31 | russellb | jmls: are you sure you're not running trunk? |
| 22:08.44 | jmls | Asterisk SVN-branch-1.4-r104665 |
| 22:08.57 | jmls | that's what show version gives ;) |
| 22:09.00 | russellb | oh, i forgot to tell you, i did svn mv trunk branches/1.4 |
| 22:09.05 | jmls | lol |
| 22:09.41 | russellb | putnopvut: thanks again for working on that voicemail stuff |
| 22:10.34 | putnopvut | russellb: yeah, I'm just anxious to get something that doesn't suck TOO badly committed. |
| 22:11.09 | russellb | well, it will be a very nice and useful feature |
| 22:11.20 | russellb | it's just a shame it wasn't easier to get ;) |
| 22:13.30 | jmls | oh oh oh. wait one minute |
| 22:15.03 | jmls | thank ____ for that |
| 22:15.18 | jmls | thought that I was buggering up on GROUP() |
| 22:15.58 | *** join/#asterisk-dev RoyK (n=roy@ip-21-60-149-91.dialup.ice.no) |
| 22:16.04 | jmls | definately only placing one call at a time to the local channel |
| 22:29.45 | *** part/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 23:01.47 | russellb | codefreeze: ping |
| 23:11.14 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 23:16.14 | *** join/#asterisk-dev anthm (n=anthm@mb20736d0.tmodns.net) |
| 23:16.14 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:19.24 | kpfleming | russellb: ping |
| 23:19.40 | russellb | kpfleming: pong. |
| 23:19.52 | kpfleming | so that code you just pulled out... i've thought about that before |
| 23:20.04 | kpfleming | but my thoughts were a very different implementation |
| 23:20.07 | kpfleming | interested? |
| 23:20.10 | russellb | sure |
| 23:20.17 | russellb | i see where he's coming from and i like the idea in theory |
| 23:20.21 | codefreeze | russellb: yes? |
| 23:20.34 | russellb | codefreeze: i was going to ask you about the code kpfleming just mentioned |
| 23:20.42 | russellb | which is basically the ast_peercmp() and supporting functions in chan_sip |
| 23:20.51 | russellb | i pulled them out because they weren't being used, mostly |
| 23:20.54 | kpfleming | if you split the relevant structure into 'static' and 'dynamic' parts, then you can just build the new one from the config and compare a hash of its static parts against a hash of the static parts of the one already in memory |
| 23:21.00 | russellb | but i'm also concerned about how we would maintain such a thing |
| 23:21.15 | kpfleming | you don't actually care what is different, just that *something* is different |
| 23:21.49 | russellb | still a lot of code to maintain, i guess ... just making sure that all of the appropriate things go into the hash |
| 23:21.55 | kpfleming | yes |
| 23:21.56 | kpfleming | no doubt |
| 23:22.11 | kpfleming | fraught with possible subtle bugs at reload time for sure |
| 23:22.22 | russellb | but if we can at least minimize the pain, it's probably worth it |
| 23:22.28 | russellb | yeah, that's what i'm worried about |
| 23:22.36 | russellb | i don't doubt the performance side .. |
| 23:22.50 | russellb | just the ease of bugs because we forget to incorporate a new variable |
| 23:23.07 | kpfleming | the real solution as mentioned many times before is a direct-edit interface that allows for changing the existing structures in memory... but that's a long-term solutin |
| 23:23.21 | russellb | yeah, which we'll have to address one of these days :) |
| 23:24.07 | russellb | so, i guess the question is, is there a reasonable shorter term thing we could do ... |
| 23:24.39 | codefreeze | OK, I somewhat follow what both of you are saying. Never finished the peercmp stuff. For short term, I could seperate it out into another branch... |
| 23:24.53 | russellb | codefreeze: yeah, it's probably best if we do it separate, yeah |
| 23:25.29 | russellb | i guess if we documented "here is what you _must_ change if you're adding new SIP peer options to sip.conf ..." |
| 23:25.42 | russellb | it's probably not _too_ bad ... |
| 23:26.22 | codefreeze | It'll speed up the loading, but I got it down from 40 sec to 1 sec already... It would be nice to keep it down to a frame time... |
| 23:26.39 | codefreeze | (for 5k+ peers) |
| 23:26.42 | russellb | codefreeze: on a semi-related note, I'm back in your SIP code and things are looking good. I still need some time to review / think about the astobj2 debug stuff you added |
| 23:27.10 | russellb | but i expect that I should be pretty much finished tomorrow sometime |
| 23:27.28 | codefreeze | And yes, it ***will*** be a beast to maintain. We **will** have to warn maintainers somehow to update one part if they make changes to the other.... |
| 23:27.40 | russellb | codefreeze: the only bug i noticed just now was that your handling of the hash table size options doesn't appear to work. the containers are created before the options are read ... |
| 23:28.21 | russellb | furthermore, i don't know if resizing them can be done in a safe way with astobj2 |
| 23:29.02 | codefreeze | Hadn't thought on that... It'd be a shame not to be able to configure their size somehow. |
| 23:29.12 | russellb | i agree ... |
| 23:29.20 | russellb | but i'm thinking about a random "reload", and I just don't see how it could work :( |
| 23:29.34 | russellb | we could have them as options that are _only_ read at module load time |
| 23:29.35 | codefreeze | As to resizing... I did it with hashtabs, it should be able to be done with astobj2 |
| 23:30.06 | russellb | well, i don't doubt that it's possible, but unless it's straight forward, we might have to delay that, or make it module load time only for now |
| 23:30.39 | codefreeze | reload resizing isn't catastrophic. We can warn folks in the example config files that if they want to change it, they have to restart |
| 23:30.54 | russellb | i'm happy with that |
| 23:31.24 | jsmith | Sorry, just now reading this... *what* would require a restart? |
| 23:31.24 | codefreeze | THere we go, got jsmith blinking |
| 23:31.34 | russellb | jsmith: resizing hash tables via a sip.conf option |
| 23:31.40 | russellb | as opposed to a compile time option |
| 23:31.40 | jsmith | Oh... |
| 23:32.07 | jsmith | Fine with me, as long as the defaults are reasonable and the side-effects are documented |
| 23:32.39 | jsmith | (and long as it doesn't end up like the IAX threads thing, where you can have 1 call and the system still complaining that it's out of threads) |
| 23:32.42 | russellb | you and your reasonable requests ... |
| 23:32.50 | russellb | lol |
| 23:33.00 | snuff-work | mm.. there are a few astobj left.. if i was to attempt to convert say jingle/gtalk from astobj to astobj2.. is there an example of it |
| 23:33.15 | jsmith | russellb: Hey, I've got a lot more where that came from... |
| 23:33.19 | russellb | snuff-home: chan_iax2 uses astobj2 |
| 23:33.20 | jsmith | russellb: I'm trying to go easy on you guys |
| 23:33.22 | russellb | among a number of other things |
| 23:33.32 | snuff-work | so does app_queue :) |
| 23:33.41 | russellb | right ... the interfaces are very similar |
| 23:33.54 | russellb | so if you read up on the astobj2 documentation and understand what it all does, the conversion should be straight forward |
| 23:33.57 | russellb | (ish) |
| 23:34.29 | codefreeze | snuff-work: I'm trying to remember if there was **any** astobj1 stuff I might have changed to astobj2 in chan_sip.... |
| 23:34.41 | snuff-work | mm well might try it again tonight.. since they are the easy ones.. |
| 23:34.50 | russellb | codefreeze: peers and users, right? |
| 23:34.57 | russellb | weren't they astobj1? |
| 23:35.00 | russellb | peers at least ... |
| 23:35.18 | codefreeze | I'd have to look. I think they were just lists |
| 23:35.34 | russellb | users and peers both |
| 23:35.39 | snuff-work | only like 6 things that use astobj... chan_zap/chan_skinny/chan_h323/chan_gtalk/chan_jingle/chan_sip |
| 23:35.41 | codefreeze | But if they were astobj1, then snuff-work would have some examples |
| 23:36.11 | codefreeze | snuff-work: see the team/murf/bug11210 branch |
| 23:36.33 | snuff-work | k.. will take a look |
| 23:37.16 | snuff-work | need to first find my callerID problem.. asterisk sets correct but chan_sip sends out unknown/unknown because calling party has Privacy:id |
| 23:37.20 | codefreeze | man, if I can't remember, it must have been a whole couple of weeks since I changed them... why does memory have to be the first thing to go? I forgot... |
| 23:38.25 | codefreeze | snuff-work: sounds like something the privacy manager would do |
| 23:39.08 | codefreeze | but you'd have programmed it in the dialplan if so... |
| 23:39.21 | codefreeze | and you wouldn't be wondering what happened |
| 23:39.37 | snuff-work | not using priv manager.. ;) |
| 23:41.33 | snuff-work | i have a work-a-round.. if i throw the call into a queue then get an agent to answer it puts the clid i want |
| 23:42.27 | snuff-work | i haven't tried using a local chan to also get around it yet though.. |
| 23:58.12 | *** join/#asterisk-dev seanbright (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |