Hello guys,
While I'm still busy with understanding the OpenBSC sourcecodes and GSM
protocols, I wonder if it's possible to control the nanoBTS's
transmissionpower. If some additional code is needed, I'd like to give a
try with some hints or directions to look at.
Thank you.
hi,
finally i ported linux-call-router to new mncc api. this is quite easy,
because only data types changed. i don't care about change of mncc api
from time to time, because openbsc does not have that much applications
yet. i think that trau frames don't have anything todo with mncc api and
should be use own interface in the future (hopefully with ipaccess).
i tested openbsc with linux-call-router. everything worked fine after
adding some fixes. now, the mncc-harald includes every work i made,
except the installation of library and include files.
fix 1: i use this workarround to allow my mobile to get a traffic
channel. the mobile reqests a sdcch channel, but currently openbsc is
not able to switch channel. (this should be possible in the future for
handover.) also it checks if there is actually a traffic channel
currently in use, when making a call.
fix 2: not actually a fix: adding imsi to gsm_mncc_number allows to
notify application about calling/connected imsi. also it is possible to
dial a subscriber with no extension assigned, just by using imsi. maybe
it is wiser to put imsi string into gsm_mncc, because it is only used
only once in a message.
fix 3: while detaching, we don't hold a ressource (we don't call
lchan_use), so we don't need to "lchan_put".
fix 4: the given cause value and location parameters are used in
mncc_release_ind function, rather than hardcoded. the plain cause
numbers are replaced by the definitions from header file.
additionally i uploaded a new inofficial version of openbsc and
linux-call-router at www.linux-call-router.de.
andreas
hi fabian,
trixbox uses asterisk. asterisk is supported by linux-call-router
(integrated channel driver). linux-call-router is supports a modified
version of openbsc. (see last post) so you can use trixbox with openbsc.
regards,
andreas
________________________________
Von: openbsc-bounces(a)lists.gnumonks.org
[mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von FABIAN SMITH
Gesendet: Samstag, 13. Juni 2009 19:24
An: openbsc(a)lists.gnumonks.org
Betreff: Open bsc + trixbox
Will openbsc work with trixbox or other pbx's ?
Hey Guys,
some of us started to look into the various 08.0x specs and even SCCP (not me
yet) and I think our common goal is to go towards a more "normal" BSS/MSC and
in the same way keeping the spirit of bsc_hack to allow to run a whole network
with one executable.
A rough split up of BSC vs. MSC would be:
BSC has the secret of:
- init hardware, bcch, oml/rsl setup
- paging
- channel allocation/management
MSC has most of the policies:
- HLR/VLR and who to allow into the network
- call handling etc...
To keep this short ('m quite tired at the moment) my goal/approach is to
create a libmsc.a and move the db.c, gsm_subscriber.c and on the way to move
policy out of gsm_04_08.c to the libmsc.a. bsc and msc would communicate with
an API that resembles the DTAP, BSSMAP interface. The MNCC use case Andreas
and Harald are working on should remain supported, same as the bsc_hack.c. The
goal of having an interface like DTAP and BSSMAP is to allow implementing the
A-Interface.
I will start this work in a branch called holger/msc and will seek for
feedback once I have something that is worthwhile to share.
good night
z.
<<36_application.patch>> again the application patch based on the
current OpenBSC source and the other patches i posted.
i cannot split this patch, because all the parts depend on each other.
the only thing i can do, i can splitt them into their functional parts.
the libbsc will not work without applying all parts then.
Hi!
I am trying to understand the code to make several tests.
If I understand, the default setting is to refuse any phone trying to
connect the network?
I would like to change this in the code to accept everyone.
I saw in bsc_hack the Control Channel Description which seems to deal with
this. Am I wrong?
static u_int8_t si3[] = {
/* header */0x49, 0x06, 0x1B,
/* cell */0x00, 0x01,
/* lai */0x00, 0xF1, 0x10, 0x00, 0x01,
/* desc */0x01, 0x03, 0x00, //Control Channel
Description
/* option*/0x28,
/* selection*/0x62, 0x00,
/* rach */0xD5, 0x00, 0x00,
/* reset*/0x80, 0x00, 0x00, 0x2B
};
Which value shall I put to accept everyone?
Thanks!
Best regards
Eric Cathelinaud
this patch will use the gsm_bts_by_lac() function to start paging of all
bts' with the same lac.
when paging is successfull, the paging_request_stop() function is called
with the current lchan, so the callback function will be called. for all
other bts', the paging_request_stop() function is called without lchan,
so the paging is stopped, but the callback function is not called.
this ensures that only one paging result is received when paging
multiple BTS.
This patch fixes the PCAP logging. If frames are received from E1
interface, an 8 byte mISDN header (MISDN_HEADER_LEN) is in front of the
RSL packet. When frames are transmitted to the E1 interface, the
pcap_write_packet function will get a message buffer without the mISDN
header in front of the RSL packet. The pcap file was tested and the
output is correct.
BN1E1 seems to have different layouts over the time.
i always jumper the cards to TE, so i use a crosslink cable for NT to
TE.
________________________________
Von: openbsc-bounces(a)lists.gnumonks.org
[mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Eric
Cathelinaud
Gesendet: Mittwoch, 10. Juni 2009 10:41
An: Harald Welte
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: layer 1 debugging
I tried to short the left and to invert the twinax plug (thus pluging
them as in the wiki) and it works too. Then it could be a mistake in the
jumper plan of BN1E1 cause they say that the left is "TE" and not "NT".
Anyone else dealing with a BN1E1 card to confirm?
Eric Cathelinaud
2009/6/9, Eric Cathelinaud <e.cathelinaud(a)googlemail.com>:
2009/6/9 Harald Welte <laforge(a)gnumonks.org>
Hi Eric,
On Tue, Jun 09, 2009 at 12:56:25PM +0200, Eric
Cathelinaud wrote:
> Thanks a lot for this layer 1 debugging tutorial. It
helped me a lot since i
> was thinking I did something wrong with mISDN. I
checked the step 3 and find
> out that my ISDN card was working fine.
> Then I tried to invert my twinax plugs and it worked.
I think there is a
> mistake in the wiki.
> It's written in
http://bs11-abis.gnumonks.org/trac/wiki/BS11_Configuration :
> - left Y01 PCM in (from BSC): RJ45 pin 4,5
> - Y02 PCM out (to BSC): RJ45 pin 1,2
>
> but for me it works with :
> Y01 PCM : RJ45 pin 1,2 (orange / white orange for a
straight cable)
> Y02 PCM : RJ45 pin 4,5 (blue / white blue for a
straight cable)
I think that depends on the jumper configuration of your
E1 card. Did you
really put the jumpers in "NT Mode" configuration?
Yes I put NT Mode following the jumper plan (short pins on the
right). My card is a Beronet BN1E1. I will try to short pins on the left
and let you know if working as in wiki.
> I can now see the network on my mobile phone thanks a
lot.
great!
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
========================================================================
====
"Privacy in residential applications is a desirable
marketing option."
(ETSI
EN 300 175-7 Ch. A6)
