| 00:04.41 | *** join/#asterisk-dev jeffspeff2 (n=jeff@c-69-245-31-42.hsd1.ky.comcast.net) |
| 00:09.42 | *** join/#asterisk-dev moy (n=moyhu@189.169.61.25) |
| 00:55.41 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 01:53.59 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 02:08.42 | *** join/#asterisk-dev bkruse (n=bkruse@76.73.154.120) |
| 02:08.42 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 02:09.04 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-195.west.biz.rr.com) |
| 02:15.40 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 02:26.03 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 02:26.03 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 02:31.31 | *** join/#asterisk-dev obnauticus (n=obnautic@c-71-193-156-193.hsd1.wa.comcast.net) |
| 03:20.01 | *** join/#asterisk-dev moy (n=moyhu@189.169.61.25) [NETSPLIT VICTIM] |
| 03:20.01 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) [NETSPLIT VICTIM] |
| 03:23.46 | *** join/#asterisk-dev bkruse (n=bkruse@76.73.154.120) |
| 03:23.46 | *** join/#asterisk-dev awk (n=awk@65.111.177.74) |
| 03:23.46 | *** mode/#asterisk-dev [+o bkruse] by irc.freenode.net |
| 03:56.15 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 04:06.47 | *** join/#asterisk-dev [hC] (n=hardcore@S01060016b6b53c0c.vc.shawcable.net) |
| 04:11.45 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) [NETSPLIT VICTIM] |
| 04:11.45 | *** join/#asterisk-dev moy (n=moyhu@189.169.61.25) [NETSPLIT VICTIM] |
| 04:16.46 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.131) |
| 04:26.33 | *** join/#asterisk-dev moy (n=moyhu@189.169.61.25) [NETSPLIT VICTIM] |
| 04:43.14 | *** join/#asterisk-dev moy (n=moyhu@189.169.61.25) [NETSPLIT VICTIM] |
| 04:57.16 | *** join/#asterisk-dev moy (n=moyhu@189.169.61.25) [NETSPLIT VICTIM] |
| 05:38.15 | *** join/#asterisk-dev moy (n=moyhu@189.169.61.25) [NETSPLIT VICTIM] |
| 06:20.53 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-292223.home.otenet.gr) |
| 07:06.59 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:07.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:15.51 | oej | Morning |
| 07:20.11 | mvanbaak | hey |
| 08:21.17 | mvanbaak | oej: how are you these days ? |
| 08:22.22 | oej | Today, I'm home. |
| 08:22.33 | oej | Have been away for 95% of the last two months. |
| 08:22.41 | mvanbaak | yeah, we noticed :) |
| 08:22.44 | oej | Tonight, I'm leaving, back friday. Leaving again sunday, back thursday. |
| 08:22.50 | mvanbaak | geez |
| 08:23.01 | oej | Yeah, it's hard |
| 08:23.03 | mvanbaak | mrsoej must have a hard time |
| 08:23.14 | oej | Don't tell her... |
| 08:23.27 | mvanbaak | you know, buy her a Wii ;) |
| 08:24.38 | mvanbaak | any idea if it stays this way ? or will there be a time you can stay home some more ? |
| 08:39.06 | oej | Trying to change my lifestyle for the fall. |
| 08:39.15 | oej | It all depends on the projects I can get and the terms |
| 08:44.37 | mvanbaak | yeah |
| 08:44.55 | mvanbaak | let's hope it works out |
| 08:53.32 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 09:14.21 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 09:28.51 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 09:43.05 | *** join/#asterisk-dev dlu_ (n=dlu@dus-ix-pos-002.dus.net) |
| 10:15.31 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 10:54.44 | *** join/#asterisk-dev pputman (n=centrex@216.207.245.1) |
| 11:02.03 | pputman | Is there anyway to change the summary of a patch I submitted? I need to change it to something a little more descriptive. |
| 11:03.54 | mvanbaak | I can update it for you if you want |
| 11:04.10 | mvanbaak | give me the bugnumber and the new summary and I'll fix it |
| 11:04.29 | pputman | 0012814 is the bug, it meant to say "changes use of usleep to nanosleep" |
| 11:04.35 | pputman | thank you |
| 11:11.12 | mvanbaak | there you go |
| 11:11.20 | pputman | thanks |
| 11:23.38 | *** join/#asterisk-dev RoyK (n=roy@ip-242-49-149-91.dialup.ice.no) |
| 11:28.40 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) |
| 12:10.11 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:10.11 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:17.50 | *** join/#asterisk-dev RoyK (n=roy@ip-150-21-149-91.dialup.ice.no) |
| 12:23.18 | mvanbaak | hey russellb |
| 12:23.45 | russellb | russellb is not here ... this is a ghost |
| 12:24.00 | mvanbaak | who you gonna call ...... |
| 12:24.31 | file | russellb's wife of course |
| 12:25.07 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 12:25.56 | russellb | la la la |
| 12:27.03 | tzanger | heh |
| 12:29.19 | mvanbaak | :) |
| 12:29.31 | mvanbaak | russellb: I found the problem with the PrivacyManager stuff |
| 12:29.36 | russellb | neato |
| 12:29.58 | mvanbaak | it's hilarious |
| 12:30.31 | mvanbaak | I was testing it with the following line: PrivacyManager(3,10, "outgoing-speakup"); |
| 12:30.47 | russellb | yeah, that's not going to work :) |
| 12:31.02 | mvanbaak | that's what I found out ;) |
| 12:31.09 | mvanbaak | anywayz, it's in trunk now |
| 12:34.50 | russellb | cool |
| 12:36.10 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:38.33 | jmls | mvanbaak: how are those eggs tasting ? |
| 12:38.36 | jmls | <PROTECTED> |
| 12:45.22 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.165) |
| 12:45.23 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 12:45.47 | *** mode/#asterisk-dev [-o ctooley] by ChanServ |
| 12:46.39 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 12:50.17 | ctooley | russellb, one consideration about Manager events: Since there's no way to turn on or off which events get triggered/sent there might be some review of whether an event is worthwhile as a heavily loaded server could be brought down by one or a small number of daemon(s) listening to Manager Events. |
| 12:50.57 | russellb | i think we should just make them subscribeable :) |
| 12:51.12 | russellb | if only i had time to do anything but fix bugs and administrative tasks ... |
| 12:51.13 | russellb | :( |
| 12:51.41 | ctooley | wouldn't that still cause the event to occur, even if it isn't sent? |
| 12:51.58 | russellb | to some degree |
| 12:52.10 | ctooley | (well, of course the "event" will occur, the "handling" of it is what I meant) |
| 12:52.29 | ctooley | hasn't had enough coffee |
| 12:53.14 | ctooley | though that might be a fun feature... "these events just will not occur if there isn't something connected to the AMI to watch and make sure they happen." |
| 12:53.38 | russellb | the infrastructure is there |
| 12:53.42 | russellb | that's how the event system works |
| 12:53.52 | russellb | but, all of the events that happen now haven't been converted |
| 12:54.01 | russellb | and a module to allow subscriptions to events has not been written |
| 12:54.13 | russellb | (actually, I have written an XML based one in a branch) |
| 12:54.46 | ctooley | So you subscribe to an event type or each individual event? |
| 12:54.52 | russellb | an event type |
| 12:54.56 | ctooley | sort of like log types |
| 12:55.14 | russellb | you can say, "give me all device state change events" |
| 12:55.24 | russellb | or, "give me all device state change events for device SIP/123" |
| 12:55.53 | russellb | or "give me all events" |
| 12:55.58 | ctooley | hmmm, that sounds nice |
| 12:56.14 | russellb | yeah ... :-/ |
| 12:56.25 | russellb | wishes he had the time to do new development work ... |
| 12:56.26 | ctooley | is it a recursive filter tree? |
| 12:56.37 | russellb | o.O |
| 12:56.47 | russellb | you may need to expand on that a touch |
| 12:56.49 | russellb | heh |
| 12:57.00 | ctooley | ie: could it be extended to say "give me all call events on device SIP/123 where condition X is met" |
| 12:57.18 | russellb | yeah, something like that ... |
| 12:57.30 | russellb | basically, each event has an event type, and information elements (the meta data) |
| 12:57.38 | ctooley | That would be _really_ nice. I'd love to be able to do conditional SIP traces. |
| 12:57.39 | oej | That would simplify chan_sip as well |
| 12:57.46 | russellb | so, you subscribe to a type, and any number of bits of criteria for information elements |
| 12:58.15 | ctooley | oej, exactly, send the messaging for SIP debugging as manager events. |
| 12:58.29 | oej | I was thinking the other way |
| 12:58.31 | russellb | and the criteria for information elements, is simply that the IE exists, or the IE exists with a specific value |
| 12:58.36 | oej | chan-sip could make more detailed subscriptions |
| 12:58.39 | oej | to the core |
| 12:58.57 | russellb | chan_sip uses this event system to handle MWI in trunk/1.6 |
| 12:59.13 | oej | Yes, but not more detailed internal subscriptions |
| 12:59.25 | russellb | ctooley: if you're curious about the API, see include/asterisk/event.h ... it's documented pretty well, if i do say so myself :-p |
| 12:59.59 | ctooley | has a call in 15 seconds about OpenSER, but when this project is complete, I might do that. |
| 13:01.28 | ctooley | Well, I was _supposed_ to have an 8AM call. It appears that the other people aren't in yet. :( |
| 13:01.37 | russellb | sounds about right |
| 13:01.39 | ctooley | even the one that asked for the call. |
| 13:02.20 | russellb | has a call every week like that |
| 13:12.09 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.87.172) |
| 13:17.18 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:17.18 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:23.12 | tzanger | morn |
| 13:24.33 | ctooley | morning |
| 13:26.20 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 13:26.20 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 13:58.08 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:58.08 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:59.22 | mvanbaak | gheh |
| 13:59.35 | mvanbaak | The Asterisk development team has released Asterisk version 1.4.21-rc2. |
| 13:59.45 | mvanbaak | A few bugs have been fixed since 1.4.21-rc2. |
| 13:59.59 | mvanbaak | so you release -rc2 that has bugfixes for rc2 |
| 14:00.00 | mvanbaak | ;) |
| 14:00.04 | lmadsen | nice! |
| 14:04.29 | russellb | sighs |
| 14:04.37 | russellb | i shouldn't write release announcements at 7 AM |
| 14:05.11 | lmadsen | totally |
| 14:05.41 | ctooley | russellb, no public emails should be sent before completion of the first pot of coffee. |
| 14:05.54 | ctooley | That should be the company policy anyway. :) |
| 14:12.49 | russellb | shrugs |
| 14:12.51 | russellb | oh well. |
| 14:13.08 | lmadsen | it happens |
| 14:13.17 | russellb | it's less that it was 7 AM and more that i've writte 2938479234 of those and i'm getting lazy and careless with them |
| 14:14.04 | *** join/#asterisk-dev freddyk (n=freddy@79.43.94.193) |
| 14:14.46 | freddyk | hello |
| 14:15.03 | freddyk | is there anyone here can help with pickup code in chan_sccp ? |
| 14:17.42 | russellb | you'll get better help if you use chan_skinnu |
| 14:17.46 | russellb | skinny* |
| 14:17.48 | russellb | that's the module that we maintain |
| 14:18.21 | freddyk | you're right |
| 14:18.31 | freddyk | but i'm developing the other channel |
| 14:18.43 | freddyk | and i would ask a reference about asterisk questions |
| 14:19.01 | mvanbaak | freddyk: why not put your time in chan_skinny ? |
| 14:19.13 | freddyk | you're all right |
| 14:19.24 | freddyk | we were porting back code to chan_skinny |
| 14:19.32 | freddyk | on a complete rewrite |
| 14:19.54 | freddyk | but there are too few people wants testing |
| 14:20.41 | freddyk | entire code will be donated to the asterisk project |
| 14:20.57 | freddyk | and added to trunk (i hope) |
| 14:21.14 | freddyk | as asterisk really needs a good skinny channel |
| 14:21.31 | freddyk | at the moment i have a question about channel locks |
| 14:21.45 | freddyk | and pickup procedures tree |
| 14:21.53 | freddyk | (how a pickup function must be called) |
| 14:22.10 | freddyk | is there someone wants to hear and try to answer ? |
| 14:25.31 | tzafrir_laptop | points out that chan_skinny in trunk actually seems to be maintains and developed |
| 14:26.17 | tzafrir_laptop | also points out freddyk has not asked a specific question |
| 14:26.25 | freddyk | ok |
| 14:26.39 | freddyk | in pickup implementation |
| 14:26.56 | freddyk | i used to allocate a new ast_channel with private |
| 14:27.04 | freddyk | then called ast_pickup_call |
| 14:27.09 | freddyk | pointing to my channel |
| 14:27.20 | freddyk | to pickup the first ringing channel |
| 14:27.28 | freddyk | and get it masqueraded into mine |
| 14:27.33 | freddyk | right ? |
| 14:28.05 | freddyk | next to that i have 3 channels |
| 14:28.16 | freddyk | ORIGINAL caller channel |
| 14:28.37 | freddyk | ORIGINAL called channel |
| 14:28.42 | freddyk | (ringing) |
| 14:28.59 | freddyk | MASQUERADED new channel |
| 14:29.13 | freddyk | now i should hangup the ORIGINAL called channel |
| 14:29.18 | freddyk | how to do that ? |
| 14:29.58 | freddyk | i looked into chan_sip code |
| 14:30.02 | freddyk | and i have |
| 14:30.25 | freddyk | ast_hangup(mynewallocatedchannel) |
| 14:30.30 | freddyk | that seems to work |
| 14:30.43 | freddyk | it hangs up original called channel in ringing state |
| 14:30.44 | freddyk | but |
| 14:31.02 | freddyk | it hangups also the channel |
| 14:31.11 | freddyk | at the first AST_CONTROL_FRAME |
| 14:31.13 | freddyk | i send |
| 14:31.20 | freddyk | (for example HOLD) |
| 14:36.01 | freddyk | is anyone ALIVE ? |
| 14:36.54 | ctooley | freddyk, Monday morning meetings |
| 14:37.12 | freddyk | so? |
| 14:38.36 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 14:38.53 | russellb | freddyk: unfortunately, not everyone is sitting here waiting for you to arrive and ask a question |
| 14:39.01 | russellb | if someone knows the answer and cares, they will answer |
| 14:39.12 | russellb | if you don't get an answer here, you can also try the asterisk-dev list |
| 14:39.30 | russellb | especially for something this long that fills up a couple of screens |
| 14:39.30 | freddyk | sorry russel |
| 14:39.43 | freddyk | it's the first time |
| 14:39.47 | freddyk | i come here |
| 14:39.58 | freddyk | and hope to find someone could answer |
| 14:40.02 | freddyk | my question |
| 14:40.16 | freddyk | maybe someone who developed this portion of code |
| 14:40.18 | freddyk | for asterisk |
| 14:40.36 | russellb | don't a bunch of channel drivers in asterisk implement this? |
| 14:40.42 | russellb | that should be a helpful example |
| 14:40.57 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 14:40.59 | freddyk | already did as the examples |
| 14:41.05 | freddyk | but really don't understand |
| 14:41.16 | freddyk | how to hangup a masqueraded channel |
| 14:42.14 | freddyk | is there something to cancel an hangup in asterisk ? |
| 14:42.23 | Rem| | hey, anyone here knows how to disable sending cnam over the facility message when performing a two b-channel transfer? |
| 14:42.41 | jsmith | Rem|: Not that I know of, but I don't know the code that well |
| 14:42.51 | jsmith | Rem|: In fact, I'm not much of a coder at all |
| 14:44.16 | Rem| | jsmith: so that is something that has to get changed in libpri right |
| 14:44.45 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 14:44.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:46.56 | jsmith | Rem|: Most likely, yes |
| 14:47.13 | russellb | doubt it is configurable |
| 14:51.24 | Rem| | yeah... thats what i figured |
| 14:53.45 | Rem| | is there a way then to disable queuing facility messages? |
| 14:54.16 | Rem| | because what is happening it is sending the cnam and the two b-channel transfer in the same facility message |
| 14:55.01 | seanbright | Rem|: if it is a bug you should submit it to the issue tracker (mantis) |
| 14:55.07 | seanbright | Rem|: not sure if the libpri maintainer is here |
| 14:56.00 | russellb | he's not |
| 14:56.19 | Rem| | ok thanks |
| 14:56.31 | seanbright | creslin? |
| 14:56.34 | seanbright | guesses |
| 14:56.49 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 14:56.49 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:57.21 | freddyk | just a question on option_debug |
| 14:57.43 | freddyk | is this connected to core set debug ? |
| 14:57.55 | seanbright | freddyk: yes |
| 14:58.48 | freddyk | so why i didn't get output messages |
| 14:58.50 | freddyk | on cli ? |
| 14:59.00 | freddyk | i have |
| 14:59.06 | seanbright | freddyk: make sure that your logger.conf is correctly configured |
| 14:59.10 | freddyk | ast_log(LOG_DEBUG, |
| 14:59.17 | freddyk | i see |
| 14:59.41 | Corydon76-dig | If the console is not configured to receive debug messages... |
| 15:00.43 | Corydon76-dig | That is a pet peeve of mine, though... that console settings affect something that would otherwise go to the log |
| 15:00.46 | *** join/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 15:10.49 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:10.49 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:12.18 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:12.18 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:13.00 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 15:13.00 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 15:20.30 | ctooley | Corydon76-dig, on M12804 I did create that patch from a checkout of branches/1.6.0 on the revision mentioned, a fresh checkout, can you supply the failure info? |
| 15:21.16 | Corydon76-dig | ctooley: patch -p0 < /path/to/patch and all 4 result in failure to apply |
| 15:21.40 | ctooley | Corydon76-dig, bizzarre, I'm downloading another fresh checkout to see what's up. |
| 15:21.59 | Corydon76-dig | Why downloading? Just 'svn update' |
| 15:22.25 | Corydon76-dig | You'll probably get conflicts; resolve the conflicts manually |
| 15:22.29 | ctooley | Corydon76-dig, I'm doing a completely clean checkout |
| 15:22.34 | ctooley | just to be sure. |
| 15:22.44 | Corydon76-dig | Sure of what? |
| 15:22.57 | ctooley | I'll just create a new patch, it was tiny to begin with. |
| 15:23.19 | Corydon76-dig | If you were compiling and had an error, I could see that, maybe |
| 15:23.28 | Corydon76-dig | but patching? |
| 15:23.50 | Corydon76-dig | I'd only ever do that if I thought there was a bug in subversion |
| 15:25.09 | ctooley | :wq |
| 15:25.11 | ctooley | ooops |
| 15:25.25 | Corydon76-dig | Permission denied |
| 15:25.26 | russellb | :x > :wq |
| 15:26.05 | Corydon76-dig | Shift-ZZ is even easier |
| 15:27.25 | ctooley | uhhhh.... the new patch is identical to the old one. I think this related to it being a diff from svn diff instead of anything else. |
| 15:28.20 | Corydon76-dig | 4 out of 4 hunks FAILED -- saving rejects to file apps/app_externalivr.c.rej |
| 15:28.31 | Corydon76-dig | ctooley: try applying the patch |
| 15:28.50 | ctooley | I did, got the same result, |
| 15:29.26 | ctooley | I pulled down a completely clean 1.6.0 checkout, rewrote the patch from scratch, ran svn diff, pulled down another clean checkout and it won't apply |
| 15:29.40 | russellb | how are you saving the patch? |
| 15:29.42 | Corydon76-dig | ctooley: I see what the problem is now |
| 15:29.53 | Corydon76-dig | Your patch contains leading spaces instead of tabs |
| 15:29.53 | russellb | sometimes you can mess it up with tabs -> spaces when copying from the terminal |
| 15:30.00 | ctooley | svn diff file.c, I'm just creating one with diff -u |
| 15:30.09 | russellb | svn diff file.c > my_patch |
| 15:30.14 | ctooley | russellb, did that |
| 15:30.14 | russellb | don't svn diff and copy from the screen |
| 15:30.19 | russellb | oic. |
| 15:30.23 | russellb | are you doing this on windows? |
| 15:30.24 | ctooley | yeah, I always redir |
| 15:30.32 | ctooley | uhhhhh, X-Windows. |
| 15:30.35 | ctooley | >) |
| 15:30.35 | russellb | :-p |
| 15:31.22 | Corydon76-dig | ctooley: if you looked at your patch with an editor and saved it before uploading, that will also sometimes change the tabs |
| 15:32.18 | *** join/#asterisk-dev RoyK (n=roy@ip-150-21-149-91.dialup.ice.no) |
| 15:32.25 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 15:32.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:32.33 | ctooley | I opened it in vim and did, :q! |
| 15:32.52 | ctooley | If that starts doing a "save" I might have to stop using VIM on principal. |
| 15:32.54 | ctooley | :) |
| 15:33.05 | Corydon76-dig | "principle" |
| 15:33.08 | ctooley | I'm not sure what the hell happened, but I have a new patch to upload |
| 15:33.19 | Corydon76-dig | Okay, let's try that, then |
| 15:33.33 | ctooley | No, I have a principal that carries my laptop for me. |
| 15:33.48 | ctooley | That's what he gets for trying to make my kids stupid |
| 15:35.48 | ctooley | Corydon76-dig, Note, this does absolutely nothing to fix any of the problems with having commas in the arguments, ie: it doesn't _do_ anything to split up arguments that are quoted, it just copies them and sends them to the application. But, I wanted to make the minimal set of changes for the 1.6.0 tree. |
| 15:37.26 | ctooley | better? |
| 15:39.55 | Corydon76-dig | Hang loose |
| 15:42.16 | Corydon76-dig | Looks better |
| 15:42.54 | Corydon76-dig | and it applies |
| 15:43.41 | ctooley | well, that's nice |
| 15:45.11 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 15:45.14 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:47.09 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 15:48.25 | *** join/#asterisk-dev nny_1 (n=Scott_My@64.203.239.83) |
| 15:48.31 | Corydon76-dig | ctooley: so is that patch for both 1.6.0 and trunk? |
| 15:49.01 | ctooley | it won't apply against trunk, I'll give you another one for trunk. |
| 15:49.46 | nny_1 | anyone know of a variable I could check to see if SIP client is being used ? |
| 15:50.00 | Corydon76-dig | Go ahead and do that... I need to apply the trunk one first |
| 15:50.49 | ctooley | Corydon76-dig, OK, that's going to have to wait a while, I was specifically trying to get a patch into 1.6.0 before the next beta, but I'm on my second round of calls that will last until about 12:30 |
| 15:54.16 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:59.55 | russellb | can someone check if downloads.digium.com is accessible externally? |
| 16:01.24 | lmadsen | works for me |
| 16:01.28 | ctooley | russellb, works for me too |
| 16:01.56 | Corydon76-dig | Yes |
| 16:02.35 | jsmith | WORKSFORME |
| 16:03.33 | ctooley | exten => s,1,Set(WORKSFORME=1) |
| 16:03.52 | ctooley | exten => s,2,Verbose(1,WORKSFORME=${WORKSFORME}) |
| 16:03.54 | ctooley | :) |
| 16:04.04 | lmadsen | invalid extension and no 'i' extension |
| 16:06.29 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 16:06.29 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:06.46 | Corydon76-dig | Morning, Deeeeeeeeeeeeeeewayne |
| 16:07.02 | Deeewayne | good morning :-) |
| 16:07.07 | *** join/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 16:07.39 | Corydon76-dig | codefreeze-lap: ping |
| 16:08.12 | codefreeze-lap | Corydon76-dig: At your command |
| 16:08.37 | Corydon76-dig | codefreeze-lap: could you take a look at my patch in 12800 and make sure that it's the best way to do that? |
| 16:09.01 | codefreeze-lap | goes to look |
| 16:24.56 | codefreeze-lap | Corydon76-dig: nice. You added the FINDLABEL capability, which I missed. Looks like an acceptable approach to me! I assume it works good in your tests? |
| 16:25.19 | Corydon76-dig | It worked for the example he gave |
| 16:25.40 | codefreeze-lap | excellent! |
| 16:26.36 | Corydon76-dig | testing ftw |
| 16:27.39 | *** join/#asterisk-dev _ys (n=yuri@80.70.236.69) |
| 16:36.23 | lmadsen | testing is for suckers |
| 16:37.26 | Corydon76-dig | lmadsen: you do realize you just set up a humorous action, right? |
| 16:37.38 | lmadsen | I do not realize that :) |
| 16:37.43 | lmadsen | ~testing |
| 16:37.44 | jbot | extra, extra, read all about it, testing is done - but yes, further excursions will take place elsewhere |
| 16:37.55 | lmadsen | haha... something was already there :) |
| 16:38.35 | Corydon76-dig | Set me up again after 6pm, and I'll do the action... :-P |
| 16:39.48 | *** join/#asterisk-dev uTx (n=unix@modemcable232.79-58-74.mc.videotron.ca) |
| 16:40.23 | codefreeze-lap | scratches head. pictures kids singing songs, do actions that go with the words... |
| 16:58.44 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:42.26 | *** join/#asterisk-dev jeffspeff (n=jeff@c-69-245-31-42.hsd1.ky.comcast.net) |
| 18:21.29 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:46.52 | *** join/#asterisk-dev bkruse (n=bkruse@76.73.154.120) |
| 18:46.52 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 18:58.54 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:09.24 | wwalker | Got a quite strange problem. we are using asterisk as a call by call route engine proxy/front-end. That part works perfectly. However, after some period of time (1 to 10 hours at 50 - 150 requests per second) asterisk just completely stops handling requests. not rejecting, just no response to any requests. |
| 19:09.53 | jsmith | wwalker: "core show locks" show any deadlocks? |
| 19:10.16 | jsmith | wwalker: "sip show channels" show any stuck channels? |
| 19:10.35 | wwalker | Additionally, there are usually 5 to 10 hung channels (in the timeout state) when it stops responding, and it's so broken, that running "restart now" at the command prompt just returns the asterisk console prompt but asterisk stays runnign. Any ideas where to look? |
| 19:12.39 | wwalker | the developer jsut restarted, so I can't check for locks now. I'll check for locks when it next fails. Thank jsmith |
| 19:12.48 | seanbright | thanks jsmith |
| 19:13.46 | russellb | wwalker: you need DEBUG_THREADS for that |
| 19:18.49 | wwalker | I think we built with DEBUG_THREADS. will go look |
| 19:19.24 | mvanbaak | I refuse to go inside |
| 19:19.27 | russellb | the "core show locks" CLI command will only be there if you did |
| 19:19.33 | mvanbaak | freaking annoying soccer |
| 19:19.35 | mvanbaak | blegh |
| 19:19.46 | Qwell | footb..err, nm |
| 19:19.49 | mvanbaak | they have taken over the tv, radio and dutch internet websites |
| 19:20.11 | Qwell | mvanbaak: do you really call it soccer there? |
| 19:20.24 | seanbright | i have memberhips to dutch internet websites... and none of them are soccer related. |
| 19:20.40 | mvanbaak | Qwell: I call it: waste of time |
| 19:20.49 | Rem| | anyone here familiar with channel.c and chan_sip.c? |
| 19:21.03 | Qwell | Rem|: I would hope so. :) What do you need to know? |
| 19:22.32 | Rem| | Qwell: well i found a bug where a channel is not getting marked UP after it receives a 200 OK |
| 19:24.09 | mvanbaak | Qwell: any objections on the skinny transfer patch ? |
| 19:24.28 | Rem| | Qwell: so if it receives a re-invite before the channels get marked UP it detects a loop |
| 19:25.44 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.165) |
| 19:25.44 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 19:26.12 | Qwell | we have no power here... we may be out for the day :p |
| 19:27.20 | seanbright | for serious? |
| 19:27.28 | *** part/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 19:27.56 | seanbright | how are you on the interweb without power? |
| 19:27.57 | mvanbaak | http://bugs.digium.com/view.php?id=9939 |
| 19:28.06 | mvanbaak | seanbright: ups + laptop |
| 19:28.22 | seanbright | + wireless broadband? |
| 19:28.25 | mvanbaak | ups for the modem and switch, and laptops |
| 19:28.46 | seanbright | crazy. |
| 19:28.57 | seanbright | wow... that's a year old bug |
| 19:29.32 | mvanbaak | seanbright: yeah |
| 19:29.37 | mvanbaak | I want it in |
| 19:30.09 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 19:30.12 | mvanbaak | Qwell: if you dont have time for it, I can take this one from you |
| 19:30.16 | file | dropping like flies |
| 19:30.29 | seanbright | plays Taps |
| 19:31.04 | mvanbaak | file: their laptop batteries are drained ? |
| 19:34.25 | Rem| | Qwell: so what I want to know is how can I make sure the channel gets marked UP before the channels gets locked up again when it receives a re-invite |
| 19:34.30 | seanbright | hey, if you guys don't ever come back... i'll take over |
| 19:34.40 | seanbright | and run things as you would have wanted. |
| 19:34.47 | seanbright | thanks for everything. |
| 19:34.48 | seanbright | heh |
| 19:39.59 | mvanbaak | lol seanbright |
| 19:44.34 | mvanbaak | ouch ! |
| 19:46.30 | mvanbaak | Qwell: you stole the UPS to power your laptop eh ? |
| 19:49.06 | mvanbaak | for a in $dutch_numbers_in_phone_book; do asterisk -rx 'console dial $a'; done |
| 19:49.20 | mvanbaak | I heard ppl hate it when you call them during a soccer match ;) |
| 19:55.54 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135) |
| 19:56.18 | seanbright | annnnnd scene |
| 19:56.37 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.132.25) |
| 19:56.46 | seanbright | takes over the channel |
| 19:58.04 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583881.dsl.bell.ca) |
| 19:58.12 | wwalker | so, with our lock up problem, core show locks and core show channels verbose both just give me the console prompt back :( |
| 19:58.14 | *** mode/#asterisk-dev [+v seanbright] by mvanbaak |
| 19:58.34 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:58.41 | mvanbaak | woooooooooooooooooow, look at seanbright |
| 19:58.44 | seanbright | heh |
| 19:58.51 | mvanbaak | ;) |
| 19:58.58 | mvanbaak | he got a +v |
| 19:59.13 | mvanbaak | ./mkill * |
| 19:59.21 | seanbright | it is so friggin hot outside |
| 19:59.37 | wwalker | jsmith: any ideas what else I can do to gather data before forcing a core dump? |
| 19:59.43 | mvanbaak | seanbright: yeah, same here |
| 19:59.58 | jsmith | wwalker: Nope... |
| 19:59.58 | mvanbaak | problem is not only the temperature, but it's freaking humid |
| 20:00.01 | mvanbaak | 99% |
| 20:00.03 | mvanbaak | blegh |
| 20:00.06 | seanbright | yeah, feels like that here |
| 20:00.15 | mvanbaak | move your arm and sweat a litre |
| 20:00.54 | seanbright | well, the humidity here isn't that bad |
| 20:01.00 | mvanbaak | hhmm, never knew caio1982 was in digium building |
| 20:01.01 | seanbright | 97 F, 33% humidity |
| 20:01.16 | mvanbaak | seanbright: here it is, 28Celcius, 98% humidity |
| 20:01.51 | seanbright | 36C, 33% |
| 20:02.03 | seanbright | i want to die. |
| 20:02.04 | seanbright | heh |
| 20:02.11 | mvanbaak | ./kill seanbright |
| 20:02.25 | mvanbaak | if this was undernet or ambernet that would have worked ;) |
| 20:02.34 | mvanbaak | too bad I dont have oper access here |
| 20:03.12 | wwalker | interestingly, hitting tab locks up the console session. have to control C and start a new console then. so something in the guts of asterisk is getting in a twist. |
| 20:03.37 | jsmith | wwalker: Yeah, sounds like it... or some type of memory corruption issue |
| 20:04.49 | lmadsen | 33% pffffffft |
| 20:05.10 | lmadsen | wwalker: what version of asterisk? I've seen that too |
| 20:05.17 | lmadsen | but that was on ABE C.1.4 |
| 20:05.25 | wwalker | 1.4.19 lmadsen |
| 20:05.29 | lmadsen | wow... |
| 20:05.33 | lmadsen | still do it in 1.2.21? |
| 20:05.39 | lmadsen | errr.. 1.2.21-rc2 |
| 20:05.57 | wwalker | 1. 4 .19 not 1. 2 .19 |
| 20:06.35 | lmadsen | s/2/4 |
| 20:06.36 | wwalker | 1.4.19.1 |
| 20:06.42 | lmadsen | I didn't mean 1.2.21-rc2 |
| 20:06.43 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 20:06.43 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 20:06.44 | wwalker | oh |
| 20:06.45 | lmadsen | I meant 1.4.21-rc2 |
| 20:06.57 | wwalker | haven't tried 1.4.21* yet |
| 20:07.11 | lmadsen | probably same issue I ran into, but haven't had a chance to debug |
| 20:07.14 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 20:07.14 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:07.57 | mvanbaak | hey bbryant |
| 20:08.05 | mvanbaak | how's the power @ digium ? |
| 20:08.20 | bbryant | back :) |
| 20:08.28 | wwalker | watching core show channels verbose (and SIPp output) seems to indicate that asterisk is receiving an ACK but not dropping the channel. |
| 20:08.40 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 20:08.40 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 20:09.27 | mvanbaak | bbryant: you are the first to reconnect to irc ! |
| 20:09.36 | mvanbaak | you just earned a muffin ! |
| 20:09.48 | bbryant | woot |
| 20:09.48 | lmadsen | mvanbaak: actually putnopvut won the muffin |
| 20:10.10 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 20:10.15 | lmadsen | putnopvut: http://www.leifmadsen.com/images/muffin.jpg |
| 20:10.47 | jsmith | lmadsen: Your website is being wonky today |
| 20:10.48 | putnopvut | lmadsen: thanks |
| 20:11.16 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.165) |
| 20:11.16 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 20:12.15 | wwalker | /root/1.4.19.1/include/asterisk/lock.h:271 __ast_pthread_mutex_destroy: channel.c line 1258 (ast_channel_free): Error: attempt to destroy locked mutex '&chan->lock' is the last message on the console of one that completely died jsut now. |
| 20:12.32 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 20:12.33 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 20:13.12 | ctooley | wwalker, you'll need to recompile with DONT_OPTIMIZE and when it locks run 'core show locks' and then connect with gdb and grab a backtrace. |
| 20:14.22 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 20:14.22 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 20:14.48 | mvanbaak | wb all |
| 20:14.57 | mvanbaak | hope the power tastes good ;) |
| 20:17.06 | Corydon76-dig | Power to the People |
| 20:17.34 | russellb | yay for power |
| 20:17.49 | russellb | so much for 5 9's from the power company |
| 20:18.25 | mvanbaak | 5 9's is a lot of downtime |
| 20:18.31 | mvanbaak | it's like an hour per year |
| 20:18.43 | Corydon76-dig | mvanbaak: Uh, no, it's 5 minutes a year |
| 20:19.08 | ctooley | russellb, what's the backtrace command to give to gdb when connected to a running asterisk instance? |
| 20:19.49 | russellb | thread apply all bt |
| 20:20.10 | Corydon76-dig | mvanbaak: and 15 seconds |
| 20:20.26 | ctooley | russellb, paging is on, forget how to turn that off too |
| 20:20.32 | russellb | set pagination off |
| 20:20.42 | mvanbaak | Corydon76-dig: lol, yeah my calculator showed the same thing ;) |
| 20:20.53 | russellb | geeks :-p |
| 20:20.54 | Corydon76-dig | 16 seconds in a leap year |
| 20:21.32 | mvanbaak | so |
| 20:21.39 | mvanbaak | we have 10 years without downtime |
| 20:22.04 | mvanbaak | that makes it possible to upgrade all our stuff during primetime and still meet the 5 nines |
| 20:22.22 | Corydon76-dig | At 4 9's, it's nearly an hour of downtime, though |
| 20:22.35 | Corydon76-dig | (per year) |
| 20:22.37 | mvanbaak | our provider gives us 4 nines |
| 20:22.40 | ctooley | There a tracker bug for the deadlocking issue? |
| 20:22.45 | mvanbaak | that's why I was confused |
| 20:22.49 | Corydon76-dig | Given Friday, though, they're closer to 3 9's |
| 20:22.50 | mvanbaak | that's almost an hour |
| 20:22.59 | russellb | ctooley: there is one that says iax2 deadlock with no information .. |
| 20:23.12 | russellb | ctooley: not sure if there are any other recent ones up there |
| 20:23.16 | ctooley | I have "core show locks" output and a backtrace from wwalker's locked asterisk instance |
| 20:23.32 | mvanbaak | russellb: jparker still in the office ? |
| 20:23.44 | putnopvut | ctooley: Let's see it! |
| 20:23.51 | ctooley | in a bug or pastebin? |
| 20:24.02 | putnopvut | ctooley: pastebin at least temporarily. |
| 20:24.02 | mvanbaak | ~pb |
| 20:24.03 | jbot | [~pb] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste |
| 20:24.12 | mvanbaak | ;) |
| 20:24.56 | mvanbaak | M99399 |
| 20:24.57 | MuffinMan | Failed to retrieve issue page for 99399. Does it exist? |
| 20:25.07 | mvanbaak | M9939 |
| 20:25.10 | MuffinMan | [assigned] [Asterisk] Channels/chan_skinny/NewFeature 0009939: [patch] Transfer implementation reported by wedhorn (Karma: +8.25) http://bugs.digium.com/view.php?id=9939 |
| 20:25.25 | mvanbaak | any objection if I take this one and finish it ? |
| 20:26.23 | Corydon76-dig | mvanbaak: what's the date of the last note on it? |
| 20:26.50 | Corydon76-dig | doubt there's an objection, but check with who it's assigned to |
| 20:26.56 | mvanbaak | 02-13-08 13:36 |
| 20:27.00 | Corydon76-dig | Go for it |
| 20:27.07 | mvanbaak | the last note is mine ;) |
| 20:27.14 | ctooley | http://pastebin.com/d35a1e215 |
| 20:27.32 | mvanbaak | I did this massive whitespace fix in chan_skinny so the patch was useless |
| 20:27.35 | mvanbaak | I fixed that |
| 20:27.58 | mvanbaak | it's assigned to Qwell |
| 20:28.17 | mvanbaak | any chan_skinny bug is automagically assigned to him |
| 20:28.51 | Corydon76-dig | ctooley: what version are you running? |
| 20:28.56 | ctooley | 1.4.19.1 |
| 20:29.09 | putnopvut | ctooley: interesting, it appears that __ast_read is holding a channel lock and refusing to let it go. Let me look at the bt... |
| 20:29.26 | putnopvut | ah, it's blocking in read() |
| 20:33.33 | putnopvut | I guess that means it's blocking while trying to read from the read end of the alert pipe? |
| 20:34.12 | Rem| | is anyone available to help me out with bug 12215? I am very close in solving it just need some help. |
| 20:36.15 | ctooley | putnopvut, any ideas? |
| 20:36.56 | putnopvut | ctooley: not immediately. I've never seen that before. |
| 20:37.21 | putnopvut | Mainly because __ast_read should only be called when there's data to be read. |
| 20:39.11 | mvanbaak | ah dammit |
| 20:39.18 | mvanbaak | .nl won the soccer game |
| 20:39.28 | mvanbaak | so another week of madness |
| 20:42.02 | Corydon76-dig | Brief discussion on adaptive realtime... |
| 20:43.07 | Corydon76-dig | The parameters I've set with a column type are type and size, and the size specifies the number of characters needed for a char type. I'm considering for the int type, making the size be the number of bytes needed for that integer type (1,2,3,4, or 8) |
| 20:43.19 | Corydon76-dig | Anybody have an opinion on this? |
| 20:44.00 | Corydon76-dig | and nevermind, I think I answered my own question, while posing it. |
| 20:44.14 | Corydon76-dig | I may want to expand the type field |
| 20:57.55 | mvanbaak | yeah |
| 20:58.03 | mvanbaak | why do it for varchar and not for int |
| 20:58.14 | mvanbaak | btw, if you implement it for int, please go to 11 |
| 20:58.21 | mvanbaak | that's the max int field in mysql |
| 20:59.07 | mvanbaak | and varchar is 255 |
| 20:59.09 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:59.37 | mvanbaak | for the int field, consider the 'unsigned' flag |
| 20:59.51 | mvanbaak | <--- just giving some info he uses in his mysql databases |
| 21:06.31 | codefreeze-lap | Hmmmm. on 10668 arkadia has been pushing hard to get ast_cdr_answer(), ast_cdr_end(), and ast_cdr_setvar() to obey the LOCKED flag like almost every other routine does. I tried that, and it messed up folks. So I reverted. Assuming he was using this from the dialplan, I then backed up and provided flags in CDR() (func), and ForkCDR() (app), that would give him the ability to end the prev CDR on forking, to lock out the disposition on the prev CD |
| 21:09.16 | ctooley | russellb, so, should I open up a new bug? |
| 21:09.23 | ctooley | Is there anything else you guys need? |
| 21:09.35 | ctooley | Or should I put that data in an existing bug? |
| 21:09.52 | putnopvut | ctooley: are you talking about the hang you're experiencing? |
| 21:10.00 | ctooley | putnopvut, yes |
| 21:10.01 | putnopvut | I can think of maybe a couple of extra things that might be helpful. |
| 21:10.08 | ctooley | what's that? |
| 21:10.18 | putnopvut | ctooley: just a sec. |
| 21:10.54 | putnopvut | ctooley: if you can get a bt full of frame 4, that would help. |
| 21:11.13 | russellb | it actually looks all normal |
| 21:11.19 | putnopvut | Sorry, not frame 4, thread 4. |
| 21:11.21 | putnopvut | russellb: it does? |
| 21:11.37 | russellb | well, there is nothing really saying for sure that thread 4 is hung |
| 21:12.16 | putnopvut | I guess not, but if a subsequent thread apply all bt full still shows thread 4 on the same read() call, it seems pretty likely. |
| 21:12.29 | russellb | nods |
| 21:12.37 | russellb | but with just that, it could be completely normal |
| 21:12.55 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 21:14.08 | putnopvut | russellb: this is making me revisit my idea of printing the amount of time a lock has been held in "core show locks" |
| 21:15.20 | russellb | yeah |
| 21:15.37 | russellb | i wish i could see where the do_monitor SIP thread is stuck |
| 21:15.41 | russellb | no line number, though :( |
| 21:15.47 | codefreeze-lap | let's see, cdr_end would need to be changed in 12 places (in 1.4); I'm not really certain that this kind of change could be classed as a bug fix in 1.4 or 1.6.0...! |
| 21:16.02 | russellb | codefreeze-lap: i leave that up to you |
| 21:16.16 | putnopvut | russellb: what do you mean? It's stuck in retrans_pkt on line 2033. |
| 21:16.24 | putnopvut | Or do you mean a different SIP do_monitor thread? |
| 21:16.34 | putnopvut | That's the only one I see. |
| 21:16.34 | russellb | where do you see that? |
| 21:16.38 | putnopvut | core show locks |
| 21:16.44 | russellb | # |
| 21:16.44 | russellb | #2 0x00002aaab1431629 in retrans_pkt (data=0x19546420) from /opt/asterisk-1.4.19-routing/lib/asterisk/modules/chan_sip.so |
| 21:16.47 | putnopvut | fifth thread from the top. |
| 21:16.57 | russellb | ah |
| 21:17.14 | putnopvut | it's trying to get the same channel lock that __ast_read holds. |
| 21:17.18 | russellb | of course i can't tell what that is because this isn't recent code :( |
| 21:17.38 | codefreeze-lap | putnopvut: Over the weekend, I played with redoing MTX_PROFILE so it'd time how long locks would block on a per-source-statement basis. And be thread safe. |
| 21:17.39 | mvanbaak | http://michiel.vanbaak.info/temp/IMG_5811.jpg |
| 21:18.01 | russellb | line 2033 of chan_sip in 1.4.19.1 doesn't line up to anything |
| 21:18.34 | ctooley | just a sec |
| 21:19.07 | ctooley | <PROTECTED> |
| 21:19.08 | ctooley | <PROTECTED> |
| 21:19.19 | russellb | how much have you modified chan_sip? |
| 21:19.28 | ctooley | uhhhh |
| 21:20.12 | seanbright | mvanbaak: olpc? |
| 21:20.12 | putnopvut | ctooley: is there deadlock avoidance stuff below that? |
| 21:20.48 | ctooley | The diff between our chan_sip.c and your chan_sip.c for 1.4.19.1 is 875 channels |
| 21:21.17 | russellb | ... |
| 21:21.17 | russellb | ? |
| 21:22.08 | mvanbaak | seanbright: yup |
| 21:22.10 | mvanbaak | XO |
| 21:22.31 | seanbright | heh |
| 21:23.42 | ctooley | sorry 875 lines, not channels |
| 21:23.48 | seanbright | heh |
| 21:23.53 | seanbright | big difference |
| 21:24.00 | ctooley | seanbright, nah, same diff |
| 21:24.06 | russellb | ok, well ... honestly, 875 lines is a _lot_ |
| 21:24.15 | russellb | and we generally tell people to hit the road for bugs reported against patched code ... |
| 21:24.20 | seanbright | ctooley: really?/ a line is a channel? |
| 21:24.26 | russellb | i really want to help, but that's a lot of changes. |
| 21:24.27 | seanbright | ctooley: would see to be a diff diff :) |
| 21:24.31 | ctooley | russellb, most of it is replacing the 480 response with a 503 |
| 21:24.43 | seanbright | s/see/seem/ |
| 21:25.04 | russellb | k, well we probably need to try the latest release. and then if it still happens, put it on the bug tracker |
| 21:25.09 | russellb | and please include your patch with the report |
| 21:26.27 | ctooley | And I have given the changes (with the exception of the 480 to 503 changes) to oej for inclusion. And, I've ported it all to trunk, but we're seeing such a performance decrease between 1.4 and trunk for chan_sip we can't use the 1.6 branch of code. |
| 21:26.32 | *** part/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 21:26.47 | ctooley | But, I'll up-rev our changes to 1.4.21-rc2 and see how that goes |
| 21:27.35 | ctooley | only about 70 or 80 lines of our changes that actually touch code that makes a difference haven't been applied to trunk. |
| 21:28.12 | ctooley | Oh yeah, there's also the failover code that oej's supposed to be getting into trunk as well. |
| 21:37.27 | mvanbaak | russellb: just to let you know: the new argument to PrivacyManager is working great |
| 21:37.41 | mvanbaak | it blocked 20 calls today and passed 350 calls |
| 21:37.52 | russellb | cool :) |
| 21:38.08 | mvanbaak | those 20 are on top of the callers that are too lazy to provide a number |
| 21:38.17 | mvanbaak | in total, it blocked over 400 calls today |
| 21:38.36 | mvanbaak | 20 that provided a callerid that did not match my checkcontext |
| 21:40.07 | russellb | if it doesn't match, you should send them into IVR hell |
| 21:40.28 | mvanbaak | lol, yeah |
| 21:40.49 | mvanbaak | I now have them go to a Playback: YO MAMMA ! <hangup> |
| 21:41.35 | mvanbaak | it's a running joke on our dutch irc channel |
| 21:41.43 | mvanbaak | JE MOEDER ! |
| 21:41.58 | mvanbaak | <YOUR MOTHER!> <--- english translation |
| 21:42.26 | mvanbaak | default answer to questions like "who's hot" "who you wanna sleep with" etc |
| 21:42.45 | mvanbaak | and most of those friends dont send callerid |
| 21:43.05 | mvanbaak | it's always funny to see them laugh on irc and then check my asterisk logs and see they tried to call me |
| 21:43.08 | mvanbaak | :) |
| 21:51.58 | *** join/#asterisk-dev oej (n=olle@114.62-97-206.bkkb.no) |
| 21:51.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 22:21.19 | *** join/#asterisk-dev dlynes (n=daniel@dsl-vlan468-66-18-244-66.nucleus.com) |
| 22:25.31 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 22:25.31 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 22:28.47 | *** part/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 22:41.33 | jpeeler | M12193 |
| 22:41.34 | MuffinMan | [assigned] [Asterisk] Resources/res_features 0012193: PARKINGEXTEN misbehaves when it is not a canonical form number and can double park or destroy the 700 entry reported by davidw (Karma: neutral) http://bugs.digium.com/view.php?id=12193 |
| 22:41.50 | jpeeler | Corydon76-dig: if you have time, see if what i added is an ok approach |
| 22:42.00 | jpeeler | seems to work... |
| 22:47.34 | Corydon76-dig | jpeeler: I'll look at it after while |
| 22:49.05 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.106.165) |
| 22:49.05 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 22:52.53 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 22:52.53 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:04.52 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 23:04.52 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:09.11 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 23:18.50 | *** join/#asterisk-dev dlynes_laptop (n=daniel@dsl-vlan468-66-18-244-66.nucleus.com) |
| 23:23.49 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 23:23.49 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 23:24.47 | Corydon76-dig | Apparently nobody is reading the commits list... |
| 23:26.22 | jameswf-home | reading=overrated |
| 23:27.06 | Corydon76-dig | Generally several people quickly point out when I insert a joke into the code |
| 23:29.02 | Corydon76-dig | I suppose it IS rather buried this time |
| 23:35.27 | *** join/#asterisk-dev dlynes (n=daniel@S01060016b68219f1.vs.shawcable.net) |
