OpenBSC

openbsc@lists.osmocom.org

5 participants
4173 discussions

by Luca Bertoncello

Hi, List! Just a question, does OpenBSC block the connection to special number such 112? I connected OpenBSC to Asterisk and in Asterisk I have an extension 112 (now just as test), an 110 and an 115. If I call the 110 or 115 I can see that Asterisk will be asked to connect the phone and the VoIP-phone with the number will be called. If I call the 112 the connection terminates and I can't see OpenBSC sending any signal to Asterisk. Could you confirm me, that OpenBSC blocks this number? And, maybe, suggest me how to delete this block... :) Thanks a lot! Luca Bertoncello -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12 _______________________________________________________________________ Impressum: NETZING Solutions AG - Fröbelstraße 57 - 01159 Dresden Sitz der Gesellschaft Amtsgericht Dresden HRB 18926 Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz USt.Id DE211326547 Mail: netzing.ag(a)netzing.de

14 years, 4 months

Re: Re: Blocks OpenBSC the calls to 112?

by 246tnt＠gmail.com

> Does it mean, that it is not possible for me to have a 112 number b > called in my network? No, it's not possible. You should avoid anything starting by '1' and anything starting by '9' in your dialplan ... Cheers, Sylvain

14 years, 4 months

Using openBSC as MSC

by Ammar Naamat Hameed

Dear All, Is it possible to use openbsc as MSC, VLR and HLR without using nanBTS as i'm trying to develop an SMSC.In other words, to make it work as MSC,HLR emulator with dummy subscribers? Regards, Ammar

14 years, 4 months

Re: nanoBTS multi-TRX setup

by Dieter Spaar

Hello Konrad, On Wed, 13 Apr 2011 16:16:01 +0200, "Konrad Meier" <meierk(a)informatik.uni-freiburg.de> wrote: > > Any idea what the NWL connector is for? Its the Rx Antenna for the "Network Listen" feature of the nanoBTS, its used for receiving the downlink of other basestations. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

14 years, 5 months

Re: nanoBTS multi-TRX setup

by Dieter Spaar

Hello Konrad, On Wed, 13 Apr 2011 13:10:54 +0200, "Konrad Meier" <meierk(a)informatik.uni-freiburg.de> wrote: > > 1. What is the purpose of the "RF cable"? > Is the TX port of the master BTS looped through the second BTS? Or hase > every nanoBTS his own TRX/RX? The RF cable is used to route TX from the rear unit to the AUX connector of the front unit. The SMB socket at the back and AUX are directly connected, there is nothing special about them. So in a stacked two-units assembly the front unit also has the TRX antenna of the rear unit at the AUX connector. Most certainly the idea is to improve transmission of the rear unit or to better separate the two TRX antennas. So TX is looped through one unit but the two TX signals are not combined. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

14 years, 5 months

How can I calibrate the clock of nanobts?

by Seungju Kim

How can I calibrate the clock of the nanobts? I looked through the mailing list and all I have found is that it is not implemented.... Sent from my iPhone

14 years, 5 months

nanoBTS multi-TRX setup

by Konrad Meier

Hi all, I was just reading the wiki page about the nanoBTS multi-TRX setup. Two things are not clear to me. 1. What is the purpose of the "RF cable"? Is the TX port of the master BTS looped through the second BTS? Or hase every nanoBTS his own TRX/RX? I am asking because I would like to use a nanoBTS-Booster with the multi-TRX setup and therefore require a combined RF signal. 2. The example example "openbsc.cfg" configures the trx 1 as follows: timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 Is this really needed? My first idea was to configure the second trx to TCH/F only. Best regards Konrad Meier

14 years, 5 months

Any plan to fork OpenBTS and/or merge with Osmocom code?

by Fabio Pietrosanti (naif)

Hi all, this email don't want to be a provocative email but just an opinion related to the creation of value for GSM TLC stack into the opensource environment. As we know currently there are several different projects growing into the GSM (then tetra and in future 3G?) opensource ecosystem. The first "pratical" base has been OpenBTS as a simplified GSM um interface for VoIP. The second major implementations was around the osmocom project that build-up a complete and well designed GSM stack with all the modular interfaces and protocols for communications between BTS and BSC, with MSC, HLR, GGSN, SGSN and major GSM network components. Additionally, if i understood correctly osmocom is much more advanced with broad scope and better design than OpenBTS. It seems to me that OpenBTS it's almost stalled due to the "commercial fork" of the OpenSource project and only fairwaves is contributing to the opensource branch. I personally really dislike the "Commercial fork" approach where the community is used only in the early phase of the project to improve it and from a certain point the community doesn't get almost any added value. I like much more the dual-licensed approach like AGPL/Commercial (like http://pjsip.org) where all the value of the code is publicly released. However, my post was related to a question: - How complex would be, leveraging existing public OpenBTS code, to integrate into the Osmocom project? I mean, having a sort of lightweight BTS component speaking A-Bis over IP to OpenBSC like the cheap nano ip.access BTS does. For what i read now Osmocom have 2 software BTS (Osmo-BTS and Soft-BTS), communicating with the A-BIS over IP interface to OpenBSC: http://lists.gnumonks.org/pipermail/openbsc/2011-March/002529.html http://lists.gnumonks.org/pipermail/openbsc/2010-April/001508.html I've read that only a lot of time ago (2009) there was a discussion about OpenBTS to OpenBSC integration: http://lists.gnumonks.org/pipermail/openbsc/2009-October/000955.html At the current stage of development (2011), with Osmocom finally getting a Software-BTS part communicating to the Software-BSC side, how really complex it would be to integrate the GSM-um related part of OpenBTS into the project? With that approach the 'GSM-um' interface would be a very simplified module of the overall system and osmocom would completely replace OpenBTS all-in-one project. Am i right? -naif p.s. Sorry for the cross-posting, i just wanted to explain the idea and get the communities feedbacks to understand 'at which point' we are in order to think 'what would be required to be done' to achieve that goal.

14 years, 5 months

[PATCH 0/7] openbsc: cleanups for ipaccess tools (3/*)

by pablo＠gnumonks.org

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> This patchset is the third in the series to cleanup code in ipaccess tools and drivers. They have been tested by bootstraping the nanoBTS successfully in a small setup with two laptops, one acting as proxy and another with osmo-nitb. They are available in the pablo/cleanups branch in openbsc git tree. BTW: I'm going to stop a bit with cleanups to add a VTY interface for ipaccess-proxy, as Harald suggested. Please, merge it! Thanks. Pablo Neira Ayuso (7): libabis: ipaccess: more robust ipaccess_idtag_name() src: more robust ipaccess_idtag_parse() libabis: ipaccess: use log instead of debug under errors in ipaccess_send() ipaccess-find: get rid of ipac_idtag_name() ipaccess-proxy: more robust option parsing and checking ipaccess-proxy: remove leftover option `--udp' ipaccess-proxy: get rid of make_gprs_sock() openbsc/include/openbsc/ipaccess.h | 2 +- openbsc/src/ipaccess/Makefile.am | 6 +++ openbsc/src/ipaccess/ipaccess-find.c | 22 +------------ openbsc/src/ipaccess/ipaccess-proxy.c | 56 +++++++++++++-------------------- openbsc/src/libabis/input/ipaccess.c | 18 ++++++---- openbsc/src/osmo-bsc_nat/bsc_nat.c | 8 ++++- openbsc/src/osmo-bsc_nat/bsc_ussd.c | 8 ++++- 7 files changed, 55 insertions(+), 65 deletions(-) -- 1.7.2.3

14 years, 5 months

wireshark: update of RSL dissector

by pablo＠gnumonks.org

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> This patch includes some updates for the wireshark RSL dissector. See patch for details. This changes are available in the pablo/wireshark-rsl branch of openBSC. Please, merge it. Pablo Neira Ayuso (1): wireshark: update extension of RSL dissector with ip.access nanoBTS support wireshark/0004-rsl-ipaccess.patch | 228 ++++++++++++++++++++++--------------- 1 files changed, 134 insertions(+), 94 deletions(-) -- 1.7.2.3

14 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC