| 00:33.07 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 00:41.53 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 00:41.53 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:01.49 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 01:02.26 | *** join/#asterisk-dev moy (~moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 01:47.46 | *** join/#asterisk-dev grndlvl (~grndlvl@c-24-23-86-39.hsd1.ga.comcast.net) |
| 01:49.05 | *** part/#asterisk-dev grndlvl (~grndlvl@c-24-23-86-39.hsd1.ga.comcast.net) |
| 02:01.24 | *** join/#asterisk-dev diegomad (mad@186.0.4.182) |
| 02:36.48 | *** join/#asterisk-dev jtodd (fcq8195r43@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 02:36.48 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 02:55.07 | mvanbaak | why am I still @ work |
| 02:55.11 | mvanbaak | Wed Mar 31 05:01:54 CEST 2010 |
| 02:55.18 | mvanbaak | something must have gone wrong |
| 02:55.31 | diegomad | hi, anyone know what happened to the reviewboard server? |
| 02:55.39 | mvanbaak | now I know why it's so damn quiet here at the office |
| 02:56.08 | mvanbaak | diegomad: probably ran out of memory or something |
| 02:56.50 | diegomad | information housed there, where else is? |
| 02:57.58 | mvanbaak | reviewboard is not mirrored |
| 02:58.10 | snuff-work | mvanbaak: i thought this new job was smaller hours.. yet u have meetings on sundays and are in the office till 5am |
| 02:58.25 | mvanbaak | snuff-work: the meeting on sunday was with my old employer |
| 02:58.31 | snuff-work | ah |
| 02:58.53 | mvanbaak | snuff-work: they now pay me 100 us$ / hour to do stuff for them in my free time |
| 02:59.01 | mvanbaak | <--- making shitloads of money at the moment |
| 02:59.27 | snuff-work | being a 'consultant' for previous company isn't bad money if u can get it |
| 02:59.28 | snuff-work | :) |
| 02:59.41 | snuff-work | so that's how u afford these new toys? :) |
| 02:59.48 | mvanbaak | and this new job,.... it's less hours |
| 03:00.07 | mvanbaak | but, I was working on dnssec for our own dns server software together with this other dude |
| 03:00.13 | mvanbaak | and we were progressing nicely |
| 03:00.17 | mvanbaak | and totally forgot time |
| 03:00.31 | mvanbaak | hacking dns code and fixing nasty shit even bind did not fix yet |
| 03:00.54 | snuff-work | i was about to say.. u make ur own custom dns server.. |
| 03:01.10 | mvanbaak | and nice thing is, I go home now, go to bed, and dont show up before something like 2PM |
| 03:01.19 | mvanbaak | yeah, we have our own DNS server software |
| 03:02.00 | mvanbaak | all dns implementations out there cannot handle 1.3 million domains with roughly 10.000 updates to zones every hour |
| 03:02.28 | mvanbaak | so we wrote our own |
| 03:02.35 | mvanbaak | and we are now implementing nsec3 |
| 03:03.23 | mvanbaak | and it's fun to do |
| 03:03.43 | mvanbaak | specially fun to see how some vendors did 'implement' it ;) |
| 03:04.19 | snuff-work | heh |
| 03:04.58 | snuff-work | disturbing topic for school play.. scarface.. http://www.youtube.com/watch?v=uovMpapeCJQ&feature=player_embedded |
| 03:05.22 | snuff-work | wants to kill unixODBC just shows me NO love |
| 03:06.34 | snuff-work | your new job.. with it being bsd only.. you guys 'virtualise' at all?.. jails etc? |
| 03:06.50 | mvanbaak | we use jails for our development platform |
| 03:06.58 | mvanbaak | every developer has his/her own jail |
| 03:07.07 | mvanbaak | but production boxen are not virtualized |
| 03:08.02 | snuff-work | must have quite a few servers under management then :) |
| 03:08.32 | mvanbaak | roughly 300 |
| 03:08.33 | mvanbaak | but I think we are the only company using high available storage under freebsd |
| 03:08.45 | mvanbaak | we are using Hast |
| 03:09.16 | mvanbaak | http://lists.freebsd.org/pipermail/freebsd-announce/2009-October/001279.html |
| 03:09.48 | snuff-work | yes i found that link via google too :) |
| 03:09.51 | snuff-work | quite new |
| 03:10.01 | mvanbaak | http://freebsdfoundation.blogspot.com/2010/02/hast-project-is-complete.html |
| 03:10.23 | mvanbaak | we are TransIP |
| 03:10.59 | snuff-work | ah.. would make sense u are the 1st ones to use since you funded dev then :) |
| 03:11.09 | mvanbaak | uhhuh |
| 03:11.55 | snuff-work | so if u wrote a custom dns server at ur prev job since couldn't handle that many updates.. what does ur current one use? |
| 03:13.24 | mvanbaak | no, we wrote the dns server at my current job |
| 03:13.43 | mvanbaak | my previous job only handled like 800 domains, so they are using bind |
| 03:14.17 | snuff-work | ah.. was getting confused.. |
| 03:14.20 | mvanbaak | my current job is the number 1 in .nl domain names, and we have roughly 400.000 not .nl domains |
| 03:16.02 | snuff-work | mm nice.. i gather its in c.. ;) |
| 03:16.08 | mvanbaak | yup |
| 03:16.14 | mvanbaak | transDNS |
| 03:16.21 | mvanbaak | wont find it online though |
| 03:16.42 | mvanbaak | because it's written to work with our custom controlpanel for customers |
| 03:17.50 | mvanbaak | a year before I started to work for transip they wrote this very cool system to provision dns + webhosting servers |
| 03:17.57 | mvanbaak | it's all based on workflows |
| 03:18.10 | mvanbaak | a workflow has a bunch of states, and it goes from one state to the other |
| 03:18.39 | mvanbaak | when it goes into error on a state, we can reset it to it's previous state and if we fixed the problem, the workflows will continue |
| 03:19.09 | snuff-work | mm sounds nice.. |
| 03:19.34 | snuff-work | i guess if you write a custom dns.. you may as well make it close to ur needs as possible |
| 03:21.00 | mvanbaak | yups |
| 03:23.29 | mvanbaak | here I am, still chatting with you |
| 03:23.32 | mvanbaak | dammit |
| 03:23.37 | mvanbaak | Wed Mar 31 05:30:19 CEST 2010 |
| 03:24.23 | snuff-work | yer only 2:24pm here :) |
| 03:25.40 | snuff-work | enjoy ur sleep |
| 03:26.03 | mvanbaak | thank you |
| 03:26.11 | mvanbaak | have to go home first ;) |
| 04:07.38 | *** join/#asterisk-dev lmsteffan (~lmsteffan@reef.ac-noumea.nc) |
| 04:15.07 | mvanbaak | and I'm home |
| 04:15.16 | mvanbaak | now it's time to get to bed \o/ |
| 04:16.49 | snuff-work | ;) |
| 05:22.53 | *** join/#asterisk-dev mag-samara (~mezhuev@81.211.87.226) |
| 05:31.23 | mag-samara | Hello to ALL. Sorry for distirbing. Where can I find "the best practice for users" for enable JitterBuffer for incoming SIP calls to app_meetme? And another question: Is it possible to change JB paremeters for Local/.../nj construction? I mean How to reduce "generic jitter buffer" in Local channel? |
| 05:42.15 | *** join/#asterisk-dev jbenden (~jbenden@cblmdm72-240-122-140.buckeyecom.net) |
| 06:19.11 | *** join/#asterisk-dev jtodd (nogwtt10yj@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 06:19.11 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 06:31.48 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 07:14.04 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:14.04 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:20.24 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 07:41.09 | mvanbaak | holy crap, I'm awake already |
| 07:42.04 | snuff-work | mm can't be good for u.. |
| 07:42.13 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:44.59 | mvanbaak | probably not |
| 08:09.55 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 10:55.45 | [psy] | whats the difference between the callerID fields in a Newcallerid event vs a Newstate event? |
| 11:08.43 | snuff-home | probably nothing.. |
| 11:08.55 | snuff-home | though i'm guessing |
| 11:49.17 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 11:49.18 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:58.33 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:58.33 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:00.48 | snuff-home | mornin kp |
| 12:02.42 | kpfleming | yes. morning. |
| 12:07.09 | *** join/#asterisk-dev Gugge (~gugge@vlan2.dlxhosting.dk) |
| 12:07.28 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 12:10.54 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 12:10.54 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:40.25 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:40.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:14.52 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 13:26.04 | *** join/#asterisk-dev jtodd (w8fvyeje5g@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 13:26.04 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 13:29.40 | *** join/#asterisk-dev hurdman (~ngeek@ys.antredugeek.fr) |
| 13:29.42 | hurdman | hi |
| 13:29.45 | hurdman | is there a function to free an ast_config_load ? |
| 13:30.11 | hurdman | i have tried ast_free but it seems to not be the great solution |
| 13:31.47 | hurdman | just found it, ast_config_destroy :) |
| 13:31.55 | hurdman | thanks ! |
| 13:32.40 | eliel | :) |
| 13:35.57 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:35.57 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:46.38 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:46.38 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:02.39 | *** join/#asterisk-dev jtodd (gn7bouuthq@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 14:02.39 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 14:04.21 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 14:17.51 | leifmadsen | doh, just missed him by 10 mins |
| 14:23.18 | *** join/#asterisk-dev moy (~chatzilla@74.12.131.229) |
| 14:33.33 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:33.33 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:40.39 | kpfleming | leifmadsen: mantis 17112 is a discussion topic for asterisk-dev, it shouldn't be in mantis |
| 14:41.09 | leifmadsen | M17112 |
| 14:41.28 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/T.38 0017112: Far Max IFP/Local max datagram Calculation and the reality reported by jasmin-annika https://issues.asterisk.org/view.php?id=17112 |
| 14:41.36 | leifmadsen | kpfleming: look at my note from about 10 mins ago |
| 14:41.51 | kpfleming | i only saw the import into JIRA, sorry :-) |
| 14:42.00 | leifmadsen | :) |
| 14:42.08 | leifmadsen | wow, issues.asterisk.org just got unusable for me |
| 14:42.54 | leifmadsen | ok, well it's better now... something must have been running slow |
| 14:46.02 | seanbright | no one uses fax anyway |
| 14:54.10 | hurdman | why is there exttable into struct ast_context *ast_context_find_or_create(struct ast_context **extcontexts, struct ast_hashtab *exttable, const char *name, const char *registrar) ? |
| 14:54.19 | hurdman | it seems to not be use |
| 14:54.35 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:54.35 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:03.36 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 15:05.43 | putnopvut | hurdman: I'm not really sure about that. I wrote a unit test recently that used ast_context_find_or_create and several of the parameters didn't really make sense to me. |
| 15:05.53 | putnopvut | I just modeled my test on how the function was typically called. |
| 15:08.26 | hurdman | ok, to keep back compatibility ? |
| 15:12.35 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 15:12.35 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 15:12.55 | *** join/#asterisk-dev ctooley (~ctooley@c-98-193-232-154.hsd1.tn.comcast.net) |
| 15:12.55 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 15:13.00 | eliel | M17110 |
| 15:13.02 | MuffinMan | [assigned] [Asterisk] Channels/chan_agent 0017110: [regression] realtime queues: persistent members not loaded from astdb on restart reported by tommyhurtig https://issues.asterisk.org/view.php?id=17110 |
| 15:13.13 | eliel | leifmadsen: ^^^ i will |
| 15:13.44 | leifmadsen | eliel: thanks! |
| 15:16.54 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 15:20.41 | *** join/#asterisk-dev wdbl (~not@ool-44c0668f.dyn.optonline.net) |
| 15:26.24 | Jacke | is matt fredrickson around? |
| 15:26.58 | Corydon76-dig | If he was, he would answer to "Cresl1n" |
| 15:30.47 | Jacke | he's not appearently, thanks ;_) |
| 15:32.30 | Corydon76-dig | Dunno his schedule; he may be in class right now |
| 15:33.46 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 15:40.13 | hurdman | is this valgrind log speak to someone ? it seems to be a memory leak but i'm not sure, i search into the src and can't found where it should be a leak http://asterisk.pastebin.com/SNz5ScWL |
| 15:42.31 | Corydon76-dig | Valgrind often reports leaks where there are none |
| 15:42.50 | Corydon76-dig | Use the builtin tools to find real memory leaks |
| 15:46.47 | hurdman | Corydon76-dig: ok, can you advise me a great howto ? |
| 15:53.36 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 15:59.23 | Corydon76-dig | MALLOC_DEBUG in menuselect, then use 'memory show summary' |
| 16:04.48 | *** join/#asterisk-dev Deeewayne (~dwayne@75.76.254.162) |
| 16:04.49 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:06.01 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 16:14.13 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:14.13 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:51.58 | *** join/#asterisk-dev flapjacks (~flapjacks@wsip-70-166-201-90.ph.ph.cox.net) |
| 17:10.35 | *** join/#asterisk-dev diegomad (~mad@190.146.200.120) |
| 17:11.33 | seanbright | hmmm |
| 17:11.54 | jsmith | seanbright: Hmmmn... in a good way, or a bad way? |
| 17:12.13 | seanbright | doing a google search for 'bria' brings up interesting image results |
| 17:12.28 | leifmadsen | heh |
| 17:23.45 | atis_work | don't do image search :p |
| 17:24.07 | seanbright | it wasn't an image search |
| 17:24.16 | seanbright | it just showed up on page 1 of the regular search |
| 17:25.38 | atis_work | ah, true, google doesn't do text-only search anymore |
| 17:26.26 | atis_work | ah, turn on SafeSearch :p |
| 17:26.52 | atis_work | nope, you can still click on images and see that |
| 17:27.36 | seanbright | ah well |
| 17:29.03 | leifmadsen | jtodd: ping? |
| 17:35.47 | hurdman | just be back, thanks for the MALLOC_DEBUG info Corydon76-dig ;) |
| 17:38.52 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 17:38.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:39.58 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:39.58 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:56.37 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 17:56.37 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 18:17.32 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:19.34 | atis_work | putnopvut: wouldn't technology search only make code heavier for variable substitution? |
| 18:20.11 | putnopvut | No, the search will be done when the channel is allocated, not when variable substitution is done. |
| 18:20.33 | putnopvut | And the complexity added at channel allocation time is just a drop in the bucket. |
| 18:22.05 | atis_work | well, that's basically dummy channel, no? |
| 18:22.09 | atis_work | like in trunk |
| 18:22.18 | atis_work | perhaps it's easier to backport it? |
| 18:29.21 | putnopvut | I had thought about it, but in my opinion, it's actually easier to just adjust the channel allocation function since I wouldn't have to find and replace all instances of allocations that can use dummy channels. |
| 18:30.05 | atis_work | i have already grepped for them.. only replacing remains :D |
| 18:31.09 | atis_work | but that's a good place to add deprecation warning in devmode for 1.8 :) |
| 18:31.46 | atis_work | ah, that was called assertion.. sorry :) |
| 18:36.43 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 18:36.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:38.26 | seanbright | holy crap bamboo won't shut up |
| 18:39.32 | atis_work | stop commiting first :p |
| 18:44.00 | atis_work | Â subject:(-"[Bamboo]") listid:"asterisk-dev.lists.digium.com" |
| 18:48.27 | pabelanger | time for a new list? asterisk-bamboo? |
| 18:49.04 | atis_work | then nobody would read it, and it would be pointless |
| 18:49.25 | atis_work | at least code reviews are useful in -dev list :) |
| 18:50.06 | atis_work | i mean - i don't read bamboo reports, but most of the devs probably are.. so i can just create a filter |
| 18:51.42 | putnopvut | It's not hard to filter Bamboo to its own folder or to /dev/null if it's a nuissance. |
| 18:51.57 | putnopvut | atis_work: After looking, I think you're right that dummy_channel_alloc is a good way to go. |
| 18:52.03 | putnopvut | I'll post a patch and a code review shortly. |
| 18:52.48 | atis_work | putnopvut: couldn't get tech list in good way? |
| 18:53.14 | putnopvut | atis_work: I actually already had the patch written and was about to post it on review board, but I decided it would be a good idea to look into ast_dummy_channel_alloc too. |
| 18:53.20 | putnopvut | I didn't realize how simple that function was. |
| 18:53.27 | atis_work | heh :) |
| 18:53.39 | putnopvut | And since you've done the work to grep for the places it should be called, my work is practically done for me. |
| 18:53.56 | atis_work | i'm just not sure that it didn't require any more dependencies/fixes |
| 18:54.41 | putnopvut | I can double check, but I'm almost certain that every "bogus" or other channel like that is created just so that pbx_substitute_variables can be called and then it is freed. |
| 18:54.58 | putnopvut | Hmm, wait a sec. |
| 18:55.16 | putnopvut | You can't just call ast_channel_free() on a dummy channel. I'd have to create a dummy_channel_free function, too. |
| 18:55.26 | putnopvut | So that would be one dependency to take care of. |
| 18:55.35 | putnopvut | I know what I'll do! |
| 18:55.46 | putnopvut | I'll open it up for discussion in the code review I already started writing. |
| 18:55.47 | atis_work | merge trunk to 1.6? :D |
| 18:58.02 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 18:58.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:58.23 | putnopvut | lol |
| 18:59.01 | atis_work | that's what i'm doing on my copy.. i'm somewhere in middle of 1.6.1 and 1.8 :) |
| 18:59.43 | putnopvut | https://reviewboard.asterisk.org/r/601/ |
| 18:59.44 | atis_work | perhaps i should call it 1.7.1 :D |
| 18:59.53 | putnopvut | atis_work: ^^ Feel free to comment on that review request. |
| 19:00.26 | atis_work | sure |
| 19:04.59 | atis_work | putnopvut: did you notice any error messages regarding device IE on testing? |
| 19:05.12 | atis_work | i think i had some before i fixed it my way |
| 19:06.02 | putnopvut | atis_work: no, but my test was a bit different from what was reported. The problem reported was on ast_pbx_outgoing_cdr_failed, which attempted to allocate a channel with a blank name. |
| 19:06.17 | putnopvut | The blank name is what caused that error message to be printed. |
| 19:06.23 | atis_work | ah |
| 19:06.40 | atis_work | so, your patch wouln't go that far either? |
| 19:06.43 | putnopvut | right |
| 19:06.58 | putnopvut | One way to fix that would be to give the channel created in ast_pbx_outgoing_cdr_failed a name. |
| 19:08.36 | putnopvut | I have to head out for a bit. I'll be back on in a little while. |
| 19:09.07 | atis_work | yeah, i have to create steal function for chanspy until tomorrow :) |
| 19:09.24 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-0-16-133.dhcp.embarqhsd.net) |
| 19:27.00 | *** part/#asterisk-dev jbenden (~jbenden@cblmdm72-240-122-140.buckeyecom.net) |
| 20:04.19 | *** join/#asterisk-dev TommyBotten (tommy@broken.pipe.no) |
| 20:08.30 | TommyBotten | I'm looking at the codec bits in the asterisk source... .data.ptr is a series of byte values. What are they, and where do I get a hold of these? |
| 20:09.02 | TommyBotten | In this case all ex_*.h-files |
| 20:09.30 | Qwell | That would be the audio.. |
| 20:10.11 | Qwell | Those header files are just samples. They are only used for cost calculations on startup. |
| 20:10.22 | TommyBotten | ah... I see |
| 20:11.41 | TommyBotten | Has there been any work done on implementing CELT into asterisk? |
| 20:11.53 | TommyBotten | I know it's not bitsream stable yet, but the API is more or less stable |
| 21:15.48 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 22:00.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-75-87-99-1.kc.res.rr.com) |
| 22:02.38 | otherwiseguy | It is Wednesday, so I'm going to ask an esoteric CDR question. :-p |
| 22:03.42 | otherwiseguy | Since ResetCDR's docs state that "First this app finds the last cdr in the list and makes a copy of it. *This new copy will be the newly forked cdr record.* Next this record is linked to the end of the cdr record list. Next, the cdr record is reset (unless you use an option to prevent this). It sounds like ForkCDR() should be the first app of the forked cdr, and therefor the lastapp field of the the record that is from before th |
| 22:03.42 | otherwiseguy | CDR was forked should be whatever was there before the ForkedCDR, call. Opinions? |
| 22:04.46 | otherwiseguy | Asterisk, in the past, used to make an record with lastapp=ForkCDR. Then it didn't. Now it does, but also does some other wrong stuff like creating 3 different records for a single ForkCDR call... |
| 22:05.13 | otherwiseguy | So before "fixing" things, I'd like to figure out what exactly it should be doing. :-p |
| 22:05.51 | otherwiseguy | And unfortunately, "what it does" and "what it used to do" aren't very descriptive in this case. |
| 22:07.12 | putnopvut | otherwiseguy: I apologize, but I have zero to offer to help you. In fact, I may actually have a negative amount of information to provide. |
| 22:07.47 | seanbright | you've forgotten more about CDRs than i will ever know |
| 22:07.54 | otherwiseguy | growls at CDRs |
| 22:08.43 | seanbright | looks for the time-off request form |
| 22:08.55 | putnopvut | points to #yourass |
| 22:09.14 | seanbright | spies #uranus |
| 22:09.18 | seanbright | it's friday! |
| 22:09.50 | otherwiseguy | There is one customer who relied on the ForkCDR lastapp entry, but that just seems weird to me. You lose the information about what you were doing before forking. And since a forked cdr still has the same uniqueid...you can tell that a cdr was forked without it. |
| 22:10.23 | putnopvut | It may be worth noting that to them. |
| 22:11.06 | putnopvut | It's quite common for someone to latch onto something that they, through observation, see to be a means of determining something. However, in some cases, this was never the intent of the developer. |
| 22:11.25 | putnopvut | And of course, the complete lack of documentation doesn't help any :-/ |
| 22:12.19 | otherwiseguy | true |
| 22:12.23 | snuff-work | i have 1 gripe.. cdr_mysql uses 'calldate'.. where in odbc u have to use 'start' |
| 22:13.07 | snuff-work | at least for adaptive_odbc |
| 22:13.53 | otherwiseguy | snuff-work: that is what views are for :-) |
| 22:14.38 | snuff-work | the only way i found out to use 'start' instead of 'calldate' for a column was looking @ code :) |
| 22:14.41 | otherwiseguy | I tend to avoid all of the *mysql modules. |
| 22:15.22 | snuff-work | it was part of my 'hrtime cdr testing' |
| 22:15.40 | snuff-work | now u too can have down to the microsecond billing.. |
| 22:15.56 | otherwiseguy | doc/tex/cdrdriver.tex has a create table command with the 'start' field. |
| 22:16.27 | otherwiseguy | I just wish my provider would do down to the second billing... |
| 22:16.35 | snuff-work | ah.. see i never looked @ that.. i just copied my current cdr tables.. |
| 22:16.55 | snuff-work | create table cdrodbc like cdr; etc |
| 22:17.56 | Corydon76-dig | seanbright: ping |
| 22:38.26 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:38.26 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:43.42 | *** join/#asterisk-dev lmsteffan (~lmsteffan@reef.ac-noumea.nc) |
| 23:03.41 | *** join/#asterisk-dev lmsteffan (~lmsteffan@reef.ac-noumea.nc) |
| 23:34.23 | seanbright | Corydon76-dig: pong |
| 23:44.10 | seanbright | otherwiseguy: i just installed bria so if you need someone else to test video over srtp with... :-) |
| 23:44.34 | otherwiseguy | seanbright: can you get it to make an srtp call without crashing bria? |
| 23:44.43 | seanbright | otherwiseguy: i can certainly try |
| 23:44.51 | otherwiseguy | always crashes with e |
| 23:44.55 | otherwiseguy | and induces much sadness |
| 23:45.06 | otherwiseguy | which may lead to drinking |
| 23:45.09 | seanbright | heh |
| 23:48.09 | *** join/#asterisk-dev lmsteffan (~lmsteffan@reef.ac-noumea.nc) |
| 23:51.17 | seanbright | this interface sucks |
| 23:51.20 | seanbright | err |
| 23:51.25 | seanbright | is... awesome |
| 23:52.39 | seanbright | this camera makes me look fat |
| 23:52.46 | seanbright | or maybe it's the fat |
| 23:55.27 | otherwiseguy | :-) |
| 23:55.47 | otherwiseguy | Sarah is getting that "I'm going to kill you if you don't feed me" look. I'll be back later. |
| 23:56.01 | seanbright | well anyway, if you could use the help, i'm able |
| 23:56.16 | otherwiseguy | seanbright: thanks |