| 00:00.50 | pabelanger | okay, so it looks like you cannot POST json to ARI |
| 00:00.57 | pabelanger | hopefully we can fix that |
| 00:36.56 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 00:36.56 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:50.12 | *** join/#asterisk-dev suneye (~atcmmi@116.7.103.132) |
| 06:40.39 | *** join/#asterisk-dev otherwiseguy (otherwiseg@nat/redhat/x-xqqtsiifsoaqoycf) |
| 07:46.16 | *** join/#asterisk-dev kesselklopfer79 (~kesselklo@astaro.starface.de) |
| 10:07.35 | *** join/#asterisk-dev otherwiseguy (otherwiseg@nat/redhat/x-mawelsigeszgxgfp) |
| 10:33.37 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:33.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:49.03 | *** join/#asterisk-dev Greenlight (~wluke@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 11:11.26 | *** join/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 11:36.57 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 12:20.05 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 12:23.54 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:23.55 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:29.29 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:29.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:47.47 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:47.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:49.55 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:53.01 | sruffell | zerohalo: sorry I missed your question from Friday. |
| 13:01.20 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 13:09.11 | *** join/#asterisk-dev zpotoloom (~tom@tom.data.ee) |
| 13:11.51 | *** join/#asterisk-dev thecardsmith (~doug@unaffiliated/protocoldoug) |
| 13:18.45 | *** join/#asterisk-dev zigg (~matt@unaffiliated/zigg) |
| 13:32.01 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-69-214.user.veloxzone.com.br) |
| 13:32.25 | *** join/#asterisk-dev otherwiseguy (otherwiseg@nat/redhat/x-vprurandnbucvngs) |
| 13:32.48 | *** topic/#asterisk-dev by file -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- AstriDevCon completed successfully. |
| 13:33.44 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-pklyaccgnwdiybnx) |
| 13:33.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:48.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:48.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:06.14 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-kgtdxpyuuuoqdwel) |
| 14:21.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 14:23.03 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jumvsdmdpbpbpmgr) |
| 14:23.08 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jumvsdmdpbpbpmgr) |
| 14:23.27 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jumvsdmdpbpbpmgr) |
| 14:25.31 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 14:27.45 | *** join/#asterisk-dev tensai (~tensai@174-126-39-53.cpe.cableone.net) |
| 14:37.09 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-vozcjkvckmblkwee) |
| 14:46.57 | pabelanger | file, Did I remember correctly that you can pass a lifetime when creating a bridge, or am I making that up. |
| 14:47.27 | file | you mean an exact lifetime that the bridge will live for? |
| 14:47.51 | pabelanger | right |
| 14:47.57 | pabelanger | or |
| 14:48.11 | file | not... really... no |
| 14:48.12 | pabelanger | lifetime of being empty, then it destroys itself |
| 14:48.35 | file | that's possible at the bridge API |
| 14:48.43 | pabelanger | basically, a bridge can live forever is what I am seeing |
| 14:48.49 | file | in ARI, yes |
| 14:48.59 | pabelanger | okay |
| 14:49.05 | file | you control the lifetime of that bridge |
| 14:49.16 | file | if you want it to die after a specific period of time, create a timer in your app |
| 14:49.20 | pabelanger | Right |
| 14:49.27 | file | or if you want it to die when someone hangs up, do so |
| 14:51.37 | *** part/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-vozcjkvckmblkwee) |
| 14:51.52 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-vozcjkvckmblkwee) |
| 15:07.01 | *** join/#asterisk-dev danjenkins (~danjenkin@80.1.94.250) |
| 15:12.14 | file | hrm |
| 15:12.33 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 15:17.43 | pabelanger | <PROTECTED> |
| 15:22.28 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-rephaaqxlauybhjk) |
| 15:33.52 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 15:40.34 | danjenkins | pabelanger: WOOP |
| 15:40.50 | danjenkins | on a side note, im leaving my current place of work (where asterisk-dev mailing list gets sent) |
| 15:41.05 | danjenkins | do i have to unsubscribe and resubsribe |
| 15:41.14 | danjenkins | or can i just change the email address somewhere? |
| 15:41.14 | Qwell | danjenkins: yes |
| 15:41.27 | danjenkins | thanks Qwell |
| 15:42.15 | Qwell | actually, I lied |
| 15:42.21 | danjenkins | oh no, i just logged in and you can change it! |
| 15:42.23 | danjenkins | :) |
| 15:42.34 | Qwell | wish I'd have known that when I switched. oh well |
| 15:44.16 | danjenkins | it's supposedly changed it for my other subscriptions too...hopefully |
| 15:48.00 | pabelanger | danjenkins, Yes, the gibson is being hacked |
| 16:16.46 | *** join/#asterisk-dev datachomper (~datachomp@nat/digium/x-ypfxjaxalklsrmth) |
| 16:35.05 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:35.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:48.53 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:48.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:52.50 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:91cb:2e60:b0ed:77f8) |
| 16:53.42 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:91cb:2e60:b0ed:77f8) |
| 16:54.40 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 16:55.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:55.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:38.55 | *** topic/#asterisk-dev by file -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- AstriDevCon completed successfully. -=- Follow on Twitter at @AsteriskDev |
| 17:55.29 | mjordan | hm. We need to have a discussion on the mailing list about chanspy functionality in ARI. |
| 17:55.46 | mjordan | leedm777: the more I think about it, the more it feels like hacking existing ChanSpy functionality into ARI is... a hack. |
| 17:56.19 | mjordan | It doesn't really give you a good upgrade path from whisper mode, where the spyer receives all audio from a bridge but whispers to one channel, to full barge where the spyer becomes a participant |
| 17:56.34 | mjordan | I mean, you can do it, but it just feels like we're using the old ways of doing bridging instead of the proper ways. |
| 17:58.56 | leedm777 | mjordan: your reasoning seems sound. |
| 17:59.52 | pabelanger | wouldn't you just add a new listener to a bridge to spy? |
| 18:00.26 | leedm777 | pabelanger: it's the whispering back to certain members of the bridge that's the problem. |
| 18:00.38 | mjordan | exactly - you have to have full control over the media paths |
| 18:00.47 | pabelanger | OIC |
| 18:00.48 | mjordan | and if we *did* do that, imagine the goofy crap you could do |
| 18:01.16 | mjordan | almost a "addPath/removePath" for specific bridges, where you could specify where you wanted your media to go |
| 18:01.40 | mjordan | but it would be a new bridge multi-mixing technology |
| 18:01.50 | mjordan | polluting softmix with this is probably not a Good Idea |
| 18:01.59 | mjordan | will write something up |
| 18:02.39 | leedm777 | yeah, email would probably be better for that type of discussion. |
| 18:03.27 | file | BRIDGE ALL THE THINGS |
| 18:07.41 | mjordan | file: for some reason, I thought you had a patch that resolved part of ASTERISK-22628 |
| 18:10.47 | file | ummm |
| 18:11.13 | file | Mark did |
| 18:11.34 | file | it was the issue where the bridge has 3 channels in it, but the code assumed only 2 would ever be present |
| 18:13.03 | pabelanger | leedm777, is there any wiki page about how filtering, searching. sorting JSON responses will happen? Or if? |
| 18:14.35 | mjordan | file: right |
| 18:14.52 | mjordan | putnopvut: do you know if all of ASTERISK-22628 got fixed? |
| 18:15.41 | leedm777 | pabelanger: nope. you have a specific use case in mind? |
| 18:16.38 | putnopvut | loooks |
| 18:16.51 | leedm777 | pabelanger: ooo. I bet you mean the responses that returns lists, right? |
| 18:17.01 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-vytnbgpdszrhjnus) |
| 18:18.43 | putnopvut | mjordan: I fixed that to an extent, but after a conversation with opticron this morning, it's entirely possible that all I did was cover up the problem (due to a 'dummy' bridge pointer being passed to bridge technology leave callbacks). opticron has another patch that he's written that may go further towards getting it correct. |
| 18:19.18 | putnopvut | Whether it's fixed entirely, I'm not 100% sure. |
| 18:19.45 | leedm777 | pabelanger: in general, it doesn't make sense for Asterisk to do the sorting. you're better off spending cycles in the application server sorting the list than asking Asterisk to do it for you. Filtering makes sense, but we don't have any plans for that right now. Not sure what you mean by searching. |
| 18:20.16 | mjordan | putnopvut: np, I'll keep it open then |
| 18:31.23 | pabelanger | leedm777, well, I was thinking more about /endpoints, right now it seems to be the only API that tries to implement filtering. I have a feeling that is a tough one because you could have SIP/foo and IAX2/foo and not really sure how else to get back a specific endpoint using /endpoints/<id> |
| 18:31.58 | leedm777 | pabelanger: /endpoints/SIP/foo <--- |
| 18:33.40 | leedm777 | Or, from the API: "path": "/endpoints/{tech}/{resource}", "description": "Single endpoint" |
| 18:34.01 | file | I wouldn't called that filtering either... it's just requesting a specific resource |
| 18:35.14 | leedm777 | file: well, you can do a GET on just /endpoints/{tech}, which returns all of the endpoints with a specified technology. |
| 18:35.24 | leedm777 | wouldn't really call that filtering, either. |
| 18:36.17 | leedm777 | I would call filtering where you would add ?state=offline to get all of the offline endpoints. |
| 18:39.52 | pabelanger | okay, that is cool. I guess /endpoints is once of the API |
| 18:40.14 | pabelanger | 's where you need 2 items to return a single endpoint |
| 19:17.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:17.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:20.30 | pabelanger | Ah, falves11, what would we do with out you |
| 19:27.14 | Qwell | get actual work done? |
| 19:56.51 | anonymouz666 | ahh the guy with positive karma..still around heh |
| 20:05.19 | pabelanger | oh snap! |
| 20:05.21 | pabelanger | 2013-10-14 16:05:00.994 30053 ERROR cliff.app [-] Channel not in Stasis application |
| 20:06.12 | pabelanger | http request to dial a channel works |
| 20:12.43 | pabelanger | and working |
| 20:29.05 | mjordan | pabelanger: I'm assuming the ERROR was a glitch? |
| 20:33.25 | pabelanger | mjordan, I was trying to answer some local channels I originated on the CLI. Still learning that all this ARI needs to happen to things in a stasis app |
| 20:33.44 | pabelanger | but have channel-answer and channel-dial working now |
| 20:34.37 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:34.37 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:36.57 | mjordan | pabelanger: cool |
| 20:46.32 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 20:57.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@bzq-218-90-50.red.bezeqint.net) |
| 21:05.34 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:05.34 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:12.21 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 21:28.52 | *** join/#asterisk-dev danjenkins (~danjenkin@cpc3-folk2-2-0-cust34.1-2.cable.virginmedia.com) |
| 22:05.40 | mjordan | Nuts. I just thought of another feature that will require pabelanger's JSON |
| 22:05.55 | mjordan | A Blinky Lights resource. You'd want to pass in event packages as JSON to that. |
| 22:06.00 | mjordan | Or something along those lines. |
| 22:07.12 | leedm777 | mjordan: yup |
| 22:26.31 | pabelanger | JSON all the requests! |
| 22:29.39 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 22:35.30 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-pklyaccgnwdiybnx) |
| 22:44.33 | pabelanger | Hmm /channels/{channelId}/continue |
| 22:44.57 | pabelanger | perhaps /channels/{channelId}/exit might be a better naming convention |
| 22:45.09 | pabelanger | or |
| 22:45.32 | pabelanger | nm, DELETE already used to hangup |
| 22:45.49 | pabelanger | Actually |
| 22:46.01 | pabelanger | POST /channels/{channelId}/answer |
| 22:46.07 | pabelanger | DELETE /channels/{channelId}/answer |
| 22:46.09 | pabelanger | to hang up |
| 22:46.31 | pabelanger | vs separate function names |
| 22:46.46 | sgriepentrog | why would you want /answer on a DELETE ? just DELETE /channels/{id} |
| 22:46.50 | pabelanger | infact, you could do the same for mute / unmute, hold, unhold |
| 22:47.05 | pabelanger | moh start / stop |
| 22:48.36 | pabelanger | sgriepentrog, well, POST /channel{id} should be to answer the channel but it is not |
| 22:48.41 | pabelanger | seems to be an update function |
| 22:48.58 | pabelanger | I would have thought: PUT /channel/{id} would be a better concept |
| 22:49.55 | pabelanger | but ya, POST / DELETE /channels/{id}/mute would make more sense to me |
| 22:50.59 | sgriepentrog | I don't think there is a POST /channel/id - at least per https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Channels+REST+API |
| 22:51.25 | sgriepentrog | POST /channels/(id)/mute and unmute are valid |
| 22:51.35 | sgriepentrog | Basically, it |
| 22:51.50 | sgriepentrog | oops. It's get for just info, post to issue some operation, and delete to kill it. |
| 22:52.32 | pabelanger | sgriepentrog, Ya, POST /channel/id doesn't exist.... so, that could be used to answer a channel then drop POST /channel/id/answer |
| 22:53.15 | sgriepentrog | Not sure why you want to post /channel/id to answer when /channel/id/answer exists and is valid? |
| 22:54.18 | sgriepentrog | I mean, unless you were to POST /channel/id and then have a json payload that identified what operation /instead/ of the operation being in the uri... But I think this way is much cleaner. |
| 22:57.02 | pabelanger | Suggestions / feedback for the APIs. For example POST /channel will dial, but POST /channel/id/dial will also dial. Why two different URL namespaces for the same operation. |
| 22:58.06 | Juggie | well, if you are dialing on a pre-existing channel you'd want an id |
| 22:58.16 | pabelanger | correct |
| 22:58.20 | sgriepentrog | I *think* the difference is originating a call from scratch, vs. taking an existing channel under statis and causing it to dial a second leg. |
| 22:58.33 | Juggie | but if you are originating that would be different |
| 22:58.39 | Juggie | but i'd argue channel isnt the place to originate |
| 22:58.44 | Juggie | since if you are doing an originate |
| 22:58.47 | Juggie | you dont have a channel |
| 22:59.29 | sgriepentrog | So the /channels/id/dial is assuming you have an active channel, vs. the POST /channels is assuming you have nothing and are creating a new call from scratch. |
| 22:59.50 | pabelanger | okay, that one is open for debate. But I think I have something with POST / DELETE /channels/{id}/mute :) |
| 22:59.54 | sgriepentrog | And by "have" I mean have a ws connection to a statis app, thus channel is already under your control and you're just refernecing it by id. |
| 23:00.02 | pabelanger | using POST / DELETE for start / stop |
| 23:00.32 | sgriepentrog | Ahh. Yeah, I can almost see that. |
| 23:00.53 | Juggie | i woudnt call it channel/dial anyway |
| 23:00.56 | Juggie | i'd call it originate |
| 23:01.05 | jql | although mute/unmute has a query parameter |
| 23:01.15 | pabelanger | sgriepentrog, Agreed, but I am proposing droping the dial from /channel/id/dial and default POST /channel/id to the dial functionality |
| 23:01.18 | jql | seems weird to DELETE with a query param |
| 23:01.21 | sgriepentrog | Having pairs of operations is a bit less elegant than a create/delete approach. |
| 23:01.59 | sgriepentrog | The docs do say originate for POST /channels. The Dial mimics the dialplan dial() function then. |
| 23:02.01 | pabelanger | jql, then you use the PUT header |
| 23:02.09 | pabelanger | to modify |
| 23:03.30 | pabelanger | sgriepentrog, going to see if I can hack something up and get it working |
| 23:03.51 | sgriepentrog | pabelanger, I understand your proposal now - and I see your point although I would still personally prefer to see it always as /channels/(id)/(action) for clarity. |
| 23:05.35 | sgriepentrog | It does appear inconsistent but I really see /channels as a separate functionality to /channels/(id). But then I'm too close to the old school agi ways I guess. |
| 23:09.04 | file | ditto |
| 23:10.55 | *** join/#asterisk-dev stgnet (~androirc@nat/digium/x-svgmtledvmhqbnjy) |
| 23:11.26 | pabelanger | okay, so I cannot directly edit res_ari_channels.c right? |
| 23:11.33 | pabelanger | it is dynamically generated code? |
| 23:15.50 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:18.27 | pabelanger | Updated swagger, that was the easy part. Now to figure out how to regenerate the code |
| 23:18.28 | sgriepentrog | The file refers to the template file to edit instead. I would ping dlee in the am to confirm correct process. |
| 23:24.07 | pabelanger | sgriepentrog, okay, think I figured it out |
| 23:24.16 | pabelanger | compiling code now |
| 23:26.49 | pabelanger | Kick ass! |
| 23:26.52 | pabelanger | that was pretty easy |
| 23:27.11 | pabelanger | okay |
| 23:27.18 | pabelanger | so, time to get a patch up and open up the discussion |