gmane.comp.telephony.pbx.asterisk.devel

Asterisk 1.2.30.3, 1.4.23-rc2, 1.6.0.2, 1.6.1-beta3,and Asterisk-Addons 1.6.0.1, 1.6.1-rc2 released

Asterisk Team — 2008-12-02T04:58:05

The Asterisk.org development team has released Asterisk versions 1.2.30.3, 1.4.23-rc2, 1.6.0.2, 1.6.1-beta3, as well as Asterisk-Addons versions 1.6.0.1 and 1.6.1-rc2. These releases are available for immediate download from http://downloads.digium.com/. This update for Asterisk includes a fix for a regression introduced in Asterisk 1.2.30 and Asterisk 1.4.21.2 and has existed in the Asterisk 1.6 branch since release. All releases with the exception of Asterisk 1.2.30.3 also contain a vast assortment of bugfixes in these releases. For a full list of changes, see the ChangeLogs: http://svn.digium.com/view/asterisk/tags/1.2.30.3/ChangeLog?view=markup http://svn.digium.com/view/asterisk/tags/1.4.23-rc2/ChangeLog?view=markup http://svn.digium.com/view/asterisk/tags/1.6.0.2/ChangeLog?view=markup http://svn.digium.com/view/asterisk/tags/1.6.1-beta3/ChangeLog?view=markup http://svn.digium.com/view/asterisk-addons/tags/1.6.0.1/ChangeLog?view=markup http://svn.digium.com/view/asterisk-addons/tags/1.6.1-rc

[policy] RCs for 1.6.X.Y releases (Was Re: tilghman:tag autotag_for_asterisk r426 - /tags/autotag_for_asterisk/1.6.0.2/)

Russell Bryant — 2008-12-02T01:41:50

On Dec 1, 2008, at 5:04 PM, SVN commits to the Digium repositories wrote: I would like to propose that we make release candidates for 1.6.X.Y releases. I consider them equivalent to 1.4.X releases, and we are making release candidates for those. They have already proven helpful in the past, and it's not a big deal to make them. -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc. _______________________________________________ --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: [Code Review] Patch pbx_dundi.c to periodicallyclean it's database cache

Matthew Nicholson — 2008-12-01T17:07:31

Yes. The missing / is intentional. I think you have to leave it off for ast_db_gettree() to work properly. I will look into this. - Matthew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.digium.com/r/63/#review162 ----------------------------------------------------------- On 2008-11-24 10:00:37, Matthew Nicholson wrote: _______________________________________________ --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: [policy] Merging between branches

Mark Michelson — 2008-12-01T17:06:32

A hardy +1 from me. I have, however, mostly been following the policy of not merging 1.4 bugfixes into 1.6.0 since they were not regressions in the 1.6.0 branch. I say mostly because in some cases the bugs were grievous enough that I could not in good conscience exclude the change from 1.6.0 (think crash or deadlock bugs). I agree with this given the slow pace of 1.6.X releases and the fact that moving from 1.6.X to 1.6.X+1 introduces potentially unwanted new features and with those, potential new bugs. I mentioned above the slow process that has happened so far with the 1.6.X releases. 1.6.0 was released on 2 October. It is now 1 December and there has been only one beta of 1.6.1 made so far. Since it must continue through the beta cycle and also go through an rc process, I don't see 1.6.1 being released before the end of the year. The original plan for the 1.6 series called for releases approximately every month. If this were followed, then the number of new features in each subsequent rel

Re: Calendaring and the bounds of Asterisk

Tim Panton — 2008-12-01T15:14:42

On 1 Dec 2008, at 14:44, Russell Bryant wrote: It seems clear to me - No, in theory, it should not be in 'core' asterisk. However, it probably isn't practical to implement all the desired functionality outside Asterisk, so given that it looks like useful functionality, yes it should be included. We need to: a) ensure we _could_ implement this in a sensible way _outside_ core asterisk by adopting a core API before too long. b) accept this useful contribution and hope the core doesn't bloat too much before 'a' happens :-) (By the way - things can be in the asterisk process without being in the asterisk core - think 729 codec or chan_skype - that's possible because they both use well defined APIs) Tim. _______________________________________________ --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

Calendaring and the bounds of Asterisk

Russell Bryant — 2008-12-01T14:44:15

Greetings, As you all know from the discussions on this list, Terry Wilson has worked hard to bring calendar integration to Asterisk. It is a very exciting new feature to be able to make available to our users. However, I have heard some concerns about whether this functionality makes sense architecturally. I have thought about this, and would like to share my thoughts. First of all, when I say "the bounds of Asterisk", I am talking about the bounds of Asterisk, the application. I'm talking about the line that we must draw that defines what belongs in Asterisk, and what should be an external tool that uses an interface provided by Asterisk to deliver the functionality. There is no problem with Asterisk the project distributing Asterisk the application, as well as a number of other tools that do one thing and do them well. I would say that in the past, we have put almost everything into Asterisk. However, the discussions about the next generation of Asterisk programming interfaces demonst

[policy] Merging between branches

Russell Bryant — 2008-12-01T13:57:44

Greetings, Last year, when we first started discussing Asterisk 1.6 branch policy [1], we had said that the only time that we would change a 1.6.X branch after it had reached a release state is for regressions against a previous release. What that has meant in practice is that as we find and fix long standing bugs that apply to all of our releases, 1.6.0 does not receive the fix. Currently, that means a fix would go into 1.4, trunk, and then 1.6.1 since it is still in beta. I now believe that this was a mistake. As it stands today, upgrading from 1.4 to 1.6.0 will introduce a number of regressions for users. This should never happen (until 1.4 or 1.6.0 is no longer in a supported state). So, I would like to immediately change the policy such that every fix that applies to 1.4 should also go into _every_ supported 1.6.X branch. We had a discussion about this last week on IRC. It seemed that everyone around at the time was in agreement about the change as far as normal bug fixes go. Howe

Re: [Code Review] manager.c does not compile on OpenBSD anymore. This patch fixes it.

Russell Bryant — 2008-12-01T13:30:58

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.digium.com/r/66/#review165 ----------------------------------------------------------- Ship it! Looks good. Put a space after the cast, though. :-) - Russell On 2008-12-01 04:49:32, Michiel van Baak wrote: _______________________________________________ --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

[Code Review] manager.c does not compile on OpenBSD anymore. This patch fixes it.

Michiel van Baak — 2008-12-01T10:49:32

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.digium.com/r/66/ ----------------------------------------------------------- Review request for Asterisk Developers. Summary ------- manager.c has a call to ast_channel_alloc with NULL as last argument. This last argument should be a pointer. And since NULL is not really a pointer compile fails on OpenBSD. The attached patch fixes it in 1.4 in trunk and the 1.6.X branches I think it's better to fix it by replacing NULL with SENTINEL in this call. Diffs ----- branches/1.4/main/manager.c 159896 Diff: http://reviewboard.digium.com/r/66/diff Testing ------- Compiles and the manager works with this patch attached on OpenBSD 4.4 Thanks, Michiel _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailma

apply_plan_to_number() in chan_zap.c

Tony Mountifield — 2008-11-28T20:38:47

I've been doing some playing with the various ISDN dialplan prefixes that can be set in zapata.conf, making PRI calls from one asterisk span to another, and also looking at the relevant code in chan_zap.c / chan_dahdi.c. I see that when a call SETUP is being processed, apply_plan_to_number() is invoked for the calling number, the calling ANI and the redirectingnum, but NOT on the called number. I was wondering whether there is a reason it was not applied to the called number, or if this is just an oversight. (I realise that there are very few situations where the TON supplied by the telco would vary between calls) It would be nice if the called party number could be canonicalised in the same way as CLID, ANI and RDINS. Looking for comparison at the SS7 code in the trunk version of chan_dahdi.c, it looks like the called number IS processed with ss7_apply_plan_to_number() so it would probably make sense to add this to the ISDN code too. Comments? Cheers Tony

channels() function in 1.6

Philipp Kempgen — 2008-11-28T20:18:29

---cut--- -= Info about function 'CHANNELS' =- [Syntax] CHANNEL([regular expression]) ---cut--- Shouldn't the syntax read CHANNEL*S*? Philipp Kempgen

Re: [Code Review] CLI permissions

Eliel Sardañons — 2008-11-28T19:05:36

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.digium.com/r/11/ ----------------------------------------------------------- (Updated 2008-11-28 13:05:36.768535) Review request for Asterisk Developers. Changes ------- Sorry for all this updates to the review board: - Make regular expression matching case insensitive. - Explain that we can use regular expressions inside the configuration sample. Summary ------- Implement CLI permissions related to issue 11123. I would like to receive an architectural review, if this is the right way to implement CLI permissions. I know there are some minor changes that need to be done (and others not so minor), maybe use RWLIST instead of a LIST, also trailing spaces, and a lot more, but If the architecture is ok, I will continue improving the code. Thanks in advanced! Diffs (updated) ----- /trunk/CHANGES 159772 /trunk/configs/cli_permissions.conf.sample PRE-CREATION

Re: [Code Review] Calendaring API for Asterisk

Russell Bryant — 2008-11-28T01:37:42

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.digium.com/r/58/#review164 ----------------------------------------------------------- /trunk/include/asterisk/calendar.h Please fill out the rest of the doxygen docs to include return values and arguments /trunk/main/calendar.c Minor nitpick ... copyright is just 2008 /trunk/main/calendar.c This list needs to be protected by a lock. /trunk/main/calendar.c It would probably be good to add a comment to make it clear that this line is just for defining a type. /trunk/main/calendar.c This seems like a good candidate for ao2_callback(). Using the new argument, you can pass a variable that the c

Re: FW: CDR save HANGUPCAUSE

Sebastian — 2008-11-26T23:25:00

Sorry, I'm not sure if the mails are actually arriving to the list. -----Original Message----- From: asterisk-dev-bounces< at >lists.digium.com [mailto:asterisk-dev-bounces< at >lists.digium.com] On Behalf Of Steve Howes Sent: miércoles, 26 de noviembre de 2008 08:52 p.m. To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] FW: CDR save HANGUPCAUSE Once is usually sufficient. On 26 Nov 2008, at 22:46, Sebastian wrote: _______________________________________________ --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 __________ Information from ESET Smart Security, version of virus signature database 2911 (20080229) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 2911 (20080229) __________ The message was checked by ESET Smart Security.

Re: FW: CDR save HANGUPCAUSE

Steve Howes — 2008-11-26T22:51:53

Once is usually sufficient. On 26 Nov 2008, at 22:46, Sebastian wrote: _______________________________________________ --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

FW: CDR save HANGUPCAUSE

Sebastian — 2008-11-26T22:46:07

_______________________________________________ --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: Difficulty of adding "i" to Page()?

Alistair Cunningham — 2008-11-26T22:28:09

Mark, Thank you very much, that's excellent. Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 http://integrics.com/ _______________________________________________ --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

Reviewboard post-commit hook

Russell Bryant — 2008-11-26T22:13:01

Our "svnbot" functionality has been expanded to reviewboard. For now, I'm using the stock post-commit script distributed by reviewboard. The current functionality is that if you include the full URL to a review in a commit message, the "svnbot" will automatically set the review as submitted. So, when you merge in the final version of a patch into the base, include a comment for the review with the full URL, and it will be closed for you. At some point, it would be nice to expand the recognized keywords to be more similar to what we use for mantis. I'll post another message here if and when that happens.

Re: Using ReviewBoard to review work in developer branches (caveats)

Russell Bryant — 2008-11-26T21:43:18

That seems to sometimes work. I have a couple of notes, though ... 1) If you're lazy and don't feel like uploading the diff, post-review is easier. The previously mentioned method of merging into a working copy and then running "post-review" from there is how you would do that. I would recommend that everyone learn to love post-review, as it is the quickest and easiest way to get changes posted, and is generally the preferred method to avoid problems such as ... 2) Sometimes raw "svn diff" puts some stuff in the diff that reviewboard gets upset about. post-review has some magic to clean that stuff up into a form that reviewboard is happy with, IIRC.

Re: Using ReviewBoard to review work in developerbranches (caveats)

Terry Wilson — 2008-11-26T21:32:03

I've always just done a svn diff https://origsvn.digium.com/svn/asterisk/trunk https://origsvn.digium.com/svn/team/twilson/calendaring > diff.txt, then manually removed any configure changes or if anything has snuck through because since the last automerge. Seemed to work fine for me...or am I missing something? _______________________________________________ --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: Using ReviewBoard to review work in developerbranches (caveats)

Johansson Olle E — 2008-11-26T21:19:00

26 nov 2008 kl. 22.04 skrev Kevin P. Fleming: This text should propably be added to the developer section of Asterisk.org together with other information needed to work with reviewboard. Just a suggestion from a cold country far away... /O _______________________________________________ --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