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
I have come across a nanoBTS 165AU but since is used and not tested
from the previous owner, I guess it has set a static IP.
After turned on is booting (RED light) and then remains (ORANGE not
flashing) even if the eth is connected to the router.
Based on observation, constant blinking orange seems to indicate the layer
2 link isn't up (eg it's powered but Ethernet isn't connected). Solid
orange is good. Once it's fully booted it seems to be solid orange with a
very quick flash off once a second seems to indicate it's trying to find
the BSC
> At the moment I am trying with ipaccess-find and BtsInstaller to find in on my LAN .
> Unfortunately it is not answering and is not even getting an IP from the router by the DHCP daemon.
>
> ipaccess-find / btsinstaller only ever seem to find my BSCs when the
machine they're running on is on the same subnet.
The easiest way to track down a rogue bts is to connect it directly to a
spare network port in the pc and then run wireshark on it. On boot my BTS
sends a number of dhcp inform requests broadcasting it's IP and then starts
blasting packets at the BSC address.
Hope this helps,