| 00:24.47 | JerJer[mobile] | anyone know if there is like a 'go away' message I can respond with when getting a subscribe message? |
| 00:25.05 | JerJer[mobile] | mostly this is for openser, but i figure someone here might have more of a clue than me |
| 00:31.06 | putnopvut | Maybe a 403? |
| 00:31.18 | putnopvut | (just guessing) |
| 00:32.40 | Corydon76-dig | Wow, can you believe it? A patch killed the thread. |
| 00:33.07 | putnopvut | ? |
| 00:33.22 | Corydon76-dig | the -users thread about the CLI commands |
| 00:33.29 | putnopvut | Oh. |
| 00:33.33 | Qwell | but no testing of the patch yet? |
| 00:33.41 | Corydon76-dig | I tested it |
| 00:33.47 | Qwell | besides you |
| 00:33.51 | Qwell | I mean the people that were complaining |
| 00:33.55 | Corydon76-dig | Works fine for anything with 3 or more words |
| 00:34.05 | putnopvut | I think "show black dogs" needs to be in Asterisk now. |
| 00:34.07 | Corydon76-dig | So "sip reload" isn't handled |
| 00:34.07 | russellb | did you handle the core stuff differently at all? |
| 00:34.18 | russellb | "show core channels" ... |
| 00:34.28 | Corydon76-dig | russellb: I just swapped the first and second arguments |
| 00:34.39 | russellb | but "sip set reload" i shandled .. |
| 00:34.44 | russellb | "set sip reload on" |
| 00:35.05 | Corydon76-dig | you mean debug? |
| 00:35.10 | russellb | oh, right |
| 00:35.12 | russellb | d'oh |
| 00:35.35 | Corydon76-dig | set sip debug off, yes |
| 00:35.40 | *** part/#asterisk-dev flujan (n=flujan@201-42-70-31.dsl.telesp.net.br) |
| 00:35.53 | Corydon76-dig | Option in asterisk.conf, alternatecli=yes |
| 00:36.14 | Corydon76-dig | So you get one or the other, not doubled commands |
| 00:36.33 | Corydon76-dig | The other one we shouldn't change is "stop *" |
| 00:36.46 | Qwell | when stop convenient |
| 00:36.46 | Qwell | heh |
| 00:36.57 | Corydon76-dig | Oooh, but it did get "when stop convenient" |
| 00:37.36 | Corydon76-dig | and "when restart convenient" |
| 00:37.37 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177585332.dsl.bell.ca) |
| 00:37.45 | Qwell | makes sense to me |
| 00:38.10 | Corydon76-dig | Well, not perfect. But anything which follows the command structure should change over fine |
| 00:38.14 | russellb | you know, i dont' mind that patch existing, but i don't know if i like the idea of putting it in. |
| 00:38.45 | russellb | i would much rather make a decision one way or the other ... if everyone really hates the commands that much, and we could take a poll i guess, then i'd rather change them all |
| 00:38.55 | russellb | i want it to be consistent, and i want there to be only one way to do it. |
| 00:38.59 | Corydon76-dig | Hey, can we create an automatic feedback mechanism that tells us what that setting is on every restart of any Asterisk install, anywhere? |
| 00:39.02 | russellb | i don't care what that way is |
| 00:39.09 | russellb | heh, um, no |
| 00:39.16 | russellb | a list poll would suffice |
| 00:39.31 | Corydon76-dig | I already know the results |
| 00:39.36 | russellb | me too. |
| 00:39.53 | russellb | and we have plenty of people willing to do "janitor projects" if we define what the end result needs to be |
| 00:40.00 | russellb | i mean, did you see how fast NEW_CLI got done? |
| 00:40.04 | Corydon76-dig | Yep |
| 00:40.07 | russellb | that was a lot of changes ... |
| 00:40.21 | russellb | so, something to think about ... |
| 00:40.26 | russellb | but i have a feeling that's the road we need to go down |
| 00:40.49 | Corydon76-dig | Well, you want to go ahead and do it? |
| 00:40.49 | JunK-Y | hiya |
| 00:41.12 | Corydon76-dig | Maybe we leave this patch for people who like the existing method |
| 00:41.20 | JunK-Y | russellb: and im sure you have in mind the cli filtering now :) |
| 00:41.24 | Corydon76-dig | so they don't have to relearn the command structure |
| 00:41.40 | JunK-Y | Corydon76-dig: ive a quick question for you |
| 00:41.49 | russellb | yeah, and maybe we leave 1.4 alone ... |
| 00:41.56 | Corydon76-dig | I have a long winded answer for you |
| 00:41.58 | JunK-Y | 16:42 <JunK-Y> (gdb) print f->frametype |
| 00:41.58 | JunK-Y | 16:42 <JunK-Y> Cannot access memory at address 0x2aa05ce6c0 |
| 00:42.05 | russellb | Corydon76-dig: let me think about it some more |
| 00:42.05 | JunK-Y | what may cause this? |
| 00:42.22 | Corydon76-dig | Memory corruption, basically |
| 00:42.33 | Corydon76-dig | Could be any number of things |
| 00:42.56 | JunK-Y | its happen after like 10-11 hours of stress testing. |
| 00:43.31 | Corydon76-dig | I'd love to be able to point you to a single cause, but that's not the way these things work |
| 00:44.11 | JunK-Y | what would be the ur step? I never been able to fix a problem like this. |
| 00:44.52 | Corydon76-dig | dunno, actually |
| 00:45.15 | Corydon76-dig | If it caused a crash in malloc/free, you could valgrind it |
| 00:45.39 | Corydon76-dig | but when the corruption happens in user-allocated space, it's very difficult to track down |
| 00:46.10 | JunK-Y | it happens on: if (f && f->frametype == AST_FRAME_DTMF) { |
| 00:46.47 | Corydon76-dig | I suspect I know the problem, although where to find the cause is another issue |
| 00:47.35 | Corydon76-dig | Something scheduled is having its memory deleted, then reallocated to something else, then it runs and whatever got allocated in its place gets its memory corrupted |
| 00:47.58 | JunK-Y | ive the gdb published at gnupress, do you know any good books for that kind of issues? |
| 00:48.07 | Corydon76-dig | It's one of the most difficult bugs to track down |
| 00:48.27 | Corydon76-dig | We get lucky when it steps on internal malloc structures, because that can be detected by valgrind |
| 00:48.55 | JunK-Y | valgrind detects mem corruption too? |
| 00:49.15 | Corydon76-dig | valgrind detects when a program steps on memory it shouldn't be modifying |
| 00:50.16 | Corydon76-dig | Basically, the spaces in between memory allocations are used by malloc to track said allocations |
| 00:50.34 | JunK-Y | ok |
| 00:51.30 | Corydon76-dig | There's bits just before and just after an allocation, and when they get stepped on, malloc calls abort(3) |
| 00:56.50 | russellb | Corydon76-dig: I have libresample working |
| 00:57.02 | putnopvut | Cool beans! |
| 00:57.09 | Corydon76-dig | Sweet |
| 00:57.20 | Corydon76-dig | You'll have to show us the magic decoder ring |
| 00:57.26 | russellb | i had to slam my door so that i could concentrate without hearing people screwing off and yelling, but i got it working. |
| 00:58.10 | Corydon76-dig | Quick, commit, before you change something and it breaks again |
| 00:58.16 | russellb | Corydon76-dig: heh, already did |
| 00:58.20 | putnopvut | Okay, I wasn't yelling, but I was probably too loud. |
| 00:58.29 | russellb | Corydon76-dig: but app_jack in my jack branch is now a working example |
| 00:59.07 | Qwell | codec_jack! |
| 00:59.28 | Qwell | I don't know how that would work :D |
| 00:59.29 | Corydon76-dig | I hesitate to ask what jack does |
| 00:59.36 | russellb | www.jackaudio.org |
| 00:59.38 | Qwell | Corydon76-dig: it's an audio backend...thing |
| 00:59.47 | Qwell | imagine alsa over IP |
| 00:59.52 | Corydon76-dig | Oh, good, not what I thought |
| 00:59.57 | russellb | lol, except not IP ... |
| 00:59.58 | Qwell | sort of |
| 01:00.01 | Qwell | russellb: really? |
| 01:00.04 | russellb | really |
| 01:00.09 | Qwell | hmm, that sucks |
| 01:00.10 | russellb | it's audio interprocess communication |
| 01:00.14 | Qwell | ahh |
| 01:01.19 | Corydon76-dig | Just Another Crazy Kumquat? |
| 01:01.20 | Qwell | I just got the weirdest call |
| 01:01.43 | Qwell | Jamaican dude, or something... he was like "eh, waddup braduh?" |
| 01:02.15 | Corydon76-dig | Isn't it great having a DID? |
| 01:02.23 | Qwell | this was on my cell... |
| 01:02.30 | Corydon76-dig | Heh |
| 01:02.37 | Qwell | 205 areacode...Birmingham. weird |
| 01:03.00 | Corydon76-dig | Your LA dealer finally caught up with you |
| 01:03.04 | JerJer[mobile] | that is app_jack ? |
| 01:03.10 | russellb | dangit ... spoke to soon ... it was working with 16 kHz ... but now 48 kHz is giving me grief |
| 01:03.25 | JerJer[mobile] | doh - me scrolls up |
| 01:03.38 | Corydon76-dig | Oh, like anybody is going to use 48k... ;-) |
| 01:03.39 | Qwell | Corydon76-dig: LA dealer? O.o |
| 01:04.42 | Corydon76-dig | Spoon dealer? |
| 01:04.51 | Corydon76-dig | Weekly fix? |
| 01:04.58 | JunK-Y | the spoon doesnt exist. |
| 01:05.05 | Qwell | what he said |
| 01:05.08 | Qwell | ^^ |
| 01:05.19 | Corydon76-dig | JunK-Y: no, "there is no spoon" |
| 01:05.37 | putnopvut | bad subtitles? |
| 01:05.45 | Qwell | that was the french sub |
| 01:05.49 | JunK-Y | ha, anyways, we all got it :) |
| 01:23.57 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:23.57 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 01:57.37 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 02:38.50 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 02:38.50 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 02:40.02 | *** join/#asterisk-dev jsmith-zzz (n=jsmith@68-246-38-7.area3.spcsdns.net) |
| 02:40.02 | *** mode/#asterisk-dev [+o jsmith-zzz] by ChanServ |
| 03:16.08 | *** join/#asterisk-dev moy (n=moyhu@189.169.57.230) |
| 03:16.29 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 04:05.37 | *** join/#asterisk-dev jsmith-zzz (n=jsmith@68-246-38-7.area3.spcsdns.net) |
| 04:05.37 | *** mode/#asterisk-dev [+o jsmith-zzz] by ChanServ |
| 04:24.30 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 04:47.58 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 05:08.33 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 05:08.33 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 05:10.27 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 05:10.27 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 05:10.31 | *** part/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 05:14.03 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-83.hsd1.al.comcast.net) |
| 05:14.03 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 05:37.08 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 06:53.37 | *** join/#asterisk-dev bkw_ (n=brian@adsl-64-149-47-251.dsl.tul2ok.sbcglobal.net) |
| 07:13.01 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 07:44.43 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 07:44.43 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:14.03 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:25.07 | *** join/#asterisk-dev mbranca (i=daemon@mi-gw1.voismart.net) |
| 10:12.35 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 10:33.14 | *** join/#asterisk-dev IgorG (n=FeedomPa@195.162.32.126) |
| 10:42.40 | *** join/#asterisk-dev andrelg (n=andrelg@189.20.64.70) |
| 10:48.39 | *** join/#asterisk-dev snuff-home (n=snuffy@220-253-51-106.VIC.netspace.net.au) |
| 10:59.22 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:04.31 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 11:59.08 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.80.10) |
| 12:12.44 | *** join/#asterisk-dev Victor_Yure (n=aaa@postfix.tradein.com.br) |
| 12:13.14 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 13:33.02 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:33.02 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 14:12.24 | *** join/#asterisk-dev ELBunce (n=erik@kde/developer/bunce) |
| 14:25.45 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 14:41.06 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-a54ac96b51598bfb) |
| 14:41.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:42.55 | *** join/#asterisk-dev bkw_ (n=brian@adsl-64-149-47-251.dsl.tul2ok.sbcglobal.net) |
| 14:55.58 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-4c59099e66eb4c80) |
| 14:55.58 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:07.37 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 15:07.49 | *** join/#asterisk-dev anthm (n=anthm@70-9-142-245.area4.spcsdns.net) |
| 15:07.49 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:17.29 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 15:23.50 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:36.06 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:36.06 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:44.15 | russellb | Corydon76-dig: *poke* |
| 15:48.23 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 15:48.28 | file | Corydon76-dig: Dwayne is in the town of Corydon |
| 15:48.30 | file | O.o |
| 15:50.51 | Corydon76-dig | which one? |
| 15:51.04 | file | unknown |
| 15:52.01 | tzafrir | M11611 |
| 15:52.02 | MuffinMan | [new] [Zaptel] zaptel (the module) 0011611: channel slave status not correctly cleared reported by richvdh http://bugs.digium.com/view.php?id=11611 |
| 15:52.41 | tzafrir | I can reproduce it here (so I guess I should acknowledge it) but I don't understand what it is about |
| 15:52.59 | Corydon76-dig | file: you like my fix for 11601? |
| 15:53.09 | Corydon76-dig | It's completely ridiculous |
| 15:53.10 | tzafrir | Why is the first channel marked as "master" when all of them are "clear"? Is it for data? |
| 15:53.32 | file | Corydon76-dig: ha |
| 15:54.22 | file | Corydon76-dig: that... is cheeky |
| 15:55.38 | Corydon76-dig | What's worse is that I've seen that same valgrind issue before, and I dismissed it as ridiculous. Now I'm not so sure |
| 15:56.27 | Corydon76-dig | I'm wondering if the first thing that should happen in any started thread is usleep(1). |
| 15:56.48 | Corydon76-dig | or if we should just get glibc to fix it |
| 15:57.44 | Corydon76-dig | Maybe they already have |
| 15:57.57 | Corydon76-dig | 2.3.4 is awfully old |
| 15:59.23 | russellb | M11080 |
| 15:59.26 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/General 0011080: SIP channel stops processing calls, but no apparent deadlock reported by callguy http://bugs.digium.com/view.php?id=11080 |
| 15:59.33 | russellb | Corydon76-dig: that deadlock is the same one in pbx.c we were talking about yesterday |
| 15:59.40 | russellb | did you happen to work on that already? |
| 15:59.50 | russellb | just wanted to check before i started and wasted time ... |
| 15:59.51 | Corydon76-dig | I don't recall |
| 15:59.58 | russellb | heh, ok |
| 16:00.14 | Corydon76-dig | which one? |
| 16:00.23 | Corydon76-dig | which deadlock, rather? |
| 16:00.26 | russellb | when you were asking about backporting the use of readlocks |
| 16:00.31 | Corydon76-dig | OH |
| 16:00.34 | russellb | i think |
| 16:00.50 | Corydon76-dig | M11609 |
| 16:00.51 | MuffinMan | [new] [Asterisk] PBX/General 0011609: Deadlock in pbx/sip introduced by fix for bug 0011323 reported by ardjan http://bugs.digium.com/view.php?id=11609 |
| 16:01.00 | russellb | yep |
| 16:01.02 | russellb | so, same bug |
| 16:01.30 | Corydon76-dig | I did a avoidance fix before I read the whole report |
| 16:01.41 | Corydon76-dig | but readlocks would be better |
| 16:02.41 | russellb | okie dokie ... i can probably do that ... |
| 16:08.08 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 16:08.08 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 16:12.57 | Corydon76-dig | russellb: did you see that the automerge scripts have been failing, or do you delete those automatically? |
| 16:13.32 | russellb | Corydon76-dig: didn't see that ... lol |
| 16:13.37 | russellb | that's amusing. |
| 16:13.46 | Corydon76-dig | The cert expired |
| 16:13.57 | Qwell | woops :D |
| 16:14.05 | putnopvut | How long have they been failing? |
| 16:14.06 | russellb | fixable. |
| 16:14.09 | russellb | FOREVER |
| 16:14.14 | putnopvut | Uh oh. |
| 16:14.16 | Corydon76-dig | A couple days... maybe a week |
| 16:14.27 | Qwell | yay for russellb finding this out before he left! |
| 16:14.40 | russellb | agreed |
| 16:14.44 | file | that would have made me sad |
| 16:14.50 | Qwell | I *could* have done it, but...meh |
| 16:14.59 | Corydon76-dig | Heh, apparently it was worth mentioning after all |
| 16:14.59 | Qwell | russellb would have had to walk me through it again |
| 16:15.00 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 16:15.31 | Qwell | russellb: I remembered those passwords for like a week or two, but they're purged now. heh |
| 16:15.59 | blitzrage | M11386 ... |
| 16:15.59 | MuffinMan | [ready for testing] [Asterisk] Core-General 0011386: Asterisk 1.4.14 and load average. reported by flujan http://bugs.digium.com/view.php?id=11386 |
| 16:16.27 | flujan | hi MuffinMan hi blitzrage |
| 16:16.55 | flujan | blitzrage: so you also are having this problem... I read your valgrind... which Linux distro are you using? |
| 16:17.08 | blitzrage | ummm.... not sure to be honest (this is on a customers box) |
| 16:17.13 | blitzrage | forgot to make a note of it |
| 16:20.27 | flujan | blitzrage: this problems shows up on a slackware 12 box. |
| 16:20.55 | blitzrage | ya, my guess is that it's not a distro issue though (I could be wrong, but....) |
| 16:21.00 | blitzrage | did you have a chance to try the patch? |
| 16:21.33 | Corydon76-dig | blitzrage: could I get you to test 10540 again? |
| 16:21.42 | blitzrage | that was the TIMEOUT() thing right? |
| 16:21.50 | Corydon76-dig | Yes |
| 16:21.52 | blitzrage | M10540 |
| 16:21.53 | MuffinMan | [ready for testing] [Asterisk] Functions/func_timeout 0010540: timeout value should accept floating point numbers reported by spendergrass http://bugs.digium.com/view.php?id=10540 |
| 16:21.58 | blitzrage | ya, let me see if I have that VM still setup |
| 16:22.06 | Corydon76-dig | woot |
| 16:22.09 | blitzrage | give me a few mins to email IT :) |
| 16:22.45 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 16:23.31 | russellb | file: since you did the original conversion of pbx.c to rwlocks, want to take a quick look at my patch? |
| 16:23.45 | file | sure |
| 16:23.55 | russellb | okie dokie. |
| 16:23.55 | file | although that was awhile back so my recollection is somewhat ... fuzzy |
| 16:24.01 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 16:24.09 | russellb | i think it's fine ... but ... doesn't hurt to glance at it. |
| 16:24.48 | Qwell | m/sg nikserve ident zomghax |
| 16:25.00 | russellb | http://pastebin.ca/827110 |
| 16:25.14 | russellb | file: i did that in about 10 minutes ... just wondering if you remembered anything special you had to do ... |
| 16:25.18 | russellb | like, any recursive locking issues |
| 16:25.22 | russellb | i guess i can just look at svn log |
| 16:25.26 | Qwell | you could always go back and look |
| 16:26.46 | file | I'm pretty sure there was |
| 16:26.56 | russellb | A57519 |
| 16:26.58 | MuffinMan | [57519] Committed by file on 2007-03-02 14:05:29: Don't try to do recursive locking/unlocking when it isn't supported. |
| 16:28.52 | file | ah yes |
| 16:29.13 | russellb | and i only converted conlock |
| 16:29.16 | russellb | because that's all i needed to fix this bug |
| 16:31.48 | russellb | :-p |
| 16:33.38 | russellb | i don't have the password for the automerge certificate |
| 16:33.42 | russellb | have to make a new one, lammmme |
| 16:33.57 | Qwell | was it passworded? |
| 16:34.13 | russellb | have to have a password to export the certificate |
| 16:34.17 | outtolunc | the cert itself |
| 16:34.20 | Qwell | oh, right |
| 16:34.24 | russellb | but you can export it without a passphrase .. |
| 16:34.28 | Qwell | gotcha |
| 16:34.32 | Qwell | oh |
| 16:34.38 | Qwell | wasn't there a spreadsheet or something? |
| 16:34.42 | russellb | it's not in there |
| 16:34.46 | Qwell | laaaamme |
| 16:35.51 | *** join/#asterisk-dev monkeytype (n=Bill@nat/digium/x-00a2412a76c00145) |
| 16:36.51 | Qwell | hey monkeytype |
| 16:37.17 | monkeytype | hallo |
| 16:37.41 | Corydon76-dig | Documenters on the -dev channel... what a radical idea... |
| 16:38.03 | tzafrir | what's this x-00a2412a76c00 ? |
| 16:38.14 | Qwell | tzafrir: freenode randomization |
| 16:38.14 | russellb | does anyone have a usb key i can use? |
| 16:38.21 | russellb | in the digium office? |
| 16:38.28 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:38.42 | Corydon76-dig | Malcolm has one |
| 16:39.37 | russellb | nm ... |
| 16:40.26 | russellb | ok, automerge should work on next run |
| 16:41.50 | Corydon76-dig | woot |
| 16:41.55 | putnopvut | M11612 |
| 16:41.56 | MuffinMan | [feedback] [Asterisk] Applications/app_page 0011612: Repeatedly calling Page with a LOCAL channel crashes asterisk reported by dtyoo http://bugs.digium.com/view.php?id=11612 |
| 16:42.00 | putnopvut | I think I know what's up here. |
| 16:42.27 | file | putnopvut: do tell |
| 16:42.28 | putnopvut | It's because the dial->channel is getting freed, then the AST_LIST_TRAVERSE tries to move to the next one based on memory just freed. |
| 16:42.55 | putnopvut | So I think this could be avoided if the "safe" traversal were used instead. |
| 16:42.58 | file | good catch |
| 17:24.02 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 17:27.10 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 17:38.10 | blitzrage | did someone break trunk? :) |
| 17:38.19 | russellb | maybe! |
| 17:38.23 | blitzrage | dial.c:817:48: error: macro "AST_LIST_REMOVE_CURRENT" passed 2 arguments, but takes just 1 |
| 17:38.23 | blitzrage | dial.c: In function ?ast_dial_destroy?: |
| 17:38.44 | putnopvut | Yeah, I just saw that. |
| 17:38.47 | blitzrage | :D |
| 17:39.29 | putnopvut | Yeah, apparently that macro is different between 1.4 and trunk. |
| 17:39.36 | putnopvut | The commit is pending... |
| 17:40.23 | putnopvut | committed! |
| 17:40.24 | putnopvut | Try now. |
| 17:47.30 | *** join/#asterisk-dev jsmith (n=jsmith@68-247-25-31.area3.spcsdns.net) |
| 17:47.30 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 17:49.21 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:49.21 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 18:01.38 | *** join/#asterisk-dev michael-i (n=michael-@host-170-68-220-24.midco.net) |
| 18:42.02 | Qwell | back to the real world |
| 18:42.11 | file | what is this real world you speak of? |
| 18:46.05 | tzafrir | let me ask again: if I see in /proc/zaptel/1 the line: |
| 18:46.08 | tzafrir | 1 TE4/0/1/1 Clear Master |
| 18:46.15 | tzafrir | What does "Master" mean? |
| 18:53.04 | Qwell | pnlarsson: ping? |
| 18:53.43 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 18:53.43 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 18:55.24 | file | are you at... the airport? |
| 18:55.46 | Qwell | russellb: when do you come back? |
| 19:02.47 | file | Qwell: he was thinking of changing it around... so who knows |
| 19:02.49 | file | maybe next year! |
| 19:02.54 | Qwell | oic |
| 19:29.48 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 19:29.57 | pnlarsson | Qwell: pong |
| 19:34.11 | Qwell | pnlarsson: I was wondering if I could get access to that system that was having the codec problems, to hack around on the source and see if I can't get to the bottom of it |
| 19:35.54 | pnlarsson | Qwell: PM? |
| 19:36.30 | *** join/#asterisk-dev apocn (n=htejeda@unaffiliated/apocn) |
| 19:36.35 | Juggie | Qwell, can get to the bottom? :) |
| 19:36.42 | apocn | Hello, Im trying to register my asterisk with a softswitch and specify the user/pass/host and reload asterisk I get the following message : Got SIP response 423 "Interval Too Brief". Any help? |
| 19:40.59 | lmadsen | apocn: thats a #asterisk question, but it sounds like you're registering too often with your switch |
| 19:48.33 | tzafrir | is there a way for asterisk to detect the externip ? |
| 19:48.45 | tzafrir | for SIP, I mean? |
| 19:49.29 | tzafrir | something as silly as getting it from http://www.whatismyip.com/automation/n09230945.asp |
| 19:50.07 | tzafrir | in case of externip=auto |
| 19:50.25 | tzafrir | Does it sound really bad? |
| 19:51.13 | tzafrir | (yeah, right, this could be implemented with #exec) |
| 19:52.53 | michael-i | it can pull it on a defined interval from a domain name pointing at the box, that's all i know of |
| 19:53.19 | tzafrir | hmm... and if we assume that externip=auto , maybe go one step further and make all local addresses "local" |
| 19:53.28 | tzafrir | (localnet) |
| 20:02.02 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 20:05.39 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:05.39 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 20:05.51 | tzafrir | ok. here's this uglyness: http://rapid.tzafrir.org.il/~tzafrir/sip_net_settings |
| 20:06.45 | tzafrir | implemented for #exec |
| 20:10.44 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:10.44 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 20:13.09 | Qwell | pnlarsson: fixed :) |
| 20:16.38 | pnlarsson | Qwell: but the numbers in core show translation is really goofy |
| 20:17.42 | pnlarsson | http://pastebin.ca/827466 |
| 20:19.43 | Qwell | pnlarsson: yeah, they are.. there's actually a reason for that. they are "valid" though...ish |
| 20:20.06 | Qwell | I can explain...sort of |
| 20:20.53 | Qwell | you'll notice that most of the numbers are very close to a multiple of 4000usec. The reason for that, is your kernel is using a timing of 250hz, which means that there can only be a 4ms (4000usec) resolution for certain things - and in this case, for the kernel timing call that we use |
| 20:21.52 | Qwell | the alternative, is to use the old way of calculating the timing, which didn't actually calculate the *CPU time* spent, but rather wall-clock time spent |
| 20:22.11 | Qwell | although this way is more *accurate*, it is less *precise*. there's a very subtle difference |
| 20:22.37 | pnlarsson | ok - as long as it works... And people understands... |
| 20:22.47 | Qwell | it's a little goofy, but... |
| 20:38.35 | apocn | Hello, Im trying to register my asterisk with a softswitch and specify the user/pass/host and reload asterisk I get the following message : Got SIP response 423 "Interval Too Brief". Any help? |
| 20:43.49 | Qwell | apocn: this isn't a channel for user support. try #asterisk |
| 20:48.46 | apocn | ah sorry |
| 20:48.52 | *** part/#asterisk-dev apocn (n=htejeda@unaffiliated/apocn) |
| 20:49.00 | lmadsen | pretty sure I said that a few hours ago :) |
| 20:50.36 | Qwell | s/a few hours/an hour/ |
| 20:53.52 | *** join/#asterisk-dev Cresl1n (n=matt@nat/digium/x-94caefee76138fea) |
| 20:53.52 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 20:58.49 | putnopvut | lmadsen: hmmm, looks like that change for IMAP voicemail (moving the #includes) didn't actually work for me. |
| 20:59.24 | putnopvut | I thought the distclean did the trick, but in fact the distclean cleared my menuselect options, so I wasn't compiling with IMAP storage when I recompiled. |
| 20:59.27 | tzafrir | hmmm... shouldn't all dates be UTC? what happens when you change a timezone? |
| 20:59.56 | putnopvut | tzafrir: I guess it depends on what you mean. |
| 21:00.05 | Qwell | cdr, probably |
| 21:00.10 | Qwell | I'd inclined to agree |
| 21:00.23 | Qwell | maybe a config option in cdr.conf? |
| 21:00.45 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 21:00.57 | tzafrir | M11610 |
| 21:00.58 | MuffinMan | [closed] [Asterisk] Resources/res_config_sqlite 0011610: CDR dates not in local time when stored reported by rbraun_proformatique http://bugs.digium.com/view.php?id=11610 |
| 21:01.04 | Qwell | ^ what he said |
| 21:01.46 | putnopvut | Yeah, I committed that because the way I read it, the reporter was saying that this stored dates in UTC as opposed to other methods. |
| 21:02.15 | putnopvut | So, I was making the change for consistency's sake. |
| 21:02.17 | Qwell | yeah, it should definitely be consistent |
| 21:05.43 | JunK-Y | if ast_translator_build_path() returns me NULL is cause theres no translation or an error, right? |
| 21:06.21 | Qwell | JunK-Y: pretty much |
| 21:06.27 | Qwell | s/pretty much/yes/ |
| 21:12.15 | JunK-Y | and if a f->frametype is 0, its caused an ast_translate or? |
| 21:19.22 | lmadsen | Corydon76-dig: ping |
| 21:19.28 | Corydon76-dig | pong |
| 21:20.31 | *** join/#asterisk-dev Laureano (n=chatzill@200.59.172.38) |
| 21:25.14 | Qwell | Corydon76-dig: pong |
| 21:26.00 | putnopvut | These pings and pongs are hard to match correctly. |
| 21:26.18 | Qwell | mine was unrequested |
| 21:26.53 | Corydon76-dig | Qwell: eh? |
| 21:27.00 | Qwell | Corydon76-dig: nothing |
| 21:27.07 | Qwell | random ponging |
| 21:27.19 | Corydon76-dig | Qwell: ping |
| 21:27.31 | Corydon76-dig | negative time response |
| 21:28.14 | putnopvut | Request to schedule in the past? |
| 21:28.24 | putnopvut | I see that a lot in res_musiconhold |
| 21:28.35 | Qwell | heh |
| 21:29.48 | Corydon76-dig | I see that a lot when I'm running under valgrind, on a machine with an X server |
| 21:30.00 | Qwell | stupid X |
| 21:30.31 | Qwell | putnopvut: so, yeah, that thing you were saying earlier... I'm totally down for that at any point, if you were still wanting to |
| 21:32.34 | putnopvut | Yeah, totally. |
| 21:34.07 | JunK-Y | u guys have any link explaining all the translation, translators and path somewhere? |
| 21:39.12 | putnopvut | Happy Holidays everyone! I'm out! |
| 22:11.34 | *** join/#asterisk-dev outtolunc (n=me@63.197.134.218) |
| 22:18.46 | Corydon76-dig | JunK-Y: no link, sorry |
| 22:19.11 | *** join/#asterisk-dev matsk (n=mk@83.233.97.210) |
| 22:19.20 | Corydon76-dig | JunK-Y: basically it uses the 'show translations' table to calculate the least cost path for translating codecs |
| 22:20.09 | Corydon76-dig | It then saves that translation path, so that it only needs to do it once per call (or really, once per translation, since if a codec for a call changes, it'll need to recalculate the path) |
| 22:23.10 | JunK-Y | if ast_translator_build_path() is NULL, its cause something bad happened, right? |
| 22:27.16 | Corydon76-dig | I believe so, yes |
| 22:30.38 | JunK-Y | even if theres no transcoding, i should have an ast_trans_pvt struct and that struct is NULL |
| 22:31.25 | *** part/#asterisk-dev bkw_ (n=brian@adsl-64-149-47-251.dsl.tul2ok.sbcglobal.net) |
| 22:31.48 | file | what? no |
| 22:32.10 | file | be specific in what you are asking |
| 22:34.16 | JunK-Y | file: we agree that even if theres no transcoding, i should have an ast_trans_pvt? |
| 22:34.47 | JunK-Y | cause in some cases, i get ast_trans_pvt pointed to NULL, after a call to ast_translator_build_path() |
| 22:35.03 | Qwell | in what cases? |
| 22:37.05 | JunK-Y | ast_translator_build_path(AST_FORMAT_SLINEAR, f->subclass); |
| 22:37.16 | Qwell | what is subclass? |
| 22:37.34 | JunK-Y | i dont know, since im in gdb and in a coredump. |
| 22:37.56 | JunK-Y | (gdb) p f->subclass |
| 22:37.56 | JunK-Y | Cannot access memory at address 0x6bc7a5dc |
| 22:59.03 | Corydon76-dig | Memory corruption again, probably |
| 23:01.50 | JunK-Y | ive 2 bugs like that, happening at 2 diff. place |
| 23:02.01 | JunK-Y | ive to go home, xmas gifts ! |
| 23:18.56 | *** part/#asterisk-dev Cresl1n (n=matt@nat/digium/x-94caefee76138fea) |
| 23:32.22 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 23:41.53 | *** join/#asterisk-dev RoyK (n=roy@ip-133-27-149-91.dialup.ice.no) |