| 00:01.04 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 00:01.04 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 00:12.39 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 00:29.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.79) |
| 00:40.04 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.79) |
| 00:43.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:10.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.179) |
| 01:40.39 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.160) |
| 01:45.25 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 01:53.30 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:57.35 | pabelanger | file: just reading your review about ARI transfers, this is just to publish events over ARI when a transfer has occurred right? And you don't send an event into ARI to invoke a transfer |
| 01:58.17 | file | correct |
| 01:59.06 | pabelanger | cool |
| 01:59.57 | pabelanger | when you say you tested it, you used both transfer button on a SIP phone and features.conf? |
| 02:00.54 | pabelanger | trying to understand what type of transfers (how they are done) invoke the events |
| 02:01.14 | file | only externally initiated transfers are enabled in the code (ie: SIP) |
| 02:01.49 | pabelanger | roger |
| 02:11.22 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 02:42.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.214) |
| 02:53.33 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:12.47 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 03:12.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:40.37 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.179) |
| 03:48.08 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 03:48.08 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:53.32 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 04:32.17 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:3e97:eff:fe14:ef66) |
| 04:40.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.197) |
| 04:53.36 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:53.27 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:57.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:57.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:12.36 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:12.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:17.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 07:24.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 07:30.10 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 07:30.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:46.15 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:46.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:47.00 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:53.47 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 08:09.17 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 08:09.17 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:53.40 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:00.18 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:adb4:7b15:80ce:e039) |
| 09:53.34 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 10:00.14 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:53.30 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 11:00.37 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:00.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:24.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 11:53.32 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:12.44 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 12:12.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:36.53 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-lezryzktmtggmnzh) |
| 12:36.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:53.31 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:57.47 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 12:57.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:02.55 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 13:02.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:13.01 | *** join/#asterisk-dev skrusty (~support@168.63.14.171) |
| 13:13.27 | skrusty | afternoon all |
| 13:13.44 | file | greetings |
| 13:14.19 | skrusty | digging my way through ARI at the moment :) |
| 13:15.14 | skrusty | just put up some code on codeplex for ARI .NET Framework, but have a question if i may |
| 13:15.56 | file | go for it, although very few people are here at the moment |
| 13:16.44 | skrusty | if ARI is to be used to replace applications such as Queue, what provision or thought has been given in ARI for actions in things like AMI to talk back to those applications? |
| 13:16.57 | skrusty | i understand it'a all work in progress |
| 13:17.14 | skrusty | just wondered if there was a roadmap for ARI maybe outlining things like that |
| 13:17.21 | file | can you clarify more on what you mean? |
| 13:17.37 | skrusty | well, in AMI for example, i can call QueueAdd etc |
| 13:17.53 | skrusty | how would you replicate that functionality if queue was written in ARI? |
| 13:18.08 | file | I'd probably do it as a RESTful API from the ARI application itself, outside of Asterisk |
| 13:18.38 | skrusty | ah, so AMI would no longer have the ability to interact with * applications? |
| 13:19.00 | skrusty | without knowing where the ARI application was for exmaple |
| 13:19.16 | file | personally I don't foresee it happening |
| 13:21.04 | skrusty | is it not the intention to replace the existing applications with ones using ARI long term (i may have misunderstand that by the way, not assuming they will be :) like queue as an example |
| 13:21.51 | file | the existing ones will still exist for quite some time, but ARI equivalent ones may come to exist |
| 13:22.17 | skrusty | wont there be a disparity then between ARI and native in terms of AMI then? |
| 13:22.32 | skrusty | i.e. native will have AMI actions, and ARI wont |
| 13:22.35 | file | yes |
| 13:22.45 | skrusty | doesn't that make ARI a second class citizen? |
| 13:22.58 | file | why do you have to expose that information over AMI? |
| 13:23.00 | skrusty | i ahve to go out of my way to do something different with ARI applications |
| 13:23.09 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:23.13 | skrusty | because AMI is a nice single point of access |
| 13:23.21 | file | sure, but there's nothing to say that the information it exposes will be the same |
| 13:23.28 | skrusty | a lot of systems use AMI to manage * and its applications |
| 13:23.40 | file | right, because that's the way you could do it in the past |
| 13:23.53 | skrusty | what's the suggested way moving forwards then? |
| 13:24.00 | file | and is a detail of how applications have lived within Asterisk |
| 13:24.06 | skrusty | im not trying to be funny by the way, just trying to understand the "vision" as it were :) |
| 13:24.54 | file | moving forward with that? |
| 13:25.07 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:26.15 | skrusty | AMI and exspoing access to applications, is it recommended then that ARI applications should expose their own restfull endpoints to interact with them? |
| 13:26.19 | skrusty | moveing away from AMI actions etc |
| 13:26.39 | file | I don't think we have a recommendation, but that's what people have generally been doing and personally what I think is a good way |
| 13:27.08 | skrusty | hmmm |
| 13:34.25 | mjordan | skrusty: using your example of QueueAdd - the logic for adding a member to a queue would live outside of Asterisk in the ARI application. There really isn't any way for AMI - which exists inside of Asterisk - to uniformly add a queue member if the logic exists in a user's application |
| 13:34.49 | *** join/#asterisk-dev pc-m (~Thunderbi@modemcable094.94-70-69.static.videotron.ca) |
| 13:35.12 | skrusty | mjordan: cheers, I understand the reasoning, just seems messy :/ |
| 13:35.26 | skrusty | almost like you should be able to use ARI to register actions to endpoints |
| 13:35.45 | skrusty | like AddQueue URI:8088/{x}/{y}/{z} |
| 13:36.19 | mjordan | while that's interesting, it isn't something planned. And you certainly wouldn't want that to be a requirement of the ARI application. |
| 13:36.38 | skrusty | no true |
| 13:36.46 | mjordan | I would suspect that, given time, what AMI is used for will not be things like "AddQueue" |
| 13:37.22 | skrusty | but in principal can you see where i am coming from in terms of disparete systems (again) |
| 13:38.22 | skrusty | i know ARI isn't supposed to cover all - but it seems like in solving one issue (requirement for c applications as modules in asterisk to do things like queues) consessions are being made |
| 13:38.30 | mjordan | the problem is AddQueue isn't "Add to any queue", it is "Add to app_queue" |
| 13:40.17 | mjordan | And AddQueue, or ConfBridgeKick, or any of those - are not core AMI or core Asterisk concepts. They are provided by the dialplan applications themselves |
| 13:41.19 | mjordan | For example, the old MeetMe AMI actions couldn't be used by ConfBridge |
| 13:41.27 | skrusty | sure |
| 13:41.34 | mjordan | so trying to co-opt the existing AMI actions into ARI would be problematic at best |
| 13:42.38 | mjordan | as it is, having an ARI application have the ability to register its own AMI actions (somehow) may have some applicability, but I'm not sure yet how much. It'd certainly be an interesting patch for someone to explore. |
| 13:42.58 | skrusty | lets say for a moment i wanted to duplicate confbridge or app_queue in ARI, how would someone who is "interacting" with asterisk know how to interact with the ARI app? |
| 13:43.14 | mjordan | you control the application, correct? |
| 13:43.23 | skrusty | i wish i had agood c skills, because i can see (from my limited time already with ARI) milage in it |
| 13:43.29 | mjordan | why would you choose AMI as your way of interacting with the application? |
| 13:44.32 | skrusty | hmm - i think the bit i am hitting here is my classic relationship with asterisk in terms of AMI |
| 13:44.32 | mjordan | skrusty: No time like the present to learn C. It is a new year :-) |
| 13:44.37 | skrusty | lol :) |
| 13:44.39 | mjordan | that's fair |
| 13:45.18 | skrusty | it's how do you shirt thinking in terms of AMI/app paradigm to ARI |
| 13:45.22 | skrusty | shift |
| 13:45.23 | skrusty | even :/ |
| 13:45.25 | mjordan | and for what it's worth, I'm a fan of C# :-) So if I were a Microsoft guy, and I had written an app in C# to communicate with Asterisk using ARI, I would probably use WCF or something else for my clients to communicate with my app |
| 13:45.40 | skrusty | webapi ;) |
| 13:45.52 | mjordan | ah, the world has moved on... |
| 13:45.56 | skrusty | wcf is mostly overly complicated |
| 13:46.01 | mjordan | the act of "adding a queue member" is really best done outside of Asterisk |
| 13:46.06 | skrusty | yeah |
| 13:46.06 | mjordan | same thing for "show me the queue stats" |
| 13:46.16 | mjordan | or "how many calls are in my queue" |
| 13:46.24 | mjordan | because the *app* knows that information, not Asterisk |
| 13:46.28 | jsmith | In fact, the entire queue logic should be outside of Asterisk :-) |
| 13:46.40 | mjordan | and if I'm writing it in C#, I should just use Microsoft's way of communicating that back to my Windows clients |
| 13:46.50 | mjordan | or if I'm writing in Java, I should use whatever they use (no idea) |
| 13:47.03 | mjordan | jsmith: exactly! |
| 13:47.05 | file | "Just because it's always been done this way, does not mean it should be or has to be done that way in the future." |
| 13:47.15 | skrusty | :) |
| 13:47.24 | mjordan | skrusty: so that's the theory, at any rate. I admit we're early in the game, so we'll see what people really need |
| 13:47.24 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 13:47.35 | skrusty | yeah |
| 13:48.14 | mjordan | I'm looking forward to a Queue implementation written in something - anything, really - so people can see if they need more complex interactions between their app and Asterisk outside of ARI |
| 13:48.34 | skrusty | my entire understanding of ARI has come about in one week while writing the ARI wrapper for .net so still new to it as a concept and a reality :) |
| 13:48.57 | mjordan | I suspect, given how easy it is to roll things in modern languages - that people will find it easier to write something that works with their app natively rather than trying to deal with the weird-isms of AMI |
| 13:49.02 | mjordan | skrusty: awesome! |
| 13:49.06 | skrusty | well, the main thing is it'll be very easy to have multiple servers on a single queue :) |
| 13:49.39 | mjordan | yup. And implementing your own announcement logic, and admin barging, etc. |
| 13:49.41 | skrusty | AsterNET.ARI - an extension of the current AsterNET (previously ASterisk.NET) framework |
| 13:49.46 | skrusty | yeah |
| 13:49.58 | mjordan | excellent |
| 13:50.06 | skrusty | ooo - one quick question, how would you do something like speaker detection on a channel using ARI? |
| 13:50.15 | skrusty | just one thing i thought this morning and forogt about :) |
| 13:50.45 | mjordan | in general, that would probably be more of a bridge thing |
| 13:51.03 | mjordan | and mostly of interest in a multi-party bridge |
| 13:51.15 | skrusty | yes, like confbridge speaker events |
| 13:51.27 | mjordan | right now, those events could be raised but aren't. It'd be pretty easy to add them |
| 13:51.50 | file | we're going to need more configurability over bridges for that |
| 13:51.55 | mjordan | file: agreed |
| 13:52.12 | mjordan | and on that note, I'm going to have to pop out and actually *go* to work |
| 13:52.16 | mjordan | later all |
| 13:52.20 | *** part/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 13:52.24 | skrusty | l8r m.... |
| 13:52.26 | skrusty | oh :) |
| 13:52.45 | skrusty | would it be a bridge event to subscribe to? |
| 13:53.31 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:54.33 | file | it would probably be an event that goes out on the bridge, yes |
| 13:54.44 | skrusty | cool |
| 13:54.50 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 13:55.20 | skrusty | it's going to make app development for 3rd parties like myself who use c# so much better! |
| 13:59.44 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187.76.181.102) |
| 14:01.02 | *** join/#asterisk-dev pc-m (~Thunderbi@modemcable094.94-70-69.static.videotron.ca) |
| 14:03.44 | file | I'm toying with a slightly crazed strategy for the ast_format_cap structure... |
| 14:06.44 | file | it involves an array and vectors... |
| 14:20.51 | leifmadsen | what will the azimuth be? |
| 14:21.00 | file | 4 |
| 14:21.37 | leifmadsen | sounds right at least |
| 14:22.20 | danjenkins | i cant be bothered to read all of the above stuff between you guys, ive read enough, i agree with skrusty |
| 14:23.09 | danjenkins | I always envisiged (if thats a word) for the ARI application to be able to create AMI actions that allowed someone to use that ARI module |
| 14:23.31 | file | danjenkins, why? |
| 14:24.30 | danjenkins | so that one day you could replace app_queue in standard asterisk, with the ari version, allowing people to still coimmunicate with "asterisk as a whole" via it's communication methods, not just a random http api that the app queue ari module replacement decided to make, which could be a completely different standard to the the one made for the voicemail replacement |
| 14:25.06 | danjenkins | there should be a standard way to interact with asterisk, as the module is part of asterisk, once its being used, do you see what i mean? |
| 14:26.24 | file | unless you define the exact interfaces in AMI for every app, there can't be a standard way - using the ones we've always had as the defacto for those types... meh |
| 14:26.48 | danjenkins | ah but its a standard format and its a standard way of talking to asterisk |
| 14:27.13 | danjenkins | i could have an XML interface into voicemail but a tcp interface into queue |
| 14:27.16 | danjenkins | you get me? |
| 14:27.41 | file | sure, does that make it the right interface? |
| 14:27.44 | file | erm but does that |
| 14:28.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:28.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:29.20 | danjenkins | no |
| 14:29.39 | danjenkins | but i see where skrusty is coming from with all this |
| 14:29.57 | file | I can too, but that doesn't mean it's a good path forward |
| 14:33.13 | file | if you expose via AMI you are confined to what AMI provides, both as a protocol and also as an implementation within Asterisk (user permissions for example), unless you build something on top of it |
| 14:35.36 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 14:38.50 | skrusty | heh :) |
| 14:39.24 | skrusty | i do think registering restfull endpoints via ari that can be excposed via AMI *could* be a good idea |
| 14:47.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.120.122) |
| 14:48.35 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.125.7) |
| 14:50.01 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:50.01 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:56.29 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-ccqdjclynpkjqkjy) |
| 14:56.29 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:56.46 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-ccqdjclynpkjqkjy) |
| 14:59.09 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:00.41 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 15:05.08 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-ccqdjclynpkjqkjy) |
| 15:05.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:15.39 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:3e97:eff:fe14:ef66) |
| 15:23.56 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-uredvxeugrgtscmt) |
| 15:33.07 | *** part/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 15:41.56 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-cgkqjoyevzgjhfld) |
| 15:42.27 | danjenkins | hey, sorry i disappeared |
| 15:43.12 | danjenkins | so yeah, whether or not you could enable communication with your app through the ARI itself, that would aleviate my issues |
| 15:44.54 | danjenkins | so your app has 5 endpoints, but theyre not available from localhost:randomPortForQueueApp 's http interface, but instead available through the one standard, the ARI http://localhost:ariPort/ari/queue/whatever |
| 15:45.52 | mjordan | danjenkins: I probably missed the context of that when I was eating breakfast. |
| 15:46.31 | danjenkins | yeah you had disconnected... |
| 15:46.32 | jsmith | Breakfast?!? That's a great idea! I think I'll grab another! |
| 15:46.33 | mjordan | are you thinking of having ARI (through Asterisk) have URI callbacks back into the application, such that an application can extend resources? |
| 15:46.33 | file | mjordan, more talk about AMI ARI ness |
| 15:46.42 | mjordan | jsmith: elevensies |
| 15:46.46 | danjenkins | one sec |
| 15:46.57 | jsmith | mjordan: Here in Eastern Standard Time, yes... |
| 15:47.08 | mjordan | ah. I'm just on second breakfast |
| 15:47.15 | jsmith | mjordan: But since you're in Central... |
| 15:47.56 | file | I'm on "Drink diet coke to keep myself going" |
| 15:50.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.148) |
| 15:50.48 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@212.34.52.66) |
| 15:52.36 | mjordan | hum hum hm. danjenkins: skrusty: this is one of those ideas that I think should be thought about some more. I definitely wouldn't want to try and force an AMI action provided by app_queue to forward its information to an ARI application, but that doesn't mean there isn't some way for an ARI application to register itself as the handler for an AMI action it defines. |
| 15:52.47 | mjordan | I honestly have no idea how that would work exactly, or if it is really needed |
| 15:53.10 | mjordan | But this feels like one of those things we should keep in the back of our head when someone (anyone?) starts writing an app_queue replacement |
| 15:53.38 | jsmith | mjordan: pabelanger, leifmadsen, and I are already starting down that road (mostly pabelanger) |
| 15:54.04 | leifmadsen | if you're trying to modify app_queue to do anything ARI, you're doing it wrong |
| 15:54.09 | mjordan | if someone has some more concrete ideas of how that would look from an end user of the APIs perspective and would want to throw it out on the app-dev list, it'd be good to get the conversation rolling there in a slightly more formal sense |
| 15:54.16 | mjordan | leifmadsen: I don't think that is what they're proposing |
| 15:54.19 | leifmadsen | ok :) |
| 15:54.20 | leifmadsen | just saying. |
| 15:54.45 | mjordan | leifmadsen: more like, how can I make it so that my ARI application looks like a dialplan application from the perspective of an AMI client |
| 15:54.55 | leifmadsen | jsmith: would you come down in March for the summit? |
| 15:55.14 | jsmith | leifmadsen: I'm trying to -- still depends on my budget numbers |
| 15:55.25 | jsmith | leifmadsen: I'd like to come (with a co-worker) if possible |
| 15:55.30 | leifmadsen | I hear ya. If it's cheaper, you're welcome to fly into Toronto and I can pick you up, and we can drive to Ottawa together |
| 15:56.11 | jsmith | OK, we'll see |
| 15:56.17 | leifmadsen | sounds good, just wanted to throw that out there |
| 15:56.32 | leifmadsen | could split on the room too if you don't mind me hanging around :) |
| 15:56.35 | danjenkins | i want to get involved with app queue rewrite, like i said i was going to, but things got in the way, like a damn new job, oh and then another |
| 15:56.46 | skrusty | afternoon |
| 15:56.47 | file | danjenkins, well that's your own fault |
| 15:56.48 | skrusty | again :) |
| 15:56.51 | mjordan | silly full time work |
| 15:56.52 | leifmadsen | it really is. |
| 15:57.07 | danjenkins | :( |
| 15:57.20 | danjenkins | I'd happily try and explain what i mean on app-dev |
| 15:57.23 | skrusty | glad to see my suggestion wasn't totally out there :) |
| 15:57.28 | leifmadsen | danjenkins: just file a jira issue, "Finish distributed queues", and mark the business impact to like 3000 and the development effort to 300 |
| 15:57.31 | skrusty | danjenkins: i'll contribute my 2cents |
| 15:57.32 | leifmadsen | that should do it |
| 15:57.44 | danjenkins | haha leifmadsen |
| 15:57.45 | Qwell | danjenkins: Don't forget to assign it to file. |
| 15:57.50 | leifmadsen | lol |
| 15:58.01 | mjordan | needs moar fax. |
| 15:58.07 | mjordan | fax through queues. Done. |
| 15:58.08 | Qwell | AMI over fax? |
| 15:58.25 | mjordan | or fax over AMI? |
| 15:58.26 | danjenkins | saying that, thats just reminded me, ast 12 died again but this time with all the things debbuging turned on, i need to add that to the issue |
| 15:58.26 | jsmith | res_stasis_fax.so |
| 15:58.39 | mjordan | vomited slightly in his mouth |
| 15:58.42 | jsmith | Just sayin' |
| 15:58.43 | danjenkins | hell im doing that |
| 15:58.50 | file | FAX FAX FAX |
| 15:59.08 | skrusty | :) |
| 15:59.18 | danjenkins | i mean, it could just register and reply with "you're doing it wrong" for every action |
| 15:59.29 | mjordan | lawl |
| 16:01.35 | skrusty | mjordan: should i bring up the topic of registering actions with AMI via ARI on the mailing list? |
| 16:03.39 | danjenkins | skrusty: can you just explain that a bit more |
| 16:04.09 | skrusty | here? :) |
| 16:04.34 | danjenkins | whereever :D |
| 16:08.51 | skrusty | well, i think it might be useful to be able to register an action (assume AMI for the moment) via ARI, e.g. in the queue analagy, QueueAdd, you could call an ARI endpoint called /RegisterAction and pass a definition (json) that can then be called from AMI. So lets say i add a new definition called QueueAdd, exposed only while my application exists, that in turn when called via AMI raises an ARI event for that action, passing with it the values defined |
| 16:10.06 | skrusty | hmm... ARI gets an AMIAction event with the event name and definition |
| 16:10.28 | skrusty | dunno, maybe im talking crap now... im tired :) |
| 16:12.13 | skrusty | _tumbleweed_ :) |
| 16:12.24 | danjenkins | no i got you |
| 16:12.29 | danjenkins | 1 sec ive just drawn it on some paper |
| 16:12.29 | skrusty | cool :) |
| 16:13.45 | skrusty | yes, they'd be transient |
| 16:13.55 | skrusty | but frameworks should take care of that |
| 16:14.18 | danjenkins | where can i upload a picture |
| 16:14.19 | skrusty | i.e. in the case of asternet it's very easy to add new definitions to actions and events by extended the framework |
| 16:14.23 | skrusty | dropbox? |
| 16:14.29 | skrusty | imgur? |
| 16:15.33 | danjenkins | http://imgur.com/jPmBuzP |
| 16:15.35 | Qwell | skydrive! |
| 16:15.37 | Qwell | glares at file |
| 16:15.45 | file | yay skydrive |
| 16:15.48 | skrusty | looking now |
| 16:16.33 | Qwell | is this just so you can use existing AMI applications with ARI queue? |
| 16:16.47 | skrusty | not _just_ |
| 16:17.12 | danjenkins | skrusty: is that what you were saying, as thats exactly what i was trying to say, i think! |
| 16:17.15 | skrusty | but don't dismiss the amount of work people have put into applications that sit 100% on top of AMI |
| 16:17.30 | skrusty | danjenkins: yeah, that looks like a good description of it! |
| 16:17.48 | Qwell | well, sure, we've written a bunch of stuff that fits that |
| 16:18.00 | skrusty | Qwell: interesting... go on? :) |
| 16:18.16 | danjenkins | and yeah not just ami, i want a standard way of interacting with anything which "is essentially a part of asterisk" |
| 16:18.18 | Qwell | But, really, unless you can 100% emulate the existing app_queue, it's not really going to work. |
| 16:18.26 | pabelanger | leifmadsen, jsmith: Indeed! |
| 16:18.47 | pabelanger | queue logic needs to be outside of Asterisk, not inside |
| 16:18.50 | Qwell | skrusty: AMI apps, I mean |
| 16:18.56 | danjenkins | ok so if you move away from "allow ami to talk to app_queue replacement" |
| 16:19.46 | danjenkins | just to, how does an app talk an ARI application |
| 16:20.21 | danjenkins | we're not all going to write our own app_queue, we'll use a nice open source one, that may or may not become part of asterisk later in life |
| 16:20.43 | skrusty | danjenkins: exactly |
| 16:20.53 | danjenkins | you write into configuration wherever that is how you want replacement app_queue to work |
| 16:20.55 | danjenkins | tahts fine |
| 16:21.15 | danjenkins | but I want my external application written on top of all of this to know when a user joins a queue |
| 16:21.20 | pabelanger | skrusty, have you seen: http://payload.readthedocs.org/en/latest/api/index.html |
| 16:21.24 | danjenkins | right now, you'd get that from ami |
| 16:21.26 | skrusty | say tomorrow i write a conf ari application, and overnight it's the number 1 conf bridge. now a dev who uses AMI to talk to meetme or confbridge now shouldn't have to start using somethig different JUST to talk to my new app |
| 16:21.37 | skrusty | pabelanger: looking now |
| 16:22.17 | pabelanger | our concept is you would not interface into Asterisk (AMI) to get information, but use an interface we are building |
| 16:22.24 | Qwell | I would argue that yes, it should have to be something different. |
| 16:22.33 | pabelanger | that way your asterisk boxes are generic as possible, and if they disappear, you don't loose the data |
| 16:24.35 | danjenkins | hmmm see i disagree |
| 16:24.41 | danjenkins | i agree about ami |
| 16:25.05 | *** join/#asterisk-dev Pullphinger (~Pullphing@12.40.23.68) |
| 16:25.11 | danjenkins | but your standard asterisk developer doesnt care if app_queue is internal to asterisk or not |
| 16:25.21 | danjenkins | theyre just using it, and it so happens to be asterisk that they are using |
| 16:26.26 | danjenkins | in the long run, your app queue replacement might replace app_queue in asterisk, asterisk might release two versions of asterisk - one without any ari modules and one tghat is asterisk as it is today, but with 0 modules built in c, theyre all external processes using the ari, but they dont know that and they dont care |
| 16:26.54 | danjenkins | theyre just using asterisk |
| 16:27.02 | danjenkins | "asterisk" as they see it |
| 16:27.31 | pabelanger | a smrt man would make the app_queue replacement not asterisk specific, and allow you to use any SIP interface |
| 16:27.53 | danjenkins | as soon as you say they have to get info about queues from http interface on port x and they have to get voicemail information from port y and they have two different interfaces, that's just crazy |
| 16:28.04 | file | what you really want is a location service or a proxy |
| 16:28.13 | pabelanger | file, exactly |
| 16:28.15 | skrusty | the other issue i see, is, if ARI were replacing (again we'll keep with app_queue) i need to know where that ARI is located in order to talk to it... now i might write something for customer x. Is there ARI on their local asterisk box, remote? Can i see it from my applications location? If i expose my actions via AMI, it doesn't matter. I only need to see AMI. |
| 16:28.25 | skrusty | file: yes i guess so |
| 16:28.41 | skrusty | i did consider something like that eaelier today |
| 16:28.49 | danjenkins | yeah, as i wrote in my diagram, a proxy of sorts |
| 16:28.54 | skrusty | danjenkins: yeah |
| 16:29.09 | pabelanger | skrusty, We are going to use a message bus to communicate to ARI. So you don't really care where it lives, you just care it is attached to the bus |
| 16:29.35 | pabelanger | then each local asterisk box runs ARI to convert from AMQP to ARI |
| 16:29.36 | pabelanger | and back |
| 16:30.19 | pabelanger | It would be cool if asterisk stasis wrote to an external message bus, so we could access everything |
| 16:34.04 | mjordan | that wouldn't be hard, but the choice of which message bus could become constraining. |
| 16:34.33 | Qwell | mjordan: which one doesn't matter, as long as it's blue |
| 16:34.36 | mjordan | there is a *lot* of code in Asterisk 12 that demonstrates how to subscribe to Stasis, convert a message to JSON, and publish it out something else |
| 16:34.39 | mjordan | Qwell: exactly |
| 16:35.05 | mjordan | I would hope that someone would be able to look at manager_channels/manager_bridges/manager_* and be able to replicate that for, say, Redis |
| 16:37.53 | mjordan | (not to mention we actually documented the crap out of the Stasis APIs) |
| 16:38.12 | ipengineer | Hello everyone! Are there any known issues with playing hold music on a queue in 12? The console is showing music to be playing but it is not. If I answer the call and the place it back on hold the music is played.. https://gist.github.com/zconkle/b65de489b4b881e14183 |
| 16:39.12 | mjordan | ipengineer: nope, that's not known. If you can, please file a bug on issues.asterisk.org - but we'll need the full debug log for that |
| 16:39.30 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information |
| 16:39.38 | ipengineer | mjordan: Ok will do |
| 16:41.47 | pabelanger | AMQP would be better then redis, but ya I get the idea |
| 16:43.17 | pabelanger | Might sponsor some work on it once things get back to normal over here |
| 16:45.12 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187.76.181.102) |
| 16:46.13 | file | when is that queue shindig thing again? |
| 16:46.33 | skrusty | queue shindig? :) |
| 16:46.45 | skrusty | does everyone sit around waiting their turn? :D |
| 16:47.05 | file | skrusty, a get together in Ottawa for pabelanger's queue replacement |
| 16:47.11 | skrusty | ah nice |
| 16:47.14 | skrusty | shame i live in the uk :/ |
| 16:48.05 | skrusty | ah, that's payload right? |
| 16:48.06 | pabelanger | Aiming for mid march |
| 16:48.10 | pabelanger | ya |
| 16:48.28 | skrusty | is it on git? |
| 16:48.32 | skrusty | or just in planning? |
| 16:48.39 | pabelanger | Going to send out official details of the event later this week |
| 16:48.49 | pabelanger | https://github.com/kickstandproject/payload |
| 16:48.56 | pabelanger | is the backend |
| 16:49.19 | skrusty | interesting |
| 16:51.23 | pabelanger | we are still deciding on the device state integration, but initial testing is we are going to use a proxy for it (kamailio) |
| 16:51.31 | pabelanger | and just have asterisk handle media playback |
| 16:51.36 | skrusty | ah right |
| 16:51.49 | skrusty | seperate out the devices, hmm |
| 16:52.24 | skrusty | now i am upset i don't live closer! :D |
| 16:52.40 | skrusty | sounds really interesting |
| 16:53.03 | pabelanger | We'll likely have remote options |
| 16:53.11 | pabelanger | voice / video |
| 16:54.03 | skrusty | cool |
| 16:57.53 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 17:31.29 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-zpavsjtgzhwyempd) |
| 17:31.29 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:39.11 | mjordan | sgriepentrog: If you can, go ahead and commit https://reviewboard.asterisk.org/r/3116/ and https://reviewboard.asterisk.org/r/3109/ as soon as possible - that should let me cut RCs of 1.8 and 11 |
| 17:52.31 | elguero | mjordan: a belated Thanks! |
| 18:00.51 | danjenkins | if someone wants to fly me out there, ill come pabelanger ;) |
| 18:01.10 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 18:01.35 | pabelanger | danjenkins, get sponsored by digium! |
| 18:01.36 | pabelanger | :) |
| 18:01.51 | danjenkins | when is it? |
| 18:02.05 | pabelanger | We look to be about 7 people strong |
| 18:02.27 | pabelanger | Confirming things on my side, but likely Mar. 22nd and 23rd |
| 18:16.20 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 18:16.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:29.31 | file | hum hum hum |
| 19:19.34 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 19:22.24 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-bnguxezenrxoytyd) |
| 19:33.00 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 19:34.53 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:34.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:45.54 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 20:02.38 | skrusty | digium can sponsor me! :D |
| 20:37.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.120.122) |
| 20:51.15 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 21:18.53 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 21:18.53 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 21:42.59 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 22:08.24 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:30.53 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 22:53.03 | *** join/#asterisk-dev bklang (~bklang@coquette.alkaloid.net) |
| 22:59.28 | bklang | hello all. I've got a system that is periodically (was daily, then 3 times in 1 hour today) leaking memory |
| 22:59.49 | bklang | it's stable for long periods then suddenly (matter of seconds) it consumes all available RAM |
| 22:59.54 | bklang | I do have a coredump, it's 25GB |
| 23:00.20 | bklang | I was also able to extract backtraces, though my very-untrained eye isn't seeing much interesting. |
| 23:02.34 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:02.34 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:06.24 | newtonr | bklang, i'd pastebin the traces (bt, bt full) so someone can take a look when they are able, or else put it up on a JIRA issue and post the link |
| 23:06.33 | bklang | ok |
| 23:06.51 | coreyf1513 | bklang: what version are you running? |
| 23:08.17 | bklang | https://gist.github.com/bklang/056416c1b7e1e15b6fe1 |
| 23:08.43 | bklang | asterisk11-11.7.0-24_centos6.x86_64 running on FreePBX distro 2.11.0.11 |
| 23:09.04 | bklang | the system is exposed to the internet (I know, I know....I keep telling them to turn it off) |
| 23:09.55 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-siavqtmhdcwrdeee) |
| 23:10.10 | bklang | what's strange is how fast it crashes |
| 23:13.20 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:13.21 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:24.15 | mjordan | bklang: if you don't mind, toss it up on an issue in JIRA. It isn't anything I've seen before |
| 23:24.40 | pabelanger | doesn't valgrind help track leaks too? |
| 23:25.02 | pabelanger | can't remember the document but thought it talked about asterisk and memory leaks |
| 23:25.04 | mjordan | it can, but it'll slow it down pretty harshly |
| 23:25.13 | mjordan | can => does |
| 23:25.24 | pabelanger | nods |
| 23:25.27 | mjordan | MALLOC_DEBUG can find leaks a bit more efficiently |
| 23:25.33 | bklang | this is a pretty busy production system, unfortunately. I can't do anythign that's going to have a big impact on performance |
| 23:25.34 | pabelanger | maybe that is it |
| 23:25.36 | mjordan | although you'll need to issue a few CLI commands |
| 23:25.50 | bklang | though as much as it crashes I'm willing to run with scissors a bit |
| 23:26.22 | mjordan | bklang: so, two options: |
| 23:26.28 | mjordan | compile with MALLOC_DEBUG |
| 23:26.34 | mjordan | that will enable some CLI commands |
| 23:26.50 | mjordan | goes to look them up |
| 23:28.13 | mjordan | memory atexit summary [byfile | byfunc | byline] |
| 23:28.22 | mjordan | you'd want to run that there times, one for each. They're cumulative. |
| 23:28.35 | bklang | ok |
| 23:28.43 | mjordan | I'd let the server run and monitor the memory. As it tacks up, I'd wait a bit so we get enough data |
| 23:28.46 | bklang | I'll probably have to go get approval to install a rebuilt executable |
| 23:28.48 | mjordan | then, issue a shutdown (which will suck) |
| 23:28.49 | bklang | it's FreePBX |
| 23:29.01 | mjordan | thought those macros looked familiar... |
| 23:29.01 | bklang | when it crashed last time the CLI was unresponsive |
| 23:29.06 | bklang | I had to get a coredump by kill -SEGV |
| 23:29.09 | mjordan | yeah, it actually crashed in the CLI |
| 23:29.10 | mjordan | ah |
| 23:29.15 | mjordan | well, that explains why it died in the CLI |
| 23:29.17 | pabelanger | asterisk -rx "foo bar" might work |
| 23:29.55 | mjordan | MALLOC_DEBUG is a lot less nasty then valgrind, and gives us a pretty good idea as to what is leaking - but you have to shut down to get the report |
| 23:30.18 | mjordan | that will produce the memory debug log file /var/log/asterisk/mmlog |
| 23:30.33 | mjordan | the mmlog file is the one that will contain the information, although you should get a list as well |
| 23:30.51 | bklang | ok, I'll see if they'll let me install a debug package tomorrow |
| 23:31.12 | bklang | though I'm still not convinced I'll be able to attach to the console to stop it. I guess we'll see |
| 23:33.49 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-ccqdjclynpkjqkjy) |
| 23:39.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.201) |
| 23:45.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.201) |
| 23:55.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.142) |