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.orgHi Andreas,
On Thu, Apr 09, 2009 at 09:10:23AM +0200, Andreas.Eversberg wrote:
> that sounds good. i will try this in hamburg on easterhegg, starting friday.
good luck. I'm not sure if nibbler is going to be there, he has some practical
experience with bsc_hack, the BS11 and everything and could probably be able
to help you out.
I'm definitely not going to attend, my time budget doesn't really permit it to
me, I've taken off a lot of time for holidays recently and really have to get
more paid work done now :(
> also i started coding on gsm_04_08.c file. i like to implement a real state
> machine and like to extract the call handling (application) from the
> signalling part (protocol). this way libbsc can be used to terminate calls to
> applications rather than just forwarding them.
yes, this is a good plan. I had this in mind for later anyway, making it more
extensible.
> here is my idea: we must define an API for applications to communicate with
> libbsc. i would suggest a structure with "message type", "call reference" and
> all informations like "calling party number". if the informations are not
> used, like "calling party number" in the "ALERTING" message, they are
> ignored:
Sounds fine to me. As you can see from my general code design, I prefer
structures with array strings and the like to dynamically allocated ones,
simplifying memory management quite a bit.
> struct high_level_structure_type_name {
> int message;
> int callref;
> u_char imei[..];
> u_char imsi[..];
> u_char tmsi[..];
> u_char dialing[..];
> u_char calling_pn[..];
> int notify_ind;
> ....
> };
>
> i would use a special message "NEW" for creating a new callref. after the
> instance (call) is released and freed, a special message "FREE" could be
> used. an example:
>
> send NEW -> returns callref (or error)
> send SETUP (callref, imei)
> recv PROCEEDING (callref)
> recv ALERTING (callref)
> recv CONNECT (callref)
> recv DISCONNECT (callref, cause)
> send RELEASE (callref)
> recv FREE (callref)
>
> paging, timers, release_complete, ... is handled by gsm_04_08.c, data base,
> numbering plan, call control is done by extracted application file. (let me
> call it callcontrol.c.)
sure, this is probably the best level for a functional split.
> the current application for call forwarding would be removed and put in a
> seperat file or even out of it and make it part of bsc_hack.
>
> what do you think?
sounds great to me, I'm looking forward to see the patch[es] :)
Regards!
--
- 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/20090409/c74417e3/attachment.bin>