OpenBSC January 2013

openbsc@lists.osmocom.org

16 participants
17 discussions

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

1 month

Re: Any interest for Osmocom meetings in Bavaria ?

by Dieter Spaar

So far three persons have indicated their interest to join a meeting at my place. Considering the time it takes to drive to my place, it probably makes sense to have the meeting at the weekend (either Saturday or Sunday) so that there is more time for the meeting itself. I can suggest one of the following dates for the first meeting, somewhere between 10:00 to 18:00 on each day: 25.8. (Sa) or 26.8. (Su) 1.9. (Sa) or 2.9. (Su) 8.9. (Sa) or 9.9. (Su) So please let me know when you have time and also make suggestions in which Osmocom topic you are interested in so that we can have some sort of agenda for the meeting to make best use of the time. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

12 years

SimpleHLR: A web interface for OpenBSC

by Peter Caprioli

Hello everyone, I've just finnished writing together a small web interface for the OpenBSC HLR. It allows you to modify various parameters in the database and also provides a set of functions to modify the HLR or sending SMSes in your own scripts. The project is still very alpha but it seems to work reasonably good. Feel free to give any feedback! Screenshots and source code is available on my website: https://stormhub.org/simplehlr/ -- *Best regards, Peter Caprioli*

12 years

OpenBSC with LCR/SIP

by Kelum Navaratne

Hello list, First of all congratulation to developers of this project making such wonderful project in an interesting subject. I am new to this project and for past few days i managed to go through the documentation and get most of it tested. Thanks for pretty good documentation in most of the areas as well. I have the osmo-nitb working very fine using a nano bts. How ever when i try to install it with LCR to interconnect with external switch, im facing some problems. Initially i thought i must use LCR+Asterisk. But later i figured out there is a built in SIP interface on LCR which there is no need to asterisk or chan_asterisk. I would prefer to use this LCR SIP interface as i dont want to use asterisk and just want to forward all calls to another SIP switch. Now in this context there seems absolutely no documentation on both openbsc and LCR/mISDN lists. Can some one please shed me some light here on how to build a LCR with SIP to be work with osmo-nitb. All i want to test is GSM phone > Osmo-nitb > LCR with SIP > SIP softswitch Thank you very much for every one's effort in this project and would be glad to see some response for this. Best Regards Nava.

12 years, 4 months

None

by FABIAN SMITH

http://www.arts-gallery.de/tmp/likemn.html FABIAN SMITH

12 years, 5 months

nanoBTS Booster for sale

by Konrad Meier

Hi all, At the University of Freiburg (Germany) we have a nanoBTS booster 1800 for sale. Details for the booster are given here: http://www.proximus.com.ua/Nano_BTS_high_power_GSM_booster.html The package includes everything required: - Booster - Power supply - 2x cable to connect to the nanoBTS (0,5 meter) - 1x cable to the antenna (5 meter) - 1x omnidirectional antenna. 3 dBd gain / 1800 MHz The antenna is a high quality omnidirectional antenna from Procom: http://www.procom.dk/products/base-station-antennas/1.3-2.0-ghz/gain-antenn… Best regards Konrad Meier

12 years, 5 months

Jan 23, 8pm / Osmocom Berlin User Group meeting

by Harald Welte

Hi all! This is the announcement for the latest incarnation of our bi-weekly Osmocom Berlin meeting. January 23, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. However, we'll have a progress report + demonstration of current osmo-pcu. If you are interested to show up, feel free to do so. The meeting is free as in "free beer", despite no actual free beer being around ;) Regards, Harald -- - 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)

12 years, 5 months

Review request for osmo-bts changes for my zecke/channel-release branch

by Holger Hans Peter Freyther

Hi, the branch is not done yet but I am confident about the first couple of commits and would like to have some extra eyes to take a look. The branch is here[1] and the general goal is to improve the reliability of the code. Under heavy use it is possible that the nitb will mark all lchans as broken. While doing the tests I noticed the following issues: 1.) On Call-Control with fast hangups (during channel modify) I can see empty FACCH messages from the DSP gsm queue. 2.) The wlc/prim request handling has the known and documented limitation that for a given confirm we do not know who sent the request. This can lead to call the 'wrong' callback with the wrong data/closure. I addressed this the following way: 1.) Add a u8Size == 0 check. For the SACCH we added a < 2 check. Should we check if a LAPDm header could fit? What would be the best limit? I have only seen u8Size == 0, so this is what I addressed.[2] 2.) I address it by passing the gsm_bts_trx as the data pointer and saving the lchan identifier in the hLayer3 pointer and then resolve the lchan from the TS. In follow up commits I introduced a new function to enter the Gsm primitive into the queue and I plan to change the callback signature for them to always include the TRX anyway. The main change is here[3]. There is still a clash between the Ciphering and the TxPower... 3.) The next commits should fix the reliability issue. I do this by keeping a queue of outstanding SAPI operations. And ACK ABIS requests when the queue becomes empty. This is mostly working right now but I have one issue with the ChannelReleaseMarker. When sending a SACCH DEACTIVATE and before the two SACCHs are deactivated send a RF Channel Release the queue appears to be stuck. cheers holger [1] http://cgit.osmocom.org/cgit/osmo-bts/log/?h=zecke/channel-release [2] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&id=2e… [3] http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=zecke/channel-release&id=af…

12 years, 5 months

Documentation for Control interface in wiki?

by Harald Welte

Hi Daniel, today I was creating http://openbsc.osmocom.org/trac/wiki/PortNumbers and realised that there is no wiki page describing what the control protocol is (which I would ahve linked from PortNumbers). I know at the time you first posted the control interface patches to the list, there was some README/Documentation. Could you please add that to a wiki page, possibly reviewing/updating it to reflect today's control interface? Thanks in advance, Harald -- - 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)

12 years, 5 months

osmo_sock_init/getaddrinfo not working for GRE/SOCKET_RAW

by Holger Hans Peter Freyther

Dear Pablo, getaddrinfo does not work for the combination of AF_INET, SOCK_RAW and IPPROTO_GRE. I have attached an example application that can be compiled with: $ gcc -o fr fr.c `pkg-config --cflags --libs libosmocore libosmogb` this prints: getaddrinfo returned NULL: Success FAILED gettadrinfo returns -8 which should be this: # define EAI_SERVICE -8 /* SERVICE not supported for `ai_socktype'. */ I am not sure what is the most clever way to resolve this. Make SOCK_RAW branch out early and do the socket/bind(/listen) manually, use getaddrinfo twice with some more unspefici options, just deal with SOCK_RAW differently now? The attached code has the benefit of at least handling INET and INET6 inside the getaddrinfo result. any ideas? holger

12 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2013