| 01:47.22 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 01:51.14 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 01:51.14 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:25.09 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 02:26.32 | *** join/#asterisk-dev bbryant1 (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 02:26.32 | *** mode/#asterisk-dev [+o bbryant1] by ChanServ |
| 02:42.23 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 04:02.26 | moy | 1.6.2 branch always fail to compile pbx lua mod, shouldn't configure or make menuselect or something detect if it's present and if not, not try to compile it? |
| 04:02.55 | Qwell | should |
| 04:03.21 | Qwell | not many people are that familiar with it I suspect. might want to poke mnicholson on Monday |
| 04:03.58 | moy | thanks Qwell, will do so |
| 04:03.59 | Qwell | I think it's in all 1.6 versions though.. not sure what would have changed |
| 04:04.43 | Qwell | 1.4 even maybe |
| 05:04.14 | moy | make menuselect in 1.6.2 branch shows openr2 library just fine as "can use" but chan_dahdi does not get linked to it, 1.4 seems fine though, any hints where to look? |
| 05:17.10 | Juggie | moy you've become quite involved since the day about 6months ago or more when you asked me what to do with some code you had written for dahdi :) |
| 05:17.24 | Juggie | or openmr2 or whatever it was |
| 05:19.32 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 05:20.11 | moy | hey Juggie , yeah time flies huh :) |
| 05:21.46 | Juggie | yep for sure |
| 05:21.48 | Juggie | havin fun :) |
| 05:41.38 | Qwell | moy: r2 support was added in 1.6.1, right? |
| 05:47.36 | moy | Qwell: 1.6.2 .... but I have a 1.4 branch as well |
| 05:47.52 | Qwell | ahh, okay |
| 05:47.58 | moy | odd, the 1.6.2 beta release links just fine, so I just have the problem with 1.6.2 branch |
| 05:48.44 | Qwell | well, with the lua problem you're having too, I'd say something went wonky with the build system |
| 05:50.24 | moy | yah, though I had the lua error with the beta .tar as well |
| 05:52.22 | Qwell | oh, hmm |
| 06:30.00 | moy | any idea based on what menuselect.makedeps is generated? |
| 06:31.51 | Qwell | moy: it's parsed out of the .c files I believe |
| 06:31.59 | Qwell | the <depend>whatever</depend> stuff |
| 06:34.49 | moy | I assumed that as well, but, in beta release of 1.6.2 menuselect.makedeps shows pri, ss7 and openr2 as dependencies of chan_dahdi, in 1.6.2 branch just pri and ss7 are, even when the .c file has the same <use> stuff |
| 06:48.05 | moy | mmm the new changes in menuselect.c are causing this |
| 06:49.00 | moy | don't know yet how though, but if I copy menuselect.c from 1.6.2 beta to the branch, then it works |
| 06:58.11 | moy | this commit: r520 | kpfleming | 2009-06-02 18:21:48 -0500 (Tue, 02 Jun 2009) | 5 lines |
| 06:58.13 | moy | is the culprit |
| 07:27.12 | moy | shit, solved, damn menuselect sourcery |
| 07:28.35 | moy | it used to work before that commit because menuselect was not being strict, solved by adding openr2 entry in build_tools/menuselect-deps.in |
| 07:28.48 | moy | time to sleep, I'm out |
| 08:35.25 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 08:42.18 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:42.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:12.24 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 11:02.27 | *** join/#asterisk-dev puzzled (n=foobar@blahfoo.xs4all.nl) |
| 12:22.57 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:22.57 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:57.23 | *** join/#asterisk-dev DarkRift (n=dark@65.92.165.162) |
| 13:48.37 | Deeewayne | waves to leifmadsen |
| 13:58.30 | leifmadsen | waves back! |
| 13:58.36 | leifmadsen | Deeewayne: how goes sir? |
| 14:00.41 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 14:02.55 | Deeewayne | not bad |
| 14:04.16 | Deeewayne | leifmadsen, do you have any idea if 'core show version' should reference Asterisk at all if you are using a modified version? |
| 14:04.59 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:04.59 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:06.03 | Deeewayne | kpfleming, should 'core show version' reference Asterisk when the source is modified ? |
| 14:06.22 | kpfleming | what does 'reference' mean? |
| 14:07.10 | Deeewayne | Asterisk SVN-branch-blah |
| 14:07.21 | kpfleming | i still don't understand the question |
| 14:08.36 | Deeewayne | if I distribute a modified version of Asterisk I want to know if I am required to change the output of 'core show version' to remove Asterisk.... to try to comply with the terms of use policy |
| 14:09.18 | kpfleming | you mean the trademark policy |
| 14:09.23 | kpfleming | there is no terms of use policy |
| 14:09.43 | kpfleming | if you have to change that, you have to change a lot more than 'core show version' |
| 14:09.45 | Deeewayne | yeah, Trademark policy |
| 14:10.02 | kpfleming | so really, you are asking if you need to remove all references to 'Asterisk' as the name of the product |
| 14:10.18 | Deeewayne | ok, yes |
| 14:10.28 | kpfleming | that's a difficult thing to answer |
| 14:10.52 | kpfleming | it depends on the changes you are making, whether the distribution is commercially-motivated or free, lots of other stuff |
| 14:34.18 | seanbright | distributes Another Business Edition |
| 14:48.11 | leifmadsen | seanbright: lol |
| 14:48.19 | leifmadsen | YABE |
| 14:50.17 | leifmadsen | why must it be so difficult to draw a line with an arrow head in gimp... |
| 14:51.46 | seanbright | you're using a program called 'gimp' and are wondering why it makes things difficult? |
| 14:57.40 | leifmadsen | heh :) |
| 14:57.44 | leifmadsen | touche |
| 14:57.46 | leifmadsen | I switched to Dia |
| 14:58.50 | seanbright | inkscape is good |
| 14:59.03 | seanbright | more for vector art |
| 14:59.14 | seanbright | but super awesome. |
| 14:59.44 | seanbright | you know what sucks? waiting for a reporter to test a patch over the weekend |
| 14:59.53 | seanbright | because we know that isn't going to happen |
| 15:08.11 | seanbright | * Note: The AST_LOG_* macros below are the same as |
| 15:08.11 | seanbright | * the LOG_* macros and are intended to eventually replace |
| 15:08.11 | seanbright | * the LOG_* macros to avoid name collisions |
| 15:08.17 | seanbright | is that still the case? |
| 15:11.02 | kpfleming | yes |
| 15:11.27 | seanbright | k |
| 15:16.14 | leifmadsen | I'm writing up a nice long blog post that explains the 1.6 release process |
| 15:16.31 | leifmadsen | hopefully it can be a reference to lower the confusion that I've been seeing lately |
| 15:19.16 | seanbright | well let's not kid ourselves |
| 15:19.23 | seanbright | 1.6 release process = confusing |
| 15:19.24 | seanbright | :) |
| 15:21.07 | leifmadsen | not really :) |
| 15:21.12 | seanbright | to me it is |
| 15:21.28 | leifmadsen | it's the same thing as 1.2 and 1.4, but now you just have 3 significant digits instead |
| 15:21.32 | seanbright | were i an asterisk newbie, i would have no clue which version to download and install |
| 15:21.57 | leifmadsen | seanbright: hence my article :) |
| 15:22.13 | seanbright | esp. with the trolly community we have "helping me" |
| 15:23.31 | leifmadsen | heh |
| 15:23.40 | leifmadsen | yes... we do seem to have a trolly community |
| 15:23.48 | leifmadsen | I can't disagree with you there |
| 15:23.56 | seanbright | "i would install 1.2" |
| 15:24.13 | seanbright | "i would wait for the 20th or so release of 1.6 before i installed it" |
| 15:24.16 | seanbright | etc, etc. |
| 15:24.42 | seanbright | this project would be so much better without users |
| 15:24.44 | seanbright | :-P |
| 15:27.09 | leifmadsen | lol |
| 15:27.27 | leifmadsen | I think people just think they can install any version and start using it without even testing anything |
| 15:27.38 | leifmadsen | ya, I might wait for the 20th revision too if I was trying to use chan_unistim |
| 15:27.40 | leifmadsen | too |
| 15:27.52 | leifmadsen | errr.... ignore that last too :) |
| 15:29.56 | seanbright | well i'm about to build a brand spanking new call center PBX |
| 15:30.03 | seanbright | what version do you recommend, sir leifmadsen. |
| 15:30.21 | leifmadsen | seanbright: I recommend the version that has the features you require :) |
| 15:30.29 | leifmadsen | and that passes the testing you have done |
| 15:30.50 | leifmadsen | I don't recommend specific versions |
| 15:31.24 | seanbright | you suck. |
| 15:31.31 | seanbright | they all have the features i need. |
| 15:31.39 | seanbright | 1.4, 1.6.0, 1.6.1, and 1.6.2 |
| 15:31.42 | seanbright | all of 'em |
| 15:31.45 | seanbright | ALL of them. |
| 15:31.46 | seanbright | heh |
| 15:31.53 | leifmadsen | then use the one that has been out the longest :) |
| 15:32.00 | seanbright | 1.4 it is |
| 15:32.27 | leifmadsen | do some forward planning and make sure there aren't any features you'll need in future development though so you don't have to rearchitect it again |
| 15:32.42 | leifmadsen | seanbright: btw -- these questions have been extremely handy for my article :) |
| 15:33.15 | seanbright | heh |
| 15:33.18 | seanbright | glad i could help |
| 15:33.29 | seanbright | so you're the load balancing guy, yeah? |
| 15:33.37 | leifmadsen | to a degree, I suppose yes :) |
| 15:33.53 | leifmadsen | I may not know exactly how to deploy it, but I sure as heck know how NOT to deploy it ;) |
| 15:34.03 | seanbright | heh |
| 15:34.14 | seanbright | well i guess i have more of a distribution question... |
| 15:34.18 | seanbright | we are gearing up |
| 15:34.38 | seanbright | this is OT for this channel, someone can tell me to move it elsewhere if they want |
| 15:35.03 | seanbright | anyway. we're gearing up to run some media. we've ordered a few circuits and with g729 plan to get ~196 channels. |
| 15:35.35 | seanbright | we don't plan to actual use all of those concurrently, but we will have the capacity to do so in the future. |
| 15:35.42 | seanbright | anyway. my current thinking is: |
| 15:36.08 | seanbright | front end box - this is connected right to the pstn and it's entire job is to transcode g729 to something else (ulaw, whatever) |
| 15:36.34 | seanbright | which sends all calls to: |
| 15:36.53 | seanbright | recording box(es): 1 or more servers with fast disks whose sole job is recording all of the calls |
| 15:36.58 | seanbright | which sends calls to: |
| 15:37.11 | seanbright | call center pbx: should be obvious what this is/does. |
| 15:37.18 | seanbright | and outbounds would work in reverse. |
| 15:37.48 | seanbright | i'm wondering if i'm overestimating the expense of transcode g729 and the recordings. |
| 15:38.04 | seanbright | but recording every call is a pretty expensive operation from an i/o standpoint. |
| 15:38.14 | leifmadsen | I agree |
| 15:38.19 | seanbright | to which part? |
| 15:38.20 | seanbright | :) |
| 15:38.20 | leifmadsen | that doesn't seem like a bad topology to me |
| 15:38.23 | leifmadsen | to all of it |
| 15:38.23 | seanbright | ok |
| 15:38.34 | leifmadsen | you're isolating the things that can go wrong too |
| 15:38.36 | file | it's not horrible if you have tons of RAM and record to ramdisk, and then batch 'em to the hd |
| 15:38.59 | seanbright | well my plan was just to throw some cheap commodity hardware in the middle layer |
| 15:39.03 | leifmadsen | with file's testing, apparently ramdisk makes a pretty huge difference |
| 15:39.05 | seanbright | but with 15k rpm disks |
| 15:39.18 | leifmadsen | disks will always be slower than solid state |
| 15:39.23 | seanbright | true |
| 15:39.25 | leifmadsen | I like the batching idea |
| 15:39.38 | leifmadsen | which you could still implement in your recording server |
| 15:39.39 | seanbright | so get a box with a shit-ton of ram |
| 15:39.41 | leifmadsen | it'll just make it even better |
| 15:39.52 | seanbright | true |
| 15:40.02 | leifmadsen | transfers could get a bit tricky I might think |
| 15:40.03 | seanbright | you think dedicating a box to g729 is a good plan? |
| 15:40.06 | seanbright | yeah |
| 15:40.12 | leifmadsen | transcoding == high CPU |
| 15:40.17 | leifmadsen | I don't see why it would be bad :) |
| 15:40.22 | seanbright | heh |
| 15:40.23 | leifmadsen | (other than complicating the transfers) |
| 15:40.33 | seanbright | well, i can overcome all of that. |
| 15:40.36 | seanbright | i'm a pretty smart guy. |
| 15:40.37 | leifmadsen | yep, I think so too |
| 15:40.42 | seanbright | plus i can just ask you guys. |
| 15:40.44 | leifmadsen | (to the former statement) |
| 15:41.15 | seanbright | and i'd think that the box i have now (dual quad-core with 4GB of memory) could handle 196 channels when no recording is going on. |
| 15:41.25 | seanbright | as the call center PBX. |
| 15:41.45 | file | I dunno what the latest codecs will get you |
| 15:42.29 | seanbright | the one really nice part about having the recording box in the middle is that out/inbound calls are recorded from start to finish for free |
| 15:42.39 | seanbright | (for free = without dialplan) |
| 15:42.42 | leifmadsen | seanbright: I think you'd be ok there too. I haven't load tested that, but my gut tells me you should be ok |
| 15:42.50 | seanbright | i am going to test it. |
| 15:42.53 | seanbright | obviously. |
| 15:42.58 | leifmadsen | seanbright: honestly, I would develop a new system on 1.6.0 so it is easier to move to 1.6.x versions down the road |
| 15:43.19 | seanbright | file: so then 196 on a single box might be tight? |
| 15:43.25 | seanbright | leifmadsen: that is what i was thinking. |
| 15:43.30 | file | seanbright: I haven't the foggiest to be honest |
| 15:43.50 | seanbright | oh, and they are 64 bit |
| 15:43.57 | seanbright | i will test and report results. |
| 15:44.14 | seanbright | just going to have my dev PBX call the new one. see which one dies first. |
| 15:44.45 | seanbright | the nice thing is that i have a friend that has access to 600 concurrent channels. when they turn the circuits up i am going to have him throw everything he's got at me :) |
| 15:45.44 | seanbright | the one thing that worries me is moving to multiple call center boxes |
| 15:46.38 | seanbright | because there is no logical way to partition our business that would evenly distribute load |
| 15:46.47 | seanbright | i mean, i could move CS off to another box, but that is 3 people |
| 15:46.51 | seanbright | whereas sales is 50. |
| 15:46.56 | leifmadsen | seanbright: http://leifmadsen.wordpress.com/2009/06/06/about-the-new-asterisk-versioning-method/ |
| 15:47.08 | seanbright | i am glad my name is not mentioned. |
| 15:47.28 | seanbright | leifmadsen: that is called "flying fish" |
| 15:47.50 | leifmadsen | :) |
| 15:48.11 | seanbright | that is what i call it, anyway. |
| 15:48.18 | leifmadsen | never heard that term :) |
| 15:48.33 | leifmadsen | I must now get ready to meet downtown for a VIP tour of the Steam Whistle brewery! |
| 15:48.55 | seanbright | you son of a bitch |
| 15:48.57 | seanbright | have fun. |
| 15:50.36 | leifmadsen | lol, oh I plan on it ;) |
| 15:50.45 | leifmadsen | I'm sure there will be some beer tasting involved |
| 15:51.02 | seanbright | i need you to write a distributed queues article next week |
| 15:51.05 | seanbright | just so you know |
| 15:51.09 | seanbright | so get mentally ready |
| 15:51.47 | leifmadsen | heh... well distributed queues are a difficult thing... I guess you need to clearly define what you mean by that |
| 15:52.17 | leifmadsen | I think a simple queue article would be a good first step |
| 15:52.29 | leifmadsen | (all of this stuff will be useful come time to update the asterisk book |
| 15:52.42 | seanbright | i really want to get my name on a book |
| 15:52.49 | seanbright | i might have to bribe you and jared |
| 16:11.11 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 16:57.27 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 19:19.58 | seanbright | cheeseburger with motor oil? bad format, indeed! |
| 19:23.20 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 19:23.20 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:29.07 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 19:29.07 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:37.22 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 20:36.00 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 20:39.42 | *** part/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 20:52.01 | *** join/#asterisk-dev bbryant1 (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 20:52.01 | *** mode/#asterisk-dev [+o bbryant1] by ChanServ |
| 21:09.23 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 21:09.23 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 21:12.30 | *** join/#asterisk-dev eliel (n=eliels@120-17-235-201.fibertel.com.ar) |
| 21:12.30 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 21:18.25 | *** join/#asterisk-dev eliel_ (n=eliels@120-17-235-201.fibertel.com.ar) |
| 21:48.22 | *** join/#asterisk-dev telecos (n=sergio@91.166.219.87.dynamic.jazztel.es) |
| 22:02.39 | *** join/#asterisk-dev DarkRift (n=dark@65.92.249.175) |
| 22:17.20 | *** join/#asterisk-dev eliel (n=eliels@120-17-235-201.fibertel.com.ar) |
| 22:17.20 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 22:23.21 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 22:23.21 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 22:52.20 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 22:52.20 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:11.42 | *** join/#asterisk-dev bbryant1 (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 23:11.42 | *** mode/#asterisk-dev [+o bbryant1] by ChanServ |