Re: [asterisk-dev] I want to make my first patch but have run into a problem and don't know how to progress.
On 10/06/2016 12:52 PM, John Kiniston wrote: I got all fired up on getting up to date with the current LTS version of Asterisk while at Astricon and I'd like to make my first patch. Awesome! Hopefully this will be the first of many to come. I want to modify bridge_builtin_features.c to honor the"MONITOR_EXEC" and "MONITOR_EXEC_ARGS" variables like Monitor() does so that my one touch recordings using automon get post processed. I'm no C programmer but I took a class at the local community college uh I guess it's been two decades ago now so forgive me. I found the code in res/res_monitor.c that handles setting the execute application and running it and I've copied what looked like the part I needed into bridges/bridge_builtin_ features.c and with a few minor changes it almost works. The part where it's breaking down is getting the format of the recorded file which I think should be touch_format I'm getting (null) so I reckon set_touch_variables doesn't do what I hoped it did. Would someone please help me get the file-name extension or point me in a better direction if this doesn't look like a good idea? I'm going to answer your question in two ways here: first, from the perspective of helping to understand the code you've written, and second addressing the "if this doesn't look like a good idea" angle. Let's examine what set_touch_variables does. set_touch_variables first determines which channel variables it needs to be looking at. Assuming you're using monitor and not mixmonitor, that means that it will look up the TOUCH_MONITOR_FORMAT, TOUCH_MONITOR, and TOUCH_MONITOR_PREFIX channel variables. It will place the values of each into the touch_monitor_format, touch_monitor, and touch_monitor_prefix local variables, respectively. In your case, it appears that touch_mointor_format ends up NULL, which most likely stems from the fact that the TOUCH_MONITOR_FORMAT variable is not set on the channel which was passed into set_touch_variables. So later when you start outputting your debug, since touch_monitor_format is NULL, the glibc print routines turn that into "(null)". Why don't you see the same thing happen in the res_monitor.c code? In that code, the ast_monitor_start() function requires a file format to be passed to it, and that format ends up getting set on the ast_monitor structure that gets created. That structure then gets set on the channel, and it can be later accessed by calling ast_channel_monitor(chan). When ast_monitor_stop() is called, it is able to get that saved format off the channel and use that for its post-processing. You could potentially do the same thing to get the file format by getting the value of ast_channel_monitor(chan)->format in your code. So now let's talk about whether your approach is the right one to take. One thing you may have noticed when doing your experimental coding is that the code that you copy/pasted comes from ast_monitor_stop(). ast_monitor_stop() is a C-level API call that is called by several places in the code, including in bridge_builtin_features.c when one-touch monitoring is stopped. This means, at least the way I see it, that the use of MONITOR_EXEC and MONITOR_EXEC_ARGS should already be in a position where they could "just work" with builtin automon. We can take a closer look at ast_monitor_stop() and see that the guard for determining if MONITOR_EXEC and MONITOR_EXEC_ARGS is used is: if (ast_channel_monitor(chan)->joinfiles && !ast_strlen_zero(ast_channel_monitor(chan)->filename_base)) If MONITOR_EXEC and MONITOR_EXEC_ARGS is currently not working, it is likely because one or both of these conditions are not met. Let's examine them one by one. ast_channel_monitor(chan)->joinfiles is a boolean that indicates if files should be joined together once recording is done. With the Monitor() application, this gets set true by setting the 'm' option (see start_monitor_exec() if you want to follow how that is done, specifically looking at MON_FLAG_MIX). Otherwise, though, this value is false. When ast_monitor_start() is called, it does not automatically set joinfiles to true. There is a function, though, called ast_monitor_setjoinfiles() you can use to set this value to true. ast_channel_monitor(chan)->filename_base is the base filename being used for monitor recordings. "base filename" means the filename minus the extra bits indicating the audio direction. The only reason this would not be set is if there were some catastrophic error. ast_strlen_zero() is a utility function that returns true if the input string is either NULL or zero-length. So since filename_base is almost certainly more than zero characters long, it's likely that ast_strlen_zero() of that is false, and negating that makes it true. Summary: This probably means that you could get the functionality you desire by calling ast_monitor_setjoinfiles(chan, 1) after ast_monitor_start() in start_automonitor() of bri
Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace
On Fri, Oct 7, 2016 at 10:31 AM, Corey Farrell wrote: > Many people don't like chan_sip, most people hate working with the code. > The rush to throw out chan_sip when PJSIP isn't ready to be the only SIP > stack annoys me a bit. Nobody is forcing anyone to use or contribute to > chan_sip. Digium changed chan_sip from core to extended support so they can > significantly reduce involvement. At some point chan_sip will fizzle out > but that hasn't happened yet. I don't think we're rushing - if anything, most people at DevCon (and I'd also say in this conversation) are being pretty realistic about how long it will take before chan_sip could be removed from the source tree. I think all we're seeing right now is a conversation about how we might eventually get there. Generally, when a module is first marked as being 'deprecated', we usually let it go through at least one additional release before it would ever be removed. Even then, our preference is to just leave the module in the source tree (usually disabled), in case someone still wants to use it. About the only time we remove a module is when it either no longer compiles, or when it is actively causing harm. Assuming we all decided to mark chan_sip as deprecated in Asterisk 15, then soonest it would be removed from the source tree is Asterisk 17 - so I think we've got some time to hash this out. As far as extended support is concerned - yes, Digium is not interested in maintaining chan_sip any longer. Our commercial products and interests are focused on the PJSIP stack. As such, once Asterisk 11 leaves bug fix support, I would expect our fixing of chan_sip related issues to drop dramatically - even more than they already have. Patches submitted for chan_sip through Gerrit will still be reviewed and receive attention, as will security patches. > Last time I checked about 200 of the PJSIP testsuite tests produced AO2 > leaks, in many cases hundreds of objects were leaked [1]. Some of these > leaks may be caused by bugs in tests and I realize that many use cases must > work without major leaking, but some use cases could cause failures. I've > submitted some fixes but I find PJSIP leak tracing more difficult than other > parts of Asterisk. I'll admit that some of the tracing is a bit more challenging, both with sorcery as well as with PJSIP memory pools. My impression right now is that any objects that are not released on shutdown are configuration objects or other similar objects that allocated a single time during some PJSIP module initialization. While those make AO2 debugging challenging (and it would be great to clean them up), they don't indicate any harmful memory leak. Of course, I do understand if that means you don't want to use those modules. > The current policy of allowing new features into released LTS branches is a > concern for me with PJSIP. If I were to start using PJSIP I would have to > worry about each 13.x.0 release having a new PJSIP feature possibly cause a > bug. A lot of bad things can be said about chan_sip, but new features are > extremely unlikely in 13.12.0. It would be nice if a core set of PJSIP and > other modules could be declared LTS frozen. During LTS releases these > modules would be strictly bug fix only. I suspect this is not yet wanted or > possible for PJSIP modules, but hope it can be re-evaluated before new LTS > branches. My hope is that eventually a basic PJSIP PBX could be run using > only frozen modules. Users with a specific needs or higher risk tolerance > could run some / all of the unfrozen modules to get more advanced or less > mature features. Eventually the list of frozen modules could grow as each > module becomes feature complete and is proven stable. I don't think I want to complicate the new feature development process. While I think we've had a few hiccups, by and large, I haven't heard of a lot of complaints with the new features/improvements that are being released mid-stream. The only ones that have bitten me are where we combined modules or introduced a new needed module (res_pjproject), and that's because I explicitly load modules that I use. Are there specific issues you're thinking of? > I do see chan_pjsip in my future. It has all the features I need plus the > config handling will improve my handling of dynamic peers. I have no > timeframe to migrate as I can't ignore my concerns and they can't be > addressed overnight. > > [1] > https://jenkins.asterisk.org/jenkins/job/periodic-ref_debug-asterisk-13/8/ > > On Tue, Oct 4, 2016 at 8:46 PM, James Finstrom wrote: >> >> So the discussion of deprecating chan_sip came up at the devcon this year >> and it caused a bit of a stir. The end result was the need for broader >> discussion with a wider audience. So let's discuss. >> >> Currently, Asterisk is running dual sip stacks. The argument is that to >> deprecate PJSIP there must be broader adoption. There is currently nothing >> motivating adoption but much slowing it. >>
Re: [asterisk-dev] Working Groups
A couple of specific comments on Dan's points below, followed by some general thoughts. On Wed, Oct 5, 2016 at 4:25 AM, Dan Jenkins wrote: > > > So +1 to working groups (oh it was me that suggested it - can I +1 my own > idea?) > > I suggested it because of the lack of ways of being able to ask for feature > requests through Jira. The idea was 1) to get the community more a part of > what drives Asterisk forward (and not just those that can turn up to devcon) > but 2) to be able to formulate a plan on things we want in certain areas > going forward. For the Node.js project there are many working groups for > different purposes (https://nodejs.org/en/about/working-groups/) - I'm part > of the documentation working group for Node.js. Because Node.js is covered > under the Node.js foundation (and then the linux foundation) people within > these working groups directly influence X. > > So the documentation working group tries to make clear documentation etc > etc; theres an Internationalisation working group who purely put their > skills in multiple languages into action by translating blog > posts/website/documentation etc into other languages used throughout the > world. > > Its a little different here because Digium are pretty much in tight control > of a lot of stuff. > > But we can still affect change within the community. So three areas close to > my heart are migrating away from chan_sip (purely from a removing old code, > we don't need two SIP stacks point of view), ARI and future features for > that - at the moment we have a wiki page for feature requests but doesn't > encourage talking publicly about these things and the third is documentation > - we all know the wiki isn't brilliant. if you know where you're going then > yes, the wiki is amazing. I have a new dev working at Nimble Ape who started > looking at ARI the week I was away at Devcon. I got back and was talking to > him and he said it was hard to find good docs etc - he had found the > examples on the wiki but when I sent him the REST docs and the Events docs > that are within the wiki he proclaimed "this is exactly what I needed last > week" - the docs are there but hard to find etc. a documentation working > group would try to tackle this. > > So yes, I'm up for working groups, each should be led by one person and then > a team built up under them. Ideally I'd like to discussion to be easy and in > a public place - this would mean (in my opinion) either making a new github > org or utilising the asterisk github org, making public repos for each > working group and having maintainers of them (for example the testing > node.js working group is here - https://github.com/nodejs/testing) - I'd > rather it be encompassed by the asterisk org but don't know how that would > sit with Digium etc. I'd prefer to avoid using Github for more work. With our focus usually on JIRA and Gerrit, I think we have a tendency to forget that it's there, and miss looking at things that occur in the existing ancillary projects. It'd be nice if we could use the existing community/project infrastructure for the working groups - Gerrit/JIRA/Discourse/etc. If the goal of a working group is to make recommendations on priorities for the project, then having a mechanism to allow the working group (and potentially the broader community) provide input and/or vote on said priorities seems like it would be useful. That makes me lean towards JIRA, but I'm open to other suggestions. > Three potential working groups: > > PJSIP migration > Documentation > ARI > I'd probably change "PJSIP Migration" to just "PJSIP" or even "SIP", but other than that, I think all three of those are good ideas for working groups. Some more general thoughts: - If the goal of a working group is to provide recommendations on project goals, than working groups really need to have someone involved who is also interested in implementing the features of the working group. I think if a working group has some interest in the user community but no active developers, then the recommendations of the working group are going to simply languish, causing frustration for the working group members. As such, I think in order for a working group to be "active", there should be at least one person on the working group who is an Asterisk developer. That doesn't have to be someone at Digium, but it should be someone who is willing to contribute patches for the working group's recommendations from time to time. - People participating in the working groups definitely need to understand that there is *no* guarantee that their recommendations will be enacted. The output of a working group should be recommendations that any developer in the community can use as a guide. That isn't to say that I think the output of working groups would be ignored - far from it, as I think everyone would benefit from this process - but the more ambitious the recommendation, the more difficult it is to build consensus and resources to a
