| 00:15.34 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 00:15.35 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:41.54 | snuff-work | mm.. i see reviewboard got a update to something much more recent.. ended up opening 'issues'.. |
| 00:42.33 | snuff-work | soon to put my bad doco attempt for a pasting |
| 04:13.10 | *** join/#asterisk-dev zh-home (~zerohalo@74.61.196.236) |
| 05:46.06 | *** join/#asterisk-dev snuff-home (~snuffy@203.219.29.182) |
| 05:46.06 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 07:03.56 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 07:04.44 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:04.45 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:16.22 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:16.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:53.14 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:91aa:2915:fa45:1ce6) |
| 07:56.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:91aa:2915:fa45:1ce6) |
| 08:15.12 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 08:15.12 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 10:38.42 | *** join/#asterisk-dev drmessano^ (~nonya@pdpc/supporter/active/drmessano) |
| 11:10.44 | oej | Afternoon! |
| 11:29.34 | oej | There's something fishy with the linked list of frames |
| 11:43.43 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:47.09 | oej | And I found it. It was a bug in my code. |
| 11:47.53 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mxbmlksldehblmvv) |
| 11:47.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:53.14 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:16.12 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mxbmlksldehblmvv) |
| 12:55.13 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-iltscabelgjtcgzc) |
| 13:19.39 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 13:52.53 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-haddgkexfiqxasjg) |
| 13:52.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:54.00 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:54.00 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:54.43 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:54.43 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:57.29 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 13:57.29 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 14:03.28 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-uufbxboiskhnmlhi) |
| 14:04.06 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-uufbxboiskhnmlhi) |
| 14:04.27 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-uufbxboiskhnmlhi) |
| 14:08.13 | mjordan | leedm777: any reason why the public app_stasis functions aren't prefixed by ast_? |
| 14:09.33 | leedm777 | mjordan: same reason none of the stasis-core functions are prefixed by ast_. It made the names too long. |
| 14:09.54 | seanbright | heh |
| 14:10.52 | mjordan | while I'm not sure I'm a fan of long names, I'm not sure breaking the naming convention is a good idea either |
| 14:11.06 | mjordan | and yeah, ao2 does it |
| 14:11.37 | mjordan | but I'm not sure it's a good precedent to set |
| 14:12.05 | leedm777 | mjordan: that would be true for both stasis-core and stasis-app, right? |
| 14:12.26 | mjordan | just looking at stasis-app right now - have to fix some merge conflicts :-) |
| 14:12.53 | mjordan | I think we've bent the whole 'ast_' prefix rule for things that acted as an incredibly common and ubiquitous API |
| 14:13.06 | mjordan | But it feels like something we should only be bending when it makes a lot of sense |
| 14:13.41 | snuff-home | mm think for something like ao2.. maybe stasis.. they are now so 'core'.. they dont need ast_ start? ;) |
| 14:14.42 | mjordan | well |
| 14:14.54 | mjordan | there's a difference however between 'stasis-core' and the applications that build on top of it |
| 14:15.09 | mjordan | stasis-app, which is the one I was looking at, isn't part of the 'stasis-core' framework |
| 14:15.14 | mjordan | unless I'm missing something :-) |
| 14:15.56 | leedm777 | that gets down to semantics. |
| 14:16.15 | mjordan | how? |
| 14:16.17 | leedm777 | stasis-app is the API by which a stasis application can be written. |
| 14:16.18 | snuff-home | mm.. i'm just rambling into this convo.. now its time to get some zz's |
| 14:16.28 | mjordan | if it's that core, then it shouldn't be in app_ |
| 14:17.33 | leedm777 | I don't necessarily think core == linked into asterisk main. |
| 14:17.46 | mjordan | core there being an adjective, I suppose. |
| 14:19.21 | leedm777 | We've built the distinct things. The message bus. The application API. The RESTful API. |
| 14:19.30 | leedm777 | Obviously the message bus is core. |
| 14:19.37 | leedm777 | Obviously the RESTful API is not. |
| 14:20.33 | leedm777 | The application API is in the sad middle place, where it fits into both places, but doesn't quite fit in, either. |
| 14:21.45 | mjordan | I might be missing how this is supposed to work. I can see that when a channel enters into the Stasis application, it is being put into a state where some other aspect of Asterisk is going to control it. However, I'm not sure I would expect code in app_stasis itself to be a broker of all actions that are going to be taken on that channel |
| 14:22.03 | mjordan | that feels like you'd end up writing an entirely new API on top of the channel/bridge APIs, and I'm not sure I see the benefit of that |
| 14:22.35 | mjordan | other then the Stasis application signaling that it has a channel in a waiting state, and being receptive to something else that tells it to release said channel, I'm not sure what it should be doing |
| 14:27.09 | leedm777 | I believe that the channel and bridging API's are/will be too low level for the RESTful API implementation to use directly. stasis-app is an abstraction that allows us to avoid putting a ton of logic in the RESTful layer. |
| 14:28.52 | mjordan | I'm in agreement that the logic shouldn't necessarily live in the RESTful layer. There should be a middle layer of abstraction between the channel/bridge APIs and the transport (whatever it happens to be). But I'm not sure putting that in an application module is a good choice. I think you'll end up writing a whole new protocol if you use JSON to transmit requests/responses to said module as well |
| 14:29.57 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:29.57 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:30.23 | mjordan | I'm willing to give this approach a shot, but I think we should be prepared to go with a different approach as fast as possible |
| 14:30.56 | leedm777 | Events from stasis-app are JSON blobs. |
| 14:31.27 | leedm777 | But requests/responses to/from stasis-app should be function calls into the module. |
| 14:32.15 | mjordan | In that case, I'm convinced that level of abstraction should not be in an Application module. |
| 14:32.25 | file | ditto |
| 14:32.27 | leedm777 | res_ module, then? |
| 14:33.31 | mjordan | Where's the benefit in it even being dynamically loadable? I suppose you can have a smaller binary, but do we expect anyone to ever replace this abstraction layer? |
| 14:34.38 | leedm777 | I'm a put-it-in-a-module-first sorta guy |
| 14:35.01 | file | WELL, it's effectively a consumer of internal APIs which then dumbs it down/does some of the work for you... which implies specific behavior and actions, I suppose someone may want to go down the road of changing that/making it more efficient/whatever |
| 14:35.09 | file | but doubtful |
| 14:35.34 | mjordan | let's start at res_ module. |
| 14:35.52 | mjordan | the application that drops a channel into Stasis still feels like an app_ module if possible |
| 14:35.56 | file | yes |
| 14:36.30 | mjordan | leedm777: you're right, we can always move something into main later if it feels appropriate, but ripping it back out is harder |
| 14:41.11 | pabelanger | So, just trying to wrap my brain around it, what would be a use case for the application Statis()? What is an example of an external statis application? |
| 14:41.36 | mjordan | pabelanger: I want to write my on Queue application |
| 14:41.36 | pabelanger | I guess, this would be res_agi, 2.0? |
| 14:41.48 | mjordan | sorta, but not really. AGI let's you run dialplan applications |
| 14:41.54 | mjordan | Stasis is: I want to write my own application |
| 14:42.12 | pabelanger | So, I could stream audio to asterisk from a Statis application? |
| 14:42.41 | pabelanger | or would asterisk expect the audio files to be local? |
| 14:42.54 | mjordan | you can playback media onto a channel (and, IIRC, into a bridge). By Stasis, I mean Stasis-HTTP here. There's actually (at least) three different Stasis components in Asterisk. |
| 14:43.25 | mjordan | pabelanger: whether or not the media is local or remote is immaterial. Right now, it would have to be local because that's how all media is represented wrt Asterisk. |
| 14:43.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:43.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:44.39 | pabelanger | mjordan: Is there a simple hello world application any place with stasis http? |
| 14:44.40 | mjordan | theoretically, if someone were to provide the ability to specify a remote file location for a media source, then that's something that it could conceivably access as well, But that's a feature that isn't uniquely tied to Stasis-HTTP. |
| 14:45.15 | mjordan | not yet, but there will be. There are wrapper libraries around the REST API that serafie has worked on up on github and linked to on the Asterisk wiki. leedm777 has documentation for the REST API up on the wiki as well |
| 14:45.35 | mjordan | but it isn't quite developed enough yet to have a 'hello world' app |
| 14:45.52 | leedm777 | Notably, 'Play' isn't implemented yet. |
| 14:45.55 | leedm777 | :-D |
| 14:46.07 | leedm777 | https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+RESTful+API |
| 14:46.11 | leedm777 | ^^ comments welcome |
| 14:46.23 | leedm777 | Here's the review for the RESTful API - https://reviewboard.asterisk.org/r/2376/ |
| 14:47.34 | pabelanger | leedm777: No play? How am I to do hello world then? |
| 14:47.35 | pabelanger | :p |
| 14:47.46 | pabelanger | checking github for examples now |
| 14:48.41 | leedm777 | Libraries are here -> https://github.com/asterisk/asterisk_rest_libraries |
| 15:55.25 | tzanger | hm, I really can't see a clear reason why you'd switch from redmine to chiliproject |
| 15:55.32 | tzanger | it seems they forked it and left it |
| 16:12.11 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:13.17 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:13.17 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:14.28 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 17:14.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:27.32 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:27.33 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:59.54 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:59.55 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:08.07 | file | putnopvut, you should clean up your branches :P |
| 18:13.52 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:13.52 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 18:20.17 | file | mjordan / putnopvut, sooooo once we merge cid and document configuration... can we merge pimp my sip into trunk? |
| 18:21.34 | mjordan | yes |
| 18:21.40 | leifmadsen | O.O |
| 18:21.49 | mjordan | I'd prefer it to get into trunk as soon as possible. |
| 18:21.51 | leifmadsen | hawt |
| 18:22.08 | mjordan | one thing we have to consider is how to run both chan_sip and chan_gulp simultaneously |
| 18:22.19 | mjordan | by run, I'm implying coexist |
| 18:22.19 | file | as long as you run 'em on separate ports it is fine |
| 18:22.20 | leifmadsen | will it be possible to run both chan_sip and chan_gulp simultaneously? (different listening ports)? |
| 18:22.25 | leifmadsen | mjordan: lolz |
| 18:22.33 | leifmadsen | asked and answered. |
| 18:22.38 | seanbright | my god |
| 18:22.43 | leifmadsen | should there be a check for that? |
| 18:22.54 | leifmadsen | something that says, "hey dummy! you're running 2 sip channels on the same port!" |
| 18:23.15 | file | depending on load order the second one wouldn't be able to bind and it would scream |
| 18:23.24 | seanbright | the nice thing about them having completely separate implemenations is that you can use them to test each other |
| 18:23.53 | leifmadsen | seanbright: it's a feature! |
| 18:23.54 | seanbright | the first thing i shall do is connect two local channels together via sip/gulp |
| 18:23.57 | seanbright | it will be glorious |
| 18:24.01 | opticron | ugh |
| 18:24.23 | leifmadsen | seanbright: Local channels? :) |
| 18:24.30 | seanbright | yes. |
| 18:24.42 | seanbright | it makes sense if you suck less |
| 18:24.56 | seanbright | also, blue jays suck |
| 18:26.39 | file | those keeping track - we don't do transfers :P |
| 18:27.29 | seanbright | no one does that |
| 18:27.31 | seanbright | so you're good |
| 18:27.41 | file | yay! |
| 18:36.19 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:36.19 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:38.49 | *** mode/#asterisk-dev [+v LieutPants] by pabelanger |
| 18:38.56 | *** mode/#asterisk-dev [-o LieutPants] by pabelanger |
| 18:39.36 | Qwell | file: it's res_sip that actually causes the port to get bound, yes? If so, it's unlikely that chan_sip would ever load first, unless forced (maybe?) in modules.conf. |
| 18:39.45 | file | Qwell, truth |
| 18:40.34 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:40.35 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:42.59 | pabelanger | Interesting, how are we going to handle that? Are we saying the new pimp my sip is prime time? Or are we giving it a release or two before having it enabled before chan_sip? |
| 18:43.54 | mjordan | no decision has been made one way or the other regarding module enabling/disabling/whatever in the future releases. |
| 18:45.59 | pabelanger | We'll have to at some point, won't we? I haven't played with the new sip channel driver, but only after Qwell asked about port binding, I'm not curious to see how it works :) |
| 18:49.04 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:49.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:02.35 | *** join/#asterisk-dev coreyf1513 (~cfarrell@2001:4830:117f:3:fc14:c99c:502f:dad0) |
| 19:29.52 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:29.53 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 19:38.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:38.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:04.10 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:04.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:15.20 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:15.21 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:44.53 | coreyf1513 | I wrote a couple of new applications for app_stack.c, the code is ready but the wording of xmldocs could use some help. is this something I should submit to jira or someplace else? |
| 20:49.28 | mjordan | coreyf1513: do you have review board access? |
| 20:49.42 | coreyf1513 | no |
| 20:50.13 | coreyf1513 | mjordan: if i did it would be the same as my jira account? |
| 20:50.14 | mjordan | k - I can take a look at it. Create an issue in Jira, sign a license contributor agreement (if you haven't already), then attach the patch to the issue |
| 20:50.18 | mjordan | coreyf1513: nope |
| 20:50.49 | mjordan | if it's something that takes a bit more then just some q&a, I'll get a review board account made for you and we can post it to there. Otherwise, we can just look at it in Jira |
| 20:50.55 | mjordan | first step is always Jira anyhow :-) |
| 20:53.20 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:53.20 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:04.36 | *** join/#asterisk-dev alecdavis (~sivad@202-78-149-14.cable.telstraclear.net) |
| 21:09.57 | alecdavis | looking for a shipit on review2427, it's a simple one, on startup IAX starts the idle threads, then immediately starts the network thread. We need to wait for the threads to start properly. ie wait for the init_cond. The symptom: If the other side has qualify set to 2000 (2 seconds) the probability of a network messages arriving before the thread has started properly is high. like in my |
| 21:09.57 | alecdavis | case 100% of the time on a P4 3.0Ghz. |
| 21:10.21 | mjordan | alecdavis: probably won't have time to review it tonight, but I can try to get to it tomorrow |
| 21:21.30 | coreyf1513 | mjordan: i posted jira 21390, do you need anything else to look into reviewboard access for me? |
| 21:27.53 | alecdavis | further, the connection then never can start, as the thread falls into ast_wait_cond, and never gets woken up, and forever gets a deferred frame queued to it. once every 2 second (in my example). and thats where review2426 kicks the other thread which has just had a deferred frame added to it, incase it fell into ast_cond_wait. |
| 21:29.54 | mjordan | coreyf1513: nope - I'll take a look at it tonight/tomorrow |
| 21:30.43 | alecdavis | so: review2427 fixes the obvious startup problem. review2426 kicks a sleeping thread that actually may have work to do. |
| 21:31.20 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 21:34.10 | alecdavis | thanks matt. |
| 21:34.37 | mjordan | alecdavis: np, I've copied your comments for tomorrow :-) |
| 21:42.20 | alecdavis | FWIW: rb2426 also fixes what rb2427 fixes, but rb2427 is the correct way to startup. |
| 21:56.22 | *** part/#asterisk-dev alecdavis (~sivad@202-78-149-14.cable.telstraclear.net) |