| 00:05.15 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable153.55-201-24.mc.videotron.ca) |
| 00:11.32 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 00:15.54 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 00:46.41 | *** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net) |
| 01:08.24 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |
| 01:29.01 | Juggie | corydon: ping |
| 01:44.54 | Corydon76-dig | pong-ish |
| 01:46.24 | *** join/#asterisk-dev jeffg (i=tC7K5B1l@pdpc/supporter/active/jeffg) |
| 01:46.58 | Greek-Boy | i dont see ping? ping! anymore on ircd's |
| 03:04.49 | *** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 03:04.49 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@pbx.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Lost: Sanity Found: Banana -=- Automated Builds, thx file! - http://buildbot.digium.com |
| 03:17.51 | Greek-Boy | Corydon76-dig: what happened with this issue? http://bugs.digium.com/print_bug_page.php?bug_id=11220 |
| 03:18.03 | Greek-Boy | I am getting something similiar |
| 03:18.18 | Greek-Boy | mpg123: no process killed |
| 03:19.50 | Greek-Boy | thats when I let all modules autoload so I am assuming this happens when format_mp3 module is loaded |
| 03:22.14 | Corydon76-dig | Greek-Boy: when a reporter fails to answer, we assume that the reporter did something stupid and doesn't want to admit it, so the issue is closed |
| 03:22.39 | Corydon76-dig | If we can't reproduce the issue, we're dependent upon the reporter responding to our queries |
| 03:25.08 | Greek-Boy | hmmm |
| 03:25.20 | Greek-Boy | i made a mistake saying format_mp3 module, that doesn't exist |
| 03:25.41 | Greek-Boy | but some module is causing the mpg123: no process killed |
| 03:25.45 | Greek-Boy | message |
| 03:25.50 | Greek-Boy | when I try to stop gracefully |
| 03:25.54 | *** join/#asterisk-dev jmesquita (n=jmesquit@200.170.114.149) |
| 03:26.15 | Corydon76-dig | Greek-Boy: res_musiconhold |
| 03:26.29 | Greek-Boy | just tried excluding that now |
| 03:26.56 | Corydon76-dig | Are you running asterisk directly or using safe_asterisk? |
| 03:27.28 | Corydon76-dig | Check your safe_asterisk script to see if it includes the line "killall mpg123" |
| 03:30.08 | Greek-Boy | i am using the debian init script that comes in the contrib dir. make config sets it up automatically and I think that it uses safe_asterisk |
| 03:30.12 | Greek-Boy | checking it out now |
| 03:31.45 | Greek-Boy | KILLALLMPG123=1 |
| 03:32.59 | Greek-Boy | killall -9 mpg123 |
| 03:34.17 | Greek-Boy | ok |
| 03:34.28 | Greek-Boy | the problem is not the mpg123 |
| 03:35.36 | Greek-Boy | it seems that the problem is attempts to run asterisk again even though i said stop gracefully |
| 03:35.45 | Greek-Boy | stop now ends ok |
| 03:36.43 | Corydon76-dig | If Asterisk ends with an error, then safe_asterisk assumes you meant to restart the process |
| 06:25.25 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 06:30.42 | *** join/#asterisk-dev lvl- (n=lvl@101.248.dhcp.lht.hhs.nl) |
| 06:33.02 | *** join/#asterisk-dev jameswf-home (n=james@ip72-204-221-181.ph.ph.cox.net) |
| 06:41.33 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) [NETSPLIT VICTIM] |
| 06:41.33 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 06:41.33 | *** join/#asterisk-dev GlobeTrotter (n=eric@196.40.26.98) [NETSPLIT VICTIM] |
| 06:41.33 | *** join/#asterisk-dev ectospasm (n=ectospas@c-71-207-229-248.hsd1.al.comcast.net) |
| 06:41.33 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) |
| 06:41.33 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 06:41.33 | *** join/#asterisk-dev Corydon76-dig (i=one@pdpc/supporter/bronze/Corydon76-home) |
| 06:41.33 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) [NETSPLIT VICTIM] |
| 06:41.33 | *** join/#asterisk-dev jsmith-away (n=user@72.21.36.138) |
| 06:41.33 | *** mode/#asterisk-dev [+oooo bkruse d3wayne Corydon76-dig jsmith-away] by irc.freenode.net |
| 06:41.33 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) [NETSPLIT VICTIM] |
| 06:41.33 | *** join/#asterisk-dev Corydon76-vcch (i=purple@pdpc/supporter/bronze/Corydon76-home) |
| 06:41.33 | *** mode/#asterisk-dev [+o Corydon76-vcch] by irc.freenode.net |
| 08:22.41 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:34.10 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 08:34.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:01.46 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 10:54.34 | *** join/#asterisk-dev Stian- (n=stian@062016138186.customer.alfanett.no) |
| 11:10.32 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:11.23 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:52.22 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 12:12.02 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:16.35 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 12:47.46 | *** join/#asterisk-dev RoyK (n=roy@box36.fortel.no) |
| 12:49.30 | *** join/#asterisk-dev corydon76-dig (i=twelve@pdpc/supporter/bronze/Corydon76-home) |
| 12:49.30 | *** mode/#asterisk-dev [+o corydon76-dig] by ChanServ |
| 12:53.42 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 12:54.24 | *** join/#asterisk-dev jcollie (n=jcollie@161.210.45.126) |
| 13:23.03 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.141.193) |
| 13:26.48 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 13:36.29 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:36.29 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:02.05 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 14:02.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:11.41 | *** join/#asterisk-dev IgorG (n=IgorG@host-90-188-188-119.pppoe.omsknet.ru) |
| 14:14.07 | anonymouz666 | mvanbaak: were you working on multiparking? |
| 14:15.14 | mvanbaak | anonymouz666: yup |
| 14:15.36 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:15.36 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:16.03 | anonymouz666 | where I can read more about it? |
| 14:16.17 | mvanbaak | it's in a branch |
| 14:16.21 | mvanbaak | you can checkout the code |
| 14:16.38 | mvanbaak | svn co http://svn.digium.com/svn/asterisk/team/group/multiparking |
| 14:17.34 | mvanbaak | basically, you have to define multiple parking zones in features.conf |
| 14:17.48 | mvanbaak | and a channel variable will control what parking lot you have access to |
| 14:19.22 | mvanbaak | there will also be a config parameter per sip peer or iax peer that will define it's parking lot |
| 14:19.42 | anonymouz666 | mvanbaak: I did multiparking other way, I think I told you how |
| 14:19.49 | mvanbaak | yup |
| 14:20.02 | mvanbaak | you told me in the bugtracker |
| 14:20.14 | mvanbaak | with a link to your patch |
| 14:20.22 | mvanbaak | but this one will be more in line with how asterisk works |
| 14:20.37 | mvanbaak | it's like contexts in the dailplan |
| 14:21.14 | anonymouz666 | yes, it's like contexts. But the bugtracker guy wasn't me :-) |
| 14:22.06 | mvanbaak | ah |
| 14:22.07 | mvanbaak | sorry |
| 14:36.25 | Qwell | +usercontext = ast_calloc(1, 256); |
| 14:36.25 | Qwell | +usercontext = ast_variable_retrieve(cfg, cat, "context"); |
| 14:36.27 | Qwell | silly |
| 14:36.49 | mvanbaak | gheh |
| 14:36.49 | mvanbaak | yeah |
| 14:39.15 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:39.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:41.22 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584185.dsl.bell.ca) |
| 14:42.09 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 14:43.51 | *** join/#asterisk-dev seanbright (i=seanbrig@65.207.74.18) |
| 14:48.08 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 14:51.39 | *** join/#asterisk-dev elguero (n=elguero@207.154.34.162) |
| 14:52.07 | *** join/#asterisk-dev elguero (n=elguero@207.154.34.162) |
| 14:56.01 | file | good morning class |
| 14:56.15 | Qwell | good morning file! |
| 15:00.26 | seanbright | puts an apple on file's desk |
| 15:02.54 | file | my desk is dirty |
| 15:03.02 | file | so I would not suggest putting an apple on it |
| 15:04.26 | seanbright | heh |
| 15:04.59 | seanbright | that's ok, it was a dirty apple anyway |
| 15:32.02 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-105864.home.otenet.gr) |
| 15:42.25 | Qwell | just as a sanity check - 1 frame of slin16 should be 640 bytes, right? |
| 15:43.00 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:43.00 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:43.02 | Qwell | 160 samples, at 4 bytes per sample? |
| 15:46.11 | Qwell | trying to use res_convert, and it's being very...odd. It converted by 640 byte slin16 file into 149 byte ulaw/alaw files |
| 15:46.37 | Qwell | sox correctly converted it into 160 byte files |
| 15:49.04 | russellb | yes, it should have been 160. |
| 15:50.33 | Qwell | res_convert is really simple too. it opens two files, then does a while (ast_read()) ast_write(); |
| 15:50.50 | Qwell | readframe/writeframe, that is |
| 15:52.06 | russellb | yeah, someone is being naughty and not consuming all the data |
| 15:53.18 | Qwell | perhaps unsurprisingly, when I converted to gsm, it produced a 0 byte file |
| 15:53.31 | russellb | that is not good, either |
| 15:53.33 | Qwell | (whereas sox made a 33 byte file) |
| 15:53.52 | Qwell | ((which is correct)) |
| 15:55.35 | Qwell | oh, and I was wrong earlier. it's 320 samples at 2 bytes per sample |
| 15:56.23 | russellb | yes. :) |
| 15:56.45 | seanbright | russellb: countdown? |
| 15:56.54 | russellb | 1 week, 5 days |
| 15:56.58 | seanbright | wow |
| 15:57.02 | seanbright | time flies |
| 15:57.06 | russellb | no kidding |
| 15:57.13 | seanbright | getting nervous yet? |
| 15:57.24 | russellb | nah |
| 15:57.41 | russellb | tired more than anything :) |
| 15:57.56 | seanbright | heh, you'll have plenty of time for sleep when you're dead |
| 15:58.52 | russellb | touche |
| 15:59.21 | russellb | i can't complain ... i'm going to be laying on a beach for a week very soon. |
| 15:59.32 | seanbright | where you going? |
| 15:59.59 | russellb | a resort in the Caribbean |
| 16:00.21 | seanbright | very nice |
| 16:00.43 | seanbright | don't forget your laptop and cell phoone |
| 16:00.48 | seanbright | s/phoone/phone/ |
| 16:02.18 | russellb | heh, i won't forget that i left them back at home, yes |
| 16:02.38 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:02.46 | Qwell | russellb: off the top of your head, can you think of any reason that it might be consistently 149 bytes for one frame of ulaw/alaw? |
| 16:02.54 | russellb | it's broken? |
| 16:02.56 | Qwell | heh |
| 16:03.02 | russellb | i can look at it in a minute if you want |
| 16:03.20 | russellb | we just have to figure out who isn't passing through all of the data they are supposed to |
| 16:03.23 | Qwell | I'm gonna try to reproduce using a slin16 file with 2 frames |
| 16:03.32 | Qwell | see if it's still 11 bytes, or if it goes to 22 |
| 16:03.45 | Qwell | also gonna try using slin8 as the source |
| 16:03.50 | russellb | cool |
| 16:05.22 | *** join/#asterisk-dev miguel3239 (n=elguero@207.154.34.162) |
| 16:07.52 | Qwell | looks like it's codec_resample. sln > ulaw is fine, sln16 > g722 is fine, sln16 > sln is not |
| 16:07.56 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:07.56 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:08.37 | russellb | k |
| 16:10.42 | Qwell | sln > sln16 is bad too |
| 16:12.43 | russellb | has an idea |
| 16:12.55 | Corydon76-lap | That's crazy talk |
| 16:19.43 | russellb | patch coming |
| 16:19.50 | Qwell | w00t! |
| 16:19.57 | Qwell | need me to test it first? |
| 16:19.57 | russellb | to test, anyway |
| 16:20.00 | russellb | yes |
| 16:20.00 | Qwell | kk |
| 16:20.04 | russellb | it's a guess ... |
| 16:20.11 | Qwell | guesses are good |
| 16:25.45 | russellb | http://pastebin.ca/955393 |
| 16:25.46 | russellb | Qwell: |
| 16:27.03 | Qwell | hmm |
| 16:27.05 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 16:27.13 | russellb | no dice? |
| 16:27.22 | Qwell | testing |
| 16:29.25 | Qwell | stupid pastebin |
| 16:29.52 | Qwell | it's hosing the formatting... any chance you could email that to me? |
| 16:30.14 | seanbright | http://pastebin.ca/raw/955393 |
| 16:30.27 | Qwell | seanbright: still replaces tabs with spaces |
| 16:30.31 | seanbright | ah |
| 16:30.35 | seanbright | stupid pastebin |
| 16:36.52 | Qwell | russellb: same :( |
| 16:36.56 | russellb | k |
| 16:38.58 | Qwell | setting that arg to 1 always did work though O.o |
| 16:39.05 | Qwell | (on a 1 frame file) |
| 16:41.52 | russellb | ok, so the setting of the flag isn't working probably |
| 16:44.08 | Qwell | I think I know why |
| 16:44.22 | russellb | eof isn't set yet? |
| 16:44.27 | Qwell | if you read 640 bytes from a 640 byte file, I don't think eof gets set |
| 16:44.27 | Qwell | yeah |
| 16:44.38 | russellb | i was afraid of that |
| 16:44.45 | Qwell | there is something that sets eof though...umm |
| 16:45.04 | Qwell | (without reading more) |
| 16:45.45 | russellb | yeah, lunch, brb |
| 17:13.51 | Qwell | russellb: I ponder why we don't just always set lastFlag to 1 |
| 17:14.35 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 17:23.49 | Qwell | or like on the last iteration of that while loop |
| 17:28.41 | russellb | that's not valid though ... |
| 17:28.51 | russellb | it's supposed to only be set when it's the last set of samples being resampled |
| 17:29.03 | Qwell | only for performance reasons, no? |
| 17:34.38 | russellb | i'd have to try to understand libresample :) |
| 17:35.52 | russellb | but i know that's the intent |
| 17:55.38 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 18:06.25 | *** join/#asterisk-dev jcollie (n=jcollie@dsl-ppp239.isunet.net) |
| 19:06.43 | Qwell | stupid C question. What will the result of this be? (int)(5.2) |
| 19:06.52 | Corydon76-lap | 5 |
| 19:06.58 | Qwell | what about 5.6? |
| 19:07.03 | Qwell | (int)(5.6), of course |
| 19:07.05 | Corydon76-lap | 5 |
| 19:07.18 | Qwell | So...hmm. |
| 19:07.39 | Corydon76-lap | Casting to an int is the same as floor for all positive numbers |
| 19:07.54 | Corydon76-lap | but it's the same as ceil for all negative numbers |
| 19:07.56 | Qwell | I'm trying to replace a buffer that's 2048 with a dynamic size, and...in most cases (all current cases) it'll be a whole number |
| 19:08.20 | Qwell | it feels like a hack to always add 1 |
| 19:08.34 | Qwell | though, the buffer would be immensely smaller than 2048 in pretty much all cases |
| 19:08.45 | Corydon76-lap | I generally divide by 512, add 1, multiply by 512 |
| 19:08.53 | Qwell | err? |
| 19:09.13 | Corydon76-lap | It increases the buffer in increments of 512 |
| 19:09.18 | Qwell | it's gonna be small. probably 160 or 320 |
| 19:09.29 | Corydon76-lap | See cdr_pgsql in trunk, I think |
| 19:09.31 | Qwell | worse case scenario...umm... |
| 19:09.45 | Qwell | 960 is pretty much worst case |
| 19:09.59 | Corydon76-lap | The reason I increment it like that is to save on the number of calls to realloc |
| 19:10.21 | Qwell | maybe dynamic was the wrong word... |
| 19:10.39 | Qwell | it's a char[2048] right now. For a single calling of the function, it'll always be the same. no need to change mid-call |
| 19:10.55 | Qwell | codec_resample.c, line 108ish.. out_buf_f[] |
| 19:11.17 | Qwell | float out_buf_f[(int)(f->samples * resample_factor)]; |
| 19:11.24 | Qwell | that's what I have now.. |
| 19:12.23 | Corydon76-lap | If +1 feels like a hack to you, do (int)ceil(...) |
| 19:12.23 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 19:12.24 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 19:12.33 | file | waves to bweschke |
| 19:12.38 | Qwell | hmm |
| 19:12.39 | bweschke | hey file! |
| 19:12.45 | *** join/#asterisk-dev CrashHD (n=CrashHD@76-14-102-131.rk.wavecable.com) |
| 19:12.45 | Corydon76-lap | That will ensure that you never exceed the amount of space that you need by a byte |
| 19:12.52 | Qwell | ceilf, right? |
| 19:13.09 | Qwell | resample_factor is a float |
| 19:13.17 | Corydon76-lap | Either way |
| 19:14.00 | Corydon76-lap | ceilf will only make a performance difference on embedded platforms |
| 19:14.23 | Qwell | "If x is infinite, x itself is returned." |
| 19:19.22 | Corydon76-lap | Confirmed. On i386, ceil and ceilf are identical in code |
| 19:19.46 | Qwell | does there need to be configure script logic for them? I see there is for ceill |
| 19:20.33 | Corydon76-lap | Hah! That's identical, as well |
| 19:21.26 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:32.00 | *** join/#asterisk-dev Greek-Boy (n=email@41.221.58.13) |
| 19:33.33 | Greek-Boy | when jumping from one extension to another using Gotoif ${exten} is empty and does not contain the extension that was originally called. Is this normal behaviour? |
| 19:34.10 | Qwell | exten or EXTEN? |
| 19:34.42 | Greek-Boy | I used ${exten} |
| 19:34.47 | codefreeze | Qwell is right. last I noticed, the var names are case sensitive |
| 19:35.00 | Greek-Boy | I'll be sure to try it |
| 19:43.24 | *** join/#asterisk-dev snuff-home (n=snuff-ho@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 19:59.31 | *** join/#asterisk-dev Laureano (n=tomas@OL93-199.fibertel.com.ar) |
| 20:04.57 | bweschke | so does the next version of Asterisk require libMonaVie ? I need to make sure all my pyramid headers are up to date in my build env |
| 20:10.46 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 20:25.30 | *** join/#asterisk-dev pgarcia (n=pgarcia@yoda.kanatek.com) |
| 20:31.10 | pgarcia | Hi, I'm having troubles trying to understand the thread behaviour for the channel drivers. |
| 20:31.44 | pgarcia | Here is the whole history: My channel driver starts a thread to wait for the device driver/sdk events.Everything goes well but due to my design, in my bridge function I have to stop my playback functions and wait for an event certifying that the play process is really done. I'm doing it waiting for a flag being set in a while with a usleep inside. The problem is that when I'm inside that loop, I cannot receive any events from my SDK. For my unde |
| 20:31.44 | pgarcia | rstanding , every channel runs in your own thread and since I have a separated thread for receiving my events, why when I wait inside a channel driver callback function, my other thread doesn't runs? |
| 20:37.04 | Greek-Boy | Qwell: I can verify that I was using ${EXTEN} and not ${exten}. |
| 20:39.30 | Greek-Boy | Qwell: I realised that i posted that you here by accident. I should be posting it in #Asterisk. my apologies |
| 20:46.06 | Qwell | I just had a random thought |
| 20:46.13 | Qwell | format_text |
| 21:01.51 | codefreeze | Convert that to ulaw! |
| 21:01.57 | Greek-Boy | format_text? |
| 21:19.37 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 21:25.08 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 21:39.40 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 21:39.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:04.56 | *** join/#asterisk-dev pputman (n=consorm@c-68-62-214-146.hsd1.al.comcast.net) |
| 22:08.02 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 22:14.31 | *** join/#asterisk-dev jameswf (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 22:36.44 | *** join/#asterisk-dev philipp64 (n=chatzill@131.107.152.19) |
| 22:43.21 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 22:44.33 | *** join/#asterisk-dev asteriskmonkey (n=asterisk@69.77.169.14) |
| 22:44.55 | asteriskmonkey | well its seems the bug with the page application crashing asterisk is not fixed |
| 22:45.18 | asteriskmonkey | using latest asterisk 1.4 subverion (branches) and ztdummy |
| 22:45.41 | asteriskmonkey | anyone else know about this? |
| 22:46.36 | Corydon76-lap | Nope |
| 22:47.17 | Corydon76-lap | What bug number is it? |
| 22:48.03 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582556.dsl.bell.ca) |
| 22:48.44 | asteriskmonkey | looks like it relates to this one > http://bugs.digium.com/view.php?id=9181 |
| 22:54.25 | asteriskmonkey | cant get it to crash on a few channels, must be something to do with the amount of sets and a timing issue probably with ztdummy, does this sound like a good assumption or a problem that anyone is aware of? |
| 23:12.56 | philipp64 | mvanbaak: ping |
| 23:13.31 | mvanbaak | pong |
| 23:15.38 | mvanbaak | philipp64: that was for you ;) |
| 23:16.02 | *** join/#asterisk-dev RoyK (n=roy@ip-105-51-149-91.dialup.ice.no) |
| 23:16.19 | philipp64 | goude middag. |
| 23:16.35 | philipp64 | I figured it had my name on it. |
| 23:17.08 | mvanbaak | hoi |
| 23:17.21 | philipp64 | was wondering if bug 11969 needed any thing else on it? |
| 23:17.45 | philipp64 | I don't have a lab install of 1.6 yet, so I haven't tried the examples... |
| 23:17.51 | *** part/#asterisk-dev asteriskmonkey (n=asterisk@69.77.169.14) |
| 23:18.00 | mvanbaak | ah, that one |
| 23:18.08 | mvanbaak | it's now up to the powers that be |
| 23:18.14 | mvanbaak | I like it how it is now |
| 23:18.26 | philipp64 | should it return a value? ${DIALSTATUS}? |
| 23:18.53 | mvanbaak | that would be the best thing to do yeah |
| 23:19.32 | philipp64 | ok. I can fix that and repost. |
| 23:20.02 | philipp64 | how are the powers-that-be for configuration bugs, anyway? |
| 23:20.19 | philipp64 | oh, hang on. just saw that it was moved to "new feature". not sure why. |
| 23:20.40 | philipp64 | it's existing functionality... just re-implemented to keep up with deprecated features. |
| 23:22.22 | mvanbaak | no, it's something new because you introduce the configs for virtual hosting |
| 23:22.25 | mvanbaak | it's not in there yet |
| 23:22.38 | mvanbaak | yes, you redefine the default macro's |
| 23:22.54 | mvanbaak | but if you want that to get in as bugfix you should post it as a seperate bug |
| 23:23.09 | mvanbaak | because the entry right now is for virtualpbx stuff |
| 23:23.10 | philipp64 | split it into two? |
| 23:23.11 | mvanbaak | and that is new |
| 23:23.21 | philipp64 | ok. I can do that. |
| 23:23.28 | mvanbaak | depends |
| 23:23.37 | mvanbaak | do you want to get it in as 1 commit |
| 23:23.41 | mvanbaak | leave it like it is |
| 23:23.58 | mvanbaak | do you need the updates to the macro's without the virtual hosting stuff, split it up |
| 23:24.05 | philipp64 | the assumption being that fixing stdexten will be easier.... since that needs to take the additional argument to facilitate the virtual-pbx stuff. |
| 23:24.35 | philipp64 | the virtual-pbx stuff is to make the example more useful to others. I can live without it. |
| 23:24.46 | philipp64 | I just need stdexten to have the new functionality. |
| 23:24.58 | philipp64 | (i.e. naming the context) |
| 23:31.42 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 23:33.16 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-183-109.hsd1.wa.comcast.net) |