| 01:35.01 | *** join/#asterisk-bugs file (n=file@asterisk/developer-and-muffin-lover/file) |
| 01:35.01 | *** mode/#asterisk-bugs [+o file] by ChanServ |
| 01:47.48 | *** join/#asterisk-bugs file (n=file@asterisk/developer-and-muffin-lover/file) |
| 01:47.48 | *** mode/#asterisk-bugs [+o file] by ChanServ |
| 02:42.41 | *** join/#asterisk-bugs Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 02:42.41 | *** mode/#asterisk-bugs [+o Qwell] by ChanServ |
| 02:47.31 | *** join/#asterisk-bugs file (n=file@asterisk/developer-and-muffin-lover/file) |
| 02:47.31 | *** mode/#asterisk-bugs [+o file] by ChanServ |
| 02:54.49 | *** join/#asterisk-bugs ZX81 (n=matt@202.49.106.158) |
| 04:30.20 | *** join/#asterisk-bugs implicit (n=implicit@ip68-105-92-210.sd.sd.cox.net) |
| 04:30.20 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 04:32.26 | *** part/#asterisk-bugs implicit (n=implicit@ip68-105-92-210.sd.sd.cox.net) |
| 04:59.36 | *** join/#asterisk-bugs mackes (n=root@cpe-76-180-239-199.buffalo.res.rr.com) |
| 05:03.56 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 06:15.19 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 10:29.59 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 10:33.20 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 11:03.49 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:38.48 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 12:40.29 | *** join/#asterisk-bugs De_Mon (i=de_mon@fl-71-52-101-157.dhcp.embarqhsd.net) [NETSPLIT VICTIM] |
| 12:40.29 | *** join/#asterisk-bugs JackEStorm (n=no@ip68-225-77-136.no.no.cox.net) [NETSPLIT VICTIM] |
| 12:40.30 | *** join/#asterisk-bugs Corydon76-dig (i=blue@pdpc/supporter/bronze/Corydon76-home) [NETSPLIT VICTIM] |
| 12:40.30 | *** mode/#asterisk-bugs [+o Corydon76-dig] by irc.freenode.net |
| 12:40.34 | *** join/#asterisk-bugs Qwell (i=north@pdpc/sponsor/digium/Qwell) [NETSPLIT VICTIM] |
| 12:40.34 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) [NETSPLIT VICTIM] |
| 12:40.34 | *** join/#asterisk-bugs yoman_ (n=are@89-138-132-186.bb.netvision.net.il) [NETSPLIT VICTIM] |
| 12:40.34 | *** join/#asterisk-bugs Deeewayne (i=dwayne@nat/digium/x-574b9a75e6d08d56) [NETSPLIT VICTIM] |
| 12:40.34 | *** join/#asterisk-bugs d3wayne (n=deeewayn@76.29.245.9) [NETSPLIT VICTIM] |
| 12:40.34 | *** join/#asterisk-bugs Corydon76-vcch (n=tilghman@pdpc/supporter/bronze/Corydon76-home) [NETSPLIT VICTIM] |
| 12:40.34 | *** join/#asterisk-bugs MuffinMan (n=muffins@neutrino.joshua-colp.com) [NETSPLIT VICTIM] |
| 12:40.34 | *** mode/#asterisk-bugs [+ooo Qwell Deeewayne Corydon76-vcch] by irc.freenode.net |
| 12:51.23 | *** join/#asterisk-bugs agx (n=AGX@88.34.216.63) |
| 12:52.38 | *** join/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 12:55.50 | *** join/#asterisk-bugs ivanfm (n=ivanfm@c906b486.virtua.com.br) |
| 13:06.19 | *** join/#asterisk-bugs d1mas (n=chatzill@host-99.dataart.net) |
| 13:07.57 | d1mas | Hello. Guys, do I understand correctly that if I wait couple of seconds without calling chan_zap's _read function and then after waiting will call it, I will miss the audio which was on the line during these seconds? |
| 13:11.30 | *** join/#asterisk-bugs Juggie (n=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) [NETSPLIT VICTIM] |
| 13:11.30 | *** join/#asterisk-bugs jmls (n=jmls@62.49.235.130) [NETSPLIT VICTIM] |
| 13:11.30 | *** join/#asterisk-bugs angler (i=angler@pdpc/sponsor/digium/angler) [NETSPLIT VICTIM] |
| 13:11.30 | *** join/#asterisk-bugs codefreeze (n=steve_mu@216.166.159.235) [NETSPLIT VICTIM] |
| 13:11.30 | *** join/#asterisk-bugs mvanbaak (n=mafkees@vanbaak.xs4all.nl) [NETSPLIT VICTIM] |
| 13:11.30 | *** join/#asterisk-bugs citats (n=james@mrplow.gnuinternet.com) [NETSPLIT VICTIM] |
| 13:11.31 | *** join/#asterisk-bugs Corydon76-home (i=six@pdpc/supporter/bronze/Corydon76-home) [NETSPLIT VICTIM] |
| 13:11.31 | *** mode/#asterisk-bugs [+ooo Juggie citats Corydon76-home] by irc.freenode.net |
| 13:13.00 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 13:13.00 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 13:13.44 | d1mas | If I'm right there is a big problem with that because WaitExten may do DUNDi lookups which take time and miss digits user dials during that lookup |
| 13:14.49 | russellb | you shouldn't miss any digits |
| 13:14.55 | russellb | they will be queued up .. |
| 13:15.15 | d1mas | That was my question: do audio frames on zap channels queue up ? |
| 13:15.37 | russellb | ah, ok, missed the question |
| 13:15.49 | russellb | and i don't actually know the answer to that |
| 13:16.05 | d1mas | if audio frames do NOT queue up, neither do digits |
| 13:16.36 | russellb | right |
| 13:16.37 | d1mas | this is because (if i understand correctly) digits are detected using dsp on zap_Read |
| 13:16.44 | russellb | correct |
| 13:16.56 | russellb | i'm fairly certain it would be queued up though |
| 13:17.17 | d1mas | I have situation now: when I do just "Read" - no mater how quick I dial digits they all read ok |
| 13:17.18 | russellb | you can't tell for sure by looking at chan_zap, as it just uses read() from a fd ... |
| 13:17.36 | d1mas | but if I do WaitExten I miss half of digits |
| 13:17.42 | russellb | interesting |
| 13:17.55 | d1mas | (i see dundi lookups on every digit I dial) |
| 13:18.06 | d1mas | (on every second if i dial quick) :) |
| 13:18.41 | russellb | hmm ... *looks* |
| 13:19.10 | d1mas | I'm not sure if reading chan_zap may reveal anything to me. If it reads audio frame, it does DSP, if not - not |
| 13:20.38 | russellb | right, chan_zap won't give you the answer you're looking for |
| 13:20.38 | russellb | it's inside zaptel |
| 13:20.38 | russellb | presumably it's just a pipe though |
| 13:20.50 | russellb | i'm too tired to look at zaptel right now |
| 13:21.13 | d1mas | ohohoh |
| 13:21.24 | d1mas | I see single read(... READ_SIZE) inside zt_read |
| 13:21.37 | d1mas | which means it reads single 20ms packet |
| 13:21.46 | russellb | yeah, but it should get called over and over if there is more data available |
| 13:22.14 | russellb | that's how all of the channel read callbacks work |
| 13:22.25 | russellb | well, almost all of them ... |
| 13:22.46 | d1mas | Right. But in my case there is a big pause between calls |
| 13:22.59 | russellb | that's true |
| 13:23.11 | russellb | but it should be ok :) |
| 13:23.30 | russellb | i don't claim it's not broken in some way, i'm just claiming that the code is designed to handle that |
| 13:23.33 | d1mas | Well, theoretically, audio frames should not queue up because otherwise every pause between zt_reads would introduce lag in the conversation |
| 13:23.44 | russellb | wellll, not really ... |
| 13:23.44 | d1mas | and the lag would increase over time |
| 13:24.05 | russellb | because even if you pause for a second, it will _immediately_ read that one second of audio and pass it through |
| 13:24.18 | d1mas | nonono |
| 13:24.26 | d1mas | there is READ_SIZE - it is 160 samples |
| 13:24.44 | d1mas | so the single read will not read more than that. |
| 13:24.59 | russellb | right, but zt_read could get called 10 times immediately |
| 13:25.17 | russellb | but you're right, it may just throw the audio away if it isn't read soon enough .. |
| 13:25.39 | russellb | we need to find out .. |
| 13:25.48 | russellb | you very well could be on to something :) |
| 13:26.11 | d1mas | i'm afraid so |
| 13:26.37 | russellb | hmmm ... willing to test a patch? |
| 13:26.48 | d1mas | If I'm ight I just have no idea how to fix :( The problem is in the very idea of synchronous processing |
| 13:26.59 | russellb | i have an idea ;) |
| 13:27.01 | d1mas | you have a patch? :) |
| 13:27.07 | russellb | in my head :-p |
| 13:27.10 | d1mas | no prob, will test. I have 1.4 |
| 13:27.47 | russellb | ok, let me code for a few minutes ... |
| 13:39.21 | russellb | compiling! |
| 13:44.20 | russellb | leg ... asleep ... pain ... |
| 13:46.48 | *** join/#asterisk-bugs Lasse123 (n=Lasse@int-gw.algitech.com) |
| 13:47.11 | russellb | d1mas: i probably won't be around long enough to find out what happens with this patch ... will you be around later today? |
| 13:48.02 | d1mas | russelb: sure |
| 13:48.12 | russellb | cool |
| 13:49.27 | russellb | still building ... slow laptop |
| 13:51.09 | d1mas | btw, what is the idea of the patch ? |
| 13:51.51 | russellb | let me post it, then i'll explain |
| 13:52.03 | russellb | guess i can just pastebin it |
| 13:52.14 | d1mas | ok |
| 13:53.05 | russellb | http://pastebin.ca/raw/797982 |
| 13:53.16 | russellb | there is a big set of unrelated comment changes to channel.h in there ... |
| 13:53.23 | russellb | but it happened to be in my working copy |
| 13:53.53 | russellb | so, the idea is ... |
| 13:53.55 | d1mas | oh :) I see :) |
| 13:54.22 | russellb | 1) we need to make sure we keep calling ast_read() on the channel, even though the code is off doing something else (DUNDi lookup) |
| 13:54.27 | russellb | autoservice is exactly what that is for |
| 13:54.37 | d1mas | Coool |
| 13:54.39 | russellb | howerver, autoservice did not do anything to keep special frames around |
| 13:54.53 | russellb | so i modified autoservice to be able to save dtmf frames for when autoservice gets stopped |
| 13:54.57 | russellb | to make sure they get handled |
| 13:55.18 | d1mas | Autoservice is the thing I was looking at before going to IRC, but the /* Read and ignore anything that occurs */ comment scared me :) |
| 13:55.25 | russellb | if/when i go to commit this, i think i'm going to change it to _always_ do this in autoservice, and not just for dtmf frames |
| 13:55.34 | russellb | i think it should be saving _all_ non-media frames no matter what |
| 13:55.41 | russellb | but this patch will test the theory |
| 13:55.42 | russellb | :) |
| 13:56.05 | d1mas | right, also not only WaitExten is affected by this |
| 13:56.13 | russellb | correct |
| 13:56.26 | russellb | that's what you're using though, right |
| 13:56.27 | russellb | ? |
| 13:56.51 | d1mas | no, I use DISA, but it doesn't really matter |
| 13:57.15 | russellb | well, it does matter, because this patch won't make a difference if you're using disa |
| 13:57.17 | d1mas | I mean the problem was found with DISA when users started complaining |
| 13:57.25 | d1mas | I know :) |
| 13:57.35 | d1mas | I will test patch with WaitExten :) |
| 13:57.51 | russellb | ok, test waitexten without it too, to make sure |
| 13:58.02 | d1mas | already did :) |
| 13:58.07 | russellb | ha, gooood |
| 13:58.12 | d1mas | I would not stating it is broken otherwise :) |
| 13:58.20 | russellb | heh |
| 13:58.33 | russellb | i'm half awake in an airport, give me a little slack :) |
| 13:59.13 | d1mas | omg |
| 13:59.29 | d1mas | sorry for bothering you with this stuff then :) |
| 13:59.46 | russellb | np .. |
| 13:59.54 | russellb | 'tis my job |
| 14:00.05 | russellb | and i enjoy it |
| 14:00.44 | d1mas | Ok, so you want me to test it already or you want to fix anything in your patch ? |
| 14:01.12 | russellb | nah, go ahead and test it |
| 14:01.21 | d1mas | 10 min |
| 14:02.06 | d1mas | ugh... did not apply. looking at it |
| 14:03.02 | russellb | really? it was against 1.4 ... |
| 14:03.18 | russellb | latest 1.4 |
| 14:05.01 | d1mas | hm. will updat. i have version SVN approximately at the time when 1.4.14 was released |
| 14:05.04 | d1mas | updating |
| 14:05.32 | d1mas | nope. does not apply to latest 1.4 |
| 14:05.45 | russellb | time to board my flight ... i'll be back on later today |
| 14:05.47 | russellb | good luck :) |
| 14:05.57 | d1mas | have a good flight! thanks |
| 14:05.59 | russellb | email me with results if you run off ... russell@digium.com |
| 14:06.03 | d1mas | sure |
| 14:39.50 | *** join/#asterisk-bugs mackes (n=root@65-121-253-83.dia.static.qwest.net) |
| 14:45.18 | *** join/#asterisk-bugs putnopvut (i=putnopvu@nat/digium/x-2450276ed395e944) |
| 14:45.18 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 15:06.21 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:06.22 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 15:35.47 | file | codefreeze: status? |
| 15:39.44 | codefreeze | file: present and accounted for? |
| 15:40.22 | file | what'cha up to? |
| 15:40.55 | codefreeze | almost 5' 11" (sorry, don't know it in metric) |
| 15:45.30 | blitzrage | sounds like about 190cm's |
| 15:48.53 | codefreeze | file: had a fun weekend/holiday, how about you? |
| 15:49.05 | file | it was gooooood |
| 15:49.34 | file | but we are overrun with bugs, therefore it would be extremely appreciated if you could knock out some of those assigned to you... some just need a simple yay and commit or nay |
| 15:50.15 | codefreeze | file: okeydoke. bugs it is. |
| 15:51.06 | blitzrage | M11346 |
| 15:51.06 | MuffinMan | [closed] [Zaptel] wct4xxp 0011346: VPM450: Failed to initialize reported by ars888 http://bugs.digium.com/view.php?id=11346 |
| 15:51.10 | blitzrage | oops |
| 15:51.19 | *** join/#asterisk-bugs kpfleming (i=kpflemin@nat/digium/x-581d095c30e0be35) |
| 15:51.19 | *** mode/#asterisk-bugs [+o kpfleming] by ChanServ |
| 15:51.19 | blitzrage | M11349 |
| 15:51.20 | MuffinMan | [new] [Asterisk] Functions/func_channel 0011349: [patch] Deprecate SIPPEER() and move functionality into CHANNEL() reported by blitzrage http://bugs.digium.com/view.php?id=11349 |
| 15:51.26 | blitzrage | that may or may not be easy to commit... ? |
| 15:51.52 | blitzrage | someone tell me if that is the right way of going about it, and I'll do IAXPEER() as well if wnated |
| 15:53.32 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 15:54.07 | file | blitzrage: I think I spot a logic flaw... it's possible for it to not get called for peer info purposes, so your find_peer would probably be unhappy under those circumstances |
| 15:54.31 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:54.48 | blitzrage | file: oh I see -- so that should go into the sip_peerinfo block and only be used there? |
| 15:55.01 | file | that is what I would do |
| 15:55.04 | blitzrage | makes sense |
| 15:55.08 | blitzrage | I'll fix it! |
| 16:04.50 | *** join/#asterisk-bugs Corydon76-lap (i=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:04.50 | *** mode/#asterisk-bugs [+o Corydon76-lap] by ChanServ |
| 16:16.05 | codefreeze | hmmm. Cam |
| 16:16.12 | codefreeze | try that again |
| 16:16.40 | codefreeze | hmmmmm. Can't build in trunk. it's choking on RAND_MAX+1... integer overflow... |
| 16:16.56 | file | oh goody |
| 16:17.11 | file | 32-bit MADNESS |
| 16:17.24 | codefreeze | conditional on DEV_URANDOM |
| 16:17.26 | *** join/#asterisk-bugs russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:17.27 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 16:17.35 | file | yeah I know what it is |
| 16:17.55 | codefreeze | What if... we just remove the +1? |
| 16:18.33 | file | reverted |
| 17:08.22 | Qwell | codefreeze: with the +1 removed, it'll be slightly less random - giving 2 a slightly higher chance of coming up, than any other number |
| 17:08.37 | Qwell | and 1, I guess |
| 17:08.44 | Qwell | and maybe 0 |
| 17:09.07 | Qwell | (infinitesimally small percentage) |
| 17:10.04 | Qwell | .0000001%? something |
| 17:12.04 | codefreeze | OK, how about a -1 instead of +1? Same affect? |
| 17:12.20 | Qwell | yeah, except then you add weight to 0-4 |
| 17:12.51 | Qwell | so, let's take small numbers as an example |
| 17:12.59 | Qwell | let's say RAND_MAX is 7 |
| 17:13.42 | Qwell | if you do a % on RAND_MAX, when the number is, say...16 |
| 17:13.48 | Qwell | you end up with 2 |
| 17:14.11 | Qwell | if RAND_MAX were at a boundary (8), you'd be okay |
| 17:15.40 | Qwell | hopefully I'm making some sense, heh. I'm not sure I am |
| 17:19.36 | codefreeze | Qwell: I may not get the picture in detail, but I think I have it in general. |
| 17:23.44 | *** join/#asterisk-bugs dlynes (n=chatzill@d154-20-45-103.bchsia.telus.net) |
| 17:45.59 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 17:58.33 | *** join/#asterisk-bugs umay (n=chris@71-208-162-10.hlrn.qwest.net) |
| 18:04.00 | umay | i would like to discuss 11379 |
| 18:04.03 | umay | just opened it |
| 18:04.46 | umay | what patch along the way broke this |
| 18:05.31 | file | M11379 |
| 18:05.31 | MuffinMan | [assigned] [Asterisk] CDR/General 0011379: 1.4.14 breaks cdr posting reported by cmaj http://bugs.digium.com/view.php?id=11379 |
| 18:05.54 | file | it was a behavior change if I remember correctly to not leave CDRs for unanswered calls in a Dial attempt or some sort... |
| 18:06.22 | umay | doesnt sound like a bug fix |
| 18:12.04 | Corydon76-lap | The bug fix was specifically to fix some duplicate CDRs in a certain situation |
| 18:12.37 | Corydon76-lap | It's assigned to murf (codefreeze) because he committed the fix |
| 18:13.54 | umay | 10659 |
| 18:13.59 | codefreeze | yes, I promised someone that I'd make the single-channel cdr dropping optional. I guess it's time to do that, and look at this 11379 |
| 18:14.57 | umay | so was the majority pleased by this change ? |
| 18:15.34 | codefreeze | you know, that's the hardest part of this job..... |
| 18:15.44 | codefreeze | making out who the majority is, that is. |
| 18:16.11 | codefreeze | All I know, is I was getting endless complaints about the stupid excess cdrs. |
| 18:16.36 | codefreeze | So, when I cut them out, now I'm getting endless complaints about that. So, option it is. |
| 18:17.16 | umay | if it didnt generate a NOTICE, then i would probably have missed it |
| 18:17.36 | codefreeze | And, if I'm really, really, wildly lucky, maybe I can find a sure-fire way to tell the diff between a no-answer and... and... oh, forget it. |
| 18:17.47 | file | those who are happy do not make a sound, those who are happy do - so either way the result is the same... endless complaints, thus option go go go |
| 18:18.05 | codefreeze | oh, that notice. Yes. I agree. Really irritating. |
| 18:18.20 | umay | it just looks like i am losing cdrs |
| 18:18.25 | umay | which is very bad |
| 18:19.05 | codefreeze | heh, heh... ignorance is bliss? |
| 18:19.34 | umay | that would be the easy way out |
| 18:45.31 | *** join/#asterisk-bugs oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:46.21 | codefreeze | Bang! An idea hit me like a wet sock. Hard and sort of sticky. |
| 18:47.00 | blitzrage | although the sticky part makes me squeemish |
| 18:47.25 | codefreeze | I've been attacking the problem from the wrong end! and no, blitzrage, I don't think that it's water... ugh! |
| 18:47.34 | blitzrage | lol |
| 18:47.42 | blitzrage | developers have a sick sense of humour |
| 18:47.48 | blitzrage | maybe that's why I get along with you guys so well |
| 19:00.55 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:08.32 | Corydon76-lap | russellb: ping |
| 20:08.52 | Corydon76-lap | M11217 |
| 20:08.52 | MuffinMan | [feedback] [Asterisk] Channels/chan_mgcp 0011217: DLCX verb not recgonized reported by mattv http://bugs.digium.com/view.php?id=11217 |
| 20:09.50 | Corydon76-lap | The Flash app is currently hardcoded to Zap. Do you think it's worth it to make the hookflash into a channel API? |
| 20:10.11 | Corydon76-lap | because MGCP needs a way to signal it, too |
| 20:45.51 | russellb | Corydon76-dig: sounds reasonable ... should probably be a CONTROL frame |
| 20:46.06 | Corydon76-lap | Ah |
| 20:46.12 | russellb | IMO .. |
| 20:46.34 | russellb | i would still do a check for if Zap || MGCP so we can log a message to say that it's not going to take effect otherwise |
| 20:47.13 | Corydon76-lap | I'd take out the warning altogether and just document that some channels implement it and some don't |
| 20:47.52 | russellb | well it's nice to know exactly which support it :) |
| 20:48.11 | Corydon76-lap | Yeah, but potentially others will in the future, too |
| 20:48.29 | Corydon76-lap | and changing the warning each time is bad design. ;-) |
| 20:49.23 | russellb | but it's exactly two ... and unlikely to change _any_ time soon |
| 20:49.31 | russellb | and it's obviously better than leaving it up for guesses |
| 20:49.45 | russellb | saying Zap and MGCP and leaving out BLAH is better than saying "some do" |
| 20:53.44 | Corydon76-lap | Hmmm |
| 21:18.37 | *** join/#asterisk-bugs infobot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 21:18.37 | *** topic/#asterisk-bugs is Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - Asterisk 1.4.13 has been released (October 10, 2007). -=- If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Goodbye 1.2. We'll miss you. Maybe. -=- Overall bug count: 328. Progress continues to be made. Drinks are on file! |
| 22:28.29 | putnopvut | M11345 |
| 22:28.30 | MuffinMan | [new] [Asterisk] Applications/app_playback 0011345: [patch] Don't try say number after hungup (new style) reported by IgorG http://bugs.digium.com/view.php?id=11345 |
| 22:29.02 | putnopvut | What is the "new style" of SayNumber? |
| 22:29.28 | Corydon76-lap | There's a say.conf activated by app_playback |
| 22:29.37 | Corydon76-lap | Why it was added there, I'll never know |
| 22:31.21 | putnopvut | I guess I still don't know what this means, then? What is "old style"? |
| 22:35.46 | putnopvut | Okay, now I see. Nevermind. |
| 22:53.03 | *** part/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |