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/.
Andreas.Eversberg Andreas.Eversberg at versatel.de
i will work on several parts parallel, but i will provide a seperat patch for every part of course. the biggest (signalling) thing is the state machine + information elements + call control. i cannot split this into serveral patches.
for me "call handling" is the application ontop of OpenBSC. there must be an API to use OpenBSC in other applications. currently the "application" in OpenBSC just takes an incomming call, does a data base lookup, and sends "SETUP" message. also it forwards messages like "ALTERING" or "CONNECT". this must be replaced by a different application in order to terminate calls instead of forwarding them.
the interface, i like to introduce, will use primitives which are specified in GSM 04 07. they begin with MNCC_xxx_yyy, where xxx is the primitive type and yyy the info about request/acknowlede and direction info:
example: MNCC_SETUP_IND indicates a setup from the remote (requested by mobile, sent to us)
i like to use a structure for every message type with its information elements: (example)
struct MNCC_setup *setup = (struct MNCC_setup *arg) // arg depends on the message type
if (setup->emergency)
printf("emergency call\n");
else
printf("dialed number is %s, and type is %d\n", setup->called, setup->called_type);
....
i will parse/create all information elements, even if not needed by built-in "call handling" or by my application. messages to the layer 3 will use a send message. (mncc_send(struct gsm_call *call, int prim, void *arg)) messages from layer 3 will use a call back function with similar parameters. this callback function pointer will point towards selected application. a special function for "allocating" the call will also be provided. this is required for application to find a free call structure.
my goal is to make the API close to the GSM specs. also if someone has better idea for API interface, please let me know.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Donnerstag, 16. April 2009 12:30
An: openbsc at lists.gnumonks.org
Betreff: Re: success
On Tuesday 14 April 2009 13:10:36 Andreas.Eversberg wrote:
> - 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.
my two cents on this.
call handling:
I think whatever we have/put into OpenBSC should be fully spec
compliant. I don't see the reason to allow to use an entire different
implementation of the call handling. I totally agree that policies
(e.g. which state to enter after ...) should be fully controllable on
the app layer.
> 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.
hmm a patch accumulating 2-3 months of work? that will be pretty hard for
everyone to review or even change direction early on...