| 00:13.05 | *** join/#asterisk-doc RobH (n=RobH@cpe-72-184-129-136.tampabay.res.rr.com) |
| 07:11.56 | *** join/#asterisk-doc codefreeze-lap1 (n=murf@216.166.159.235) |
| 11:57.09 | *** join/#asterisk-doc ctooley (n=ctooley@mo-76-0-47-96.dhcp.embarqhsd.net) |
| 12:00.27 | *** join/#asterisk-doc lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:00.27 | *** mode/#asterisk-doc [+o lmadsen] by ChanServ |
| 12:24.47 | *** join/#asterisk-doc ctooley (n=ctooley@209.33.106.165) |
| 12:30.59 | *** join/#asterisk-doc codefreeze-lap (n=murf@216.166.159.235) |
| 12:42.01 | lmadsen | ctooley: morning! |
| 12:42.09 | lmadsen | codefreeze-lap: morning! |
| 12:42.23 | ctooley | morning |
| 12:42.29 | ctooley | brb, gotta run my kid to school |
| 12:42.44 | lmadsen | question for the room! So I have a client who wants to be able to hit a key to hangup the call they are one, but to continue on in the dialplan... |
| 12:42.55 | ctooley | She neglected to tell me about 15 pages of homework last night and she had to sit and do it this morning, so she missed the bus |
| 12:42.59 | lmadsen | I see the g and h/H options... but I don't think either of those do what I want |
| 12:43.03 | ctooley | will look at it when I get back lmadsen |
| 12:43.08 | codefreeze-lap | lmadsen: a hearty g'morning! to you too! |
| 12:43.16 | lmadsen | codefreeze-lap: haven't heard from you in a while! |
| 12:43.25 | lmadsen | ctooley: thanks man... have a good ride to school :) |
| 12:43.34 | ctooley | lmadsen, I have that set up by hitting ## |
| 12:43.39 | ctooley | we call it reoriginate |
| 12:43.43 | ctooley | will get you the settings for it. |
| 12:43.51 | lmadsen | ctooley: is that a patch, or applicationmap? |
| 12:44.00 | codefreeze-lap | lmadsen: true! must be a sign that we are busy or something |
| 12:44.03 | ctooley | features |
| 12:44.21 | lmadsen | codefreeze-lap: oh you're busy? I've just been over here twiddling my thumbs :) |
| 12:44.32 | lmadsen | ctooley: thanks... I'll check it out and see if I can figure it out before you return :) |
| 12:44.54 | codefreeze-lap | lmadsen: right. yes. Sure. I believe. Yep. |
| 12:45.08 | lmadsen | codefreeze-lap: haha... ya... I'm doing a lot of work in CustDev now |
| 12:45.21 | lmadsen | always have about 3-4 projects on the go, and that doesn't include consulting |
| 12:46.39 | codefreeze-lap | Well, better that than.... twiddling thumbs, eh? |
| 12:55.33 | ctooley | ok, back |
| 12:55.39 | ctooley | lmadsen, still need me to go pull it? |
| 12:55.48 | lmadsen | ctooley: if you have it, yes please! |
| 12:56.40 | ctooley | [applicationmap] |
| 12:56.43 | ctooley | reoriginate => ##,caller,Hangup |
| 12:57.05 | lmadsen | oh... and that just hangs up the one leg of the call... and continues in the dialplan? |
| 12:57.12 | ctooley | yup |
| 12:57.20 | lmadsen | I think I want to run that on the callee, but same idea |
| 12:57.52 | ctooley | <PROTECTED> |
| 12:57.53 | ctooley | <PROTECTED> |
| 12:57.53 | ctooley | <PROTECTED> |
| 12:57.53 | ctooley | <PROTECTED> |
| 12:58.06 | ctooley | from our AEL2 that runs our prepaid platform |
| 12:58.25 | lmadsen | hrmmmm... with 'g', doesn't that cause a reoriginate everytime though that the other end hangs up first? |
| 12:58.27 | ctooley | BTW codefreeze-lap I'm not sure why that segfault was occurring, I haven't checked with more recent versions. |
| 12:58.45 | ctooley | lmadsen, that's correct, we want that. |
| 12:58.49 | ctooley | you may not |
| 12:59.26 | lmadsen | ahhh... ya, I don't want it to happen every time the other end hangs up... only when the reoriginate is triggered by the DTMF... I'll have to figure something out |
| 12:59.46 | lmadsen | wish I was running 1.6... there is the ability to group application maps together |
| 12:59.48 | ctooley | ## with ,callee, should work |
| 13:00.39 | lmadsen | ya, gonna try: reoriginate => ##,peer/caller,Hangup() |
| 13:00.41 | ctooley | codefreeze-lap, you should be happy, we're still using AEL2. :) |
| 13:00.51 | lmadsen | errr... callee :) |
| 13:00.54 | lmadsen | bah... its early |
| 13:01.09 | lmadsen | oh wait |
| 13:01.10 | lmadsen | you were right |
| 13:01.21 | ctooley | huh? |
| 13:01.32 | lmadsen | I keep getting confused as to what is the "ActivateOn" and what is "ActivateBy" |
| 13:01.50 | lmadsen | self/peer is the channel to activate it on, and the caller/callee is who can activate it |
| 13:01.57 | lmadsen | so 'caller' is correct in my situation as well |
| 13:02.30 | ctooley | oh, I didn't actually implement it so I don't have the "experience" of how it worked, that was a pre-existing condition when I started at Excel. |
| 13:02.32 | lmadsen | :D |
| 13:03.22 | ctooley | Because, and I mean no offense to the people who wrote AEL, I would not have implemented our CC apps with AEL, I'd have used EIVR. We do way too much "logic". |
| 13:04.29 | ctooley | Our stupid prepaid applications runs a very complex set of AEL using a complicated set of Macro's and then fires off an AGI script (not even a FastAGI) to make a connection to an API server. |
| 13:05.03 | ctooley | The entire application could have been written without the API server, without the AGI and with a minimal set of AEL/dialplan to handle the call. |
| 13:05.28 | ctooley | They didn't even write the real "how does it work" stuff in AEL, they just do prompting and then connect to the API for all the heavy lifting. |
| 13:06.43 | ctooley | executing a new python virtual machine to parse a python script written like embedded C as much as possible to make the API connections. |
| 13:08.56 | ctooley | is installing 1244 new packages on his laptop, while working. :( |
| 13:09.34 | codefreeze-lap | ctooley: for the crash: the only thing I can think of is that if DIALSTATUS or DIALRESULT is null, then... maybe a crash. I'll look into it.. |
| 13:10.36 | ctooley | codefreeze, this AEL is migrated from a 1.2 system, it's OLD |
| 13:10.52 | ctooley | codefreeze-lap, ^^ |
| 13:12.04 | codefreeze-lap | ctooley: as to EIVR, you are meaning using the asterisk IVR, right? |
| 13:12.41 | ctooley | codefreeze-lap, EIVR is usually how I refer to ExternalIVR() |
| 13:12.58 | codefreeze-lap | aha |
| 13:14.04 | ctooley | It's not that AEL is "bad" but we do about 25 db queries per call and those are all deterministic on the logic. There's a query set of 150 queries and which one to run is determined by the results of the previous runs. |
| 13:14.24 | ctooley | And that's just the database portion, not to mention the extremely complex rating system |
| 13:14.34 | ctooley | So, it's not really the domain of AEL. |
| 13:15.10 | ctooley | Which is why it's implemented in a Tomcat servlet and the AGI script sends and receives query data to/from that. |
| 13:16.17 | ctooley | If it was written in an ExternalIVR() application, then everything would be contained in classes for that application. But, the guy that implemented the Asterisk side of things didn't really know anything about how the Prepaid platform side of things worked so he stayed out of it. |
| 13:16.32 | ctooley | the guy that implemented the platform side of things knew even less about asterisk, so he stayed out of that. |
| 13:17.08 | codefreeze-lap | ctooley: hmmm. Sounds like an interesting application whichever way it is implemented. I've never played with the ExternalIVR() app. I learn something new every day. |
| 13:17.12 | ctooley | In the end, there are 4 different programming languages involved in every call and we fire up 9 processes (not to mention the asterisk, tomcat and db threads) |
| 13:17.55 | codefreeze-lap | ctooley: hoo-boy. yeah, sounds like a good unification and simplification is in order. |
| 13:17.55 | ctooley | codefreeze-lap, You know our ExternalIVR() application framework (the external part of ExternalIVR()) is GPL'd and available, right? |
| 13:18.44 | codefreeze-lap | ctooley: no, had no idea. Worlds within worlds. What's it called? |
| 13:19.50 | ctooley | It's: Veraz->Asterisk->Asterisk executing AEL->AEL executes python AGI script->tomcat servlet->prepaid engine->database... times 5-6 messages for every single call |
| 13:20.04 | ctooley | isn't that just awesome? |
| 13:20.41 | codefreeze-lap | ctooley: lol-- it **is** awesome. And that it all works well, is even more so! |
| 13:21.00 | ctooley | codefreeze-lap, yeah... for some definitions of "works" |
| 13:21.43 | jsmith | Sounds like many points of failure to me ;-) |
| 13:21.53 | ctooley | jsmith, yeah, no kidding. |
| 13:22.33 | ctooley | I can remove the AGI script, Tomcat servlet, and prepaid engine all from the mix with our EIVR() framework, and the AEL can become 1/10th the size it is now. |
| 13:23.19 | ctooley | Oh, and I can remove 5-20 seconds of unbilled time from every call because we can move through prompts so much faster (everything in EIVR is asynchronous) |
| 13:23.28 | jsmith | Right... |
| 13:24.03 | ctooley | The only hard part for some people is the initial learning curve. That whole asynchronous thing throws people for a loop. |
| 13:25.24 | ctooley | Asterisk is still doing all the actual call processing, it's not like the audio or dtmf detection comes from the EIVR app, but the application sends commands to tell Asterisk what to do. Sort of the way CCXML or VXML is supposed to work, but about 1/1000th the weight of either of those. |
| 13:26.13 | jsmith | Right |
| 13:26.42 | ctooley | There are some things I don't like about ExternalIVR()'s protocol at the moment though. |
| 13:27.43 | ctooley | A) In the TCP socket version of the EIVR protocol there should really be some form of security/authentication. I'm reasonably sure implementing this via TLS wouldn't be unreasonably hard. |
| 13:28.15 | ctooley | B) there's no externalivr.conf to define "ivr peers" so you have to "know" who you're connecting to in the dialplan, not very pretty. |
| 13:29.08 | ctooley | C) I'd love for the external application to be able to stay on bridged calls (sort of a 3 legged call) and handle additional things as needed. |
| 13:29.39 | ctooley | All possible to implement, all entirely reasonably things. Exactly zero time. :) |
| 13:33.25 | ctooley | please see topic in #prepaid |
| 13:33.59 | jsmith | Huh |
| 13:34.08 | ctooley | that was only supposed to go to our internal server |
| 13:34.16 | ctooley | :) |
| 13:34.33 | ctooley | the /wallchan wasn't supposed to spam all the freenode channels I'm on. |
| 13:55.23 | *** join/#asterisk-doc ctooley (n=ctooley@209.33.106.165) |
| 13:56.56 | ctooley | yay, fc8 has a massive font. |
| 13:59.03 | jsmith | There is no "fc8"... there's "F8" |
| 13:59.19 | jsmith | But yes, F8 has some funky font problems... which F9 has corrected |
| 13:59.22 | ctooley | yeah yeah yeah |
| 13:59.38 | ctooley | dude, this an FC6 laptop upgraded to 7, and now 9 |
| 13:59.40 | ctooley | errr 8 |
| 13:59.47 | ctooley | I'm a bit leary of going to 9 already. :) |
| 14:00.04 | ctooley | And, I've done all upgrades 'live' |
| 14:00.25 | *** part/#asterisk-doc ctooley (n=ctooley@209.33.106.165) |
| 14:00.30 | *** join/#asterisk-doc ctooley (n=ctooley@209.33.106.165) |
| 14:00.34 | ctooley | oops, wrong X |
| 14:01.05 | ctooley | crap, lost my window manager some how |
| 14:01.32 | jsmith | ctooley: F9 has a nice "pre-upgrade" feature, which is really slick |
| 14:01.52 | ctooley | "pre-upgrade"? |
| 14:08.59 | jsmith | Yeah... it checks your system, downloads all the necessary packages, and does a dependency check *before* the upgrade, to make sure it'll work |
| 14:09.06 | jsmith | Then the upgrade only takes about 5 minutes |
| 14:09.08 | jsmith | It's really slick |
| 14:14.27 | ctooley | yum upgrade does than anyway, "RPM Transaction Test" |
| 14:15.05 | jsmith | Yeah... but a yum upgrade isn't always guaranteed to work |
| 14:15.25 | jsmith | That being said, I've always had pretty good luck |
| 14:22.11 | *** join/#asterisk-doc RobH (n=RobH@rob.tech.wikimedia.org) |
| 14:44.11 | *** join/#asterisk-doc ctooley (n=ctooley@209.33.106.165) |
| 15:21.54 | *** join/#asterisk-doc ctooley (n=ctooley@209.33.106.165) |
| 15:21.55 | lmadsen | chuckles at ctooley |
| 15:22.45 | ctooley | because of my connection? I'm trying to make my Sprint USB device work too. |
| 15:23.33 | lmadsen | ya |
| 15:23.40 | lmadsen | I need breakfast since it's almost lunchtime now |
| 15:23.50 | ctooley | me too |
| 16:27.06 | ctooley | jsmith, lmadsen so, should we just decide what it's going to be for them since asterisk-doc is the documentation channel anyway? :) |
| 16:27.23 | lmadsen | eh? |
| 16:27.54 | lmadsen | -dev reference? |
| 16:27.54 | brac | you best check yo'self! |
| 16:27.59 | ctooley | lmadsen hasn't been paying attention to -dev |
| 16:28.00 | ctooley | :) |
| 16:28.03 | lmadsen | that's true :) |
| 16:31.31 | lmadsen | ctooley: say that again? pls catch me up.... are you trying to keep the docs IN the code, or OUT of the code? |
| 16:32.03 | ctooley | lmadsen, the docs need to stay in the code, but there needs to be standardized way to get them _out_ of the code and into a human readable format. |
| 16:32.14 | lmadsen | that still seems annoying |
| 16:32.36 | lmadsen | makes it hard to update documentation in the code |
| 16:32.41 | ctooley | The person that changes the way an application works (ie: the one that knows how the code works) will never update it if it's in a separate places |
| 16:33.47 | ctooley | lmadsen, no, you're going about it the wrong way. There shouldn't be someone writing documentation that doesn't know how the software works. There should be a standard way to write the documentation that's right there _with_ the code so the person that updates the code updates the documentation at the same time. Very much the same as doxygen developer documentation |
| 16:34.20 | ctooley | Once that user documentation gets "exported" to a different format (say docbook) it can be expanded by having something that describes the application "include" the exported format. |
| 16:35.25 | lmadsen | I guess..... it can be in the code... but it needs to not be all over the friggin' place like it is now |
| 16:35.34 | lmadsen | its practically impossible to update the documentation in the source as it stands now |
| 16:35.39 | jsmith | lmadsen: Yes it does |
| 16:35.47 | jsmith | lmadsen: It's the only way it'll be kept up to date |
| 16:36.00 | jsmith | lmadsen: It'll just be 100 times easier for us to extract from the source |
| 16:36.03 | lmadsen | it can't be an included file? that seems difficult? |
| 16:36.22 | lmadsen | #include app_foo_docs.c |
| 16:36.23 | lmadsen | or something |
| 16:36.33 | ctooley | lmadsen, then you have someone documenting applications that doesn't know when the application has changed. |
| 16:36.50 | ctooley | The documentation should be updated at the time of the change, not later. |
| 16:37.12 | lmadsen | I agree... but it should still be easily updatable |
| 16:37.19 | lmadsen | it seems to be all over the place right now |
| 16:37.27 | ctooley | That way there can be an additional "check" in the review process for commits. "Does this affect how you execute and application? If yes, did you updated the documentation?" |
| 16:37.35 | ctooley | lmadsen, that's on purpose |
| 16:38.13 | ctooley | lmadsen, it's easiest to update if you have what you're doing right in front of you, what are you going to "update" about it if you aren't the one making the change? |
| 16:38.18 | lmadsen | making it difficult ot update docs is on purpose? |
| 16:38.56 | lmadsen | ignore my comments about it being in the code, I can agree on that... but it seems documentation is all over the place in the code and is hard to find to actually update if you wanted to |
| 16:39.18 | jsmith | lmadsen: It's better to have it in the same *file* as the source code you're modifying, rather than in some other file. |
| 16:39.32 | lmadsen | jsmith: I thought I just said I agreed about that |
| 16:39.49 | ctooley | lmadsen, we are talking about user documentation, right? |
| 16:40.09 | ctooley | because right now the only thing that I think we have for "user" documentation is what's in the "descrip" fields and those are at the top. |
| 16:40.31 | lmadsen | yes, not dev docs |
| 16:40.55 | ctooley | and what we're talking about would be a section at the top of the code which is user documentation which replaces the current descrip mechanisms. |
| 16:40.56 | lmadsen | maybe I haven't looked at the code in a while, but I just remember it being a bit of a bitch to update docs |
| 16:43.36 | ctooley | lmadsen, and we're attempting to make that a more reliable/easier job. |
| 16:43.47 | ctooley | specifically jsmith is taking on the brunt of that. :) |
| 17:06.33 | ctooley | lmadsen, I think we're essentially talking about replacing the functionality of the app, synopsis, and descrip "static const char *" definitions at the top of the .c files, correct jsmith? |
| 17:07.25 | jsmith | ctooley: Bingo! Roger! Spot on! Absitively Posolutely! Precisely! |
| 17:07.55 | ctooley | jsmith, right, so they should be essentially in the same spot, making them easier to update and more valid. |
| 17:09.36 | jsmith | ctooley: Yes, although I'd suggest putting something in the coding guidelines that says something to the effect of "For new application, please put the documentation at the top of the .c file, to make it easier to find later." |
| 17:11.13 | ctooley | jsmith, right, and as I said, a review in the bugs.digium.com process, like the other reviews, which requires anything that changes the application execution to also require updates to the documentation. |
| 17:11.52 | jsmith | Yup |
| 17:14.43 | lmadsen | all docs at the top for the CLI commands, app/func documentation, etc... would be pretty slick |
| 17:16.00 | ctooley | lmadsen, essentially that's how it is for all the stuff I've seen now, it's just utterly unstructured and impossible to automatically for anything other than "spew the description" |
| 17:16.23 | lmadsen | gotcha |
| 17:16.33 | lmadsen | well, sounds like things are moving forward... which is always a good thing |
| 17:17.28 | ctooley | lmadsen, oh, and we volunteered you to have all the apps/funcs/etc updated by next week to whichever format jsmith comes up with. :) |
| 17:17.49 | lmadsen | ctooley: no problem... just tell my Project Manager I'm going on a sabbatical :) |
| 17:18.02 | ctooley | hehe |
| 18:10.42 | *** join/#asterisk-doc RobH (n=RobH@cpe-72-184-129-136.tampabay.res.rr.com) |
| 18:37.31 | *** join/#asterisk-doc kannan (n=kann@123.201.60.110) |
| 18:43.48 | *** join/#asterisk-doc RobH (n=RobH@cpe-72-184-129-136.tampabay.res.rr.com) |
| 20:57.51 | lmadsen | ctooley: you use polycom phones? |
| 20:58.14 | ctooley | lmadsen, haven't for a while |
| 20:58.31 | lmadsen | ah... nevermind then :) |
| 20:58.41 | ctooley | wishes we had phones that nice. |
| 20:58.54 | lmadsen | apparently these people can't transfer calls... and I wonder if its because I set the number of calls per line key is set to 1 |
| 20:58.55 | ctooley | lmadsen, ping wwalker on -dev he's got some clients with Polycom's |