| 00:01.58 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 00:01.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 00:11.54 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 00:27.05 | *** join/#asterisk-dev suneye (~atcmmi@119.122.152.6) |
| 00:53.21 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:36.33 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:38.15 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 01:38.15 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 02:44.32 | snuff-work | opticron: your doing stasis/stasis http stuff right? |
| 02:59.18 | opticron | snuff-work, I'm doing all kinds of stuff, focusing on bridge/res_stasis/app_stasis/stasis_http at the moment |
| 03:07.49 | snuff-work | now with stasis.. that's basically the new 'manager/ami' or am i getting them slightly mixed up |
| 03:10.30 | opticron | depends on which stasis you're talking about |
| 03:10.36 | opticron | :) |
| 03:10.47 | opticron | there's Stasis-Core which is the internal messaging bus |
| 03:11.01 | opticron | there's Stasis-HTTP which is a command/response interface |
| 03:12.07 | opticron | there are stasis applications which are exposed to events, one interface of which is websocket |
| 03:15.05 | snuff-work | ok.. so ami is being restructured to use 'stasis' for events right? |
| 03:15.32 | opticron | stasis-core, yes |
| 03:16.25 | opticron | because most of the information that AMI consumes for generating events is useful elsewhere for other purposes |
| 03:19.15 | snuff-work | so the 'stasis http'.. and say 'show endpoints'.. if i submit that query via json or whatever.. id get back a list of things atm ? |
| 03:20.24 | opticron | take a look at rest-api/api-docs/endpoints.json for the json description of the interface |
| 03:20.38 | opticron | it's not going to be 'show endpoints' |
| 03:21.39 | opticron | it'll probably be a GET request on http://localhost:8088/stasis/endpoints |
| 03:22.03 | snuff-work | k.. |
| 03:23.31 | snuff-work | that displays what the return data will look like.. aka for a stasis/endpoint/mine.. it will just pump out whatever the internal variable names are within a endpoint struct ? |
| 03:23.37 | snuff-work | or we still need to do the mapping |
| 03:23.57 | opticron | the response structures are defined as models |
| 03:25.08 | snuff-work | those models are where? |
| 03:25.15 | opticron | also in the json |
| 03:25.18 | opticron | look down further |
| 03:25.29 | snuff-work | just doing svn up atm.. ;) |
| 03:25.37 | opticron | the response type will be defined for the query |
| 03:26.02 | opticron | for the GET requests, either Endpoint or List[Endpoint] |
| 03:26.11 | snuff-work | just seeing if there is possible 'leg work' stuff.. i could do |
| 03:26.59 | opticron | further down in the endpoints.json file, there will be a models definition that has a Endpoint entry |
| 03:28.05 | snuff-work | k.. i see a 'model' |
| 03:28.32 | snuff-work | dont see any 'reply' part.. or i'm not getting it |
| 03:30.37 | Juggie | the problem with asterisk input/output is asterisk :) |
| 03:31.21 | snuff-work | ello Juggie |
| 03:31.23 | Juggie | theres no easy solution but the fact that each modules, eg confbridge like was mentioned even need to give 2 shits what ami/agi/cli/csv/json/http etc is, is the major suck |
| 03:31.40 | Juggie | modules need to have input/output |
| 03:31.53 | Juggie | how the output is formatted should not be chan sips problem |
| 03:31.56 | Juggie | or any other modules problem |
| 03:32.18 | Juggie | its a total overhaul |
| 03:32.22 | Juggie | but its the right fix. |
| 03:32.33 | snuff-work | gives up on stasis stuff.. not understanding.. goes back to doing paid work.. and cli cmds later |
| 03:32.51 | Juggie | snuff-home, me either :0 |
| 03:33.27 | snuff-work | i get 'part' of it.. but i'm still miles off ;) |
| 03:35.29 | Juggie | i wonder how far statis is along on the direction of removing all output from modules |
| 03:35.35 | Juggie | or if its even going in that direction |
| 03:37.02 | Juggie | in the end under the assumption that statis is useful |
| 03:37.07 | Juggie | i'd never interface with it directly |
| 03:37.38 | Juggie | one would simply write a redis or ampq proxy and dump all events into a common message bus for all of your servers |
| 03:38.23 | snuff-work | i really dont care.. i was just interested if i could help add more 'stasis stuff' grunt work |
| 03:38.40 | snuff-work | i have no intention of using it.. i have no need.. |
| 03:38.47 | snuff-work | no need for even ami |
| 03:39.06 | Juggie | same |
| 03:39.23 | Juggie | everything i/we do with asterisk now is done via fastagi |
| 03:39.28 | Juggie | asterisk is just a gateway into fastagi |
| 03:39.51 | Juggie | and everything is implemented in there |
| 03:40.22 | Juggie | some claim agi sucks but i'd argue its quite stable and fine |
| 03:52.27 | snuff-work | mm.. i dont even use that.. because i work at a simple SMB office style.. no queue crazyness etc |
| 03:55.07 | Juggie | ya we just use asterisk as an ivr platform |
| 03:55.12 | Juggie | not office pbx |
| 03:55.24 | Juggie | its not so much the platform though as the gateway |
| 05:58.54 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1006) |
| 05:58.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:32.49 | *** join/#asterisk-dev bulkorok (~chatzilla@gw1.pinguin.ag) |
| 06:39.12 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:39.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:18.11 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1006) |
| 07:18.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:18.33 | oej | Morning folks |
| 07:37.08 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1007) |
| 07:37.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:39.02 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 08:06.47 | snuff-work | mornin oej |
| 08:07.45 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1007) |
| 08:07.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:41.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:41.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:23.32 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:49.32 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 11:49.32 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 11:57.20 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:57.20 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:02.47 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:56.12 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xszemvoaisurmssy) |
| 13:04.35 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:04.35 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:45.00 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:53.35 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-rsviycqngevifdzz) |
| 13:55.53 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-nmolshkpbwxneusx) |
| 13:55.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:02.17 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:02.17 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:02.30 | oej | mjordan: Hi! |
| 14:29.04 | mjordan | oej: good morning/afternoon/evening! |
| 14:41.25 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:48.07 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 15:11.15 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:11.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:39.23 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 15:39.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:40.07 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:08.50 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 17:08.50 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 17:16.29 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:16.29 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:16.17 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:16.17 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:38.15 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:49.42 | opticron | leedm777, ping |
| 18:49.47 | leedm777 | pong |
| 18:50.11 | opticron | would you say that stasis-http-created bridge should always be associated with a stasis application from creation time? |
| 18:51.07 | opticron | currently, the API has it floating in the bitbucket with soft associations to stasis applications |
| 18:51.12 | leedm777 | as in the app is subscribed to the bridge's topic? |
| 18:51.34 | opticron | as in the app owns the bridge from creation time |
| 18:51.46 | opticron | not necessarily an additional subscription |
| 18:52.15 | leedm777 | What would it mean for an app to own a bridge, other than the subscription? |
| 18:53.11 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 18:53.11 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 18:53.12 | leedm777 | Maybe listing all the bridges for an app... |
| 18:53.35 | opticron | the app would be the only thing that had a direct pointer to the bridge other than the bridging core |
| 18:54.12 | leedm777 | Why would the app need that pointer? |
| 18:54.47 | opticron | let me put it this way: would you ever expect one application to throw one of its channels into a bridge, and then another application throws one of its channels into that same bridge? |
| 18:55.10 | leedm777 | I expect our users to try and to anything and everything :-D |
| 18:55.20 | opticron | ok, that's what I was looking for |
| 18:55.26 | opticron | code stays as-is |
| 18:56.08 | leedm777 | works for me |
| 18:56.28 | opticron | prepares to push things to reviewboard |
| 19:44.37 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 20:12.00 | pabelanger | So, not sure I am asking this correctly, but... if I have two channels bridged together (via dial) and I know the uniqueid of one channel, how can I get the uniqueid of the other channel I am bridge too? |
| 20:14.10 | mjordan | over AMI? |
| 20:14.15 | mjordan | or something else? |
| 20:14.35 | pabelanger | well, it this cause from within asterisk |
| 20:14.42 | pabelanger | EG: app_foo |
| 20:15.02 | pabelanger | I can give more details if needed but it is a sloppy app I have inherited |
| 20:15.14 | russellb | what * version |
| 20:15.22 | pabelanger | 1.4 :( |
| 20:15.48 | russellb | ast_bridged_channel(chan)->uniqueid |
| 20:16.15 | pabelanger | cool |
| 20:16.32 | russellb | there be dragons |
| 20:16.54 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:16.54 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:16.55 | pabelanger | okay, reading up on it now |
| 20:18.46 | mjordan | lots of dragons |
| 20:19.06 | mjordan | also: that function has just died a silent death in trunk |
| 20:19.48 | pabelanger | Ya, this app will die a fiery death. It will never get ported if I have a say |
| 20:20.42 | Qwell | Am I missing something, or do I need to put a bunch of code into the core, if I want to publish a channel event from an app? |
| 20:21.13 | mjordan | welp. |
| 20:21.20 | mjordan | yes? |
| 20:21.43 | mjordan | it kind of depends. You can do it all from the app, but it ends up going app -> stasis -> AMI at that point |
| 20:21.46 | mjordan | all within the app |
| 20:22.05 | mjordan | the other option is to push the topics/message types to core, and the app just raises them |
| 20:22.11 | mjordan | theoretically, any app can raise them however |
| 20:22.14 | Qwell | The fancy type macros (DEFN, INIT, etc) don't work unless they're exported |
| 20:22.27 | mjordan | they probably should be |
| 20:22.54 | mjordan | if something other than your application may want to produce/consume those messages, then it goes in core. |
| 20:23.01 | mjordan | If only your app wants them, keep it in the app |
| 20:30.27 | leedm777 | mjordan: app specific types shouldn't be in core; they should go in the app. |
| 20:41.43 | mjordan | leedm777: perhaps I wasn't clear enough; that was what I was implying. If only your application needs the message type, the message type should be defined in the application and it should be raised and consumed within that application module. |
| 20:42.32 | leedm777 | mjordan: and if the app wants to expose the message type? |
| 20:43.29 | mjordan | leedm777: In that case, there's two options: put it in core or export symbols. I dislike the second in some cases, because you're creating dependencies between the producer/consumer that may not work out well. It certainly doesn't work well if a consumer is in core. |
| 20:44.21 | leedm777 | True, if the consumer is in core, then the type should be in core. |
| 20:44.59 | leedm777 | But we should be able to avoid littering core with lots of app-specific types. |
| 20:45.47 | mjordan | Unfortunately, the most common consumer is AMI. |
| 20:46.20 | leedm777 | Methinks, then, that types need a vtable with a to_ami method, then. |
| 20:46.48 | *** join/#asterisk-dev alecdavis (~alecdavis@210.48.127.227) |
| 20:46.50 | mjordan | or else types need to be registered. |
| 20:46.54 | Qwell | points out ast_manager_publish_message() |
| 20:47.18 | mjordan | yeah. It's a cop out. |
| 20:47.19 | Qwell | (and _publish_event(), which I've added for app_queue) |
| 20:47.54 | Qwell | Should that not exist then? |
| 20:49.47 | alecdavis | when are we releasing asterisk-11.5.0-rc1? I was asked in bug report ASTERISK-21787. |
| 20:52.01 | leedm777 | Qwell: ast_manager_publish_message() has a purpose, but it shouldn't be overused. It's for the cases where there's some legacy AMI event that's not interesting to anything but AMI, and doesn't really deserve its own type. |
| 20:53.01 | Qwell | Such as? |
| 20:53.05 | leedm777 | Qwell: But in the cases where the event is interesting enough that it deserves its own type, sending out a ast_manager_publish_message() with the same data seems silly. |
| 20:53.36 | leedm777 | mjordan knows. |
| 20:53.50 | leedm777 | It's interesting that the function is in trunk, but no one is using it yet. |
| 20:54.12 | leedm777 | Maybe it was some silly one-off events from voicemail |
| 20:56.31 | *** join/#asterisk-dev alecdavis (~alecdavis@202.36.76.21) |
| 20:58.16 | mjordan | one that comes to mind is the app_minivm notification that an external system was notified of an MWI change. |
| 20:58.41 | russellb | that's like ... the ast_debug() of AMI events |
| 20:58.52 | mjordan | heh |
| 20:59.09 | mjordan | the 'system' ones for fully booted and shutdown I pushed onto that as well (reload too I think) |
| 20:59.20 | mjordan | they happen one time and the data being conveyed is relatively arbitrary |
| 20:59.46 | mjordan | really, it feels like we're trying to create public information in the producers and share that information with the consumers. Since both consumers and producers are loadable modules, you're going to run into dependency problems at some point. |
| 21:00.34 | mjordan | alecdavis: there's a bug in the branches right now. A patch went in that makes Queue do announcements to callers in the first position. Unfortunately, that can prevent the agent from hearing the caller. |
| 21:00.47 | mjordan | alecdavis: so that has to get tweaked up before we do the RC. |
| 21:42.15 | alecdavis | mjordan: thanks. what release/review was that? |
| 21:42.54 | alecdavis | mjordan: 'that' being the patch that broke the branches. |
| 21:53.46 | mjordan | ASTERISK-21782 |
| 21:53.46 | LieutPants | [ASTERISK-21782] [Status: Open] Delayed audio to agent when answering a queue call - https://issues.asterisk.org/jira/browse/ASTERISK-21782 |
| 22:35.03 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:35.03 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:35.25 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-nmolshkpbwxneusx) |
| 23:06.29 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 23:30.17 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |