| 00:16.00 | Entomologist | *** CLOSED (14388) [PBX/General] "dialplan show globals" does not show the correct TRUNKMSD setting |
| 00:16.01 | Entomologist | Reported by: macli Karma: 0 |
| 00:16.01 | Entomologist | http://bugs.digium.com/view.php?id=14388 |
| 00:16.01 | Entomologist | ********************************************************* |
| 00:39.31 | *** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim) |
| 01:48.32 | lmadsen | Corydon76-dig: ping! |
| 01:48.36 | lmadsen | M14387 |
| 01:48.38 | MuffinMan | [new] [Asterisk] Resources/res_musiconhold 0014387: mpg123 crashes when trying to play stream. reported by jonnt (Karma: +0.50) http://bugs.digium.com/view.php?id=14387 |
| 01:48.39 | lmadsen | have at it :) |
| 01:51.20 | adr|an | ping ponk |
| 01:51.22 | adr|an | :) |
| 01:51.25 | adr|an | hello |
| 01:53.12 | lmadsen | howdy! |
| 01:54.53 | adr|an | how knows who can i configure my Tribox to send SMS to mobile ? |
| 01:55.12 | lmadsen | see #trixbox |
| 01:55.23 | adr|an | okay thanks |
| 01:55.41 | adr|an | y will try... wish me luck :D |
| 01:56.01 | lmadsen | either way, this is not the room you are looking for :) |
| 01:57.25 | adr|an | :) |
| 01:57.45 | adr|an | on tribox |
| 01:57.53 | adr|an | all the people sleep right now:) |
| 01:59.17 | lmadsen | adr|an: ok :) |
| 01:59.34 | lmadsen | you can try #asterisk, but they are just going to tell you to go to #trixbox |
| 02:46.05 | *** join/#asterisk-bugs blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:46.05 | *** mode/#asterisk-bugs [+o blitzrage] by ChanServ |
| 03:09.35 | *** join/#asterisk-bugs adr|an (n=xpl@unaffiliated/adrianxxx) |
| 03:11.16 | *** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 03:11.16 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 06:41.53 | *** join/#asterisk-bugs De_Mon (i=de_mon@fl-67-77-166-5.dyn.embarqhsd.net) |
| 06:57.49 | *** join/#asterisk-bugs De_Mon (i=de_mon@fl-67-77-166-5.dyn.embarqhsd.net) |
| 07:35.58 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 09:16.20 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 11:20.16 | *** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim) |
| 12:19.39 | *** join/#asterisk-bugs guaxinim (n=guaxinim@unaffiliated/guaxinim) |
| 13:36.11 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:36.11 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 13:36.46 | lmadsen | salutations! |
| 13:51.12 | Entomologist | *** CLOSED (14347) [Channels/chan_sip/Transfers] Transfer executes callers channel in wrong context |
| 13:51.12 | Entomologist | Assigned to: putnopvut |
| 13:51.12 | Entomologist | Reported by: alesz Karma: 0 |
| 13:51.12 | Entomologist | http://bugs.digium.com/view.php?id=14347 |
| 13:51.12 | Entomologist | ********************************************************* |
| 13:53.22 | lmadsen | oops... might either need to rebuild the addons, or fix something so that the addons can build again in asterisk |
| 13:53.27 | lmadsen | M14392 |
| 13:53.29 | MuffinMan | [new] [Asterisk] Addons/General 0014392: Addons will not build on 1.6.1 rc-1 or 1.6.0 svn reported by zktech (Karma: neutral) http://bugs.digium.com/view.php?id=14392 |
| 13:53.38 | *** join/#asterisk-bugs shido6 (n=shido6@96-28-34-156.dhcp.insightbb.com) |
| 14:36.45 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 15:04.11 | lmadsen | M14364 |
| 15:04.12 | MuffinMan | [new] [Asterisk] Core/ManagerInterface 0014364: NULL file descriptors causing GUI to eventually stop functioning reported by awk (Karma: +2.50) http://bugs.digium.com/view.php?id=14364 |
| 15:05.37 | lmadsen | M14384 |
| 15:05.38 | MuffinMan | [assigned] [Asterisk] Core/PBX 0014384: Background leaves files open indefinately reported by fiddur (Karma: neutral) http://bugs.digium.com/view.php?id=14384 |
| 15:05.43 | lmadsen | awk_r: is that the same issue? |
| 15:06.03 | file | no, and 14384 should go to someone who can look at it relatively now |
| 15:06.17 | lmadsen | hopes putnopvut gets in soon |
| 15:06.25 | lmadsen | I have a few issues for him so I can do a release today (if possible) |
| 15:06.27 | lmadsen | found a few blockers |
| 15:06.44 | file | a release of what? |
| 15:06.56 | lmadsen | 1.6.0.6 |
| 15:06.58 | lmadsen | -rc1 |
| 15:07.01 | file | oic |
| 15:07.10 | file | you should make it so they show up on the roadmap as blockers then ^_^ |
| 15:07.21 | lmadsen | I think you should block your face |
| 15:07.30 | lmadsen | O_O |
| 15:07.31 | file | and the new/uncommented list could use a looksee |
| 15:07.39 | awk_r | lmadsen, they seem to be causing the same symptoms, but probably don't have the same cause. |
| 15:07.49 | lmadsen | file: ya I looked at it yesterday, but there were a lot of issues on there I wasn't sure how to move forward |
| 15:26.56 | *** join/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 15:26.56 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 15:33.28 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 15:54.20 | *** join/#asterisk-bugs jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:55.39 | oej | Leif: Got access to a system that exposed that 183 proplem and have a large debug file. Could not see which type of frame that caused it, so I will retry tomorrow with a heavily patched system to see if I can find out more for file... Just to give you an update. |
| 16:03.35 | *** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-41b266586567acd8) |
| 16:03.35 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:06.09 | lmadsen | putnopvut: !! |
| 16:07.05 | putnopvut | lmadsen: hello! |
| 16:13.06 | file | codefreeze-lap: so are the CDR issues ever going to be... solved? |
| 16:15.15 | lmadsen | putnopvut: I have a call to run off to do, but when I get back, I have a few things I would like to discuss if you have a minute |
| 16:15.48 | putnopvut | lmadsen: sure |
| 16:15.55 | putnopvut | 6028 |
| 16:16.22 | codefreeze-lap | file: Good Question. I feel like I took a wrong turn in the maze, and stepping back may be more work than going forward. |
| 16:17.21 | file | codefreeze-lap: right... so where do you call it quits and focus on the real right way to do it instead of the bandaids |
| 16:18.56 | codefreeze-lap | Well, I have been... writing up the doc for what the CDR *should* be, then coding it up. Trouble is, that side of the effort is "new dev" work, and limited to quarter-time. |
| 16:20.05 | file | I understand, so are you going to continue trying to solve the issues in the previous versions? |
| 16:22.05 | codefreeze-lap | I have determined to look at each bug filed, and try to determine if I can solve it in a practical amount of time, if at all. Trouble is, it's such a rats nest, just looking at them takes a while. Most of these end up being stuff I either did wrong or were never covered; so I want to clean it up. |
| 16:24.15 | codefreeze-lap | file: Actually, these side cases are educational... I've spotted situations that my new stuff won't cover... like situations handled in the drivers that never get a channel created... |
| 16:25.20 | codefreeze-lap | file: and interesting angles on disposition if an incoming call never gets bridged. |
| 16:27.06 | file | uh huh |
| 16:30.21 | codefreeze-lap | file: yeah, sorry for the boring chatter. I'm tempted, for instance, to close 11849 as "can't solve", but... they feel very strongly about it, and I keep having a nagging feeling that if I play around in the transfer code, maybe swap a CDR here or there, I might be able to give them what they want at least in the most common situations. |
| 16:30.49 | *** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-f82920213be7fb29) |
| 16:30.49 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 16:32.24 | codefreeze-lap | But, because of masq issues, I also notice that after the latest round of parking fixes, that the h-exten's are running more often than they should.... ugh. |
| 16:33.45 | file | "never ending" |
| 16:34.54 | codefreeze-lap | file: it's the surest sign that the architecture is wrong... something that couldn't have easily have been predicted earlier. |
| 16:35.35 | file | well yes, I'm just concerned that the amount of time spent to try to correct a fundamentally flawed architecture has grown so large |
| 16:35.45 | codefreeze-lap | file: if the general architecture is right, tweaks won't hurt things much. |
| 16:35.47 | file | trying to give everyone what they need with what we have is admirable, but it just seems to go n |
| 16:35.55 | file | erm on |
| 16:36.25 | codefreeze-lap | file: yes. I agree, but... no one springs for my offer to "rewrite to fix". |
| 16:36.42 | codefreeze-lap | It's basically fear. |
| 16:37.07 | file | I don't understand your last statement, "rewrite to fix" for a 1.6 series aye? |
| 16:38.26 | codefreeze-lap | file: I don't think anyone want to declare CDRs in general a loss in 1.4, and abandon it completely, and let me call the rewrite a big "bug fix" and work on it full time. |
| 16:38.40 | codefreeze-lap | uh, /want/wants/ |
| 16:40.28 | file | do you need someone else to set the point where you have to say "I'm sorry, but I can't go any further with CDRs" in earlier versions? |
| 16:45.31 | codefreeze-lap | file: and, while I have your ear, the h-exten prob also needs to be redone. If I add a simple flag to channels that gets set when you start a pbx on it, then, when a channel closes, an h-exten needs to be run on that channel... whether it still has a pbx or not. As to someone else, if team/management want to call CDR's a loss, I'll cooperate. |
| 16:46.11 | codefreeze-lap | file: and it gets juicy when you have two channels that are so marked... |
| 16:47.07 | file | I'm just quite concerned that the amount of time spent on trying to keep the 1.4 CDR boat afloat has turned out to be immense and that regressions have been introduced over numerous versions |
| 16:47.33 | file | including crashes from the CDR code itself |
| 16:47.55 | codefreeze-lap | file: a very good concern. |
| 16:51.25 | codefreeze-lap | file: I wonder also, if a masquerade shouldn't pass the pbx pointer to the newly-created channel instead of leaving it on the zombie... |
| 16:51.43 | file | why? |
| 16:52.27 | codefreeze-lap | So that you can run the h-exten on it. |
| 16:52.35 | russellb | that would break the world in some cases. |
| 16:53.03 | russellb | we use the presence of a pbx on a channel to infer things about the channel ... |
| 16:53.26 | russellb | and in that case, it could have a pbx, when it's not actually in its own channel thread, and not actually running a pbx ... |
| 16:53.31 | russellb | >_< |
| 16:54.05 | codefreeze-lap | yes, any new thread will have to run the h-exten on the channel if the pbx ptr is set, and its a hangup. |
| 16:54.36 | codefreeze-lap | Any other behavior is wrong. |
| 16:55.02 | lmadsen | I also have the same concerns as file, because it seems by trying to fix the CDR issues, we cause the CDRs to be inconsistent across 1.4 releases. |
| 16:55.28 | file | quite |
| 16:55.45 | file | the inconsistency then turns into an issue report, which gets fixed, and then exposes another issue... |
| 16:56.22 | codefreeze-lap | murf: I tried like heck to make "tweaks", but yes, they introduce changes and inconsistencies from release to release. No way around it. |
| 16:56.24 | lmadsen | exactly. However I'm not entirely sure how to resolve that. |
| 16:57.14 | lmadsen | I mean, we might just have to say, "this is how CDRs are right now, and this is how they must stay -- CDR code is frozen in 1.4, and is EOL" or something like that |
| 16:57.33 | putnopvut | M14374 |
| 16:57.33 | lmadsen | save crash issues or something |
| 16:57.35 | MuffinMan | [assigned] [Asterisk] Applications/app_transfer 0014374: Revision 172517 segfault after using A *2 transfer to B and B dial *2 reported by aragon (Karma: +3.75) http://bugs.digium.com/view.php?id=14374 |
| 16:57.42 | file | we understand your issues and they have been taken into consideration for the new CDR architecture |
| 16:57.55 | lmadsen | file: aye |
| 16:59.42 | codefreeze-lap | file: lmadsen: I have *so* wanted to do that, but there's a bunch of CDR-holics that will not be happy campers. |
| 16:59.57 | lmadsen | that's the point -- you can't make everyone happy |
| 17:00.12 | lmadsen | and when you try, you get into the very situation we're in now. Mole hunting. |
| 17:03.16 | codefreeze-lap | Well, like it or not, making a fix to the CDR implementation involves maq, transfers, channel drivers, features, and h-extens, bridging, all at once, and requires a rewrite one way or the other, either in 1.6 as a chunk, or piecemeal to 1.4, over a bunch of revs. |
| 17:03.28 | codefreeze-lap | uh /maq/masq/ |
| 17:05.37 | file | piecemeal to 1.4? |
| 17:06.38 | codefreeze-lap | file: yes, exactly what I've been doing... a change here breaks this and that, bug report, fix, breaks this and that... the ripple effect is in effect a rewrite of sorts. |
| 17:06.48 | lmadsen | I'd rather freeze CDRs, and backport it when it was "fixed" if it was possible |
| 17:07.18 | lmadsen | if not, I'd still just prefer to leave CDRs as they are in 1.4, so that, even with deficiencies, people will at least know what they are getting |
| 17:08.10 | codefreeze-lap | Well, that leaves a chunk of users with no fixes, and no alternatives, until I complete the rewrite. |
| 17:08.36 | codefreeze-lap | (and by alternatives, I include "hope" that a problem will get fixed) |
| 17:09.17 | lmadsen | right, but what if you fix all the issues for those users, but which causes the same number of issues to pop up for other people? That seems to be the cycle we're getting into. |
| 17:09.47 | lmadsen | if we're going to be in that cycle forever with the current architecture, then it doesn't really seem to make any sense to me... |
| 17:11.58 | file | the rewrite would have to be seriously reviewed and discussed before being backported, if considered |
| 17:12.59 | codefreeze-lap | lmadsen: I cannot argue with you. My bug fixing has improved some issues, led to further probs in other places, in what might seem an eternal round... |
| 17:13.34 | lmadsen | brb -- gotta run off to some other consulting. Back in a bit. |
| 17:14.13 | lmadsen | but it sounds like we need to come up with a game plan for 1.4 CDR issues, rather than going in the current direction we're going in now. |
| 17:14.34 | codefreeze-lap | file: yes, and I've been trying to prod folks into reading the spec I'm writing.... it's hard work, reviewing the spec, and few are willing. |
| 17:14.47 | lmadsen | codefreeze-lap: I started yesterday, but ran out of time, but will try again today |
| 17:15.30 | file | I'm more concerned of the code from it and impact |
| 17:16.00 | file | I'm not a user of CDRs |
| 17:22.09 | codefreeze-lap | file: agreed. I plan to not code until the spec is reviewed/completed, but I also realize that I need to implement it and fill in detail based on the issues I find while implementing. |
| 17:22.17 | *** join/#asterisk-bugs dbrooks (n=dbrooks@nat/digium/x-b2c2337ba31fde54) |
| 17:22.44 | file | so if we need to discuss the way forward for dealing with CDR issues in 1.4 I'm sure we can make that happen |
| 17:24.40 | codefreeze-lap | file: I think the need exists, let's make something happen |
| 17:25.51 | file | -dev list? |
| 17:26.30 | codefreeze-lap | file: and/or conf call? |
| 17:26.47 | lmadsen | lets have a conf call first, then when it is detailed, we can send a msg to the list |
| 17:26.57 | lmadsen | then we know what we're asking for feedback on |
| 17:27.51 | codefreeze-lap | Well, I can guarantee good attendance, if I shut down all current CDR bugs, with "can't fix" and a note that there will be a conf call at a certain time, certain place... |
| 17:28.17 | file | that's silly |
| 17:28.26 | file | of course individuals will be upset over that |
| 17:28.32 | codefreeze-lap | pitchforks, torches the whole bit! ;) |
| 17:28.48 | lmadsen | well, I figured the call would determine what we would do about the currently open bugs :) |
| 17:29.09 | codefreeze-lap | lmadsen: you take the fun out of it! ;) |
| 17:29.33 | lmadsen | i.e. discussion on the call with a list of the open issues. Start with what our goal with the CDRs is in 1.4, then apply that to the open bugs to determine if they are a "will fix" or "won't fix", etc... |
| 17:29.41 | lmadsen | codefreeze-lap: hey, you know me, I'm totally up for closing out issues :) |
| 17:29.48 | file | reasonable goal. |
| 17:29.59 | codefreeze-lap | I'm with you all. |
| 17:30.14 | codefreeze-lap | or should I say y'all? |
| 17:30.17 | lmadsen | ok, so when should this call take place, and who should be invited? |
| 17:30.38 | codefreeze-lap | russell, for one |
| 17:30.49 | file | that's... complicated |
| 17:30.52 | putnopvut | I'd be interested in listening at least. |
| 17:31.03 | file | since russellb is leaving on a jetplane for a bit |
| 17:31.12 | lmadsen | file: I want to hear nothing of the sorts |
| 17:31.14 | russellb | O.O |
| 17:31.29 | codefreeze-lap | well, this requires some mngment approval, etc |
| 17:31.39 | lmadsen | agreed. Perhaps kevin can be russellb |
| 17:31.40 | lmadsen | :) |
| 17:31.44 | russellb | i've missed most of this conversation, but let me ask this ... |
| 17:31.50 | russellb | why is a call required? |
| 17:31.51 | lmadsen | ask away! |
| 17:31.57 | russellb | why can't we use the mailing list? |
| 17:32.01 | lmadsen | russellb: we're trying to figure out what to do about CDRs in 1.4 |
| 17:32.01 | file | that is why I proposed the -dev list |
| 17:32.09 | russellb | there is a big problem with schedules and timezones for live converstaion |
| 17:32.15 | russellb | -dev list is almost always the right place. |
| 17:32.15 | file | russellb: so you can participate as well as well as others over there |
| 17:32.15 | lmadsen | well I figured if we knew what to send to the list, it'd help |
| 17:32.39 | lmadsen | I was mostly talking about a pre-dev list chat |
| 17:32.40 | russellb | well if you don't know what to send to the list, you don't know what to talk about on the phone |
| 17:32.56 | russellb | perhaps |
| 17:33.03 | russellb | though you can start a conversation without a proposal |
| 17:33.34 | lmadsen | well, there is some rough thoughts of what to do. I thought a quick chat would help eliminate some noise from the dev-list |
| 17:33.34 | file | codefreeze-lap: I'm also curious over what you mean by management approval and what you need it for... |
| 17:33.57 | lmadsen | I'm certainly not opposed to dev-list only though |
| 17:34.19 | codefreeze-lap | approval/buy-in... after all, digium has been the one footing the bill, so to speak, for the endless changes to CDRs |
| 17:34.33 | russellb | we can chat this afternoon if need be |
| 17:35.15 | russellb | i'm free from 2 to 5 CT |
| 17:35.50 | lmadsen | I'm free between those times as well |
| 17:35.57 | file | ditto |
| 17:36.02 | codefreeze-lap | ditto |
| 17:36.05 | file | preferably before 4 CT... |
| 17:36.05 | lmadsen | (or rather, can make time ot be free) |
| 17:36.15 | russellb | ok, 31337 at 2pm CT, then |
| 17:36.21 | russellb | can someone put it in zimbra? |
| 17:36.22 | lmadsen | ACK |
| 17:36.28 | lmadsen | I will |
| 17:36.30 | russellb | thanks. |
| 17:36.41 | lmadsen | to those involved, or a more general list? |
| 17:36.59 | russellb | just us is probably fine |
| 17:37.09 | russellb | we're not making any big decisions or anything |
| 17:37.13 | lmadsen | right |
| 17:37.23 | russellb | and you can ping swdev to see if anyone else wants to join |
| 17:37.34 | russellb | but i suspect we have everyone. |
| 17:39.22 | lmadsen | writing an email now |
| 17:39.57 | lmadsen | note for anyone else watching: we are not making any sweeping decisions -- this is just to come up with a more fine tuned idea of what we'll bring up on the dev list |
| 17:40.18 | lmadsen | community involvement is very much encouraged :) |
| 17:41.21 | codefreeze-lap | a meeting about a proposal |
| 17:41.44 | lmadsen | right |
| 17:45.06 | *** join/#asterisk-bugs The_Boy_Wonder (n=davidvos@nat/digium/x-22d2530c0f5e6876) |
| 17:51.11 | russellb | others can call in too, no big deal |
| 17:52.14 | lmadsen | aye |
| 17:53.59 | Marquis42 | russellb: How might one do such a thing, were he so inclined? |
| 17:54.31 | russellb | call digium ... IAX2/guest@pbx.digium.com/s@default |
| 17:54.35 | russellb | extension 6060 |
| 17:54.37 | russellb | bridge 31337 |
| 17:55.00 | Marquis42 | Great, thanks. |
| 18:59.08 | *** join/#asterisk-bugs russellb_ (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 18:59.08 | *** mode/#asterisk-bugs [+o russellb_] by ChanServ |
| 19:39.45 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 20:14.18 | *** join/#asterisk-bugs anonymouz666 (n=anonymou@189.24.32.173) |
| 20:14.27 | anonymouz666 | hello putnopvut |
| 20:14.34 | anonymouz666 | I have a strange condition in app_queue.c |
| 20:14.40 | putnopvut | anonymouz666: what's wrong? |
| 20:16.45 | anonymouz666 | asterisk 1.4.21.2. the scenario is: you call a DID - ITSP ---> (SIP) asterisk ---> (ISDN) siemens -> legacy extensions. In app_queue a have member like: Zap/g2/6900,0. the app_queue doesn't call the extension. |
| 20:16.56 | anonymouz666 | if you call directly to zap/g2/6900 everything works fine. |
| 20:17.03 | anonymouz666 | let me send logs through pastebin |
| 20:20.25 | anonymouz666 | http://www.pastebin.ca/1326537 |
| 20:21.52 | anonymouz666 | until I got [2009-02-03 17:50:31] DEBUG[5163]: app_queue.c:1949 ring_one: Nobody left to try ringing in queue |
| 20:21.58 | anonymouz666 | and then I hangup |
| 20:22.11 | anonymouz666 | this happens ONLY in that condition. |
| 20:24.17 | *** join/#asterisk-bugs Khratos (n=khratos@190.166.103.180) |
| 20:24.50 | putnopvut | anonymouz666: hmmm, I'm trying to understand exactly what's happening (from a code point-of-view). |
| 20:26.26 | putnopvut | Nothing is coming to mind as far as why that's happening right now. Could you open a bug report about this? |
| 20:27.01 | anonymouz666 | yes I can. |
| 20:27.05 | anonymouz666 | let me test with Local members. |
| 20:27.30 | putnopvut | Can you also try testing with newer 1.4 code, too? |
| 20:27.46 | anonymouz666 | yeap |
| 20:27.49 | anonymouz666 | I did a diff |
| 20:28.01 | anonymouz666 | but i didn't see much difference |
| 20:28.08 | anonymouz666 | lots of things about atxfer |
| 20:28.18 | anonymouz666 | realtime |
| 20:29.34 | anonymouz666 | let me test with the latest app_queue code and then I open I bug if necessary. |
| 20:29.43 | putnopvut | thank you very much |
| 20:29.47 | anonymouz666 | With Local member does not work either. |
| 20:30.05 | anonymouz666 | ok, thanks for your attention. talk to you tomorrow. |
| 20:30.08 | anonymouz666 | bye |
| 20:33.35 | *** join/#asterisk-bugs DaneM (n=dane@adsl-76-252-255-196.dsl.chi2ca.sbcglobal.net) |
| 20:33.37 | russellb | M11849 |
| 20:33.40 | MuffinMan | [assigned] [Asterisk] CDR/General 0011849: Missing CDR's for Transfers reported by greyvoip (Karma: +0.75) http://bugs.digium.com/view.php?id=11849 |
| 20:35.36 | DaneM | Hello again. With reference to bug http://bugs.digium.com/view.php?id=13890 I've installed another OS, and downloaded/compiled * from SVN, and found that `dahdi show channel 1` still shows it in an off-hook state when not in use. I have posted a note to the bug with the output of that command. Anybody (Qwell, lmadsen, et al) have time to take a look? |
| 20:36.10 | Qwell | DaneM: get a good card |
| 20:36.28 | lmadsen | x100p is not a supported card |
| 20:36.30 | Qwell | These are the types of problems you can expect from a $10 clone |
| 20:36.37 | DaneM | any suggestions on which one (for under 60 USD)? |
| 20:36.42 | DaneM | this is not a clone, I think... |
| 20:37.15 | lmadsen | x100p is no longer a supported card for these types of reasons |
| 20:37.16 | DaneM | ok |
| 20:37.16 | lmadsen | DaneM: you might be better off with an ATA adapter then |
| 20:37.24 | lmadsen | check out something by linksys, grandstream, etc... |
| 20:37.37 | DaneM | lmadsen: ok. thanks. I'll look into it. |
| 20:37.44 | Qwell | meanwhile... |
| 20:37.55 | lmadsen | I'm going to close your open issue |
| 20:38.05 | Qwell | was about to |
| 20:38.09 | Qwell | but go ahead if you'd like! :D |
| 20:38.12 | DaneM | ok...so sad :-( |
| 20:39.55 | Entomologist | *** CLOSED (13890) [Hardware Issues] x100p modem no longer functions in 1.5 beta1 after update |
| 20:39.55 | Entomologist | Reported by: DaneM Karma: 0 |
| 20:39.55 | Entomologist | http://bugs.digium.com/view.php?id=13890 |
| 20:39.55 | Entomologist | ********************************************************* |
| 20:50.20 | lmadsen | codefreeze-lap: ping? you dropped... |
| 21:21.54 | codefreeze-lap | lmadsen: You probably didn't hear it, but I asked, "Am I... Alone...?" ..... zeep zeep zeep ... "yeah" |
| 21:28.43 | lmadsen | codefreeze-lap: ya, didn't hear that :) |
| 21:34.21 | Khratos | Are there substancial changes on Manager interface between Asterisk 1.4.22.1 and Asterisk 1.4.23.1 ? I ask because a software I did on php worked just fine making Asterisk edit its own config files, but now I receive a lot of 'broken pipe' errors |
| 21:40.34 | Corydon76-dig | Khratos: I'm looking |
| 21:41.07 | Khratos | ok |
| 21:47.51 | Corydon76-dig | Khratos: what changed is that ast_carefulwrite no longer waits forever -- it now waits the intended period of time |
| 21:49.10 | Khratos | Oh my... Is there any way to override that behavior ? |
| 21:49.22 | Corydon76-dig | Khratos: what you may want to do is increase the value of "writetimeout" in your manager.conf. It defaults to 100 |
| 21:49.52 | Corydon76-dig | That's in milliseconds |
| 21:50.08 | Khratos | I see, let me try out |
| 21:55.39 | Khratos | I saw that also got a 'Connection reset by peer', and even increasing it to 1000 did not work. I will look another workaround or revert to 1.4.22.1 , thanks anyways |
| 21:56.02 | Corydon76-dig | Uh, connection reset by peer means that the client closed the connection |
| 21:56.42 | Corydon76-dig | and the problem isn't on the server side |
| 21:57.03 | Entomologist | *** CLOSED (13494) [Resources/res_features] One-touch parking failure results in the call drop, while parties should be able to continue conversation |
| 21:57.03 | Entomologist | Assigned to: jpeeler |
| 21:57.03 | Entomologist | Reported by: mdu113 Karma: 5.5 |
| 21:57.03 | Entomologist | http://bugs.digium.com/view.php?id=13494 |
| 21:57.03 | Entomologist | ********************************************************* |
| 21:57.34 | Khratos | Yes, actually the script I did is intended to simulate the behavior of CodeIgniter behavior for building DB requests... it closes the connection for every command it sends |
| 21:57.59 | Corydon76-dig | How does it close the connection? |
| 21:58.20 | Corydon76-dig | Does it send an "Action: Logoff\r\n\r\n" or does it just shutdown the socket? |
| 22:00.13 | Khratos | Yes, it sends action logoff |
| 22:00.29 | Corydon76-dig | Does it wait for the server to close the connection? |
| 22:00.48 | Corydon76-dig | because the server responds to that logoff command with a confirmation |
| 22:01.36 | Khratos | I use a property of the class object to store commans, after it sends them all to the socket, it closes the connection |
| 22:01.46 | Corydon76-dig | That's why |
| 22:02.28 | Corydon76-dig | In prior versions, Asterisk never bothered to actually check whether the write out to the socket succeeded or not, but now it'll report an error if it happens |
| 22:12.54 | *** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim) |
| 22:18.18 | *** join/#asterisk-bugs eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 22:24.17 | *** join/#asterisk-bugs ZX81 (n=matt@202.20.97.211) |
| 22:24.33 | ZX81 | hi, can someone help with where I should clasify a bug: http://pastebin.ca/1326645 |
| 22:24.36 | ZX81 | core dump |
| 22:24.51 | ZX81 | not really sure where it should go |
| 22:24.56 | ZX81 | I could just put asterisk crash |
| 22:25.05 | ZX81 | but would like to be more specific |
| 22:26.54 | ZX81 | oh well pbx/general |
| 22:28.33 | ZX81 | M14395 |
| 22:28.35 | MuffinMan | [new] [Asterisk] PBX/General 0014395: Crash - maybe in filestream_destructor reported by ZX81 (Karma: +11.75) http://bugs.digium.com/view.php?id=14395 |
| 22:31.54 | *** part/#asterisk-bugs DaneM (n=dane@adsl-76-252-255-196.dsl.chi2ca.sbcglobal.net) |
| 22:34.30 | putnopvut | ZX81: yuck, I thought we had fixed all that stuff up :( |
| 22:34.42 | ZX81 | yeah |
| 22:34.46 | ZX81 | been stable since then |
| 22:34.48 | putnopvut | I can recategorize it for you. It's a problem with file playback, apparently. |
| 22:34.52 | ZX81 | :D |
| 22:34.53 | ZX81 | cool |
| 22:35.05 | ZX81 | erm it's submitted under pbx/general |
| 22:35.13 | ZX81 | not sure if I can change category on open ticket |
| 22:36.24 | ZX81 | music on hold file? |
| 22:37.45 | putnopvut | I went ahead and changed it for you to res_musiconhold :) |
| 22:38.45 | ZX81 | cool thanks man |
| 22:38.49 | ZX81 | playing stock files |
| 22:38.52 | ZX81 | will post that too |
| 22:49.09 | *** part/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 23:03.51 | *** join/#asterisk-bugs eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 23:59.18 | *** part/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-f82920213be7fb29) |