MFC/R2 Asterisk Channel Driver

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

-- 
"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.c
om--

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

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.c
om--

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

On 28/03/2008, at 21:57, John Todd wrote:
>    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?

That's definitely not a problem, at all, IMHO.

Here in Brazil we still have to handle absurd situations
regarding R2  
signaling. In fact, that's the very reason why Digium,
Sangoma or  
whatever company does not sell more boards around here. Just
a tiny  
fraction of people here can afford and easily get a decent
ISDN  
connection. I've worked on a project that even used Steve's
Unicall  
in the great majority of clients (like... 150, yeah). And
that was a  
Telco company.

It's really really great to hear about Moises plan, though
I'm not  
sure if a software based R2 solution is the best approach
and I'm  
taking it with a grain of salt. There are at least 3
companies  
selling Asterisk-compatible boards with R2 done builtin, in
hardware,  
witch has proved to be much more stable, well supported and
scalable  
than anything else.

Moises, do you already have something for testing or have
you just  
started thinking about it? Vapourware or real stuff, another
 
brazilian guy monitoring this list has already forward your
message  
to the Asterisk Brasil list 

[]s

--
Caio Begotti <http://caio.ueberalles
.net>

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

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

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.rhinoequipme
nt.com

-----Original Message-----
From: John Todd <jtoddloligo.com>

Date: Fri, 28 Mar 2008 17:57:49 
To:Asterisk Developers Mailing List <asterisk-devlists.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.c
om--

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

!DSPAM:1031,47ed9693139812086318029!


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

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

>  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?

Sorry for not being clear. That is correct. My code no has
no direct
dependencies on other software beyond libc. The only
indirect dependency
is that my code requires the user (in this case Asterisk) to
provide
function pointers
to routines for the multi frequency tone detection and
generation. I
reviewed the routines
on main/dsp.c and I think that they can work just fine,
probably they
would require a bit
of tweaking though.

>    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.

I feel the same. Just want to be sure Asterisk devs feel
that is the way to go.

>    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?

For the past year I have giving support and adapting the
chan_unicall
driver written by Steve, during this time I have made good
relationship with
many people in México, Colombia, Brazil and Argentina. I
think I would not
have any problem finding people on those 4 countries to test
it.

>  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.)

Hopefully this will happen soon.

Moisés Silva

-- 
"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.c
om--

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

>  Moises, do you already have something for testing or
have you just
>  started thinking about it? Vapourware or real stuff

I have the R2 library, real code, working with a test
program here in
México that all it does
is make and receive calls and put them in an echo-like
program. I will
setup the website
soon, unfortunately the openr2.org domain is taken and I am
deciding
another name
and waiting for the owner to answer to see if I can make a
deal with him.


-- 
"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.c
om--

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

On 28 de mar de 2008, at 21:57, John Todd wrote:

>    Testing this code presents another headache,
> since many of the testing folks for Asterisk live
> in ISDN worlds and R2 is not common.

Sorry, but you're patronizing the people using Asterisk
outside US  
and Europe.

Maybe you don't have enough information about what
happens(at least  
about technology) outside US. I can give you details about
the  
brazilian Asterisk community, if you want.

Of course we have a lot o people that will test everything
related to  
R2. This is why we have such GREAT initiative from Moises.

Moises, we can post your project on our mailing list and
portal to  
get people commitment. What you think?

Congratulations, you have my support.

--
Denis Galvão
AsteriskBrasil.org


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

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

On Fri, Mar 28, 2008 at 7:50 PM, Caio Begotti <caioueberalles.net> wrote:
> On 28/03/2008, at 21:57, John Todd wrote:
> There are at least 3 companies
>  selling Asterisk-compatible boards with R2 done
builtin, in hardware,
>  witch has proved to be much more stable, well
supported and scalable
>  than anything else.

Well, I think there is a big misconception regard those
hardware-built-in MFC/R2  implementations.
AFAIK all of those asterisk-compatible boards depend on
software
implementations of MFC/R2 protocol and at least one of them
is GPL
(but
heavy dependent on their own hardware interrupts) with the
main
difference that they use a hardware DSP for the MF tone
generation
rather
than a software based DSP like libmfcr2 does.

-- 
Octavio H. Ruiz Cervera
Tel.: (+52 55) 8590-9000 Ext. 7016
Mobile: (+52 155) 5514-087790
Mobile: (+52 155) 5541-351242

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

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

>  Moises, we can post your project on our mailing list
and portal to
>  get people commitment. What you think?
That sounds good, as soon as I have chan_zap working with my
R2
library I will let you know.
May I contact you off-list to see if we can arrange some
testing of
the library even before
getting it into chan_zap?

-- 
"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.c
om--

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

>  Doing the tone detection on the card is not an issue -
its such a
>  lightweight process. I was told none of the locally
produced cards has
>  echo cancellation, though. Is that right? If so, its a
huge drawback.

Not totally right, I've played with the Brazilian card and
using full
60 channels they give you 64taps of  hardware echo cancel
where other
mainstream manufacturers gives you 128ms over 240 channels
but,
anyway at least for that manufacturer, they had a
competitive HWEC
where the Ottawa based company doesn't offer it at all.

Mr Begotti said that he know about at least three companies
which
offer R2 support for their cards,  I only  know about two,
where one
of them have not released their R2 support yet .


Regards,

-- 
Octavio H. Ruiz Cervera
Tel.: (+52 55) 8590-9000 Ext. 7016
Mobile: (+52 155) 5514-087790
Mobile: (+52 155) 5541-351242

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

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