Hi Caleb,
The segfault is introduced with this patch:
http://cgit.osmocom.org/libosmocore/commit/?id=f5a079f739c57d8be7c59149fd45…
Is is not really a bugfix, but if you just comment out the following
part from lapd_core.c added by the above patch and recompile openbsc, it will help:
dl->tx_hist = NULL;
The problem is probably related to the RESET function, because Nokia
units are being reset during the initialization phase, and
bootstrapped after that. The reason for this is if this reset is not
concluded, then the BTS will not apply certain configuration parameters
(e.g. change in ARFCN, transmit power, timeslot configuration).
I strongly suggest you anyway, to start with TCF/F FR configuration,
and if you see major alarm "BCF operation degraded: difference between
PCM and BTS clock", it means that your E1 card is not able to provide
accurate enough timing for the BTS. According to Nokia, you need +-5Hz
accuracy on the E1 to meet the timing requirements, but even then at
least 20-25 minutes of operation is needed for the BTS clock to be
synced and the alarm goes away. Usually DAHDI or other E1 cards clock
are not precise enough but don't worry: even with the alarm you can
make pretty good quality phone calls, but remember: if you experience
severe call quality degradation, or the phones cannot camp, or they
loosing the network all the time, it is going to be a timing related
problem. Anyway, do you have the Nokia InSite manager software? If not
just write me a mail and I can help with that. You definitely going to
need that and an LMP cable to do the initial setup, before you can get
started with OpenBSC.
BR,
Csaba
Hey Peter,
> I'd suggest to make LCR use SIP for communcation with Asterisk. See
> http://stuge.se/lcr.txt for a minimal example of LCR configuration.
Do you have some more example configuration files for the Asterisk end
of the SIP trunk?
> Since you're using bridging you might also want to try rtp-bridge
> between GSM and SIP, which could allow GSM phones and SIP phones to
> negotiate codec directly, avoiding any transcoding. (But maybe it
> only works with Abis over IP and not over ISDN? I'm not sure.)
I am almost sure that RTP bridge can only be used with IP based BTSes
which I don't have. My units are connecting via E1 dahdi.
> You can of course continue to debug the LCR-Asterisk module but I
> would suggest moving to SIP since I think working with SIP on both
> legs makes debugging a bit easier.
My problem is that I made test calls an analyzed the logs at both LCR
and Asterisk end, and there is no difference between a good and a half
sided call. First, I forced the GSM phones to use TCH/F FR only, then
I forced LCR and Asterisk SIP clients to use Alaw only (SIP clients
are not supporting any GSM codec). Transcoding obviously happens
between TCH/F FR and Alaw, but how on earth is possible that the
direction of the call can affect that this transcoding is going to
be a success or not? If its a transcoding failure it shouldn't work in
any direction. If its a call routing problem, then the call shouldn't
make its way to the called party. But none of this is what happens.
So I really don't know where to look, or how to debug this problem.
BR,
Csaba
Hi,
When sending sms via openbsc commandline the sms gets extra data added
to its tail.
The coversion from text to PDU results in the converted data + garbage,
this data is posted to the 'sms' database 'user-data' field, and then sent.
in the 'sms' database you can verify that a short sms text results in
long user-data
phone to phone sms works without problems.
Henry
Hi,
I am trying to modify osmocomBB to work without the phone as layer 1.
My goal is that application will using socket to communicate with BTS
(modified BTS which can send and receive message throught sockets).
I analyzed the osmocomBB code and I found that I'll have to modify
osmocon.c (host/osmocon/osmocon.c) file. This file is interface between
serial communication and layer2. If I am right, I have to do this changes:
1. Delete functions handle the serial interface
2. Add new tool server to dnload structure
3. Creating new tool server for L1 interface (UNIX socket or IP socket
with GSMTAP)
4. Add callback function for reading from layer2 socket and forward
this messages to L1 socket interface.
Simplified I have to listen and forward packets from BTS to layer2
socket and from L2 to L1.
Do I think in right direction or I am wrong and it will need more
modifications?
Best regards,
Miroslav Babjak