OpenBSC, nanoBTS and Asterisk integration

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Tue Sep 29 09:52:20 UTC 2009


Hi Sylvain,

On Tue, Sep 29, 2009 at 10:36:44AM +0200, Sylvain Munaut wrote:

> It's a pity that there are no free EFR/AMR codec implementation, I
> have to use plain old GSM-FR.

what do you mean by 'free' ?  patent-free: no, certainly not.  but free as in
'souce code available': sure, there are!

AMR-NB and AMR-WB: http://www.penguin.cz/~utx/amr

I thought I had also found an EFR library some time in the past, though
I cannot find it right now.

> > If yo think it is worth putting this in the OpenBSC git, or at least
> > hosting it on openbsc.gnumonks.org, I'm very open to that.
> 
> Yes, I've put it on git hub because it was easy to setup and didn't want to
> bother setting it up on one of my servers. It might be good to host it on
> openbsc.gnumonks.org to keep everything grouped. I would keep it in a
> separate git tree tough.

ok, if you send me your SSH public key, I'll create a repository for you.

> > Or are you planning to actually submit this into asterisk mainline, then
> > of course any repo you use now is meant to be only temporary.
> 
> Yes, I'll consider submitting it once it and openBSC are stable enough
> to have 'numbered' releases.
> OTOH, there might be kindof a mess with licences. IIRC, a few years
> back it was required to release copyright to digium (so that then can
> do supported binary distributions with additional features to their
> clients) and that also imply no link (static or otherwise) to GPL
> code.

Ok, I see.  Let's investigate this further down the road.  As I indicated
before, I really don't like the 'daemon in library' approach that we're using
right now, where the entire OpenBSC 'daemon' runs inside a library that is
linked to some other executable.

I suppose at some point we actually want to offer some kind of IPC based API
for external programs, where OpenBSC runs in one process and the other
application in another.  Once that happens, I might consider licensing the 
library on the other side of the IPC under a different license.

> The version I had two days ago was a little too hackish, with things like
> my own IP and RTP port hardcoded at several places and stuff :)

don't worry about that too much, can be cleaned up gradually... that's why we
call it bsc_hack ;)

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list