Re: [asterisk-dev] [Code Review] 4112: testsuite: Make tests/fax/pjsip/* depend on chan_pjsip
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4112/ --- (Updated Oct. 28, 2014, 6:07 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5797 Repository: testsuite Description --- PJSIP fax tests are missing dependency on chan_pjsip and res_pjsip_t38, causing them all to fail if Asterisk was compiled without pjproject. I have not looked into if these tests actually require res_pjsip_t38 (I don't have pjproject on my system). I added it since all tests have 't38' in the name. Diffs - /asterisk/trunk/tests/fax/pjsip/t38/test-config.yaml 5649 /asterisk/trunk/tests/fax/pjsip/gateway_t38_g711/test-config.yaml 5649 /asterisk/trunk/tests/fax/pjsip/gateway_native_t38/test-config.yaml 5649 /asterisk/trunk/tests/fax/pjsip/directmedia_reinvite_t38/test-config.yaml 5649 Diff: https://reviewboard.asterisk.org/r/4112/diff/ Testing --- Verified these tests no longer attempt to run when Asterisk was compiled without pjproject. 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
Re: [asterisk-dev] [Code Review] 4113: func_cdr: CDR_PROP leaks payload
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4113/ --- (Updated Oct. 28, 2014, 6:11 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 426252 Bugs: ASTERISK-24455 https://issues.asterisk.org/jira/browse/ASTERISK-24455 Repository: Asterisk Description --- cdr_prop_write allocates payload twice, causing a leak for every call. I've removed the allocation with the declaration of payload, leaving it to be allocated at line 563. Diffs - /branches/13/funcs/func_cdr.c 426139 Diff: https://reviewboard.asterisk.org/r/4113/diff/ Testing --- Visual inspection only - my system is busy running other tests and this fix is very clear. 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
Re: [asterisk-dev] [Code Review] 4111: app_queue: ao2_iterator not destroyed, causing leak
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4111/ --- (Updated Oct. 28, 2014, 6:17 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 426255 Bugs: ASTERISK-24454 https://issues.asterisk.org/jira/browse/ASTERISK-24454 Repository: Asterisk Description --- update_realtime_members doesn't release the iterator for q-members, causing a reference leak. Diffs - /branches/11/apps/app_queue.c 426232 Diff: https://reviewboard.asterisk.org/r/4111/diff/ Testing --- Testsuite against 13, compile test/visual inspection for 11. 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
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)
Not asking for unqualified promises about the future of Asterisk. Simply asking for an acknowledgment of the obvious, that is, Asterisk without the dial plan wouldn’t be Asterisk. The fact that one is not forthcoming raises a red flag with respect to the future of Asterisk. Furthermore, adding “asynchronous AGI” and ARI/Stasis to Asterisk is similarly a cause for concern since it’s a complete break with the original Asterisk design. Since Asterisk is an open source community supported project, one would expect the consultants/developers pushing these changes would be willing to share their vision with the rest of the Asterisk community. On Oct 27, 2014, at 2:32 PM, Jeffrey Ollie j...@ocjtech.us wrote: On Mon, Oct 27, 2014 at 2:04 PM, Paul Albrecht palbre...@glccom.com wrote: The reason the dial plan can never be deprecated is because Asterisk wouldn’t be Asterisk without the dial plan. Sure, you could re-engineer Asterisk so that it would be “better for a small select group of users at the expense of the majority of community that use the product as designed for the purpose it was originally intended. However, you’re either very naive or delusional if you think the community is going to follow you down that path. Do you really believe the community is going simply chuck their dial plans and walk away from their investment in Asterisk? Not likely, dude. My comment/question wasn't really about dial plans, per se. My question was about you insisting that Digium make such unqualified promises about the future of Asterisk. Even though Digium is a private company, I believe that they are still bound by U.S. laws regarding forward-looking statements[1]. So even if they wanted to (which I doubt), there's no way you're going to get the promise that you're looking for. [1] http://en.wikipedia.org/wiki/Forward-looking_statement -- Jeff Ollie -- _ -- 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] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)
So. After all this I'm tired of hearing the same argument. I've decided to take the other side. I have seen the progression of Asterisk for the last 5+ years. I was at Astricon when it was held in the DC area and the last one in Atlanta (I wish you'd go back there instead of Vegas!). I tried to use Asterisk many times but always found it wanting. Why? I'm a programmer. I like to be able to make tools do what I want. So, I left Asterisk and moved on to FreeSWITCH. After beating my head against the FS wall for quite some time I was just about ready to give up completely. Until I saw the videos from Astricon 2013 talking about ARI. I knew immediately this is what I wanted. Over the last several months I have written a full answering service system using ARI. It is PERFECT! Would I like a few more features in ARI? Of course. I'm I blown away by how complete the new options are?. Without ARI I could've never have done what I did. Should they drop the dialplan? Please. Now. I can't believe this isn't holding back options. You really want to stick with the dialplan? Really? Fine. Do it. You have all the source code. Apparently, you use V1.4 anyway. What difference is it to you? Be honest. This has nothing to do with the Asterisk Community. It has to do with you. What you want. There are many of us who are very thankful they have moved forward. Both ARI and PJSIP. The old SIP problems were many and awful. If all you want is a standard PBX you've got it. What I want is something I can work with without having to program in C again which I gave up many, many years ago. I have no interest in going back. So, from my POV and hopefully many who will discover Asterisk again (I'm talking to you FreeSWITCHers!) ARI (and PJSIP) are the real thing. This is a very exciting time and I'm looking forward to many applications that I will be able to create. Thank you Digium and all the Asterisk developers for going in this direction. I will certainly be at Astricon next year (even if it's in LV) and you will hear me support moving forward as quickly as possible. Phil Mickelson CBA Software, LLC On Tue, Oct 28, 2014 at 10:58 AM, Paul Albrecht palbre...@glccom.com wrote: Not asking for unqualified promises about the future of Asterisk. Simply asking for an acknowledgment of the obvious, that is, Asterisk without the dial plan wouldn’t be Asterisk. The fact that one is not forthcoming raises a red flag with respect to the future of Asterisk. Furthermore, adding “asynchronous AGI” and ARI/Stasis to Asterisk is similarly a cause for concern since it’s a complete break with the original Asterisk design. Since Asterisk is an open source community supported project, one would expect the consultants/developers pushing these changes would be willing to share their vision with the rest of the Asterisk community. On Oct 27, 2014, at 2:32 PM, Jeffrey Ollie j...@ocjtech.us wrote: On Mon, Oct 27, 2014 at 2:04 PM, Paul Albrecht palbre...@glccom.com wrote: The reason the dial plan can never be deprecated is because Asterisk wouldn’t be Asterisk without the dial plan. Sure, you could re-engineer Asterisk so that it would be “better for a small select group of users at the expense of the majority of community that use the product as designed for the purpose it was originally intended. However, you’re either very naive or delusional if you think the community is going to follow you down that path. Do you really believe the community is going simply chuck their dial plans and walk away from their investment in Asterisk? Not likely, dude. My comment/question wasn't really about dial plans, per se. My question was about you insisting that Digium make such unqualified promises about the future of Asterisk. Even though Digium is a private company, I believe that they are still bound by U.S. laws regarding forward-looking statements[1]. So even if they wanted to (which I doubt), there's no way you're going to get the promise that you're looking for. [1] http://en.wikipedia.org/wiki/Forward-looking_statement -- Jeff Ollie -- _ -- 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 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)
On Tue, Oct 28, 2014 at 11:24 AM, Phil Mickelson p...@cbasoftware.com wrote: So. After all this I'm tired of hearing the same argument. I've decided to take the other side. I have seen the progression of Asterisk for the last 5+ years. I was at Astricon when it was held in the DC area and the last one in Atlanta (I wish you'd go back there instead of Vegas!). I tried to use Asterisk many times but always found it wanting. Why? I'm a programmer. I like to be able to make tools do what I want. So, I left Asterisk and moved on to FreeSWITCH. After beating my head against the FS wall for quite some time I was just about ready to give up completely. Until I saw the videos from Astricon 2013 talking about ARI. I knew immediately this is what I wanted. Over the last several months I have written a full answering service system using ARI. It is PERFECT! Would I like a few more features in ARI? Of course. I'm I blown away by how complete the new options are?. Without ARI I could've never have done what I did. Should they drop the dialplan? Please. Now. I can't believe this isn't holding back options. You really want to stick with the dialplan? Really? Fine. Do it. You have all the source code. Apparently, you use V1.4 anyway. What difference is it to you? Be honest. This has nothing to do with the Asterisk Community. It has to do with you. What you want. There are many of us who are very thankful they have moved forward. Both ARI and PJSIP. The old SIP problems were many and awful. If all you want is a standard PBX you've got it. What I want is something I can work with without having to program in C again which I gave up many, many years ago. I have no interest in going back. So, from my POV and hopefully many who will discover Asterisk again (I'm talking to you FreeSWITCHers!) ARI (and PJSIP) are the real thing. This is a very exciting time and I'm looking forward to many applications that I will be able to create. Thank you Digium and all the Asterisk developers for going in this direction. I will certainly be at Astricon next year (even if it's in LV) and you will hear me support moving forward as quickly as possible. I LOVE this post. Thanks, Phil. Well said. I said this in my talk last week and will reiterate it here. I think the Asterisk dev community has been doing an amazing job over the last few years. Internal refactorings have been achieved that we used to dream of. A new SIP channel driver finally exists. The new API work just totally rocks. It's an absolutely critical piece of what is needed from Asterisk to fit in to the way future telephony applications should be architected in my view. Well done, dev community. Keep kicking ass. -- Russell Bryant -- _ -- 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] 4117: Fix building chan_phone on big endian systems
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4117/ --- Review request for Asterisk Developers. Bugs: https://issues.asterisk.org/jira/browse/ASTERISK-24458 https://issues.asterisk.org/jira/browse/https://issues.asterisk.org/jira/browse/ASTERISK-24458 Repository: Asterisk Description --- A left over from the formats conversion. Note: there seem to be a few other left-over AST_FORMAT_SLINEAR, mostly in comments. Fix those as well? Diffs - /branches/13/channels/chan_phone.c 426440 Diff: https://reviewboard.asterisk.org/r/4117/diff/ Testing --- Big endian platforms (sparc, powerpc, s390x) on buildd.debian.org now build. Thanks, Tzafrir Cohen -- _ -- 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] 4118: install init.d files on GNU/kFreeBSD
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4118/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Do install the files in the config target even in GNU/kFreeBSD. Also: $ grep 'OSARCH.*gnu' main/Makefile ifneq ($(findstring $(OSARCH), linux-gnu uclinux linux-uclibc kfreebsd-gnu),) Diffs - /branches/13/Makefile 426440 Diff: https://reviewboard.asterisk.org/r/4118/diff/ Testing --- Thanks, Tzafrir Cohen -- _ -- 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 28 October 2014 14:44, Russell Bryant russ...@russellbryant.net wrote: On Tue, Oct 28, 2014 at 11:24 AM, Phil Mickelson p...@cbasoftware.com wrote: So. After all this I'm tired of hearing the same argument. I've decided to take the other side. I have seen the progression of Asterisk for the last 5+ years. I was at Astricon when it was held in the DC area and the last one in Atlanta (I wish you'd go back there instead of Vegas!). I tried to use Asterisk many times but always found it wanting. Why? I'm a programmer. I like to be able to make tools do what I want. So, I left Asterisk and moved on to FreeSWITCH. After beating my head against the FS wall for quite some time I was just about ready to give up completely. Until I saw the videos from Astricon 2013 talking about ARI. I knew immediately this is what I wanted. Over the last several months I have written a full answering service system using ARI. It is PERFECT! Would I like a few more features in ARI? Of course. I'm I blown away by how complete the new options are?. Without ARI I could've never have done what I did. Should they drop the dialplan? Please. Now. I can't believe this isn't holding back options. You really want to stick with the dialplan? Really? Fine. Do it. You have all the source code. Apparently, you use V1.4 anyway. What difference is it to you? Be honest. This has nothing to do with the Asterisk Community. It has to do with you. What you want. There are many of us who are very thankful they have moved forward. Both ARI and PJSIP. The old SIP problems were many and awful. If all you want is a standard PBX you've got it. What I want is something I can work with without having to program in C again which I gave up many, many years ago. I have no interest in going back. So, from my POV and hopefully many who will discover Asterisk again (I'm talking to you FreeSWITCHers!) ARI (and PJSIP) are the real thing. This is a very exciting time and I'm looking forward to many applications that I will be able to create. Thank you Digium and all the Asterisk developers for going in this direction. I will certainly be at Astricon next year (even if it's in LV) and you will hear me support moving forward as quickly as possible. I LOVE this post. Thanks, Phil. Well said. I said this in my talk last week and will reiterate it here. I think the Asterisk dev community has been doing an amazing job over the last few years. Internal refactorings have been achieved that we used to dream of. I second every one of Phil's points and this observation in particular. Trying to bend Asterisk to be capable of these sorts of things used to be the stuff of nightmares and despair. Now there is hope that complex use cases and capabilities are becoming first class citizens within the project and its community and that the stagnation and horror of earlier years is no more. This is very much appreciated and welcomed, and I hope we can contribute more going forward in whatever form we are able. A new SIP channel driver finally exists. The new API work just totally rocks. It's an absolutely critical piece of what is needed from Asterisk to fit in to the way future telephony applications should be architected in my view. Well done, dev community. Keep kicking ass. +10 -- Russell Bryant -- _ -- 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
[asterisk-dev] [Code Review] 4120: res_pjsip_acl: contact ACL permits are being interpreted incorrectly
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4120/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- In the attempt to skip past the 'contact' part of the variable name before passing it into the acl handler, we have a momentary lapse of sanity and forget that '_allow' isn't 'allow' and ast_append_acl interprets it as another deny. Diffs - /branches/12/res/res_pjsip_acl.c 426232 Diff: https://reviewboard.asterisk.org/r/4120/diff/ Testing --- deny=0.0.0.0/24 allow=ip address of a device that tries to register Note that I have to reload pjsip after startup in order for the ACL to work... that seems like a bug surely. In any event, with the patch the device successfully registers. Without the patch, the registration is blocked by the ACL. 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] 4117: Fix building chan_phone on big endian systems
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4117/#review13603 --- Ship it! Ship It! - Jonathan Rose On Oct. 28, 2014, 12:46 p.m., Tzafrir Cohen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4117/ --- (Updated Oct. 28, 2014, 12:46 p.m.) Review request for Asterisk Developers. Bugs: https://issues.asterisk.org/jira/browse/ASTERISK-24458 https://issues.asterisk.org/jira/browse/https://issues.asterisk.org/jira/browse/ASTERISK-24458 Repository: Asterisk Description --- A left over from the formats conversion. Note: there seem to be a few other left-over AST_FORMAT_SLINEAR, mostly in comments. Fix those as well? Diffs - /branches/13/channels/chan_phone.c 426440 Diff: https://reviewboard.asterisk.org/r/4117/diff/ Testing --- Big endian platforms (sparc, powerpc, s390x) on buildd.debian.org now build. Thanks, Tzafrir Cohen -- _ -- 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] 4119: pjsip: handle outbound unregister correctly
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4119/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24411 https://issues.asterisk.org/jira/browse/ASTERISK-24411 Repository: Asterisk Description --- Patch from John Bigelow: This patch sets the status of the outbound registration to reflect when it has been unregistered. Since the registration is unregistered rather than stopped, the registration schedule remains active as before. The patch also updates the documentation of both the AMI and CLI commands. Diffs - /branches/12/res/res_pjsip_outbound_registration.c 426523 Diff: https://reviewboard.asterisk.org/r/4119/diff/ Testing --- Previously failing test channels/pjsip/registration/outbound/unregister/unauthed now passes. Other pjsip tests that were passing still pass. Thanks, Scott Griepentrog -- _ -- 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] 4115: res_fax: fax gateway frames leak
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4115/ --- (Updated Oct. 28, 2014, 3:50 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 426527 Bugs: ASTERISK-24457 https://issues.asterisk.org/jira/browse/ASTERISK-24457 Repository: Asterisk Description --- fax_gateway_framehook leaks translated frames. Over 1.6mb worth of frames is leaked by tests/fax/sip/gateway_g711_t38 by one of the instances of Asterisk. Diffs - /branches/11/res/res_fax.c 426232 Diff: https://reviewboard.asterisk.org/r/4115/diff/ Testing --- Verified tests/fax/sip/gateway_g711_t38 no longer leaks on 11 and 13. 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
Re: [asterisk-dev] [Code Review] 4121: testsuite: Close ARI websocket connections before stopping reactor
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4121/ --- (Updated Oct. 28, 2014, 5:19 p.m.) Review request for Asterisk Developers. Changes --- Override stop_reactor in AriBestTestObject per recommendation of mjordan on IRC. Repository: testsuite Description --- All (or most) tests in tests/rest_api leak numerous referenced objects by not closing the ARI websocket connection. Diffs (updated) - /asterisk/trunk/lib/python/asterisk/ari.py 5796 Diff: https://reviewboard.asterisk.org/r/4121/diff/ Testing --- Using r4038 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
Re: [asterisk-dev] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)
What is the alternative to the dial plan? Is everyone talking about getting rid of the statements like: exten = s,1, what is the alternative? -- _ -- 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 28 October 2014 19:47, Derek Andrew derek.and...@usask.ca wrote: What is the alternative to the dial plan? Is everyone talking about getting rid of the statements like: exten = s,1, what is the alternative? Remote applications based on APIs like ARI. This is the start of the discussion, and please remember that nothing has been decided or even presented as a robust plan yet. This is brain-storming. Additionally, note that the original proposal was to deprecate AMI/AGI in favour of ARI once it is feature complete with those protocols; an entirely lesser change than the removal of the dialplan in its entirety. -- _ -- 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)
I can't speak for anyone else, but my vision would be for an easy to use application that would allow for all the options you now have and even more. The major difference is that you wouldn't have to try to figure out all the complexities of the current dialplan. For example, you could have a drag and drop type of flow chart that could be used for simple channel control. Then you could name them, almost like macros, and combine them to create more complex channel control. Or, you could use some logical language constructs that include If/Then/Else, Case, While, etc. All of those could be handled through the ARI (along with Stasis). And, combine them with a database for even more flexibility. Further, imagine that you didn't have to even reload Asterisk to get this done! That you could add new dialplans, change existing ones, and remove them completely, all in realtime. My hope is to get the ability to create extensions the same way. Then I could handle everything. BTW, I have a system, right now, that is handling incoming calls exactly like the above. I can add new phone numbers, remove them, etc and I never have to reload Asterisk. I don't have the simple to use general front end, but it wouldn't be that hard to add. I literally have a single entry point in the dialplan to handle all incoming calls. It seems to work (so far) exactly like I expect it to. Each of those phone numbers are a different customer. Depending on the customer information significantly different options are displayed to the screen. There is no way I could've done that with the existing dialplan. And, further, each time a new customer was added or removed Asterisk would've had to been reloaded. That would've been a non-starter. And, this is just one alternative. I can guarantee you that you let a bunch of programmers loose on this and you'll get a bunch of alternatives. I believe, this is exactly what the Asterisk developers were hoping for. At least, I hope it is! Hope that answers your question. Phil Mickelson CBA Software, LLC On Tue, Oct 28, 2014 at 5:47 PM, Derek Andrew derek.and...@usask.ca wrote: What is the alternative to the dial plan? Is everyone talking about getting rid of the statements like: exten = s,1, what is the alternative? -- _ -- 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] [Code Review] 4038: Testsuite: Process REF_DEBUG logs, fail any test that leaks
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4038/ --- (Updated Oct. 28, 2014, 6:06 p.m.) Review request for Asterisk Developers. Changes --- print message when REF_DEBUG identifies leaks. Add contrib/scripts/refleaks-summary to print objects leaked per instance of Asterisk. Bugs: ASTERISK-24379 https://issues.asterisk.org/jira/browse/ASTERISK-24379 Repository: testsuite Description --- This causes any test that leaks references to fail if REF_DEBUG is enabled. Additionally run-local is modified to allow REF_DEBUG to be enabled through setup: MENUSELECT_OPTIONS='--enable REF_DEBUG' ./run-local setup Note if this option is used with Asterisk 1.8 all tests will fail due to manager.c leaking the sessions container. Diffs (updated) - /asterisk/trunk/runtests.py 5803 /asterisk/trunk/run-local 5803 /asterisk/trunk/contrib/scripts/refleaks-summary PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4038/diff/ Testing --- Ran against tests/channels/SIP/route on Asterisk 11 with and without r4037 applied. Test fails without, passes with. 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] 4122: testsuite: Fix freeze on tests/pbx/dialplan_reload
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4122/ --- Review request for Asterisk Developers and Scott Griepentrog. Repository: testsuite Description --- In some configurations 3 seconds is not enough of a delay before Asterisk is fully booted, preventing core restart gracefully from succeeding. This causes many iterations to be skipped, and in some cases the test never ends. Make use of core waitfullybooted to delay restarts. Remove unused global variables workingdir and testdir, add global variable restart_iterations to specify 50 runs. Decrease reactor_timeout from 300 to 30, use reset_timeout instead. Diffs - /asterisk/trunk/tests/pbx/dialplan_reload/run-test 5803 Diff: https://reviewboard.asterisk.org/r/4122/diff/ Testing --- Yes 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] AstriDevCon Summary
Hey everyone! Last week was AstriDevCon, and we had a great turn out with nearly 50 developers from all over the world. We had a lot of great discussion about a variety of topics, the notes of which are up on the Asterisk wiki: https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2014 Keep in mind that these notes were hastily taken during quite a lot of dynamic discussion. At the end of the conversation, the folks at AstriDevCon laid out a couple of broad objectives for the project for the coming year: 1. Improve our infrastructure and move the project to Git. In addition, we should take the opportunity to clarify and improve our contribution process. 2. Improve the documentation of the project, such that it is easier to install, deploy, and configure Asterisk. A number of suggestions were made on this topic, including performing and documenting some case studies on different deployments, providing configuration make targets for different scenarios, and generally improving the documentation in Asterisk and on the wiki. 3. Continue to improve the APIs in Asterisk, with a focus on enabling Asterisk as a media application server. In particular, what capabilities ARI should have should be further explored, focussing on allowing an application developer to configure and control the 'core' capabilities in Asterisk. Several general improvements to ARI were also discussed. Keep in mind that these are just just general objectives - while specific features were discussed, it's hard to know exactly what will be done when and by whom. As an open source project, any feature or improvement to Asterisk is always welcome - and I expect that developers both at Digium and in the community will have many other projects that they pursue over the next year. At the same time, these guidelines will hopefully focus everyone in the project on the some general goals. In addition, there are a number of Action items that are highlighted in the notes. The following is a synopsis of each of these action items: 1. Draft a policy for allowing improvements in release branches. The Asterisk project today does not exist in the same world - and is not the same project - as when the no new feature in release branches policy was first employed. We have a rigorous peer review process, multiple test suites, continuous integration infrastructure, and more to help prevent regressions or other problems from occurring. In addition, the world today is also moving faster, and we'd like to make sure that Asterisk maintains pace with changes in the industry. At the same time, we have to ensure that release branches are stable and that a user can upgrade within a release branch and not worry about behavioural changes. We feel we can strike that balance with the right policy. 2. Finish an evaluation of Git and related infrastructure pieces and move the project to Git. Paul Belanger has done a great job setting up a temporary project for the Asterisk Test Suite [1] that uses Gerrit and Jenkins for code review/continuous integration/management. I'd encourage everyone to go take a look at it, ask questions, and evaluate it as a platform for the Asterisk project. (Keep in mind that it's a starting point, not a finished product!) [1]http://lists.digium.com/pipermail/asterisk-dev/2014-October/070938.html 3. Evaluate pulling the tests out of the Asterisk Test Suite into a separate repository and versioning the tests and the Test Suite. We've reached a point where people are using the Asterisk Test Suite's libraries to run their own tests, and where versioning the libraries in the Test Suite will help provide some stability to people's infrastructure. Versioning tests would help when a test's behaviour is different between different versions of Asterisk. Both can be done in conjunction with moving the project to Git. 4. Explore capabilities in AMI/AGI that may be candidates for ARI. Today, ARI has a fundamentally different objective than AMI/AGI: allow a person to build a custom communications application (in the same vein as a dialplan application) using the language of their choice. At the same time, it is conceivable that someone would want to use ARI for more than just that - for example, the asterisk resource in ARI fits outside the realm of a custom communications application. Likewise, actions such as pushing configuration to an Asterisk server is useful for a communications application, but is not necessarily tied to application. This action is to explore what capabilities ARI should have, focussing on controlling and manipulating the core of Asterisk. Paul Belanger had a good suggestion for this evaluation - drop the dialplan applications/functions and look at what is currently provided, as well as what could be provided. 5. Document the ARI features that were discussed over the past year and propose a design for them. Three features in particular were discussed but not implemented: playback of media from a remote URI, TTS, and
[asterisk-dev] [Code Review] 4124: audiohooks: Clean references to formats
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4124/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24465 https://issues.asterisk.org/jira/browse/ASTERISK-24465 Repository: Asterisk Description --- Cleanup references to in_translate[x].format / out_translate[x].format in ast_audiohook_detach_list. Diffs - /branches/13/main/audiohook.c 426528 Diff: https://reviewboard.asterisk.org/r/4124/diff/ Testing --- Yes 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] 4125: app_queue: fix a couple leaks to struct call_queue in set_member_value
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4125/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24466 https://issues.asterisk.org/jira/browse/ASTERISK-24466 Repository: Asterisk Description --- set_member_value has a couple leaks to references in the variable q found through testsuite tests/queues/set_penalty. This change also removes the REF_DEBUG_ONLY_QUEUES compiler declaration, this is no longer possible with the updated REF_DEBUG code. Diffs - /branches/11/apps/app_queue.c 426569 Diff: https://reviewboard.asterisk.org/r/4125/diff/ Testing --- All tests/queues/set_penalty no longer leaks any references (verifies first added queue_unref). I'm unsure if the second added queue_unref has been tested, but seems like it is needed. 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
