Email enviado por Moisés Silva em 28/03/02008 para a lista asterisk-dev comentando sobre sua iniciativa de disponibilizar seu código R2 para o projeto Asterisk.
Será que chegou a hora?
Subject: [asterisk-dev] MFC/R2 Asterisk Channel Driver
Date: 28 de março de 2008 19h23min40s GMT-03:00
For the past months I have been playing with MFC/R2 and now I
have written a library (OpenR2) able to handle this signaling for
México, adding other countries variant should be matter of just
tweaking some stuff here and there. I'd like to have MFC/R2 support
in Asterisk out of the box, so all users in México, Brazil and any
other country where R2 is still present can have an R2 solution that
just works.. I know Unicall and libmfcr2, and they work just fine.
However, I started this for 3 reasons:
1. AFAIK Licensing of libmfcr2 and Unicall cannot be included in
Asterisk because of GPL. I know that Steve is thinking in probably
release some of its code (unicall, spandsp, libmfcr2, who knows?)
under LGPL or some other license, but that's something I am not
2. Unicall abstraction is cool, but users have to install it along
with spandsp, libsupertone, libmfcr2 and libunicall just to get R2
working with chan_unicall. That many layers cause users to get
confused and often install incompatible versions which lead them to
odd errors and frustration. Yeah, one could argue they deserve it for
not installing it right, but I am not going to blame them, I think
having R2 built-in into official Asterisk distribution will greatly
3. R2 is old but fun :-)
I'd like to hear opinions about how this should be handled to
better fit into Asterisk. Try to integrate R2 signaling into chan_zap?
or create a new channel driver chan_mfcr2?. I am inclined to think
that having R2 into chan_zap is better, however I remember some code
was already there back in Asterisk 1.2, but was dropped for some
reason, anybody knows why?
"I do not agree with what you have to say, but I'll defend to the
death your right to say it." Voltaire