[asterisk-r2] OpenR2 release candidate and development ideas feedback

Moises Silva moises.silva at gmail.com
Wed Nov 19 17:04:02 CST 2008


Probably some of you already know it, the first release candidate for
openr2 is out there in google code:
http://code.google.com/p/openr2/downloads/list

Also, I'd like to ask for opinions and probably any volunteer coders
here. Currently there is a couple of activities that I have in mind.

1. Windows and/or Mac OS build.
2. Asterisk patches.
3. DTMF/R2 support (Venezuela users mostly).

The number one is about making openr2 code to build in Windows or Mac
OS. Or both :)

The second project is less time consuming (I think), the idea is
create a doc/asterisk/patches directory where other directories will
exists, one directory for each major release of Asterisk. 1.2, 1.4 and
1.6. Now that we have the first release candidate of openr2 it would
be easier to have patches for Asterisk and not just the SVN branches I
have been providing. So, one directory could be:

doc/asterisk/1.4/1.4.22/

And put the required patches, or even better, an already modified for
R2 chan_dahdi.c/chan_zap.c along with a Makefile to compile using the
Asterisk headers. That way a user can easily do this:

# cd doc/asterisk/1.4/1.4.22/
# make
# make install

And that make install would copy the created R2-enabled chan_dahdi.so
to /usr/lib/asterisk/modules replacing the old and not-R2 enabled
chan_dahdi.so included with Asterisk.

The other option is not include chan_zap.c or chan_dahdi.c modified
there, but just include a patch for users to apply.

The advantage of having the modified chan_zap.c/chan_dahdi.c with a
Makefile is that no patching is required, users just replace their old
chan_zap.so/chan_dahdi.so with "make install" with the R2-enabled one.
The disadvantage is that a directory would be needed each time a new
Asterisk release goes out. But I really like this approach better over
the patching.

The advantage with the patch, is that as long as the patch applies
cleanly to newer Asterisk versions, there is no need to do anything,
but in any moment a patch does not apply or causes undesired
side-effects (like segfaulting) there will be needed to create a new
directory with a new patch for the new Asterisk version.

Comments, ideas?

If there is anyone willing to work in some of this sub-projects, it
will be my pleasure to provide access to an SVN branch in the
development openr2 repository to work on.

Moy

-- 
"I do not agree with what you have to say, but I'll defend to the
death your right to say it." Voltaire



More information about the asterisk-r2 mailing list