OpenBSC

openbsc@lists.osmocom.org

9 participants
4277 discussions

logging level all everything
by Neels Hofmeyr 12 Sep '18

12 Sep '18

Hi list, looking at the logging code, I was surprised: turns out the 'logging level all everything', though quite a misnomer, was an important counterpart to 'logging level all (debug|...|fatal)'. It worked like this: Assuming some levels are set... logging level foo fatal logging level bar debug Now 'logging level all' would override all of them forcefully: logging level all error # Now all categories including 'foo' and 'bar' log exactly error,fatal # messages. logging level all debug # Now all categories including 'foo' and 'bar' log all messages from debug # thru fatal. # manipulating individual categories has no effect at all now! logging level foo notice logging level bar error # no change in logging behavior! logging level foo fatal logging level bar debug # the way to get rid of the forced level was: logging level all everything # Now we see above configured behavior of foo == fatal, bar == debug This is *still the case*, only that we're now ignoring the 'everything' keyword. The consequence is that we can force all categories and clamp them to all-the-same level, but we cannot lift that clamp anymore! :/ I think we should never have accepted the removal of 'everything' as such, it should have been replaced with a more accurate command, like 'no logging level all'. I am considering to bring this back now, ... but But now that we haven't had 'everything' for a long time and the outrage about it has been limited, I am also drawn towards completely dropping that feature, or at least renaming it. Damage is done, no need to go back to mad naming. From the logging discussion, we concluded that we want a command to set the log level for all categories at once, one-time; not force-clamping all to one level until the clamp is removed, but as if we set each individual level manually. I've cracked my head on what name other than "all" we could want this command to have, 'logging level (*|each|any|set-all)'? I keep coming back to 'logging level all (debug|...|fatal)' being by far the best name for this. Backwards compatibility: what do users see when we modify 'logging level all' to not be a forceful clamp, but instead setting individual levels once-off? If a user had a config of "all" coming last: logging level foo debug logging level bar fatal logging level all notice then the experience is that all categories are logging at level 'notice', and that is what the user most likely also expects to happen. Changing the 'all' command does not change the logging behavior one bit. If in turn the config has "all" first: logging level all notice logging level foo debug logging level bar fatal Then the experience is still that before changing the command, all categories are logging at level 'notice'. Most likely the user expected though to see foo='debug' and bar='fatal', because they were set after the 'all' -- what other reason could a user have to keep these lines in the config file, which don't have any effect as-is? If we change the 'all' command to not be a forceful clamp but just a one-time set, then the logging behavior changes to what the user likely expected when writing this config. However: if these settings were forgotten in the config file, we would suddenly change the logging behavior and might surprise users ... but I still kinda think we would change it to what the user expected, right? And the user would likely go: "ah, finally it's doing what I wanted all the while!" right? So, I want to make 'logging level all' manipulate each individual category once-off, I want to completely deprecate the 'everything' keyword, and drop the "global clamp" feature entirely. Maybe I'd re-add the clamp as 'logging level force-all (debug|...|fatal)' and 'no logging level force-all' to switch it off. That would be exactly the old clamping feature just with less confusing names. The only thing that makes me write here is that I'm only 90% sure on changing the meaning of an existing command, of 'logging level all'. If there is no negative feedback on this here, that would bring me to 100%. Thanks! ~N

4 10

OsMux + MGW + SIP
by Keith Whyte 11 Sep '18

11 Sep '18

Hi community! I'd like here to set out a few issues that we have identified for going forward with the rhizomatica autonomous networks and the osmocom split stack. Some of this has been very briefly discussed between myself and Pablo, and I bring it to the mailing list so hopefully there will be feedback, ideas and suggestions :) I am cherry picking from previous emails here, (mostly mine) please excuse any repetition. I hope others will post their previous comments on this thread, either verbatim of edited to be relevant to the current discussion. 1) This is a question that relates to voip traffic in and out of the autonomous communities over satellite. Currently this is what we HAVE to have in the local village to support autonomous operation): * BSC * MSC * HLR * Freeswitch (freeswitch is our call control, call routing, billing etc) We can't have any essential backhaul running over the satellite , like A for example as we would loose all functionality when the sat link is down, and we'd burn expensive bandwidth! One option to use osmux from autonomous community (village) is to teach osmo-mgw to speak osmux, then we have a co-located bsc/msc/mgw in the village, and the media transport is osmux to another mgw in our datacentre that is demuxing and converting to RTP suitable to be forwarded to our upstream VoIP provider. The question here is what is signalling the MGW in the data centre? Maybe another freeswitch could signal the osmoMGW via some kind of SIP<->MGCP translator. Or we teach the MGW to speak SIP? Another option that I want to put on the table and see what people say is to look at implementing osmux as a codec in freeswitch. I don't know what that would mean in terms of effort. I don't know if the osmux code can be abstracted, if that is the right term, into it's own external includible library that could then be used to build a freeswitch codec. I looked some implementations of AMR codec for freeswitch, and really it looks like a boiler plate codec with registration, setup and then it calls the encoding and decoding functions in the opencore amr library. Maybe, we can do the same with osmux? Then we could have two freeswitchs signalling and transcoding to/from osmux? - then we are not really working on osmo solution and others in the osmo community might prefer to see osmux fully implemented in MGW before anything else? Here are a number of related tickets from Harald on osmux integration: http://osmocom.org/issues/1683 and http://osmocom.org/issues/2832 as well as https://osmocom.org/issues/2909 I think though, that in 1683, we are stalled by https://osmocom.org/issues/2391 for the split setup. 2) Another question relates to this proposal of a media gateway less mode: https://osmocom.org/issues/3142 I think this suits us, because really our call signalling is all happening in freeswitch and we would prefer I think not to have the media gateway at all most of the time. and in fact for local Mobile to Mobile calls on the same BTS, we would in fact prefer the RTP be local on the sysmobts, or indeed BTS<->BTS! Freeswitch has a "bypass media" parameter, in fact you can even activate this at call processing time before bridging the call, depending on whether it makes sense in terms of direct connection being possible and the lack of transcoding. There's also a "bypass media after bridge" parameter that is automatically using SIP (re)-INVITES to switch the RTP stream from passing through freeswitch or going directly from end point to end point. Using "bypass media" in our profile works nicely; of course, as all it is doing is using the IP address(es) of the osmo-bts in the SDP, so the rtp stream loops on lo in the sysmobts. It would help with something that I mentioned at Osmodevcon, Harald, which was that in some cases we might like to avoid having our RTP go over the (sometimes variable quality) Wifi links between the BTS and the BSC. A problem is that if you use "bypass media" you have no early media and no audible ringing signal, you don't get any audio stream until the B leg picks up. This is what "bypass media after bridge" is for. Unfortunately, osmo-nitb (at least, and I don't believe anything has been done in osmo-bsc related) plus LCR or osmo-sip-connector combinations do not react correctly to the SIP reINVITES, you end up with multiple calls. So all that needs to be fixed / implemented. I noticed mention of implementation of MNCC_RTP_MODIFY on fairwaves branches of OpenBSC and LCR. I've compiled and tested this, but as far as I can see it is still not working, as issuing a SIP reINVITE from freeswitch is still setting up new calls, not just changing the RTP streams. Maybe I also need a fairwaves osmo-bts. So this is something I think I would like to see: * Full support for SIP reinvite in osmo-sip-connector which would then send a MNCC_RTP_MODIFY which ends up sending (I think it's called a IPAC_CRCX?) to osmo-bts which will then switch the stream endpoints. This I believe is also necessary for handover to function with an MNCC socket setup and we don't currently have it, not even in the osmo-nitb. * Implement a no media gateway mode in osmo-msc and have the MSC control the media stream using SIP via MNCC/osmo-sip-connector instead of controlling the MGW using MGCP. K/

6 9

Re: OsMux + MGW + SIP
by Keith 10 Sep '18

10 Sep '18

I was browsing a little through the osmux code in openbsc and libosmo-netif, but I did not quite find the answer to this question I have: Pablo maybe you can shed light? When you divide the OSMUX stream again and turn each circuit ID back into individual RTP stream you have an associated port and IP, right? (on the terrestrial side) I'm wondering if we could have: * local bsc and it's colocated mgw * local msc, with two colocated mgws (we decide which one to signal depending on if the call is local or needs the SAT stream) another point here is I undertand we don't _really_ need two MGWs, so maybe just one in the village, shared between bsc/msc and one in the datacentre. so in the case of a call that is using sat/ osmux, the MSC in the village is signalling the MGW in the datacentre, therefore this MSC knows which IP/port combination to tell to osmo-sip-connector and on to freeswitch, which then signals whatever SIP UA in the data centre So, the fact that osmux is used at all is completely transparent to the SIP UAs Does that make sense? k/

2 2

Call Detail Log - OSMO Elements
by Ron 07 Sep '18

07 Sep '18

Hi Community, Is there a documentation regarding the Call Detail Logs in any of the OSMO Elements such as Call Information (call started, duration and end/caller and callee information,etc...) and SMS Information (sent/received time/sender and receiver,etc...)? And may we know what log level configuration do we need to configure for us to see those information? Thanks in advance. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

4 6

Fwd: Multi-Tenancy / Multi-Operator Support
by Shingirai Simba 06 Sep '18

06 Sep '18

---------- Forwarded message --------- From: Harald Welte <laforge(a)gnumonks.org> Date: Thu, Sep 6, 2018 at 12:30 PM Subject: Re: Multi-Tenancy / Multi-Operator Support To: Shingirai Simba <shingy92(a)gmail.com> Hi! I would appreciate if you could send your response to the mailing list, so I can further follow-up to it. This way, our conversation is to the benefit of the wider Osmocom community. Regards, Harald On Thu, Sep 06, 2018 at 11:57:48AM +0200, Shingirai Simba wrote: > Hie Harald > > Indeed i am referring to 3GPP MOCN / GWCN as per TS 23.251, but any viable > work around is most welcomed even if it does not met specifications. I am > contemplating the idea of just running this kind of configuration as 3 > different LXD instances, but will i able to share the same physical SDR > radio instance with the 3 separate core networks.' > > Regards > > Shingirai A. Simba > > On Thu, Sep 6, 2018 at 7:54 AM Harald Welte <laforge(a)gnumonks.org> wrote: > > > Hi Shingirai Simba, > > > > On Wed, Sep 05, 2018 at 04:15:26PM +0200, Shingirai Simba wrote: > > > We are contemplating on a Multi-Operator / shared radio for 3 communitiy > > > operators in Zimbabwe, Africa. > > > > The question is: How exactly does the above high-level goal translate into > > concrete technical architecture? Would the goal be to run your complete > > own > > PLMN with the other operators just roaming into that network (i.e. using > > TCAP/MAP > > roaming interface), or are you referring to a 3GPP MOCN / GWCN as per TS > > 23.251? > > > > Or something else entirely? > > > > > Does OsmoBSC/OsmoMSC n support this using SDR front ends. > > > > In either of the two cases, the current implementation doesn't provide > > everything > > you'd need for such a setup. But let's continue this discussion once it's > > more > > clear what kind of technical architecture you're looking for. > > > > -- > > - 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) > > -- - 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)

2 1

Multi-Tenancy / Multi-Operator Support
by Shingirai Simba 06 Sep '18

06 Sep '18

Hie We are contemplating on a Multi-Operator / shared radio for 3 communitiy operators in Zimbabwe, Africa. Does OsmoBSC/OsmoMSC n support this using SDR front ends. Regards Shingirai Simba

2 1

The magic behaviour of 'logging level all LEVEL'
by Vadim Yanitskiy 31 Aug '18

31 Aug '18

Hi all, A discussion was started during the review of https://gerrit.osmocom.org/10116/. The main idea of this change is to fix the behaviour of 'logging level all LEVEL', but I think it was also mixed with some additional feature, which I would like to discuss here, publicly. First of all, the change introduces a new special logging level 'unset', which allows one to reset a given category (i.e. unset its custom value): !! Initial logging configuration: logging level all error logging level mncc debug logging level pag notice logging level meas debug !! Resetting DMNCC: # logging level mncc unset !! So, now DMNCC has no custom log level, it will use !! the default level (in this example it is 'error'): logging level all error logging level pag notice logging level meas debug This feature looks fine and extremely useful for me. But (among fixing) this change additionally changes the behaviour of a command for setting the default logging category (i.e. 'logging level all LEVEL'): !! Initial logging configuration: logging level all error logging level mncc debug logging level pag notice logging level meas debug !! Changing the default logging level: # logging level all debug !! Ahhh, I've lost my custom levels :( logging level all debug !! What I expected to get: logging level all debug logging level mncc debug logging level pag notice logging level meas debug So, together with changing the default logging category, this command now would also reset all custom settings... I am not sure this is exactly what one need/expect, so I would like to share the following ideas: 1) The category 'all' looks/sounds confusing when it's used in such cases like this: # logging level all debug because one can interpret it like: "set all categories to debug". despite actually (according to the implementation) this is related to the default logging policy. Maybe, we should rename it to 'default'? So, 'logging level all LEVEL' would *set all categories* to a given logging LEVEL, while 'logging level default LEVEL' would only affect the default logging level... 2) Introducing the new command: # logging level unset LEVEL which is intended to assign a given LEVEL to all categories, which have no custom logging level (i.e. have 'unset'), would make the idea of having default logging policy meaningless. Setting logging level(s) for all possible categories (using this command), looks like writing iptables rules for all possible and impossible cases instead of using the DEFAULT policy... 3) The introduced behaviour of resetting all categories to 'unset' could be implemented in a separate function, and can be represented by a separate command: # logging level unset-all The name of this command clearly defines the expected behaviour. Moreover, it doesn't affect the default logging level, which can be still changed by a separate command. As we (me and Pau) have different opinions, or we simply don't understand each other, let's make this discussion public, and let's see what others think about this... With best regards, Vadim Yanitskiy.

5 25

GGSN p-t-p address?
by Keith 24 Aug '18

24 Aug '18

Hi all, idle curiosity here more than anything..... I noticed that if I bring up a pppd link with a GSM modem to an osmo stack GPRS network, I get assigned an IP address from the pool as configured on osmo-ggsn; ip prefix dynamic 10.20.0.0/16 ip dns 0 192.168.11.2 ip dns 1 192.168.11.2 ip ifconfig 10.20.20.253/16 but the p-t-p address is 192.168.100.101; Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: local IP address 10.20.0.8 Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: remote IP address 192.168.100.101 Here's the resulting ifconfig: 3g-gwan Link encap:Point-to-Point Protocol inet addr:10.20.0.8 P-t-P:192.168.100.101 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:54 (54.0 B) TX bytes:76 (76.0 B) This is not really a problem but I thought it was weird so I looked for this IP (192.168.100.101) in the source code but it was nowhere to be found. I'm a bit rusty on ppp, but should it not be the address configured in the ggsn's ip config? I thought maybe it was coming from the local pppd stack, so I booted an old windows 7 machine and connnected the GSM modem, and it got the same p-t-p address of 192.168.100.101 thnx/ K.

5 12

CSN.1 directory
by benoit michau 24 Aug '18

24 Aug '18

Dear osmocom community, This email to point to a recent development I made on CSN.1, which might be of interest to some of you. I extracted and consolidated all CSN.1 definitions from 24.008, 44.018 and 44.060 (the "consolidation" part was quite hard...). I have also developped a CSN.1 to Python translater, and a runtime to encode / decode any CSN.1 structures. This is available here: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1dir and there: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1 And there are some quick explanations on how to use this in the wiki: https://github.com/ANSSI-FR/pycrate/wiki/Using-the-pycrate-csn1-translator-… Regards Benoit

4 7

Move osmo-bsc (with osmo-bts-trx and osmo-trx-lms) to another device
by Norbertas Kremeris 20 Aug '18

20 Aug '18

Dear all, I have a running and working osmocom network stack (2g only, no GPRS/DATA) with osmo-trx-lms using a LimeSDR mini (osmo-trx-lms, osmo-bts-trx, osmo-bsc, osmo-hlr, osmo-stp, osmo-msc, a and single osmo-mgw process) , and I would like to have osmo-bts-trx, osmo-trx-lms and osmo-bsc moved to another computer. I would like to have an AoIP connection between the pc1 and pc2. As far as i understand, osmo-bsc and osmo-mgw communicate over AoIP (as per the manual here http://ftp.osmocom.org/docs/latest/osmomgw-usermanual.pdf). My knowledge about the interconnection of all the osmocom core components is rather limited, and what at first seemed like a trivial task (to move osmo-bsc to the other computer and changing the msc mgw remote ip) has turned into a 2 day ordeal with me trying to wrap my head around the functionality of all the core components without any success. I have modified my stack to work with a single osmo-mgw process (but the moving of osmo-bsc does not work with osmo-mgw-for-bsc and osmo-mgw-for-msc either). Attached are all the configuration files used. The IP of the osmo-bts-trx, osmo-trx-lms and osmo-bsc running pc (PC1) is 192.168.1.249, the ip of the pc (PC2) that is running the core network components is 192.168.1.219. All my osmocom components are built from source (latest tags). Running the osmoBSC on the PC1 connects to osmo-bts successfully and does result in a network being shown on the phone, but osmo-bsc constantly throws errors: <0007> a_reset.c:106 A-RESET(msc-0)[0x1ee0530]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1edfd30]{AS_DOWN}: Event AS-TRANSFER.req not permitted Any pointers would be very appreciated. Sincerely, Norbertas

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC