Hi,
This week end I started coding a channel driver to integrate OpenBSC and Asterisk directly. You can find the code here http://github.com/smunaut/ast_chan_openbsc
The current public version is what I coded this Saturday, it doesn't do much, only registers itself as a channel driver and runs the openBSC core within asterisk. It will work only for the ip.access at first (at least) because I'm directly bridging the RTP audio from the nanoBTS to the RTP subsystem of Asterisk.
I spent a good part of today hacking together enough code to make a call and it worked, I got bidirectional audio. This latest code is not public yet because it's just a big mess and only take care of setup and not cleanup (so you can do 1 call and then restart :) With this hack, I just wanted to confirm that it could work without too much problem. I will try to clean it up ASAP and publish it so that there is a minimal functionality testable :)
OTOH, my time is limited and I split it between OpenBSC, OpenBTS and airprobe so some weeks may be slow.
Sylvain
Hi Sylvain,
On Sun, Sep 27, 2009 at 07:35:05PM +0200, Sylvain Munaut wrote:
This week end I started coding a channel driver to integrate OpenBSC and Asterisk directly. You can find the code here http://github.com/smunaut/ast_chan_openbsc
thanks, this is exciting news. Please keep us posted. 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.
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.
This latest code is not public yet because it's just a big mess and only take care of setup and not cleanup (so you can do 1 call and then restart :)
that's not enough reason to not have it in a separate branch in your git repo, one that you delete as soon as you have merged a cleaned-up version to the master branch :)
OTOH, my time is limited and I split it between OpenBSC, OpenBTS and airprobe so some weeks may be slow.
sure, don't worry. We all know that feeling...
This week end I started coding a channel driver to integrate OpenBSC and Asterisk directly. You can find the code here http://github.com/smunaut/ast_chan_openbsc
thanks, this is exciting news. Please keep us posted.
Ok, I cleaned most of the mess yesterday and updated the tree. The branch 'master' contains eveything that's cleaned up. I also added a 'hack_call' branch that has minimum call control to be able to make mobile-terminated call. Only the 'normal calls' work ( dial -> ring mobile -> answer mobile -> hangup on mobile). Any deviation will most likely result in a crash :) But it's usable and all instructions are in the README for people to test.
It's a pity that there are no free EFR/AMR codec implementation, I have to use plain old GSM-FR.
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.
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.
So that may take some time :)
This latest code is not public yet because it's just a big mess and only take care of setup and not cleanup (so you can do 1 call and then restart :)
that's not enough reason to not have it in a separate branch in your git repo, one that you delete as soon as you have merged a cleaned-up version to the master branch :)
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 :)
Sylvain
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 ;)
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!
Yes, there is the openmoko & android (using opencore) too. But I meant 'free' as in I can use/distribute it without having to worry :) Here I'm not sure it would be accepted to be merged into asterisk ...
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.
Yes, having the core running in there is not the most elegant solution :) But since all the interaction is done via the MNCC interface, it's probably very easy to just export that as a socket. Just need to clean up a little the message format (with like type & length field always set properly and such) and then only the mncc.h header would be used by external apps ...
Sylvain
On Tue, Sep 29, 2009 at 09:21:41PM +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!
But I meant 'free' as in I can use/distribute it without having to worry :)
well, if you think that way then you probably should not ever distribute OpenBSC, as it probably implements dozens of things that are covered by GSM related patents. This is why we are working on an experimental implementation for research purpose. As soon as you use that in a commercial context, you will have to ensure that you have licensed the apropriate patents (GSM Essential IP) from Siemens and others.
Yes, having the core running in there is not the most elegant solution :) But since all the interaction is done via the MNCC interface, it's probably very easy to just export that as a socket. Just need to clean up a little the message format (with like type & length field always set properly and such) and then only the mncc.h header would be used by external apps ...
yes, though in this case Andreas Eversberg would have to decide on the licensing of that.
Also, MNCC does not cover everything we might want to expose to applications, but it is a start.
-
Harald Welte -
Sylvain Munaut