[asterisk-dev] MFC/R2 Asterisk Channel Driver
John Todd
jtodd at loligo.com
Fri Mar 28 19:57:49 CDT 2008
At 4:23 PM -0600 2008/3/28, Moises Silva wrote:
>
>Hello List,
>
> 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
>counting on.
>
>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
>help.
>
>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?
>
>Regards,
>
>Moisés Silva
Hello -
So let me distill what isn't explicitly
mentioned, and correct me if I'm wrong: You're
going to submit your code for MFC/R2 use back to
the Asterisk project, and under the terms and
license agreements that would permit it to be
used in all versions of Asterisk? And there are
no components that are externally licensed or
required, meaning your software is/could be
completely distributed inside of Asterisk as a
full solution?
That being said and asked, I would suggest that
it appears inside of chan_zap, since it by
definition will be talking with the Zap cards for
communications with the physical layer. Perhaps
older versions were removed because of the
license issues, but it does not seem to be
consistent with the current channel delineations
to have it as it's own channel.
Testing this code presents another headache,
since many of the testing folks for Asterisk live
in ISDN worlds and R2 is not common. Do you have
a testbed, or do you know a lot of R2 people in
the Americas or central Asia who might be able to
test different versions? I'd love to see R2
included as a part of Asterisk - there have been
several occasions where I needed it in the past
and had to jump through hoops to get it working
(or not.)
JT
More information about the asterisk-dev
mailing list