asterisk users - May 2004 - *** Asterisk Sunday News: Gone Fishing...

Spring is back in the Stockholm area. After a few day's worth winter
re-runs,
the sun is back and night-time temperature is at least 5 degrees celsius. Time
to
move out all my annual flowers and prepare the garden for summer.

Sweden is famous for our annual five week holidays - by law. From june to late
august, it's almost impossible to make any business decision, since
there's always
people away. Some offices close for a couple of weeks during july.

With people away and offices being closed, it's important to have a PBX that
can
handle the calls and make sure the message is delivered. Asterisk is of course
my preferred choice, and this week, I'll give you some insight into how you
can
make Asterisk handle the calls while you're away. Stay tuned!

This week's topics:
-------------------
*** What's a stable release, anyway?
*** The Wiki: A mission critical information source
*** A new data architecture: AST_DATA
*** Asterisk: Gone fishing
*** Asterisk award-of-the-week: The inventors of NAT

*** What's a stable release, anyway?
------------------------------------
On the mailing list this week, there's been a discussion on the two
development
branches we have. There are currently two branches, the "stable" and
the "head"
branch.
The situation is that there are known bugs in the "stable" branch that
is fixed
in the "head" branch. So if this source tree is labelled
"stable" - why not
fix known bugs?

Well, in an Open Source project, there's really no marketing department or
product relase plan management. Things happen and we move forward. The split
of the development tree was done to see if we could work simultaneously with
two code bases. One that was *aiming* for a stable 1.0 release and one more
wild and risky. The number of patches to the stable tree has been very limited,
no new functionality, only bug fixes. The "head" source has been more
open
to new ideas and a number of new functions and changes has been introduced here.

The problem we are facing now is that a fix to a major timing problem,
that affects audio quality, has been done to cvs head. The fix is not
a few lines of code to one file, but a lot of changes to a lot of files.
It is so much that it really makes it hard to also fix "stable".
And there's no consensus that the fix has solved the problem.

This is a dilemma for people that wants to use Asterisk in production.

We have the following menu:
* RPMs and Tarballs - these are the releases, really, at this point old,
   includes the audio bug
* CVS stable - with the audio bug
* CVS head - with new code, possily some unknown bugs

I have no answer to this, only that there's a lot of internal discussion
going on and hopefully we'll see some action in the following week. Please
note that the "stable" cvs was *aiming* for a stable release, but has
not
been the actual base for any new release at all so far. It might not
be. We'll see.

I'll end this note with quoting Steven Critchfield on the mailing list:

   "As version numbers are just arbitrary pointers at a point in source
code
time, don't get too worried about the label. To make all those that are
currently making noise happy, maybe it should be put forth that current
stable has a version number and is abandoned. Then you place a new
feature freeze on -head and fork a new -head off and go from there. "

*** The Wiki: A mission critical information source
---------------------------------------------------
The Asterisk wiki on http://www.voip-info.org has grown to a very
important tool for the Asterisk community. A few hours of downtime this
week led to quite a lot of mails on the mailing list. The maintainer
of the Wiki, James H. Thompson, started the wiki without knowing what
would happen. I started filling it with information from
the sources and the mailing list and after that a number of contri-
butors joined me and the wiki has grown ever since.

And we're stuck in the software. Jim didn't really see this happen,
nor did I. The software is really slow and bad. Jim has spent
many hours trying to speed it up. With the help of a sponsor,
Commpartners, the wiki server is now hosted on a new powerful
server with plenty of bandwidth.
During the summer, Jim and I will work on setting up a European
read-only mirror to see if this can speed up things, while providing
an alternative if the main server for any reason is unreachable.

The Asterisk Wiki is really a successful community project.
I am happy to announce that Jim has reached an agreement with
the Asteriskdocs.org project to share material so that Asteriskdocs,
another community documentation project, can use the wealth
of information we have produced on the Wiki to produce
a better Asterisk handbook.

* http://www.voip-info.org
* http://www.asteriskdocs.org

*** A new data architecture: AST_DATA
-------------------------------------

Asterisk today includes a number of patches to support database lookups
of voicemail, sip and iax2 users. There's also a lot of patches out
there on the net that read extensions from a database. There's mysql
patches, postgresql patches and unixodbc. Quite messy, indeed.

A developer, Rob Gagnon, took ownership of the problem and started
a development project that is beginning to take form and go from
"a lot of interesting compileable code pieces" to
"Steve, this is really useful".

The idea is to have a common architecture for data source access,
an internal abstraction layer. Applications that read configuration
or extension data shouldn't have to bother whether the data is stored
in text files, a database-of-your-favorite-brand or an LDAP server.
(Or even DNS if Duanne starts coding :-)

With ast_data, the SIP channel may look for a user first in the
text file, then in the MYSQL database and finally in Microsoft
Active Directory. It all depends on getting the proper drivers
produced. This will be a *major* enhancement to Asterisk and will
let us clear up the source code of the IAX and SIP channel as
well as the voicemail application.

* http://svn.asteriskdocs.org/res_data/
* (No wiki documentation page yet.. ??? )

*** Asterisk: Gone fishing
--------------------------
Did you know that Asterisk have a scheduler that can automatically switch
modes depending on the date and time? If you want your office extension
to dial your cell phone on evenings and nights, or go directly to voicemail
during weekends, this is what you need.
Looking into the sample config in all Asterisk distributions, be it
RPM, tar-ball or CVS, you'll find extensions.conf.sample
------
;
; Timing list for includes is
;
;   <time range>|<days of week>|<days of month>|<months>
;
;include => daytime|9:00-17:00|mon-fri|*|*
-----
So you could create a weekend clause that redirects all calls to
the "officeclosed" extension like this:
include => officeclosed|*|sat-sun|*|*

* The christmas special
include => christmasgreeting|*|*|25|dec

* Swedish holidays
include => gonefishing|*|*|*|jun-aug

* Evening shift
include => redirecttobkw|17-24|mon-fri|*|*

Working with context includes that depend on time of day, day of week or month
is
really a powerful feature of Asterisk. The Asterisk handbook (draft 2) provides
the following example:

    [newyears]
    exten => s,1,Playback(happy-new-years)
    [daytime]
    exten => s,1,Dial(Zap/1,20)
    [nighttime]
    exten => s,1,Playback(after-hours-msg)
    [default]
    include => newyears||||1|jan
    include => daytime|9:00-17:00|mon-fri
    include => nighttime

Read more
* http://www.voip-info.org/wiki-Asterisk+tips+openhours

*** Asterisk award-of-the-week: The inventors of NAT
----------------------------------------------------
I would like to award this weeks voip-business-award to the inventors of NAT.
Everyone that works with SIP on a contractual basis, charging per hour, just
got to love NAT. All the different variants, timeouts and how this affects
SIP just makes the number of hours being charged skyrocket. Thank you.
And please don't tell our clients about the IAX2 protocol. And please
don't
teach the equipment vendors about STUN, symmetric signalling and UPNP.
We wan't the voip business segment to grow, don't we ;-)

* Recommended reading: http://www.voip-info.org/wiki-NAT+and+VOIP
* http://www.voip-forum.com/index.php?p=122

*** Useful Asterisk web links:
------------------------------
* Asterisk: http://www.asterisk.org
* Asterisk mailing lists: http://lists.digium.com
   (users, dev, biz and cvs mailing list)
* Asterisk bug tracker: http://bugs.digium.com
* Asterisk IRC channel: #asterisk on irc.freenode.net
* Digium: http://www.digium.com
* Wiki: http://www.voip-info.org
* Voip Search: http://search.voip-forum.com
* Astricon: http://www.astricon.net

That was all for this week. Time to go off line. It's "mother's
day"
in Sweden so I have to visit my mother. Wonder if she will appreciate
getting a VOIP extension on my Asterisk PBX - including voice mail?
She'll just love the zapateller application, that's for sure ;-)
(See http://www.voip-info.org/wiki-Asterisk+Telemarketer+Torture )

If you have topics for me to include in the next edition of
Asterisk Sunday News, mail me off list :-)

Have a nice Asterisk week!
/Olle

Olle E. Johansson wrote:
> The idea is to have a common architecture for data source access,
> an internal abstraction layer. Applications that read configuration
> or extension data shouldn't have to bother whether the data is stored
> in text files, a database-of-your-favorite-brand or an LDAP server.
> (Or even DNS if Duanne starts coding :-)
It's already committed to CVS :)

-- 
Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers

> From: "Olle E. Johansson" <oej@edvina.net>
snip
> *** What's a stable release, anyway?
> ------------------------------------
snip
> The problem we are facing now is that a fix to a major timing problem,
> that affects audio quality, has been done to cvs head. The fix is not
> a few lines of code to one file, but a lot of changes to a lot of files.
> It is so much that it really makes it hard to also fix "stable".
> And there's no consensus that the fix has solved the problem.
> 
> This is a dilemma for people that wants to use Asterisk in production.
> 
> We have the following menu:
> * RPMs and Tarballs - these are the releases, really, at this point old,
>    includes the audio bug
> * CVS stable - with the audio bug
> * CVS head - with new code, possily some unknown bugs
Relatively minor correction to the above...

The Stable cvs did have the iax2 timing fix applied as of May 21st (I 
think that was the date). However, there seems to be a case that 
channel_capi still needs attention.

A goggle search and review (look for asterisk-cvs) indicates the majority
of fixes are actually being applied to Head and very few to Stable (and
its not because the bug didn't exist in Stable either). Head is now 
more stable/usable (eg, fewer bugs) then is Stable. As previously
stated, its time to lock down Head, fix the few remaining bugs, and 
make "it" the well-overdue & historic v1.0 production release.

Hi!
> The Stable cvs did have the iax2 timing fix applied as of May 21st (I 
> think that was the date). However, there seems to be a case that 
> channel_capi still needs attention.
And there is the "no ring sound" issue as well that would need to be 
fixed in order to qualify for a 1.0 release.
> more stable/usable (eg, fewer bugs) then is Stable. As previously
> stated, its time to lock down Head, fix the few remaining bugs, and 
> make "it" the well-overdue & historic v1.0 production
release.
Might indeed by the better approach. However, will this same problem 
occur over and over again, so that in the end we are effectively still at 
a single-stream asterisk code system?

Cheers, Philipp

Philipp von Klitzing wrote:
>>more stable/usable (eg, fewer bugs) then is Stable. As previously
>>stated, its time to lock down Head, fix the few remaining bugs, and 
>>make "it" the well-overdue & historic v1.0 production
release.
> 
> 
> Might indeed by the better approach. However, will this same problem 
> occur over and over again, so that in the end we are effectively still at 
> a single-stream asterisk code system?
It depends if we can find a group of developers that are willing to maintain
a release for a period of time, while the rest are exploring new frontiers.

I really think there needs to be a release-team that manages the code and
inserts bug fixes so we can not only release a stable, but keep that
release stable for a while and only add security/stability fixes.

/O

On Sunday 30 May 2004 04:32, Olle E. Johansson wrote:
<snip>
> *** Asterisk: Gone fishing
> --------------------------
> Did you know that Asterisk have a scheduler that can automatically
> switch modes depending on the date and time? If you want your
> office extension to dial your cell phone on evenings and nights, or
> go directly to voicemail during weekends, this is what you need.
> Looking into the sample config in all Asterisk distributions, be it
> RPM, tar-ball or CVS, you'll find extensions.conf.sample
> ------
> ;
> ; Timing list for includes is
> ;
> ;   <time range>|<days of week>|<days of
month>|<months>
> ;
> ;include => daytime|9:00-17:00|mon-fri|*|*
GotoIfTime() was created specifically because there were so many
people who were having problems with the include syntax.  It has
exactly the same format (even uses the same internal code), but the
mode is active (if the current time is X, go here) instead of passive
(if the current time is X, change the effective context to include Y).

It's arguable that GotoIfTime() makes the dialplan logic more clear
and should give the dialplan programmer more control than with include
syntax.

-- 
Tilghman

> On Sun, 30 May 2004 21:34:27 +0200, Olle E. Johansson
<oej@edvina.net>
> wrote:
>
>> Philipp von Klitzing wrote:
>>
>>>> more stable/usable (eg, fewer bugs) then is Stable. As
previously
>>>> stated, its time to lock down Head, fix the few remaining bugs,
and
>>>> make "it" the well-overdue & historic v1.0
production release.
>>>   Might indeed by the better approach. However, will this same
problem
>>> occur over and over again, so that in the end we are effectively
still
>>> at a single-stream asterisk code system?
>>
>> It depends if we can find a group of developers that are willing to
>> maintain
>> a release for a period of time, while the rest are exploring new
>> frontiers.
>>
>> I really think there needs to be a release-team that manages the code  
>> and
>> inserts bug fixes so we can not only release a stable, but keep that
>> release stable for a while and only add security/stability fixes.
>
Hi, My name is Stuart Grimshaw, a new (and very impressed) user of
Asterisk, I'm also a Senior Developer for a large UK online retailer, as
well as having recently held the same position for one of the UK's leading
ISP's.

  From the threads I have read, and in particular this one, I see a project
that is at a crossroads. One way leads to bickering, endless arguments and
a shattered codebase. The other leads to harmony amongst the developers,
a well planned and organised codebase and release/development cycle.
Dedicated teams focused on their job in hand, be that developing new
features or merging bug fixes into older versions of the software. Down
one road lies XFree, the other leads to XOrg, one road is phpGroupWare,
the other lies eGroupWare.

There needs to be leadership, someone with vision who can steer the teams
in the right direction, Asterisk needs a Linus Torvalds, and a couple of
Alan Cox's. It needs a Daniel Robbins.

There should to be two teams, one that concentrates on the stable version
and one that develops the new features, there's no reason why people
can't be on both teams, indeed the stable version needs that otherwise how
will people know which patches need to be applied. I would create a new
stable release right now, call it STABLE_1_1

Most importantly, I would stop encouraging people to use the HEAD branch,
leave that for those who want to test new features, who understand that
it's unstable, guide new users toward the stable release. Build some
packages, advertise the packages, don't require people to use CVS to get
hold of releases.

This will have numerous benefits, users will report bugs in the stable
branch, at the moment no-one seems to know what is still broken in the
stable branch, other than the individuals who made the patches, these bugs
will get fixed, and new ones will not be introduced by people upgrading
to the latest HEAD branch, they will get the latest version of stable and
it will fix their problem, without introducing a whole bunch of new ones.
It
also means that bugs being re-introduced into CVS wont effect people (See
Thor Atle Rustad's post from yesterday "Unblocking incoming SIP"

I hope people understand what this email is about, it's about helping
people think what they have, about encouraging people to take a lead, and
hopefully avoid the pitfalls of so many other great OpenSource projects.
I've purposely avoided using language that is preaching or sounds like
I'm
telling people the best way to do things, and any paragraph that does so
is purely unintentional.

I really would like to help the Asterisk effort, and I hope people take
these comments on board.

I've also sent this mail twice, as I sent it from an email address that
isn't subscribed to this list originally.

-- 

-S