success

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
Wed Apr 15 21:17:56 UTC 2009


On Tue, Apr 14, 2009 at 01:10:36PM +0200, Andreas.Eversberg wrote:
  
> on the easterhegg 2009 we got everything running. even audio worked! and
> we catched our first imsi from a public network.

congratulations.  It's good to know that others can reproduce our work.

> the following things must be changed in the software:
> - sending time slot 1 frames requires a queue and a timer, rather than
> using "usleep()". sleeping causes loss of audio and signalling
> informations. (i work on that)

I completely agree.  the usleep() was just a quick and dirty hack.

> - subslots are in reverse order: slot 2 (0..3) must have mask 00110000
> and not 00001100. this causes no audio.
> - both time slots (2 and 3) must be configured, or unitialized pointers
> cause a crash.

interesting.  Why was it working for us here before?

> - data link is available since DL_ESTABLISH_IND is received and not
> MPH_*.

ok.  This is a misunderstanding of mISDN on my part.

> - in order to release layer 2 and unload the driver after stopping of
> bsc_hack, a special ioctl must be given after opening socket.

the question is: do we want this? At least during development, I don't think
so.  The BS-11 has the nice property that you can just restart OpenBSC and
everything will keep working.  The BCCH stays alive, phones in idle mode don't
even notice tha OpenBSC was restarted.

This is very different from the nanoBTS, where the BCCH dies as soon as the
TCP connection to OpenBSC is down.  You need to perform network selection
again after restarting OpenBSC.

So if we release layer 2, then we should at least have a commandline option
to keep the current behavior.

> - some little extras: changing card number and "location area code" by
> additional arguments.

> @harald | @dieter: other isdn drivers (windows) have obviously reversed
> bit order on transparent channel. bit 0 is exchanged with bit 7 and so
> on. to make it work, i did not change the bit order, i just changed the
> location of the subslot, and it worked.

I am using mISDN with HFC-E1 and BS-11 on a Linux x86 box without changing
anything regarding the subslot bit order.  I think at least three people
have wokring BS-11 + OpenBSC setups.  So I'm a bit surprised that you bring
up the bit order now.  Was it only coincidence when it worked so far? Maybe
this needs more investigation.

> i would like to provide a patch for the solutions above. i will see, if
> i can do that this weekend.

great, please one patch per problem, if possible.

> - provide a real state machine to the layer 3 with timers. make calls
> setup and release cleanly.
> - support transcoding of all information elements.
> - remove all call/subscriber handling from layer 3 and put it into a
> seperat file (layer 4 call control). it will then be possible to
> initialize libbsc without the built-in call control and database, to use
> it for other applications like asterisk and linux-call-router.
> - add application interface to traffic channels for transcoding and
> switching.

I agree with those goals, so if there are any issues from my side, they
would likely only relate the implementation of it, not the goal/target.

> the estimated time for this will be about 2-3 months. the result will be
> a complete BSC+MSC with routing and PBX features and asterisk interface.
> i will provide a patch en-block, because i work on all parts at the same
> time.

ok.  It would be great if you could keep us in the loop, e.g. use a public
set of patches, or a svn branch in our repository, or something similar.  If we
can keep up-to-date with what you're doing, we can probably give better
feedback than if we have to wait for three months and then get thousands of
lines of patches that need to be reviewed all at once.

Thanks again for all your help, it is really appreciated.
-- 
- 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090415/c7cdfa8f/attachment.bin>


More information about the OpenBSC mailing list