| 00:18.59 | *** join/#asterisk-dev jpeeler (n=jpeeler@adsl-065-005-230-151.sip.lft.bellsouth.net) |
| 00:20.39 | file | waves to jpeeler |
| 00:22.54 | jpeeler | hello file, you never miss a greeting! |
| 00:24.50 | Juggie | its really a script! |
| 00:24.52 | file | I'm crazy like that |
| 00:26.05 | Juggie | hmmmm |
| 00:26.10 | Juggie | i should get some swiss chalet |
| 00:49.01 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 00:50.00 | *** join/#asterisk-dev korihor (n=humberto@190.39.161.145) |
| 00:57.29 | *** join/#asterisk-dev MuffinMan (n=muffinma@mctnnbsa24w-142167052094.pppoe-dynamic.nb.aliant.net) |
| 01:43.48 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 02:23.25 | *** join/#asterisk-dev oej (n=olle@216.64.24.250) |
| 02:23.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 02:51.48 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 03:15.21 | *** join/#asterisk-dev oej (n=olle@216.64.24.250) |
| 03:15.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 03:40.53 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 06:10.43 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 08:20.51 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 08:20.51 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:22.00 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 08:22.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:29.58 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 09:21.48 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:24.10 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 10:02.52 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.136) |
| 10:22.27 | *** join/#asterisk-dev floppp (n=flopp@nat-staff.b3g-telecom.com) |
| 10:47.14 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 11:08.49 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:53.45 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:01.58 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 12:12.33 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584477.dsl.bell.ca) |
| 12:32.40 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 12:32.48 | *** join/#asterisk-dev oej (n=olle@216.64.24.250) |
| 12:32.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:36.43 | *** join/#asterisk-dev CrashHD (n=CrashHD@65.74.161.225) |
| 12:39.30 | *** join/#asterisk-dev CrashHD (n=CrashHD@65.74.161.225) |
| 12:45.54 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 12:50.48 | *** join/#asterisk-dev VoipForces (n=courchea@office.prival.ca) |
| 12:52.05 | VoipForces | Hi all, anyone care to look at issue 12123 (http://bugs.digium.com/view.php?id=12123) and give me some impression espetially regardinig the last comment ? Thanks. |
| 12:56.38 | ctooley | VoipForces, I looked at it, but unfortunately I'm of no help on that one. |
| 12:57.06 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.231.245) |
| 12:57.25 | M1s3ry | VoipForces, FYI, alot of the developers who would be able to reliably comment on that are not in yet |
| 12:57.45 | M1s3ry | VoipForces, at least the digium developers |
| 12:58.13 | VoipForces | Thanks ctooley |
| 12:59.05 | VoipForces | M1s3ry, yes I noticed, will try again later. Just that I have been pulling my hair out on this one. |
| 13:00.03 | ctooley | VoipForces, we've all been there |
| 13:02.28 | M1s3ry | :p |
| 13:34.09 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:36.22 | *** part/#asterisk-dev korihor (n=humberto@190.39.161.145) |
| 13:39.27 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:39.27 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:43.34 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 13:50.48 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 13:55.17 | Corydon76-dig | VoipForces: so in other words, one of the functions you're calling is marking the channel as answered... |
| 13:55.54 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 13:55.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:57.51 | VoipForces | Corydon76-dig: Well, as soon as the dtmf are send to the PRI, the channel is considered answered by asterisk and branches of to the dialplan context which starts with an answer and the AMD code |
| 14:01.44 | *** join/#asterisk-dev Skarmeth (n=Skarmeth@iris.aspec.com.br) |
| 14:02.27 | Corydon76-dig | That means that something is probably calling ast_answer() |
| 14:03.07 | Corydon76-dig | That probably means that you cannot use ast_dtmf_stream() |
| 14:03.15 | Corydon76-dig | You'll have to emulate it and send the DTMF yourself directly |
| 14:03.48 | VoipForces | hmmm and how would I do that in the dial code I modified? |
| 14:04.35 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:04.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:05.10 | Corydon76-dig | Try using ast_senddigit on each DTMF char |
| 14:06.28 | VoipForces | Ok, will try that, but unfortunatly I can not do that till 11pm tonight as this is a live system and they have about 3 PRi full of calls duriing the day (5 PRI total in the system). |
| 14:06.50 | Corydon76-dig | You don't have a test system? |
| 14:07.42 | VoipForces | Don't have a way to test it outside without being tied to the PRI. |
| 14:07.54 | VoipForces | Plus this system is in Ottawa and I'm in Montreal... |
| 14:11.31 | atis_work | hi guys. i wonder if there's a way how i can use ast_uri_encode directly in some printf-like function (i.e. ast_build_string), so i don't need multipe buffers for each encoded value |
| 14:11.33 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 14:12.01 | atis_work | ast_uri_encode seems to return converted value, so i should just use the same buffer for every conversion? |
| 14:12.11 | atis_work | i just couldn't find such usage anywhere |
| 14:16.30 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 14:17.12 | atis_work | for example, if in http://www.pastebin.ca/1002905 i would like to uri_encode qe->parent->name |
| 14:18.02 | VoipForces | Thanks Corydon76-dig should give you feedback tomorrow, will put them in mantis anyway |
| 14:18.57 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 14:21.39 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-622f79f718fc7848) |
| 14:23.28 | *** join/#asterisk-dev bkw__ (n=brian@70.234.160.41) |
| 14:36.57 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 14:37.00 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:37.00 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:43.49 | *** join/#asterisk-dev oej (n=olle@216.207.245.1) |
| 14:43.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:45.07 | snuff-home | hello russell/oej |
| 14:58.49 | *** join/#asterisk-dev tzafrir (n=tzafrir@local.xorcom.com) |
| 14:58.49 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:21.01 | oej | hello snuff-home |
| 15:22.31 | snuff-home | :) |
| 15:23.27 | snuff-home | doing your 'sip master classes' still? |
| 15:25.54 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:38.06 | Qwell | realtime queue callers? |
| 15:38.20 | putnopvut | Qwell: yeah, I saw that. |
| 15:38.26 | Qwell | is it update only? |
| 15:38.30 | putnopvut | yeah. |
| 15:38.44 | putnopvut | It just stores them there so you can see who's in the queue from some external source easily. |
| 15:38.57 | putnopvut | And then removes them when they leave the queue. |
| 15:39.02 | Corydon76-dig | And why can't they just use AMI? |
| 15:39.23 | putnopvut | Corydon76-dig: see bug summary. |
| 15:39.58 | snuff-home | btw.. anyone want to comment on 12555.. i added a patch which should solve but is there something more i'm missing? |
| 15:40.41 | Corydon76-dig | putnopvut: sounds like a plea for 'I don't wanna' |
| 15:41.20 | Corydon76-dig | If anything, perhaps the response should be a native AMI command for querying the channels in a queue |
| 15:42.01 | Corydon76-dig | Action: QueueStatus, perhaps |
| 15:43.00 | Corydon76-dig | Realtime isn't supposed to be a storage medium for status information |
| 15:43.37 | Corydon76-dig | and there's a massive slippery slope there. It opens the door to all sorts of other things stored in a db that really shouldn't be there |
| 15:44.11 | Corydon76-dig | ostensibly for status information |
| 15:45.12 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:51.04 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:12.15 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 16:37.20 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 16:37.20 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 16:37.52 | bkruse | oej: You believe users.conf is causing a bug? |
| 16:38.06 | oej | I believe that users.conf is a bug |
| 16:38.09 | oej | :-) |
| 16:38.13 | putnopvut | oej: I was just about to say that! |
| 16:38.17 | bkruse | He puts 5061 in sip.conf, you cannot change bindaddr/bindport or any other general variables from users.conf in other channel drivers... |
| 16:38.23 | bkruse | oej: I completely agree |
| 16:38.25 | oej | I just don't know. But not all settings are supported in users.conf |
| 16:38.41 | bkruse | oej: If you want to rewrite the GUI according to use the other config files, and manager those config files, please, be my guest |
| 16:38.43 | oej | So the GUI changes sip.conf |
| 16:38.54 | bkruse | oej: I thought that when hassip=yes, that it is parsed just like a sip context? |
| 16:39.07 | oej | bkruse: I have a module called ASTUM that fixes the problem that users.conf tried to solve |
| 16:39.12 | oej | bkruse: No |
| 16:39.15 | bkruse | (it is like that for zapata, if zapchan=number then it is parsed like a zapata context) |
| 16:39.51 | oej | Ok, so users.conf replacement should be a topic for next astridevcon |
| 16:40.11 | oej | We should really replace it quickly and mark users.conf deprecated for next major release |
| 16:40.16 | bkruse | Sure, but we have so much built on that already, that simply replacing it from an asterisk standpoint does not solve the problem of the tools that use it |
| 16:40.30 | oej | Is users.conf used in Switchvox? |
| 16:40.38 | tzafrir | users.conf generates only a peer entry and not a user entry for sip, right? |
| 16:40.44 | bkruse | Not sure, highly doubt it. |
| 16:40.45 | Qwell | tzafrir: it's a friend now |
| 16:40.46 | oej | bkruse: Well, that's up to the developers of the packages |
| 16:40.49 | bkruse | I thought they used realtime |
| 16:40.49 | Qwell | I think |
| 16:41.13 | bkruse | oej: Well, the developers of the products are across and down the hall from you currently :] |
| 16:41.22 | oej | So I think it's mostly AsteriskNow and the GUI that will need a redesign. It won't be a major one though |
| 16:41.27 | oej | :-) |
| 16:41.37 | bkruse | B0rking asterisk to where the gui no longer works on the a) appliance and b) business edition will make a couple people quite angry |
| 16:41.40 | oej | It will be easy for them to migrate to astum |
| 16:41.54 | bkruse | oej: Then I am down for it. We already have something else going in that direction..... |
| 16:42.04 | oej | I did not say we should remove users.conf, I want to add a better way so people can switch and a solution that we can support. |
| 16:42.14 | oej | And ASTUM is a year older than users.conf anyway - he he |
| 16:42.32 | bkruse | oej: Did mark not use ASTUM "just because" ? |
| 16:42.58 | bkruse | I think one of the problems is that this GUI is already tested. We will need some support from a few others to actually do something like that |
| 16:42.59 | oej | I had him read all the docs, then he kind of forgot I think. The way Mark works. |
| 16:43.21 | oej | He was focused on the issue at hand, not discussing the solution with the rest of us |
| 16:43.52 | oej | Yes, but I've seen a number of users.conf related issues that we simply can't solve... |
| 16:44.01 | oej | astum.conf is the other way around. |
| 16:44.15 | tzafrir | oej, what is astum? |
| 16:44.23 | bkruse | The way users.conf stays there, is because it "works for what we use it for", which is very basic trunk/user manipulation on a small pbx |
| 16:44.24 | oej | We have a users module - an internal directory - and say "this is a SIP phone. Go fetch all personal attributes from the user manager" |
| 16:44.30 | snuff-home | Corydon76-dig, new version of my janitor changes.. note no app_dial or app_queue |
| 16:44.35 | oej | Instead of pushing something into SIP saying "go create a phone" |
| 16:45.10 | russellb | oej: yes, i completely agree with you |
| 16:45.16 | russellb | your approach is by far the best way to do that |
| 16:45.28 | oej | And I wrote the documentation *before* the code :-) |
| 16:45.44 | oej | So I still think we can add that as a way forward and agree on the API |
| 16:45.46 | bkruse | oej: That is the proper way, I wish I could do that more often :] |
| 16:46.02 | bkruse | russellb: Why was users.conf implemented? (I might know the answer to that one, mark style). But furthermore, why didn't we switch to this before the GUI because such a big deal? |
| 16:46.11 | bkruse | Err... s/such/more of/ |
| 16:46.25 | oej | As it stands, it's just another way and users.conf can still be there. I just don't want to expand it because that will be very messy. |
| 16:46.28 | russellb | it was the quick and dirty hack to the problem at hand |
| 16:46.48 | bkruse | russellb: Ugh, that is how the last, I mean, current gui got so out of hand and was so hard to maintain/add features |
| 16:46.49 | *** join/#asterisk-dev atis_home (n=chatzill@193.238.213.215) |
| 16:46.51 | russellb | oej: that's true... |
| 16:46.53 | oej | And there was no discussion about it... :-) |
| 16:47.04 | bkruse | oej: So I heard... :] |
| 16:47.04 | russellb | not even internally ;) |
| 16:47.11 | bkruse | russellb: So true |
| 16:47.18 | oej | I think Mark was under a lot of pressure from Mark to find a solution, so he pushed forward |
| 16:47.43 | oej | We where all a bit suprised (or angry) about the HTTP server. I was here in Huntsville then and remember the discussions we had with Mark... |
| 16:47.45 | bkruse | Your right, I dog on em a lot, especially working with those javascript functions with 10 variable names including: t1,t2,t3,t4,t5, etc |
| 16:47.48 | oej | And then users.conf... |
| 16:47.56 | bkruse | But he was under a lot of pressure to get that done, at the tim |
| 16:48.08 | oej | Well, he had full right to do that and I don't blame him. We just gotta make it right and continue on. |
| 16:48.58 | bkruse | Well, who would be for that? Would it be geared more towards the GUI ? (so we could do user level logins/management, instead of someone that can login to the GUI can make system calls (pbx) and calls (shell)) |
| 16:49.13 | bkruse | oej: I do like the way this is heading, however :] |
| 16:49.50 | *** join/#asterisk-dev JerJer[mobile] (n=jj@dhcp189.infra.nac.ilabs.interop.net) |
| 16:50.38 | *** join/#asterisk-dev JerJer[mobile] (n=jj@dhcp189.infra.nac.ilabs.interop.net) |
| 16:51.39 | snuff-home | goes for some zzz's |
| 16:54.12 | atis_home | hey, i saw from logs that you were discussed "realtime queue callers" a bit here |
| 16:54.40 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:54.52 | atis_home | Corydon76-dig: can you explain your logics behind - why realtime shouldn't store status information? |
| 16:56.10 | oej | I think we should implement locks in svn |
| 16:56.27 | oej | Someone changed properties while I was merging a change and I ended up in conflict on "." |
| 16:56.55 | oej | Oh, status information in a database... |
| 16:56.58 | Qwell | . always conflicts on a 2nd merge |
| 16:57.00 | atis_home | some updates are already done for realtime queue members (paused), and for SIP peers (register time, ip) |
| 16:57.11 | Qwell | 1.4>trunk>1.6, the 1.6 props will be in conflict |
| 16:57.12 | oej | That would be interesting. The amount of status changes we have in a call... |
| 16:57.35 | oej | Well, registrations doesn't change very often. What do you want to store for queues? |
| 16:58.20 | atis_home | M12556 |
| 16:58.21 | MuffinMan | [new] [Asterisk] Applications/NewFeature 0012556: [patch] Realtime queue callers reported by atis (Karma: +11.25) http://bugs.digium.com/view.php?id=12556 |
| 16:58.46 | atis_home | well, in future i want to store all kind of status in db, as it's easily accessible |
| 16:59.09 | atis_home | especially if request count for status is greater than actual status changes |
| 16:59.29 | oej | I agree with corydon, we don't want to save call data in realtime |
| 16:59.34 | Qwell | what happens if asterisk goes down? |
| 16:59.41 | atis_home | i apologize, but i won't be able to discuss this here today, i have to run to concert.. could we continue in mantis? |
| 16:59.47 | oej | Asterisk *never* goes down, qwell |
| 16:59.53 | Qwell | stop now |
| 16:59.56 | atis_home | Qwell: status will be reset, as will be calls |
| 17:00.39 | atis_home | Qwell: there are few lines in load_module and unload_module |
| 17:00.55 | oej | qwell: Well, we should deprecate all "stop" commands... |
| 17:02.17 | oej | :-) |
| 17:02.50 | oej | Currently, we have no call states or device states in realtime. Adding that would be a huge change. |
| 17:05.11 | atis_home | oej, not that huge in terms of code, but huge improvement for potential users ;) |
| 17:05.32 | Corydon76-dig | atis_home: fix the bugs; don't use them as an excuse to add more |
| 17:06.06 | atis_home | i already told that i'm using this on my production with ~100 agents (~50 simultenous calls), all the agents monitor their own state, plus 20 supervisors monitor everything.. |
| 17:07.19 | Corydon76-dig | but you only need to query status once per connection. After that, you need only listen for status changes |
| 17:07.21 | atis_home | Corydon76-dig: i would really like to hear your objections against storing status in realtime, as i don't see any. There is no way how AMI would work with 100 simultenous requests for queue status. |
| 17:07.45 | atis_home | Corydon76-dig: yes, but then you have to keep daemon to listen, process all that |
| 17:08.23 | Corydon76-dig | Because a) realtime is not designed for that kind of data, and b) it sets us down a slippery slope for adding all sorts of other "status" changes that are more appropriate for other purposes |
| 17:08.43 | Corydon76-dig | atis_home: you don't need a daemon, just use the same persistent AMI connection to listen for new events |
| 17:09.46 | Corydon76-dig | atis_home: the problem is also that you're changing from an event-based system to a poll-based system. We already know poll-based does not scale well; this is why we've converted most things to event-based |
| 17:09.49 | atis_home | Corydon76-dig: how would you set up persistent AMI connection from PHP webpage? |
| 17:10.20 | atis_home | Corydon76-dig: this is not poll based, but push based system |
| 17:10.24 | Corydon76-dig | I wouldn't use PHP for that purpose, but I believe there's a way to do that with Web 2.0 and Javascript |
| 17:10.38 | atis_home | Asterisk only cares to push data to db backend, who does the rest |
| 17:10.45 | Corydon76-dig | atis_home: no, it's still poll-based, you're just changing the location of the poll |
| 17:10.59 | Corydon76-dig | and polling does not scale well |
| 17:11.40 | Corydon76-dig | Use the HTTP manager, with a web 2.0 interface |
| 17:12.55 | atis_home | Corydon76-dig: that feature is actually an event to db backend. no polling there. |
| 17:13.00 | Corydon76-dig | I understand that you've already got something that works for the time being, but it really isn't that scalable. |
| 17:13.00 | atis_home | sorry, i really have to run now |
| 17:13.27 | atis_home | Corydon76-dig: I see my feature much more scalable than any other current option |
| 17:13.40 | Corydon76-dig | atis_home: then you're not seeing all the options |
| 17:13.42 | atis_home | Corydon76-dig: would you post some summary to mantis |
| 17:14.36 | Corydon76-dig | Ask someone to show you what can be done with Web 2.0 and the HTTP manager |
| 17:15.07 | Corydon76-dig | There may be another developer in your company who can already do that |
| 17:15.20 | Qwell | please don't "Web 2.0" as a noun :( |
| 17:15.22 | Qwell | don't use* |
| 17:15.44 | Corydon76-dig | Qwell: would you prefer using it as a verb? ;-) |
| 17:15.47 | Qwell | yes |
| 17:17.44 | VoipForces | Hi all, looking at app_queue code (1.4) but maybe I missed it. Is there a way when the queue app performs a dial on a local channel to know in the dialplan that the call was initiated by app_queue and not someone who just dialed manually |
| 17:18.23 | Corydon76-dig | There is, if you set an inheritable variable before the Queue |
| 17:18.44 | Corydon76-dig | Set(_fromqueue=1) |
| 17:18.56 | Corydon76-dig | NoOp(${fromqueue}) |
| 17:19.45 | VoipForces | Interesting, did not think that would carry through the queue dials. I'll try that right now. |
| 17:21.18 | Corydon76-dig | I'm pretty sure it should |
| 17:21.39 | Corydon76-dig | Alternatively, you could set it on a Dial... |
| 17:21.57 | VoipForces | we will know in a few minute, modifying my code |
| 17:25.40 | ctooley | Anyone got an good ideas for call-state and media to failover to a "standby" server in the event that asterisk crashed, the box running asterisk crashed, or some other reason causes asterisk to become unavailable? I realize that with TDM this is pretty tricky (though possible with SS7), but for IP call types reinvites should allow for media and signaling to both be handled by a standby server. |
| 17:32.26 | VoipForces | Corydon76-dig: Nope the _fromqueue is not retained as it looks like it a new channel instance I'll try with __ |
| 17:33.13 | Corydon76-dig | snuff-home: you've uncovered a bug in app_meetme |
| 17:33.40 | VoipForces | Corydon76-dig: Same with __ |
| 17:34.12 | Corydon76-dig | VoipForces: ah. THEN... |
| 17:34.23 | VoipForces | Corydon76-dig: what would be needed is a channel variable created by app_queue. Something like QueueCall=1 |
| 17:34.46 | Corydon76-dig | Set a __ variable on everything else and distinguish the Queue by what it DOESN'T have |
| 17:35.22 | VoipForces | Corydon76-dig: wow, that's a big rework.. i think.. let me see |
| 17:35.54 | VoipForces | Corydon76-dig: still like the app_queue variable better ;-) Worth a feature request in mantis? |
| 17:36.32 | Corydon76-dig | Feature requests without patches get closed |
| 17:36.58 | VoipForces | Corydon76-dig: I'll do a patch no prob, already have my disclaimer signed anyway |
| 17:39.54 | VoipForces | Corydon76-dig: Just have to find where exactly in app_queue does it do the dial to the agents... |
| 17:43.50 | VoipForces | Corydon76-dig: Never realized that app_queue is probably the most complicated app in asterisk LOL |
| 17:53.27 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 17:59.02 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:12.20 | *** join/#asterisk-dev xrg_ (n=panos@77.83.40.166) |
| 18:17.04 | *** join/#asterisk-dev korihor (n=humberto@190.78.209.202) |
| 18:27.55 | *** join/#asterisk-dev callguy (n=chatzill@pool-72-70-66-31.bstnma.east.verizon.net) |
| 18:31.03 | anonymouz666 | callguy! |
| 18:31.13 | callguy | yes! |
| 18:31.59 | anonymouz666 | Looking at my CLI right now I remembered you (the mantis issue) with my deadlock with chan_local :) |
| 18:32.25 | callguy | ahh right - though thankfully i think we've moved on from that one |
| 18:33.51 | seanbright | guess who has to have his transmission replaced? |
| 18:34.00 | seanbright | and its not PastryChef or MuffinMan |
| 18:34.13 | file | ummm... is it seanbright? |
| 18:34.17 | seanbright | ding ding ding |
| 18:34.29 | file | do I get a prize? |
| 18:34.47 | seanbright | hands file a jacked-up transmission and a bill for $4500 |
| 18:34.52 | seanbright | you win! |
| 18:36.34 | file | :( |
| 18:36.44 | seanbright | also hands file a muffin |
| 18:36.50 | seanbright | that should take the edge off |
| 18:49.42 | Corydon76-dig | seanbright: lucky you. I only need a new condenser |
| 18:50.59 | seanbright | Corydon76-dig: i'm not going to pay for it. if honda of america won't take care of it, i'm just trading it in. |
| 18:51.30 | seanbright | ... on a new honda probably |
| 18:51.31 | seanbright | :-/ |
| 18:53.27 | Corydon76-dig | Oh, I'm definitely replacing my condensor. I still have 2 years left to go before trade-in |
| 18:53.54 | seanbright | how much is that going to run you? |
| 18:54.50 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:56.43 | seanbright | ... if you don't mind me asking :) |
| 18:59.09 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 19:00.27 | Corydon76-dig | Just under $1k |
| 19:00.36 | Corydon76-dig | probably just over, with labor |
| 19:16.52 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:23.21 | Juggie | hmmmm |
| 19:23.41 | Juggie | last day to file your taxes in canada today, busy day in the phone world. |
| 19:25.32 | file | so true |
| 19:25.43 | file | the wait time at the post office was horrid as well |
| 19:27.12 | seanbright | Corydon76-dig: not too bad, i'm jealous |
| 19:27.43 | Juggie | netfile got extended file. |
| 19:27.46 | Juggie | to may6th now |
| 19:27.55 | Juggie | to file your taxes via netfile and be 'ontime' |
| 19:28.09 | file | I already filed and got my assessment :D |
| 19:28.15 | Juggie | did you netfile it? |
| 19:28.21 | file | yes. |
| 19:28.26 | Juggie | ya, most sensible people do |
| 19:28.26 | seanbright | i already got audited |
| 19:28.33 | Juggie | but we still get like 6.5million paper tax returns |
| 19:28.52 | Juggie | file, i've got 1million CDR records for today already |
| 19:28.57 | Juggie | and the day is 1/2 over. |
| 19:29.19 | Juggie | no doubt we'll hit 2mil this evening once people get home from work |
| 19:30.45 | VoipForces | Juggie: are you saying that revenue canada uses asterisk? |
| 19:31.15 | Juggie | i'm not saying anything besides the fact that i have cdr records, any phone system generates them :) |
| 19:31.48 | Juggie | but yes we are working with asterisk thats commonly known |
| 19:31.54 | Juggie | but not to handle this volume, not yet. |
| 19:32.09 | VoipForces | ok... tried dialing in yesterday got busies so that made me design a camp-on feature on out pbx LOL |
| 19:32.20 | Juggie | yah |
| 19:32.29 | Juggie | we are busy busy |
| 19:32.32 | Juggie | which service did you want |
| 19:32.52 | VoipForces | netfile technical, was missing my netfile number lol |
| 19:33.00 | Juggie | hah |
| 19:33.03 | Juggie | good luck |
| 19:33.49 | VoipForces | was able to get through yesterday. Getting the web interface to cooperate was an other thing LOL |
| 19:33.56 | Juggie | i think thats the e-service helpdesk right? |
| 19:34.19 | VoipForces | think so, 7258 number |
| 19:34.33 | VoipForces | used that number to test my camp-on application today lol |
| 19:34.41 | Juggie | french |
| 19:34.46 | Juggie | is 7258 |
| 19:34.51 | VoipForces | et oui |
| 19:35.04 | Juggie | that service is getting bombed |
| 19:35.09 | Juggie | because of netfile being hosed |
| 19:35.59 | Juggie | e-service has had almost 400,000 calls attempts so far today |
| 19:36.10 | VoipForces | well, now I have camp-on on my pbx. |
| 19:36.19 | VoipForces | wow, how many channels (PRI ?) |
| 19:36.28 | Juggie | not sure |
| 19:36.31 | Juggie | and i said call 'attempts' |
| 19:36.47 | Juggie | we certainly cannot complete 400,000 calls in a day |
| 19:36.57 | VoipForces | count 20-30 from me when I tested my app :-) |
| 19:37.00 | Juggie | not when you need an agent to answer them |
| 19:37.48 | Juggie | that would be next to impossible |
| 19:38.05 | VoipForces | indeed |
| 19:39.11 | Juggie | you would need 10,000 agents :) |
| 19:39.20 | Juggie | or something close to that |
| 19:49.43 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 19:54.30 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:58.18 | bbryant | file: the situation is that when i have an audio hook attached to a channel, i try to remove it but i get a deadlock because the memory has been free'd but something is still trying to use the lock |
| 19:58.49 | file | what memory has been free'd? |
| 19:59.03 | bbryant | what i'm doing for the audiohook is _detach_source, _detach, and _destroy |
| 19:59.25 | file | you don't need _detach_source |
| 19:59.29 | bbryant | theok |
| 19:59.31 | bbryant | *ok |
| 19:59.47 | file | just detach and destroy |
| 19:59.55 | bbryant | ok |
| 20:24.27 | seanbright | i want to do a 'du' but show the number of files instead of the size |
| 20:24.30 | seanbright | any ideas? |
| 20:25.44 | russellb | du | wc -l |
| 20:25.45 | russellb | :-p |
| 20:25.48 | bbryant | file: could you think of any reason that detach could lock up? |
| 20:26.16 | seanbright | russellb: so close, yet so far |
| 20:26.19 | russellb | bbryant: you're detaching before destroying the datastore aren't you? |
| 20:26.26 | bbryant | yes |
| 20:27.36 | russellb | COUNT=0; for n in `find .` ; do if [ -f $n ] ; then COUNT=$[${COUNT} + 1] ; fi ; done ; echo "Num files: ${COUNT}" |
| 20:28.00 | file | russellb: what exactly is the flow of things? |
| 20:28.02 | file | wait, not you |
| 20:28.04 | bbryant | russellb: what about files with spaces in the path || filename? |
| 20:28.04 | file | bbryant: you! |
| 20:28.17 | russellb | touche. |
| 20:28.17 | seanbright | russellb: well... i've been unclear, but its OT either way :) |
| 20:28.21 | russellb | quote $n then |
| 20:28.22 | russellb | :) |
| 20:28.27 | Corydon76-dig | find . | wc -l |
| 20:28.31 | seanbright | russellb: this is the output i am looking for: |
| 20:28.38 | russellb | Corydon76-dig: lol ... |
| 20:28.49 | seanbright | ./dir1 18 |
| 20:28.53 | russellb | bbryant: why don't you commit your code so we can look |
| 20:28.54 | seanbright | ./dir1/dir2 20 |
| 20:28.54 | sruffell | seanbright: Is this post referring to a bug that you've identified about zaptel 'make install' in 1.4.10 that isn't in 1.4.9? http://lists.digium.com/pipermail/asterisk-users/2008-April/210635.html. |
| 20:28.57 | Corydon76-dig | find . -type f | wc -l |
| 20:28.59 | bbryant | russellb: will do |
| 20:29.30 | seanbright | sruffell: well, i didn't idenfity it, tzafrir did |
| 20:29.53 | seanbright | sruffell: but yes, the devices are not installed properly apparently. there is a makefile patch that resolves it in the 1.4 branch. |
| 20:30.07 | Corydon76-dig | seanbright: find . -type d -exec "find {} -type f | wc -l" \; |
| 20:30.08 | Qwell | find . -type d -exec du --max-depth=0 {} \; |
| 20:30.09 | Qwell | noobs |
| 20:30.26 | sruffell | hmm...ok...thanks. I took the minute to test and didn't see a problem....and I've only heard tzafrir mention a problem with the 2.6.24 kernel. thanks. |
| 20:30.32 | bbryant | http://svn.digium.com/view/asterisk/team/bbryant/noise_reduction_and_agc/funcs/func_speex.c?view=markup |
| 20:31.01 | seanbright | sruffell: there was someone in #asterisk the other day that had the same problem. applying the patch from svn seemed to fix it for him. |
| 20:31.07 | seanbright | Qwell: perfect. danke. |
| 20:31.14 | sruffell | seanbright: thanks. |
| 20:31.17 | Qwell | that shows file size per dir |
| 20:31.23 | seanbright | oh |
| 20:31.26 | seanbright | god bless it |
| 20:31.28 | seanbright | hehe |
| 20:31.37 | russellb | bbryant: you should only detach if !is_new |
| 20:32.47 | russellb | otherwise you haven't attached yet |
| 20:33.07 | file | that would do it |
| 20:33.09 | bbryant | oh right, i thought the attaching was earlier |
| 20:33.22 | bbryant | it still locks though, odd |
| 20:33.48 | russellb | is valgrind still flipping out? |
| 20:34.21 | russellb | file: I messed him up because I wanted the ability to turn the filters off, which requires removing the audiohook and datastore |
| 20:34.23 | russellb | :) |
| 20:34.26 | russellb | oooops |
| 20:34.46 | Corydon76-dig | seanbright: find . -type d -exec sh -c 'size=`find {} -type f | wc -l` ; echo "$size\t{}"' \; |
| 20:34.50 | file | naughty russellb |
| 20:35.18 | seanbright | Corydon76-dig: my hero |
| 20:35.23 | Qwell | echo -e |
| 20:35.30 | seanbright | i just made it a space |
| 20:35.43 | Corydon76-dig | -e ? |
| 20:35.48 | seanbright | makes \t work |
| 20:35.58 | russellb | ok, seriously, off topic :-p |
| 20:36.03 | seanbright | heh |
| 20:36.06 | putnopvut | Who here owns a pony? |
| 20:36.08 | Corydon76-dig | Worked fine for me without -e |
| 20:36.35 | Corydon76-dig | but maybe that's only because my sh is bash, not dash |
| 20:36.42 | seanbright | i'm using bash |
| 20:37.01 | seanbright | but it works either way |
| 20:37.02 | seanbright | so |
| 20:37.03 | seanbright | yay! |
| 20:37.13 | bkruse | Corydon76-dig: -e \t = a tab, but without it, it is the string literal \t |
| 20:37.31 | bkruse | But maybe it is what you said (about sh/bash) |
| 20:37.39 | Corydon76-dig | bkruse: I'm telling you about what I observed, not what the manpage says |
| 20:38.18 | bkruse | Corydon76-dig: Agreed. That is the beauty of the shell :] |
| 20:39.55 | seanbright | sruffell: i just re-read that link you posted, i think the author of that message included my response out of context. just fyi. |
| 20:40.43 | Corydon76-dig | seanbright: even better: find . -type d -exec sh -c 'size=`find {} -maxdepth 1 -type f | wc -l` ; echo "$size\t{}"' \; |
| 20:40.59 | sruffell | seanbright: thanks again...I was a little confused. I'm still looking for the patch and I guess I need to do a better job of keeping up with the users lists. |
| 20:41.17 | seanbright | sruffell: i can get you the rev # if you need it |
| 20:41.21 | seanbright | Corydon76-dig: ohhh, nice, |
| 20:41.35 | Corydon76-dig | Actually, you could even remove the '-type f' |
| 20:41.46 | file | pokes bbryant |
| 20:41.47 | Corydon76-dig | and then you get all entries |
| 20:41.49 | sruffell | seanbright: It's already been commited into svn? If so...I'll just look back (again, I'm thinking there was only a change for the xpp installation stuff there...) |
| 20:42.04 | seanbright | sruffell: yeah, its in svn. |
| 20:42.14 | Corydon76-dig | or "! -type d" |
| 20:42.23 | Corydon76-dig | and exclude just directories |
| 20:42.28 | seanbright | sruffell: http://svn.digium.com/view/zaptel/branches/1.4/Makefile?view=patch&r1=4167&r2=4166&pathrev=4167 |
| 20:42.42 | seanbright | Corydon76-dig: yeah, -type f does the trick for me at the moment |
| 20:42.45 | Corydon76-dig | gets even more obsessive... |
| 20:42.53 | seanbright | heh |
| 20:43.12 | bbryant | pokes file |
| 20:43.25 | sruffell | seanbright: arghh..that's a commit that I made. |
| 20:43.35 | seanbright | sruffell: that is the fix |
| 20:43.42 | seanbright | sruffell: so good job :) |
| 20:43.57 | file | bbryant: I have to add another API call ^_^ |
| 20:44.14 | russellb | bbryant: sorry, what i told you to do is not possible |
| 20:44.21 | sruffell | well...jsmith pinged me about an issue he was havin |
| 20:44.24 | bbryant | russellb: ? |
| 20:44.33 | file | or you |
| 20:44.35 | sruffell | so....he turned me onto the fact that there were problems on some systems. |
| 20:44.44 | sruffell | seanbright: anyway..thanks again. |
| 20:44.46 | bbryant | file: i see |
| 20:44.48 | seanbright | sruffell: that revision was made post 1.4.10 was tagged |
| 20:44.49 | russellb | bbryant: removing an audiohook from a channel from the channel's own thread ... |
| 20:44.51 | seanbright | sruffell: no sweat |
| 20:45.45 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 20:45.55 | file | bbryant: there just needs to be an API call that takes in a channel and audiohook, removes from the proper list, sets state on the audiohook, and returns... |
| 20:46.10 | file | once we have channel reference counts... that can change |
| 20:46.27 | russellb | ast_audiohook_remove() ? |
| 20:46.29 | bbryant | ok |
| 20:46.50 | file | russellb: sounds good enough to me |
| 20:54.33 | seanbright | russellb: does that iax fix warrant a 1.4.20? |
| 20:55.02 | Juggie | fix a few moer things first, no one will upgrade mid day anwyays :) |
| 20:55.05 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:55.41 | Juggie | *more |
| 20:57.21 | russellb | seanbright: yes ... |
| 20:57.31 | russellb | but, i want to get some testing on it first |
| 20:57.36 | russellb | to make sure I don't introduce crashes |
| 20:57.40 | seanbright | russellb: that's crazy talk |
| 20:57.40 | russellb | I guess that's what RCs are for ... |
| 20:58.25 | seanbright | well once 1.4 is eol'd all will be right in the universe |
| 20:59.03 | *** join/#asterisk-dev snuff-home (n=snuff-ho@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 20:59.43 | Corydon76-dig | russellb: how about if we do an rc1 of zaptel 1.4.11 at the same time? |
| 21:00.06 | seanbright | ohhh, RCs of 1.4? didn't know those were done. |
| 21:00.12 | seanbright | or wasn't paying attention |
| 21:01.18 | Corydon76-dig | Someone kept complaining, so we started doing those on 1.4.19 |
| 21:01.40 | Corydon76-dig | Now if it doesn't work on release, he'll have only himself to blame |
| 21:01.49 | seanbright | hates these guessing games |
| 21:01.58 | seanbright | Corydon76-dig: PM please |
| 21:01.58 | seanbright | ;) |
| 21:02.11 | Corydon76-dig | seanbright: it's 4PM |
| 21:02.22 | seanbright | sweet, thanks. |
| 21:07.15 | seanbright | do you guys have an in-house test harness you use? or just on a tech-by-tech basis? |
| 21:07.32 | bbryant | file: that did it, awesome |
| 21:08.42 | file | good good |
| 21:30.48 | seanbright | ok, honda is going to pay for half of it, so only $2200 for the new transmission |
| 21:30.51 | seanbright | yay |
| 21:37.52 | Corydon76-dig | Yay |
| 21:52.40 | snuff-home | mm nice to know i found a bug Corydon76-dig.. now to get up the stones to try and add the extra locks in app_dial |
| 22:16.52 | *** join/#asterisk-dev Utah_Dave (n=David_Bo@72-166-51-162.dia.static.qwest.net) |
| 22:38.23 | snuff-home | 1.25 more -ve karma for falves and he gets on the alltime lowest ;) |
| 22:38.31 | codefreeze | snow predicted here this week. The magic that is called "Wyoming". |
| 22:49.33 | *** part/#asterisk-dev korihor (n=humberto@190.78.209.202) |
| 22:52.06 | *** part/#asterisk-dev Utah_Dave (n=David_Bo@72-166-51-162.dia.static.qwest.net) |
| 22:52.21 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 22:52.27 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-193.bredband.comhem.se) |
| 22:54.51 | *** join/#asterisk-dev snuff-home (n=snuff-ho@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 23:16.06 | *** join/#asterisk-dev RoyK (n=roy@91.149.31.193) |