[asterisk-dev] MFC/R2 Asterisk Channel Driver

[James Finstrom]

I also think the addition to chanzap is an awesome idea (thought it was in the 1.6 works) the biggest issue we have seen with the current implementation is also testing so getting a good test bed will be key to making it more then a 1 sub-version wonder
James Finstrom
Rhino Equipment Corp.
http://www.rhinoequipment.com

-----Original Message-----
From: John Todd <jtodd at loligo.com>

Date: Fri, 28 Mar 2008 17:57:49 
To:Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Subject: Re: [asterisk-dev] MFC/R2 Asterisk Channel Driver


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

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

!DSPAM:1031,47ed9693139812086318029!