<div><br>PessoALL,</div>
<div> </div>
<div>Para conhecimento de todos um e-mail do Moises Silva enviado à lista Asterisk-Dev.</div>
<div> </div>
<div>[]´s</div>
<div> </div>
<div> </div>
<div>Victor</div>
<div><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Moises Silva</b> <<a href="mailto:moises.silva@gmail.com">moises.silva@gmail.com</a>><br>Date: 28/03/2008 19:23<br>
Subject: [asterisk-dev] MFC/R2 Asterisk Channel Driver<br>To: Asterisk Developers Mailing List <<a href="mailto:asterisk-dev@lists.digium.com">asterisk-dev@lists.digium.com</a>><br><br></span>Hello List,<br><br> For the past months I have been playing with MFC/R2 and now I<br>
have written a library (OpenR2) able to handle this signaling for<br>México, adding other countries variant should be matter of just<br>tweaking some stuff here and there. I'd like to have MFC/R2 support<br>in Asterisk out of the box, so all users in México, Brazil and any<br>
other country where R2 is still present can have an R2 solution that<br>just works.. I know Unicall and libmfcr2, and they work just fine.<br>However, I started this for 3 reasons:<br><br>1. AFAIK Licensing of libmfcr2 and Unicall cannot be included in<br>
Asterisk because of GPL. I know that Steve is thinking in probably<br>release some of its code (unicall, spandsp, libmfcr2, who knows?)<br>under LGPL or some other license, but that's something I am not<br>counting on.<br>
<br>2. Unicall abstraction is cool, but users have to install it along<br>with spandsp, libsupertone, libmfcr2 and libunicall just to get R2<br>working with chan_unicall. That many layers cause users to get<br>confused and often install incompatible versions which lead them to<br>
odd errors and frustration. Yeah, one could argue they deserve it for<br>not installing it right, but I am not going to blame them, I think<br>having R2 built-in into official Asterisk distribution will greatly<br>help.<br>
<br>3. R2 is old but fun :-)<br><br> I'd like to hear opinions about how this should be handled to<br>better fit into Asterisk. Try to integrate R2 signaling into chan_zap?<br>or create a new channel driver chan_mfcr2?. I am inclined to think<br>
that having R2 into chan_zap is better, however I remember some code<br>was already there back in Asterisk 1.2, but was dropped for some<br>reason, anybody knows why?<br><br>Regards,<br><br>Moisés Silva<br><br>--<br>"I do not agree with what you have to say, but I'll defend to the<br>
death your right to say it." Voltaire<br> </div>