| 02:06.15 | *** join/#asterisk-bugs ZX81 (n=ZX81@202.20.97.211) |
| 02:56.28 | *** join/#asterisk-bugs infobot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 02:56.28 | *** topic/#asterisk-bugs is Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Overall issue count: 286 -=- Monitor new reports in #asterisk-commits -=- Test bugs marked Ready For Testing -=- Mantis happy now. |
| 05:39.30 | *** join/#asterisk-bugs bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 05:39.30 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 05:47.50 | *** join/#asterisk-bugs implicit (n=implicit@200.12.227.181) |
| 05:47.50 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 05:58.42 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 06:02.17 | *** join/#asterisk-bugs fakhir_ (n=fakhir@unaffiliated/fakhir) |
| 08:53.11 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 10:57.35 | *** join/#asterisk-bugs jmls (n=jmls@mail.tessera.co.uk) |
| 12:09.26 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:37.18 | *** join/#asterisk-bugs agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 12:38.12 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:38.12 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 12:55.18 | *** join/#asterisk-bugs jsmith (n=jsmith@142.131.189.26) |
| 12:55.18 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 13:14.12 | *** join/#asterisk-bugs jsmith (n=jsmith@142.131.189.26) |
| 13:14.12 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 13:19.30 | *** join/#asterisk-bugs dsfr (n=dsfr@pdpc/sponsor/digium/dsfr) |
| 13:34.26 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 13:34.26 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 13:46.03 | *** join/#asterisk-bugs mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 14:18.09 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:18.09 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 15:01.08 | *** join/#asterisk-bugs elguero (n=elguero@207.154.34.162) |
| 15:01.46 | file | Corydon76-dig / Corydon76-vcch: are you... there? |
| 15:01.55 | Corydon76-dig | Of course |
| 15:02.05 | file | M12252 |
| 15:02.06 | MuffinMan | [new] [Asterisk] Channels/chan_sip/General 0012252: Deadlock in chan_sip reported by callguy http://bugs.digium.com/view.php?id=12252 |
| 15:02.07 | Corydon76-dig | -vcch only on Thursdays |
| 15:02.30 | file | I suspect you caused that... with this... |
| 15:02.34 | file | A103780 |
| 15:02.36 | *** join/#asterisk-bugs angler (n=angler@pdpc/sponsor/digium/angler) |
| 15:02.37 | MuffinMan | [103780] Committed by tilghman on 2008-02-18 13:31:52: When a SIP channel is being auto-destroyed, it's possible for it to still be |
| 15:04.19 | file | if it was channel locking it would show up in the csl, but your loop would not |
| 15:06.11 | file | thought(s)? |
| 15:08.24 | file | wonders what would happen if iflock was unlocked prior to the usleep and locked afterwards |
| 15:08.49 | Corydon76-dig | Is iflock called prior to __sip_destroy ? |
| 15:08.58 | file | nods |
| 15:09.42 | Corydon76-dig | That's dangerous... the pvt could disappear out from under us |
| 15:10.24 | Corydon76-dig | I think we'd need to simply return at that point with an error code |
| 15:10.37 | Corydon76-dig | EAGAIN, basically |
| 15:11.53 | file | so instead of looping around, we could schedule dialog destruction |
| 15:12.23 | Corydon76-dig | Well, it's already scheduled. Technically, we could be getting called from the scheduler |
| 15:12.43 | file | there are cases where we would not |
| 15:14.32 | Corydon76-dig | That's true |
| 15:15.52 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:15.52 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 15:16.07 | file | Corydon76-dig: want to take it? |
| 15:16.28 | Corydon76-dig | Sure |
| 15:16.32 | file | aight |
| 15:32.06 | *** join/#asterisk-bugs miguel3239 (n=elguero@207.154.34.162) |
| 15:45.58 | *** join/#asterisk-bugs Yourname`` (n=chatzill@unaffiliated/yourname/x-837320) |
| 15:46.26 | Yourname`` | Hi putnopvut, I'm sorry I didn't know it came up as a bug. I was aware that it would be a feature request; so put it under 'feature' for severity. |
| 15:47.05 | putnopvut | Yourname``: right, the policy is that if you were going to submit a feature, it needs to have a patch. |
| 15:47.23 | Yourname`` | Ah.. |
| 15:47.26 | putnopvut | The problem with what you're asking for is that it would require pretty much a rewrite of app_queue to be done. |
| 15:47.36 | Yourname`` | Wow! |
| 15:47.45 | Yourname`` | So it won't make sense to come in as 1.4. |
| 15:47.49 | Yourname`` | Probably 1.6? |
| 15:47.57 | putnopvut | Yourname``: yeah, 1.6 at some point. |
| 15:48.15 | Yourname`` | Makes sense. |
| 15:48.22 | Yourname`` | But don't you think it's a good feature tho? |
| 15:48.41 | putnopvut | Yeah, the problem comes down to the way queue members and callers are matched. |
| 15:49.11 | putnopvut | What would be great is if, as soon as a member became available, an event was sent which could interrupt whatever the caller is currently doing and connect the two... |
| 15:49.36 | Yourname`` | Yeah, that sounds good. |
| 15:49.39 | putnopvut | But right now it doesn't work that way. The caller sees if there are members available, and if not, then it goes into the uninterruptable announcement messages and such. |
| 15:49.43 | Juggie | file, how much subway would i have to bribe you with to write me a ~100 line function? :) |
| 15:49.44 | Yourname`` | So you'll end up creating some new event for that? |
| 15:49.55 | file | Juggie: uh, that does what? |
| 15:50.00 | Yourname`` | putnopvut: ah |
| 15:50.19 | Yourname`` | Seems complicated alright. This almost sounds like a rewrite done for autofill |
| 15:50.52 | Juggie | basically a copy of pbx_substitute_variables_helper_full except it using ast_str. |
| 15:50.59 | putnopvut | autofill would be much more reliable in an event-based queue. |
| 15:51.29 | file | Juggie: I decline. |
| 15:51.53 | Juggie | :( how about if i make it subway & muffins? :P |
| 15:52.21 | Corydon76-dig | Juggie: you're finding it daunting? |
| 15:52.25 | file | nope. |
| 15:52.44 | Juggie | Corydon76-dig, its a bit of a convoluted function yeah. |
| 15:56.19 | Juggie | its doing alot so i'm just trying to wrap my head around it.. but its not that clear :) |
| 16:00.17 | *** join/#asterisk-bugs Yourname`` (n=chatzill@unaffiliated/yourname/x-837320) |
| 16:00.24 | Yourname`` | Sorry about that putnopvut |
| 16:00.52 | putnopvut | Yourname``: it's all right :) |
| 16:01.34 | Yourname`` | I have one devel kind of question though, which hasn't been answered by ANYBODY in more than a week, and I don't understand why.. |
| 16:01.53 | Yourname`` | If someone will be kind enough to look at it once, that'd be dandy. |
| 16:02.15 | Yourname`` | http://lists.digium.com/pipermail/asterisk-users/2008-March/207890.html |
| 16:06.30 | Corydon76-dig | This is not a support channel |
| 16:09.00 | *** join/#asterisk-bugs jmls (n=jmls@mail.tessera.co.uk) |
| 16:25.35 | *** join/#asterisk-bugs seanbright (i=seanbrig@65.207.74.18) |
| 16:35.33 | *** join/#asterisk-bugs implicit (n=implicit@200.12.227.181) |
| 16:35.33 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 16:59.02 | file | pokes putnopvut |
| 16:59.15 | *** join/#asterisk-bugs Deeewayne (n=dwayne@216.207.245.1) |
| 16:59.15 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 17:00.19 | putnopvut | file: what's up? |
| 17:00.25 | file | M10487 |
| 17:00.27 | MuffinMan | [feedback] [Asterisk] Applications/app_voicemail 0010487: IMAP integration with MS Exchange crashes Asterisk-1.4.10.1 reported by ewilhelmsen http://bugs.digium.com/view.php?id=10487 |
| 17:00.31 | file | I remember you mentioning that sometime... |
| 17:02.19 | putnopvut | Oh, that. |
| 17:02.42 | file | it is coming up on my list. |
| 17:02.50 | putnopvut | I was considering giving it the boot. |
| 17:03.06 | *** join/#asterisk-bugs elguero (n=elguero@207.154.34.162) |
| 17:03.09 | file | well there hasn't been much reply about your timeout query |
| 17:03.18 | putnopvut | Yeah... |
| 17:03.47 | file | it is up to you :D |
| 17:04.00 | putnopvut | I'll contemplate it. |
| 17:12.05 | *** join/#asterisk-bugs jmls_work (n=jmls@mail.tessera.co.uk) |
| 17:22.43 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 18:43.59 | Yourname`` | http://lists.digium.com/pipermail/asterisk-users/2008-March/207890.html -> Can someone please look at this and help me out? |
| 18:54.25 | russellb | i'm not sure what that is because i haven't lookecdx |
| 18:54.29 | russellb | but this is not a technical support channel |
| 18:54.41 | russellb | unless you're referring to a bug on the bug tracker, please don't bring it up here |
| 19:00.37 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:34.08 | file | M10058 |
| 20:34.11 | MuffinMan | [assigned] [Asterisk] Channels/chan_sip/Interoperability 0010058: Asterisk rfc2833 DTMF fails with SIP service providers reported by tracinet http://bugs.digium.com/view.php?id=10058 |
| 20:34.12 | file | the fix for that bothers me :( |
| 20:35.54 | *** part/#asterisk-bugs jmls_work (n=jmls@mail.tessera.co.uk) |
| 20:40.24 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 20:41.15 | d1mas | Hello. Some time ago I have reised a question on -dev list. ( http://lists.digium.com/pipermail/asterisk-dev/2007-December/031178.html ) Can someone please explain the design? |
| 21:06.42 | d1mas | ... |
| 21:08.09 | Corydon76-dig | d1mas: I don't understand your complaint |
| 21:08.30 | d1mas | corydon76: i'm not complaining, I'm asking... |
| 21:08.33 | Corydon76-dig | Is it "let's change something because we can" or what? |
| 21:09.00 | Corydon76-dig | You asked how it worked, and then you explained how it worked. |
| 21:09.06 | d1mas | corydon76: it is more lets change something because it makes things more logical |
| 21:09.10 | Corydon76-dig | So you answered your own question |
| 21:09.18 | d1mas | I asked WHY it works this way |
| 21:09.28 | Corydon76-dig | Because it works |
| 21:10.21 | d1mas | next time you can shorten you answer to just "because". |
| 21:10.23 | Corydon76-dig | Your idea isn't any more logical. You could say it's more organized, but it's perfectly logical now |
| 21:10.25 | d1mas | not a much difference |
| 21:10.55 | Corydon76-dig | We have an idiom in English. "If it ain't broke, don't fix it." |
| 21:11.05 | d1mas | I know this one |
| 21:11.18 | Corydon76-dig | Yeah. It works. Don't fix it. |
| 21:11.20 | d1mas | but from my perspective it IS broken. |
| 21:11.39 | d1mas | the Read does not pick ups digit pressed during Background |
| 21:11.40 | mvanbaak | so fix it |
| 21:11.41 | Corydon76-dig | Describe what it does that is unexpected, from a performance perspective |
| 21:12.14 | Corydon76-dig | That's because Background doesn't refer to the audio, it refers to the digits |
| 21:12.29 | d1mas | sorry? |
| 21:12.40 | Corydon76-dig | It's a common misunderstanding of what Background does |
| 21:12.58 | Corydon76-dig | Background and Read were never meant to be used together |
| 21:12.59 | d1mas | well, it plays something and stops when digit pressed |
| 21:13.08 | mvanbaak | uhhuh |
| 21:13.12 | mvanbaak | that's correct |
| 21:13.24 | mvanbaak | you have to use Background and WaitForDigit together |
| 21:13.36 | mvanbaak | waitexten or something |
| 21:13.43 | Corydon76-dig | Background and WaitExten |
| 21:13.53 | mvanbaak | there |
| 21:13.55 | Corydon76-dig | Read is entirely different |
| 21:14.27 | Corydon76-dig | Background and WaitExten are built to receive a new extension. Read is built to continue in the current extension. |
| 21:14.37 | d1mas | but the problem is - you can not play something really long and read digits at the end |
| 21:14.47 | Corydon76-dig | Sure you can |
| 21:15.02 | Corydon76-dig | Just make one long prompt and use Read on that single prompt |
| 21:15.03 | d1mas | you can do background(xxx&yyy&zzz)+ReadExten |
| 21:15.12 | d1mas | but you can not do that wt Read |
| 21:15.18 | Corydon76-dig | Sure you can |
| 21:15.20 | d1mas | because read does not let you put &. |
| 21:15.23 | d1mas | hmm |
| 21:15.37 | Corydon76-dig | Read(var,somereallylongpromptthatgoesonfor5minutes) |
| 21:15.42 | Qwell | so... |
| 21:15.48 | Qwell | what IS the point of Background? |
| 21:15.57 | Qwell | it's just Read+Goto |
| 21:16.10 | Corydon76-dig | Qwell: same as WaitExten, except that it plays a sound in the background |
| 21:16.26 | Qwell | Read could be considered as "in the background" |
| 21:16.37 | Qwell | though I guess background exits once the prompt is done |
| 21:16.45 | mvanbaak | yup, it does |
| 21:16.47 | Corydon76-dig | WaitExten could be reimplemented as Background, with a length of silence |
| 21:16.48 | d1mas | Corydon76: in in this case I will need to concatenate individual prompts to create single file |
| 21:16.54 | Qwell | it seems pretty silly to have all of these |
| 21:17.10 | Qwell | d1mas: well, Read could be improved to support & |
| 21:17.14 | Qwell | it may already in trunk |
| 21:17.20 | Corydon76-dig | Qwell: they're built on completely different uses of Asterisk |
| 21:17.33 | Qwell | yep, supports & in trunk already |
| 21:17.53 | Corydon76-dig | Background/playback/waitexten are all on the extension-based use of Asterisk. Read is about an IVR system |
| 21:18.10 | Qwell | playback has no idea of extensions |
| 21:18.20 | d1mas | qwell: I agree. This is one of way to fix things |
| 21:18.24 | Corydon76-dig | Okay, fair enough |
| 21:18.50 | Qwell | but, background+waitexten isn't really possible, is it? what if they press 1 during the prompt, and then 234 after the prompt (inside the waitexten)? |
| 21:19.05 | Qwell | or, rather, what *should* be the waitexten. |
| 21:19.12 | Qwell | would it not already try to goto extension 1? |
| 21:19.13 | Corydon76-dig | Qwell: if they press a digit during the Background, then they never execute the WaitExten |
| 21:19.18 | Qwell | right |
| 21:19.19 | d1mas | qwell: I believe waitexten won't be executed in this case |
| 21:19.30 | Qwell | so, how is background useful? :) |
| 21:19.35 | d1mas | qwell: as background returns nonzero, pbx core will read the rest |
| 21:20.00 | Qwell | I guess at that point, you're just relying on inter-digit timeout.. |
| 21:20.02 | Qwell | ugh |
| 21:20.05 | Corydon76-dig | Qwell: actually, you should be asking how WaitExten is useful |
| 21:20.16 | Corydon76-dig | Qwell: since Background does more than WaitExten |
| 21:20.20 | Qwell | Corydon76-dig: playback+waitexten I can see being useful |
| 21:20.33 | Qwell | but, really, even then...just use Read |
| 21:20.37 | Corydon76-dig | Qwell: but playback doesn't let you collect digits |
| 21:20.51 | Qwell | neither do a lot of IVRs during prompt playback |
| 21:20.54 | Corydon76-dig | You press a digit during Playback, and the digit is lost |
| 21:21.05 | Qwell | and it pisses me off every time it happens :P |
| 21:21.26 | Corydon76-dig | Heh |
| 21:21.30 | Qwell | "Press 1 for English, "*1* "or 2 for .." |
| 21:21.38 | Qwell | *1* "or 3 for .." |
| 21:21.40 | Corydon76-dig | So the lesson is, use the tools to concatenate your prompts together |
| 21:21.57 | Corydon76-dig | ulaw and gsm, you can just use cat |
| 21:22.09 | Qwell | all of these apps can use & |
| 21:22.16 | Corydon76-dig | Sure, now |
| 21:22.37 | d1mas | well.... |
| 21:22.44 | d1mas | you not always can concatenate |
| 21:22.53 | Corydon76-dig | Sure you can |
| 21:22.57 | Qwell | and you certainly don't always want to |
| 21:23.00 | d1mas | I mean you can do, but it will make dialplan ugly |
| 21:23.07 | d1mas | let me explain |
| 21:23.13 | Corydon76-dig | The only time you can't is with files with headers |
| 21:23.32 | Corydon76-dig | You've already lost the argument on 'ugly' |
| 21:23.53 | d1mas | you have greeting A and them B immediately follow. Then user enters something. And if input is incorrect, you tell this to user and repeat with greeting B |
| 21:24.21 | d1mas | each A and B are quite long constructed from several "primitive" prompts |
| 21:24.26 | mvanbaak | simply use playback for A and background for B |
| 21:24.41 | Qwell | but then the digit is lost |
| 21:24.45 | Corydon76-dig | mvanbaak: not always an option |
| 21:24.54 | d1mas | mvanbaak: not really a good idea. A is long and user who knows things wants to skip it |
| 21:25.05 | Corydon76-dig | mvanbaak: some customers want their customers to be able to shortcircuit the system |
| 21:25.08 | mvanbaak | then use background :) |
| 21:25.23 | d1mas | mvanbaak: ... which does not work with Read :) |
| 21:25.30 | mvanbaak | so use waitexten ;) |
| 21:25.43 | Qwell | then it can't be short-circuited |
| 21:25.50 | mvanbaak | it can |
| 21:25.58 | Corydon76-dig | or concatenate the two prompts together and play it back with Read or Background, your choice, depending upon the mode in which you want to use Asterisk |
| 21:26.16 | mvanbaak | look, if you only have 4 digit extensions |
| 21:26.33 | mvanbaak | nad a user presses 1 during background, and 234 during waitexten, it will go to 1234 |
| 21:26.34 | d1mas | mvaanbaak: use waitexten for reading a PIN code or something? I'm sure it can be done, but isn't it a pervert way? |
| 21:27.07 | mvanbaak | d1mas: ah, reading a pin is something different then what I use background/waitexten for |
| 21:27.18 | mvanbaak | for that you should use read |
| 21:27.25 | Corydon76-dig | d1mas: end result is that no, nothing will be changed. |
| 21:27.34 | mvanbaak | read puts the digits in a variable |
| 21:27.50 | mvanbaak | background+waitexten will automagically jump to the exten given |
| 21:28.03 | d1mas | mvanbaak: I know the difference |
| 21:28.23 | Corydon76-dig | I think this discussion has morphed beyond pointless at this point |
| 21:28.28 | mvanbaak | lol |
| 21:28.29 | mvanbaak | yeah |
| 21:28.37 | d1mas | mvanbaak: the problem is that I will have to create really cumbersome dialplan and concatenate multiple prompts together into single file to achieve result |
| 21:29.29 | d1mas | well, the original question was why pbx _core_ should bother in collecting digits and doing a jump when application can do it |
| 21:30.30 | Corydon76-dig | autofallthrough=no |
| 21:35.38 | d1mas | just curious how many people have this setting |
| 21:58.08 | Corydon76-dig | Most people on 1.2. Everybody still on 1.0 |
| 21:58.36 | Corydon76-dig | and when they upgrade, they won't want to change it for fear of breaking their dialplans |
| 22:00.39 | d1mas | I bet you will deprecate this option sooner or later |
| 22:02.14 | d1mas | (because it can be easily replaced with just a modification of dialplan) |
| 22:11.53 | Corydon76-dig | Doubtful |
| 22:31.18 | mvanbaak | wow |
| 22:31.28 | mvanbaak | posting a small comment on a bug just took 12 minutes |
| 22:32.07 | mvanbaak | from the moment I hit 'Add Note' till the moment I saw the confirmation page |
| 22:36.48 | putnopvut | I wonder if China is DOSing the site again. |
| 22:37.05 | Yourname`` | Is there a document somewhere that says how Asterisk interprets SIP error codes and classifies them as reason 0, 1, 2 or what? |
| 22:37.07 | mvanbaak | ok, time to get some sleep |
| 22:37.22 | Corydon76-dig | There is no document, no |
| 22:37.37 | mvanbaak | it will be a good sleep, now that multiparking is nearing completion |
| 22:37.40 | Corydon76-dig | but it's easy enough to find in the SIP source |
| 22:37.49 | Yourname`` | So, if I want to record disconnected numbers in Asterisk, I wouldn't be able to? |
| 22:37.51 | Yourname`` | Ahh.. |
| 22:38.00 | russellb | putnopvut: site is responsive to me |
| 22:38.28 | mvanbaak | russellb: the site is, but posting new data to it took a long time |
| 22:38.32 | Corydon76-dig | Not responsive to me, but then again, I'm in the middle of another asterisk-sound release |
| 22:38.34 | mvanbaak | browsing it is fast |
| 22:38.48 | Yourname`` | Sometimes a SIP 404 Not Found gets classified as "Call failed, reason 0" or "Call failed, reason 8" |
| 22:39.09 | Yourname`` | Which is confusing because I wonder what makes Asterisk classify the same SIP error code into two different reasons |
| 22:39.14 | Corydon76-dig | So I'm probably using a good amount of Digium bandwidth |
| 22:39.48 | Corydon76-dig | Yourname``: two different places in the code, two different methods |
| 22:40.05 | Yourname`` | Even if one SIP error code triggers it? |
| 22:40.14 | russellb | #asterisk-bugs != support forum |
| 22:40.23 | Corydon76-dig | Depends on the response |
| 22:40.41 | Yourname`` | Ok, ok.. |
| 23:36.41 | *** join/#asterisk-bugs jmls_work (n=jmls@mail.tessera.co.uk) |
| 23:37.11 | *** join/#asterisk-bugs seanbright-home (n=seanbrig@c-69-251-175-43.hsd1.md.comcast.net) |