Re: [asterisk-dev] Extend MixMonitor to record stereo files
Hi, Unfortunately using MixMonitor and the options 'r' and 't' didn't work. The two files created are not synchronised (different lengths) depending on various scenarios. For example who initiated the call and then who hung-up first. After reading through the source code I'm not convinced that our own dev team is the most viable resource to extend the MixMonitor app and associated WAV areas. Minimal C dev experience partly but mostly it feels like quite a lot of Asterisk source and audio processing skills are required. Is there a recommended way to offer a bounty for feature requests (I have read the wiki on Bug Bounties). I'm sure I can find budget to sponsor this feature, although it may not be enough if this is a really big bit of work :) I don't want to just post up a random figure which may be insulting to the amount of work required, no more than wasting money. I did post a message on the Asterisk Forums but haven't yet had a reply, so apologies for the duplication if you have already read that. Many Thanks Alex From: Alex Barnes Sent: 14 November 2013 16:19 To: Asterisk Developers Mailing List Subject: RE: [asterisk-dev] Extend MixMonitor to record stereo files Thanks for your reply Scott. We hadn't noticed the new MixMonitor options 'r' and 't'; I must stop using the voip-info wiki rather than the new docs :) We are currently testing to see if setting both options will produce two separate (or three maybe looking at the app_monitor.c file) wav files that we can merge together like we do when using Monitor. If this does work then extending FreePBX to pass these extra options should be trivial in comparison to adding stereo WAV support to Asterisk itself. I'll continue reading around the Asterisk source in the meantime though so thanks again for pointing out the WAV handling issue. Kind Regards Alex From: asterisk-dev-boun...@lists.digium.commailto:asterisk-dev-boun...@lists.digium.com [mailto:asterisk-dev-boun...@lists.digium.com] On Behalf Of Scott Griepentrog Sent: 14 November 2013 15:16 To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] Extend MixMonitor to record stereo files It's definitely possible. Many moons ago (before mixmonitor) I once hacked the mixing script in FreePBX to use sox to build a stero wav file from the two recordings - so I understand the usefulness of what you're trying to do. Be aware that both the Asterisk project and the FreePBX project are open source, and you can contribute to either or both. If I'm not mistaken (willing to be corrected on the internet if I'm wrong ;-) the WAV handling code is fixed in mono and 8khz (or at least used to be) and it may be tricky to add in stereo support. That being said, it's certainly possible to do it within Asterisk. It would require changes to both MixMonitor() or creation of StereoMixMonitor and the WAV handling. The part that I'm fuzzy on is how best to pass the two channels between them. On Thu, Nov 14, 2013 at 3:57 AM, Alex Barnes alex.bar...@completeautomotivesolutions.co.ukmailto:alex.bar...@completeautomotivesolutions.co.uk wrote: Hi all, I was hoping somebody knowledgeable about the inner workings of app_mixmonitor could give me an idea of how feasible our change might be? User Story: As a FreePBX user I would like MixMonitor to save recordings in stereo wav format where inbound calls are one channel and outbound are another. This will allow me to more clearly hear who is speaking as well as more easily extract the audio of just one speaker. Note: The FreePBX part is important as we cannot make it use Monitor and an external bash script without hacking apart a lot of the dial plan, hence we are stuck using MixMonitor. We are a dev company but with little C experience and zero Asterisk application development knowledge HOWEVER we're very happy to give it a whirl. I'm literally just starting on researching this and no doubt have lots of reading to do regarding general Asterisk app development, research WAV format issues in C and MixMonitor, how to submit changes to the Asterisk project etc etc. I was hoping somebody could let me know if they think this will definitely not work or if they happen to know of some of the issues we may face and possibly where to start looking. Thanks in advance Alex The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), Motors.co.ukhttp://Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various
[asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)
Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)
Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4103: chan_pjsip: Add 'moh_passthrough' option for passing through musiconhold requests.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4103/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Currently when musiconhold is started or stopped in PJSIP it is always locally generated using res_musiconhold. This change adds an option, moh_passthrough, that allows musiconhold requests to be passed through chan_pjsip. This is done by sending a re-INVITE with recvonly state on the streams when the channel is put on hold and sending a re-INVITE with sendrecv state on the streams when the channel is taken off hold. The end result of this being that an upstream entity (such as another PBX) can generate the musiconhold instead. Diffs - /trunk/res/res_pjsip_sdp_rtp.c 426095 /trunk/res/res_pjsip/pjsip_configuration.c 426095 /trunk/res/res_pjsip.c 426095 /trunk/include/asterisk/res_pjsip_session.h 426095 /trunk/include/asterisk/res_pjsip.h 426095 /trunk/contrib/ast-db-manage/config/versions/339e1dfa644d_add_moh_passthrough_option_to_pjsip.py PRE-CREATION /trunk/channels/pjsip/dialplan_functions.c 426095 /trunk/channels/chan_pjsip.c 426095 Diff: https://reviewboard.asterisk.org/r/4103/diff/ Testing --- Enabled option. Placed call to a remote server. Put call on hold and off hold. Confirmed re-INVITEs were sent with proper state. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4100: codec_dahdi: Fix crash on load of codec_dahdi.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4100/#review13585 --- I'm not sure this should go in as it is. I think it is better to remove the dependency on core_src_codec and core_dst_codec in codec_dahdi. I have another patch I've worked up, just finding the best place to post it. - Shaun Ruffell On Oct. 21, 2014, 4:11 p.m., rmudgett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4100/ --- (Updated Oct. 21, 2014, 4:11 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24435 https://issues.asterisk.org/jira/browse/ASTERISK-24435 Repository: Asterisk Description --- Codec_dahdi is the only translator that uses the struct ast_translator-core_src_codec and struct ast_translator-core_dst_codec pointers. Unfortunately, nothing ever initialized the pointers. Diffs - /branches/13/main/translate.c 426078 /branches/13/include/asterisk/translate.h 426078 /branches/13/codecs/codec_dahdi.c 426078 Diff: https://reviewboard.asterisk.org/r/4100/diff/ Testing --- Made some calls that perform translation. No crashes happened. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI(Ben Klang)
On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI(Ben Klang)
On Wed, Oct 22, 2014 at 11:14 AM, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. Just because someone decided to bring up a radical idea does not mean we refuse to discuss it. This is an open source project. Communication is done in an open, transparent manner. People should feel like they can bring up interesting, radical, and yes - even crazy - ideas. If you don't like that, you don't have to participate in the discussion. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI(Ben Klang)
On 10/22/14, 12:14 PM, Paul Albrecht wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. It doesn't merit discussions and shouldn't be on the agenda in the first place. Really? Paul, aside from the Digium team, everyone else that's there at DevCon have spent outside funds to get there and I think the consortium is pretty well able to discuss whatever they'd like regardless of your dictator like statements which goes against everything that an open sourced project/community is supposed to be. There have been years where I'm able to attend DevCon and there have been other years, like this one, where I'm not able to attend because of prior business commitments. In the prior years where I haven't been able to attend, I don't personally feel like anything major was implemented without first being vetted with the list and community at large. I'm not really sure why you perceive the whole AstriDevCon event to be some kind of conspiracy theory against the community at large, but knowing both Josh, Leif, and many other people in that room for some number of years now, I can assure you that I've never seen anything other than 100% transparency. You've made more than clear in prior posts to this forum that you're not really a fan of ARI. I think we all get it. There are other people that are fans and, for them, they're in transition to using it in a more mainstream fashion because it's able to do things for them that AMI and AGI cannot. I personally still use AGI and AMI in many production scenarios with Asterisk today and I'm only just thinking lately about certain applications that I could transition to ARI. We cannot discount that there's a very large cost for the developers, testers, and the community at large to continue to keep AMI/AGI maintained and functionally up to date with all the Asterisk changes along with ARI given the way that AMI/AGI were originally implemented in the codebase. For people that are absolutely hooked on still using AMI/AGI in the longer term, perhaps a discussion could ensue at some point about a bridge with AMI/AGI functionality being built off of ARI itself, or maybe that's just crazy talk. I really don't know. The great thing about Asterisk and the community around it is that if there's enough participation and interest, anything can happen. BJ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI(Ben Klang)
On Wed, Oct 22, 2014 at 9:14 AM, Paul Albrecht palbre...@glccom.com wrote: The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. I still think it is crazy we didn't all agree finally naming the testsuite was a big deal. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4105: codec_dahdi: Fix segfault on load.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4105/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24435 https://issues.asterisk.org/jira/browse/ASTERISK-24435 Repository: Asterisk Description --- This is another version of https://reviewboard.asterisk.org/r/4100/ that doesn't change anything in the core of Asterisk. Diffs - branches/13/codecs/codec_dahdi.c 426095 Diff: https://reviewboard.asterisk.org/r/4105/diff/ Testing --- Called between two phones with g729 on one side and g722 on the other and made sure transcoder show indicated the transcoder was in use and I could hear myself. Thanks, Shaun Ruffell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4105: codec_dahdi: Fix segfault on load.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4105/#review13586 --- This patch contains formatting changes suggested by rmudgett already. - Shaun Ruffell On Oct. 22, 2014, 6:17 p.m., Shaun Ruffell wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4105/ --- (Updated Oct. 22, 2014, 6:17 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24435 https://issues.asterisk.org/jira/browse/ASTERISK-24435 Repository: Asterisk Description --- This is another version of https://reviewboard.asterisk.org/r/4100/ that doesn't change anything in the core of Asterisk. Diffs - branches/13/codecs/codec_dahdi.c 426095 Diff: https://reviewboard.asterisk.org/r/4105/diff/ Testing --- Called between two phones with g729 on one side and g722 on the other and made sure transcoder show indicated the transcoder was in use and I could hear myself. Thanks, Shaun Ruffell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AstriDevCon 2014: Agenda itemDeprecate AMI/AGI(Ben Klang)
On Oct 22, 2014, at 11:31 AM, Matthew Jordan mjor...@digium.com wrote: On Wed, Oct 22, 2014 at 11:14 AM, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. Just because someone decided to bring up a radical idea does not mean we refuse to discuss it. So you agree that deprecating AMI/AGI is “crazy talk” but you’ll discuss it because of your open-mindedness? This is an open source project. Communication is done in an open, transparent manner. People should feel like they can bring up interesting, radical, and yes - even crazy - ideas. By the same token, when you propose ideas, you must be prepared for honest criticism and accept it in graciously rather than simply resorting to argument ad hominem. If you don't like that, you don't have to participate in the discussion. You haven’t really responded to the substance of my post, that is, is asterisk abandoning the dial plan? -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AstriDevCon 2014: Agenda itemDeprecate AMI/AGI(Ben Klang)
On 22 October 2014 14:55, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 11:31 AM, Matthew Jordan mjor...@digium.com wrote: This is an open source project. Communication is done in an open, transparent manner. People should feel like they can bring up interesting, radical, and yes - even crazy - ideas. By the same token, when you propose ideas, you must be prepared for honest criticism and accept it in graciously rather than simply resorting to argument ad hominem. I don't think that word means what you think it means. If you don't like that, you don't have to participate in the discussion. You haven’t really responded to the substance of my post, that is, is asterisk abandoning the dial plan? Someone proposed an idea during the devcon. Nothing has been decided or even discussed yet. What you're reading and freaking out about is simply a list of ideas mentioned during the devcon, and noted in a document. That's as far as it has gotten; a list of minutes you're reading without further context based on actual participation in the conference itself. Leif. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: Agenda item DeprecateAMI/AGI(Ben Klang)
On 10/22/14, 3:06 PM, Paul Albrecht wrote: On Oct 22, 2014, at 11:47 AM, BJ Weschke bwesc...@btwtech.com wrote: On 10/22/14, 12:14 PM, Paul Albrecht wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. It doesn't merit discussions and shouldn't be on the agenda in the first place. Really? Paul, aside from the Digium team, everyone else that's there at DevCon have spent outside funds to get there and I think the consortium is pretty well able to discuss whatever they'd like regardless of your dictator like statements which goes against everything that an open sourced project/community is supposed to be. There have been years where I'm able to attend DevCon and there have been other years, like this one, where I'm not able to attend because of prior business commitments. In the prior years where I haven't been able to attend, I don't personally feel like anything major was implemented without first being vetted with the list and community at large. I'm not really sure why you perceive the whole AstriDevCon event to be some kind of conspiracy theory against the community at large, but knowing both Josh, Leif, and many other people in that room for some number of years now, I can assure you that I've never seen anything other than 100% transparency. You've made more than clear in prior posts to this forum that you're not really a fan of ARI. I think we all get it. There are other people that are fans and, for them, they're in transition to using it in a more mainstream fashion because it's able to do things for them that AMI and AGI cannot. I personally still use AGI and AMI in many production scenarios with Asterisk today and I'm only just thinking lately about certain applications that I could transition to ARI. We cannot discount that there's a very large cost for the developers, testers, and the community at large to continue to keep AMI/AGI maintained and functionally up to date with all the Asterisk changes along with ARI given the way that AMI/AGI were originally implemented in the codebase. For people that are absolutely hooked on still using AMI/AGI in the longer term, perhaps a discussion could ensue at some point about a bridge with AMI/AGI functionality being built off of ARI itself, or maybe that's just crazy talk. I really don't know. The great thing about Asterisk and the community around it is that if there's enough participation and interest, anything can happen. What you’re discounting is the Asterisk community that have used and are using dial plans and AGI/AMI. If ARI can’t work in that environment, then ARI should be abandoned as simply unworkable. I'm not discounting that at all. As I stated already, I am part of that community that's still making very active use of dial plans and AGI/AMI on production systems. ARI, by itself, cannot replace that functionality. It wasn't ever intended to when it was conceived. Although I was admittedly not in the room nor did I hear any stream or recording of the event yesterday, I read from Leif's bullet point that we refers to the company and application that he's personally working with in the current day. We doesn't represent the Asterisk community at large. I think if you had read through the rest of the points and opinions documented by Matt and the rest of the Digium folks at https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2014, that would have become abundantly clear. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4105: codec_dahdi: Fix segfault on load.
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4105/#review13587
---
Ship it!
Minor nits.
The commit description has using using.
branches/13/codecs/codec_dahdi.c
https://reviewboard.asterisk.org/r/4105/#comment24106
Need to update the doxygen function parameter documentation.
- rmudgett
On Oct. 22, 2014, 2:13 p.m., Shaun Ruffell wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4105/
---
(Updated Oct. 22, 2014, 2:13 p.m.)
Review request for Asterisk Developers.
Bugs: ASTERISK-24435
https://issues.asterisk.org/jira/browse/ASTERISK-24435
Repository: Asterisk
Description
---
This is another version of https://reviewboard.asterisk.org/r/4100/ that
doesn't change anything in the core of Asterisk.
The commit message from original git-patch:
codec_dahdi: Cannot use struct ast_translator.core_{src,src}_codec.
This fixes a Segmentation fault introduced in r419044 media formats:
re-architect
handling of media for performance improvements.
The problem is that codec_dahdi was using using core_src_codec and
core_dst_codec in the
ast_translator structure when these fields were never set. Now instead of
trying to map
the new core codec descriptions to the way DAHDI defines different
codecs, we will store
the DAHDI specific formats in 'struct translator' directly so we can
refer to them without
mapping.
This also allows us to remove the global_format_map structure, since we
can now query
the list of translators directly to make sure we do not ever register a
DAHDI based
translator for a specific path more than once and eliminate the need to
keep the list and
the map in sync.
Diffs
-
branches/13/codecs/codec_dahdi.c 426095
Diff: https://reviewboard.asterisk.org/r/4105/diff/
Testing
---
Called between two phones with g729 on one side and g722 on the other and
made sure transcoder show indicated the transcoder was in use and I could
hear myself.
Thanks,
Shaun Ruffell
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4106: configure: Add autoconf check for libopus
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4106/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Because opus transcoding support cannot be included in the standard Asterisk distribution, a few codec_opus implementations have popped up. To make it easier for people to drop in opus support in their own installations, this patch adds configure checks for libopus. I don't see why this wouldn't be safe for 13, but I will defer to the reviewers on that decision. Diffs - /trunk/makeopts.in 426095 /trunk/include/asterisk/autoconfig.h.in 426095 /trunk/configure.ac 426095 /trunk/configure UNKNOWN /trunk/build_tools/menuselect-deps.in 426095 Diff: https://reviewboard.asterisk.org/r/4106/diff/ Testing --- Thanks, Sean Bright -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4105: codec_dahdi: Fix segfault on load.
On Oct. 22, 2014, 2:33 p.m., rmudgett wrote:
Minor nits.
The commit description has using using.
Also the commit description would need to have the following headers added:
ASTERISK-24435 #close
Reported by: Marian Koniuszko
Review: https://reviewboard.asterisk.org/r/4105/
- rmudgett
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4105/#review13587
---
On Oct. 22, 2014, 2:13 p.m., Shaun Ruffell wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4105/
---
(Updated Oct. 22, 2014, 2:13 p.m.)
Review request for Asterisk Developers.
Bugs: ASTERISK-24435
https://issues.asterisk.org/jira/browse/ASTERISK-24435
Repository: Asterisk
Description
---
This is another version of https://reviewboard.asterisk.org/r/4100/ that
doesn't change anything in the core of Asterisk.
The commit message from original git-patch:
codec_dahdi: Cannot use struct ast_translator.core_{src,src}_codec.
This fixes a Segmentation fault introduced in r419044 media formats:
re-architect
handling of media for performance improvements.
The problem is that codec_dahdi was using using core_src_codec and
core_dst_codec in the
ast_translator structure when these fields were never set. Now instead of
trying to map
the new core codec descriptions to the way DAHDI defines different
codecs, we will store
the DAHDI specific formats in 'struct translator' directly so we can
refer to them without
mapping.
This also allows us to remove the global_format_map structure, since we
can now query
the list of translators directly to make sure we do not ever register a
DAHDI based
translator for a specific path more than once and eliminate the need to
keep the list and
the map in sync.
Diffs
-
branches/13/codecs/codec_dahdi.c 426095
Diff: https://reviewboard.asterisk.org/r/4105/diff/
Testing
---
Called between two phones with g729 on one side and g722 on the other and
made sure transcoder show indicated the transcoder was in use and I could
hear myself.
Thanks,
Shaun Ruffell
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: AgendaitemDeprecate AMI/AGI(Ben Klang)
On Oct 22, 2014, at 2:26 PM, Leif Madsen lmad...@thinkingphones.com wrote: On 22 October 2014 14:55, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 11:31 AM, Matthew Jordan mjor...@digium.com wrote: This is an open source project. Communication is done in an open, transparent manner. People should feel like they can bring up interesting, radical, and yes - even crazy - ideas. By the same token, when you propose ideas, you must be prepared for honest criticism and accept it in graciously rather than simply resorting to argument ad hominem. I don't think that word means what you think it means. If you don't like that, you don't have to participate in the discussion. You haven’t really responded to the substance of my post, that is, is asterisk abandoning the dial plan? Someone proposed an idea during the devcon. Nothing has been decided or even discussed yet. What you're reading and freaking out about is simply a list of ideas mentioned during the devcon, and noted in a document. That's as far as it has gotten; a list of minutes you're reading without further context based on actual participation in the conference itself. Here’s a link to the minutes: https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2014 It has you saying: Leif: we're in a transition, moving from dialplan model to external control model. Probably need external application to be built for us to move completely away from AMI/AGI. So you’re saying Asterisk is moving away from the dial plan or were you misquoted? Leif. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstriDevCon 2014: AgendaitemDeprecate AMI/AGI(Ben Klang)
On Oct 22, 2014, at 2:13 PM, Scott Griepentrog sgriepent...@digium.com wrote: is asterisk abandoning the dial plan? It's clear that there is a desire to have a way of running Asterisk with little or no dialplan. While currently there is no way to abandon the dialplan as you point out, that could actually happen, someday, many years and versions from now. But even then I would expect there could be a loadable module to add dialplan support for those who still need it, where the dependencies on dialplan have since been removed from the core. There has to be some more justification for such a profound change to a mature product interface than some vague desire by unknown persons who know best for the entire Asterisk community. So, to answer your question, yes, and no. On Wed, Oct 22, 2014 at 1:55 PM, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 11:31 AM, Matthew Jordan mjor...@digium.com wrote: On Wed, Oct 22, 2014 at 11:14 AM, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. Just because someone decided to bring up a radical idea does not mean we refuse to discuss it. So you agree that deprecating AMI/AGI is “crazy talk” but you’ll discuss it because of your open-mindedness? This is an open source project. Communication is done in an open, transparent manner. People should feel like they can bring up interesting, radical, and yes - even crazy - ideas. By the same token, when you propose ideas, you must be prepared for honest criticism and accept it in graciously rather than simply resorting to argument ad hominem. If you don't like that, you don't have to participate in the discussion. You haven’t really responded to the substance of my post, that is, is asterisk abandoning the dial plan? -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Scott Griepentrog Digium, Inc · Software Developer 445 Jan Davis Drive NW · Huntsville, AL 35806 · US direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090 Check us out at: http://digium.com · http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4105: codec_dahdi: Fix segfault on load.
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4105/#review13589
---
Ship it!
Ship It!
- Joshua Colp
On Oct. 22, 2014, 7:13 p.m., Shaun Ruffell wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4105/
---
(Updated Oct. 22, 2014, 7:13 p.m.)
Review request for Asterisk Developers.
Bugs: ASTERISK-24435
https://issues.asterisk.org/jira/browse/ASTERISK-24435
Repository: Asterisk
Description
---
This is another version of https://reviewboard.asterisk.org/r/4100/ that
doesn't change anything in the core of Asterisk.
The commit message from original git-patch:
codec_dahdi: Cannot use struct ast_translator.core_{src,src}_codec.
This fixes a Segmentation fault introduced in r419044 media formats:
re-architect
handling of media for performance improvements.
The problem is that codec_dahdi was using using core_src_codec and
core_dst_codec in the
ast_translator structure when these fields were never set. Now instead of
trying to map
the new core codec descriptions to the way DAHDI defines different
codecs, we will store
the DAHDI specific formats in 'struct translator' directly so we can
refer to them without
mapping.
This also allows us to remove the global_format_map structure, since we
can now query
the list of translators directly to make sure we do not ever register a
DAHDI based
translator for a specific path more than once and eliminate the need to
keep the list and
the map in sync.
Diffs
-
branches/13/codecs/codec_dahdi.c 426095
Diff: https://reviewboard.asterisk.org/r/4105/diff/
Testing
---
Called between two phones with g729 on one side and g722 on the other and
made sure transcoder show indicated the transcoder was in use and I could
hear myself.
Thanks,
Shaun Ruffell
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-users] AstriDevCon 2014: Agenda itemDeprecate AMI/AGI(Ben Klang)
On Wed, Oct 22, 2014 at 1:55 PM, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 11:31 AM, Matthew Jordan mjor...@digium.com wrote: On Wed, Oct 22, 2014 at 11:14 AM, Paul Albrecht palbre...@glccom.com wrote: On Oct 22, 2014, at 10:33 AM, Joshua Colp jc...@digium.com wrote: Paul Albrecht wrote: Really? Shouldn’t something this major affecting the entire Asterisk community get discussed on the lists? Any idea what Leif is talking about when he says the community is in transition, moving from dial plan model to external control. It was something Ben Klang brought up and wanted to talk about - it's not something that has been decided 'nor does anyone know what the future entails. Any further discussions will naturally occur on the mailing list and in fact some things have explicit action items to bring them up on here. The suggestion that Asterisk should consider deprecating AMI/AGI is “crazy talk.” It doesn’t merit discussion and shouldn’t be on the agenda in the first place. It’s completely impractical and can never happen. Moreover, Leif seems to think we (the asterisk community) are in transition. What does that mean? Are we abandoning the dial plan? Seriously? That’s never gonna happen either. ARI isn’t easier to use than dial plan scripting. I guess one could hope that what happens in Vegas stays in Vegas”, but I don’t think the Asterisk community has that kind of luck. Just because someone decided to bring up a radical idea does not mean we refuse to discuss it. So you agree that deprecating AMI/AGI is “crazy talk” but you’ll discuss it because of your open-mindedness? I didn't say that the idea of deprecating AMI/AGI is crazy talk. I did say that radical ideas - and even ones that some folks think are crazy - are all fine to discuss at AstriDevCon. The whole point of AstriDevCon is to have a large, free, and open conversation about Asterisk Development. I fundamentally disagree with the notion that that should be discouraged. This is an open source project. Communication is done in an open, transparent manner. People should feel like they can bring up interesting, radical, and yes - even crazy - ideas. By the same token, when you propose ideas, you must be prepared for honest criticism and accept it in graciously rather than simply resorting to argument ad hominem. You didn't have honest criticism. You labelled a discussion point as crazy talk and said we shouldn't have even discussed it. There was no ad hominem attack. I never attacked you. I never even attacked your statements. I simply defended the free exchange of ideas in AstriDevCon. I have no problem doing that. On the other hand, you did callously label an Asterisk Developer's admittedly ambitious idea as crazy talk. In the future, you may want to choose your language more carefully if you wish for others to have a more open discussion with you. If you don't like that, you don't have to participate in the discussion. You haven’t really responded to the substance of my post, that is, is asterisk abandoning the dial plan? There are Asterisk users (who also happen to develop) who would like to minimize the dialplan necessary in their systems, to the point where they may no longer even need the dialplan. This is a fundamentally sound idea for some systems, particularly those that require scaling Asterisk out to many machines. There are also some Asterisk users who build complex applications on top of Asterisk, and who find having to use multiple interfaces cumbersome. They like ARI, and would like to see it able to do more than what it currently does today. Fully deprecating a feature in Asterisk is non-trivial. You must have: (1) A logical and full replacement for the feature (2) Buy-off from the developer community (3) Several major versions of the project in which the deprecated feature must remain Even in the case of point #3, deprecated features have often lasted in *many* versions of Asterisk. We are enormously conservative in what we choose to remove from the project. I would imagine that things as important as traditional dialplan, AMI, or AGI would be very difficult to ever deprecate. Finally, as I've noted to you before [1] [2], please don't cross post across lists. As this discussion is about AstriDevCon, it should be on the asterisk-dev mailing list. [1] http://lists.digium.com/pipermail/asterisk-dev/2013-October/063075.html [2] http://lists.digium.com/pipermail/asterisk-app-dev/2013-October/000113.html -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4080: Test Suite: Fix the 'expected-result' YAML property for test configuration
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4080/#review13590 --- Ship it! I tested all combinations of pass/fail and it works correctly. - Scott Griepentrog On Oct. 21, 2014, 9:57 a.m., jbigelow wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4080/ --- (Updated Oct. 21, 2014, 9:57 a.m.) Review request for Asterisk Developers. Repository: testsuite Description --- When the 'expected-result' (or 'expectedResult') YAML property for test configuration is set to False and the test fails, the test should be marked as passed. However it is marked as failed. This patch should fix the issue so that tests are marked as passed in this scenario. Additionally: * Check if p.returncode is not zero so self.passed is a boolean rather than an int in some cases. * Added some print statements to make it clear why a test was marked as passed or failed when the 'expected-result' YAML property is set to False. * Added text to the failure message so it's easily known when looking at the results file that the test was expected to fail but passed and therefore marked as failed. Diffs - /asterisk/trunk/runtests.py 5766 /asterisk/trunk/lib/python/asterisk/test_config.py 5766 Diff: https://reviewboard.asterisk.org/r/4080/diff/ Testing --- Tested the various scenarios and they all seem to properly work as expected now. Thanks, jbigelow -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4105: codec_dahdi: Fix segfault on load.
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4105/
---
(Updated Oct. 22, 2014, 4:27 p.m.)
Status
--
This change has been marked as submitted.
Review request for Asterisk Developers.
Changes
---
Committed in revision 426097
Bugs: ASTERISK-24435
https://issues.asterisk.org/jira/browse/ASTERISK-24435
Repository: Asterisk
Description
---
This is another version of https://reviewboard.asterisk.org/r/4100/ that
doesn't change anything in the core of Asterisk.
The commit message from original git-patch:
codec_dahdi: Cannot use struct ast_translator.core_{src,src}_codec.
This fixes a Segmentation fault introduced in r419044 media formats:
re-architect
handling of media for performance improvements.
The problem is that codec_dahdi was using using core_src_codec and
core_dst_codec in the
ast_translator structure when these fields were never set. Now instead of
trying to map
the new core codec descriptions to the way DAHDI defines different codecs,
we will store
the DAHDI specific formats in 'struct translator' directly so we can refer
to them without
mapping.
This also allows us to remove the global_format_map structure, since we
can now query
the list of translators directly to make sure we do not ever register a
DAHDI based
translator for a specific path more than once and eliminate the need to
keep the list and
the map in sync.
Diffs
-
branches/13/codecs/codec_dahdi.c 426095
Diff: https://reviewboard.asterisk.org/r/4105/diff/
Testing
---
Called between two phones with g729 on one side and g722 on the other and made
sure transcoder show indicated the transcoder was in use and I could hear
myself.
Thanks,
Shaun Ruffell
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4107: Wiki: Some new PJSIP-related pages
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4107/ --- Review request for Asterisk Developers. Description --- I have written the following wiki pages: https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+for+Presence+Subscriptions https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=30278158 https://wiki.asterisk.org/wiki/display/AST/Configuring+Outbound+Registrations https://wiki.asterisk.org/wiki/display/AST/Asterisk+PJSIP+Troubleshooting+Guide The first three pages are tutorial pages for Asterisk PJSIP usage. The first focuses on setting up presence subscriptions, the second focuses on setting up resource list subscriptions, and the third focuses on configuring outbound registrations. The fourth page is a general PJSIP troubleshooting guide. The intent of this page is not to be exhaustive at the moment, since this is a page that likely will be updated frequently as specific issues are encountered. This page may need to be split into multiple pages, but I'll leave that judgment to the reviewers. Diffs - Diff: https://reviewboard.asterisk.org/r/4107/diff/ Testing --- Thanks, Mark Michelson -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4100: codec_dahdi: Fix crash on load of codec_dahdi.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4100/ --- (Updated Oct. 22, 2014, 4:45 p.m.) Status -- This change has been discarded. Review request for Asterisk Developers. Bugs: ASTERISK-24435 https://issues.asterisk.org/jira/browse/ASTERISK-24435 Repository: Asterisk Description --- Codec_dahdi is the only translator that uses the struct ast_translator-core_src_codec and struct ast_translator-core_dst_codec pointers. Unfortunately, nothing ever initialized the pointers. Diffs - /branches/13/main/translate.c 426078 /branches/13/include/asterisk/translate.h 426078 /branches/13/codecs/codec_dahdi.c 426078 Diff: https://reviewboard.asterisk.org/r/4100/diff/ Testing --- Made some calls that perform translation. No crashes happened. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4107: Wiki: Some new PJSIP-related pages
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4107/#review13591 --- In the outbound registrations page you might want to mention what contact_user actually is. It's the id of the endpoint, right? - George Joseph On Oct. 22, 2014, 3:37 p.m., Mark Michelson wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4107/ --- (Updated Oct. 22, 2014, 3:37 p.m.) Review request for Asterisk Developers. Description --- I have written the following wiki pages: https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+for+Presence+Subscriptions https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=30278158 https://wiki.asterisk.org/wiki/display/AST/Configuring+Outbound+Registrations https://wiki.asterisk.org/wiki/display/AST/Asterisk+PJSIP+Troubleshooting+Guide The first three pages are tutorial pages for Asterisk PJSIP usage. The first focuses on setting up presence subscriptions, the second focuses on setting up resource list subscriptions, and the third focuses on configuring outbound registrations. The fourth page is a general PJSIP troubleshooting guide. The intent of this page is not to be exhaustive at the moment, since this is a page that likely will be updated frequently as specific issues are encountered. This page may need to be split into multiple pages, but I'll leave that judgment to the reviewers. Diffs - Diff: https://reviewboard.asterisk.org/r/4107/diff/ Testing --- Thanks, Mark Michelson -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4108: Weak References
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4108/ --- Review request for Asterisk Developers, George Joseph and rmudgett. Repository: Asterisk Description --- This implements weak references. The weak object is a real ao2 with normal reference counting of its own. The original object is destroyed when the only reference remaining is from the weak object. Diffs - /trunk/tests/test_astobj2_weaken.c PRE-CREATION /trunk/main/astobj2.c 426072 /trunk/include/asterisk/astobj2.h 426072 Diff: https://reviewboard.asterisk.org/r/4108/diff/ Testing --- Very little, I'm unsure how to actually test that this cannot race, since any potential for a race would be due to very exact timing. Thanks, Corey Farrell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4109: Documentation: CDR unanswered behavior
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4109/ --- Review request for Asterisk Developers. Bugs: https://issues.asterisk.org/jira/browse/ASTERISK-24279 https://issues.asterisk.org/jira/browse/https://issues.asterisk.org/jira/browse/ASTERISK-24279 Repository: Asterisk Description --- Fixes the documentation of the cdr.conf option 'Unanswered' to hopefully more accurately explain the behavior. Culled some less than accurate, somewhat misleading information and explained a little bit about what kinds of calls will be skipped from logs under this context. In addition, fixing a bit of missing documentation and a dead link on the wiki: https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=22088359selectedPageVersions=15selectedPageVersions=13 I'm not sure if I'm entirely satisfied with my definition for Unanswered. Diffs - /branches/12/main/cdr.c 426095 /branches/12/configs/cdr.conf.sample 426095 Diff: https://reviewboard.asterisk.org/r/4109/diff/ Testing --- I checked some simple calling scenarios involve app_dial in one case and call files in another to make sure that the behavior didn't differ from the definition... at least in those scenarios. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4108: Weak References
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4108/ --- (Updated Oct. 22, 2014, 7:07 p.m.) Review request for Asterisk Developers, George Joseph and rmudgett. Changes --- Fix author on test. Repository: Asterisk Description --- This implements weak references. The weak object is a real ao2 with normal reference counting of its own. The original object is destroyed when the only reference remaining is from the weak object. Diffs (updated) - /trunk/tests/test_astobj2_weaken.c PRE-CREATION /trunk/main/astobj2.c 426072 /trunk/include/asterisk/astobj2.h 426072 Diff: https://reviewboard.asterisk.org/r/4108/diff/ Testing --- Very little, I'm unsure how to actually test that this cannot race, since any potential for a race would be due to very exact timing. Thanks, Corey Farrell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
