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

[Alexis Gavidia]

Moises i can help you with

3. DTMF/R2 support (Venezuela users mostly).

I am from venezuela, and i have R2 e1 with Movistar To test

Thnaks Alexis Gavidia


On 11/19/08, Moises Silva <moises.silva at gmail.com> wrote:
>
> 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
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-r2 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-r2/attachments/20081119/868ffee7/attachment.htm