From rafael at rhizomatica.org Sat Aug 3 17:17:50 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Sat, 3 Aug 2019 14:17:50 -0300 Subject: Sample configs for reproducing osmo-nitb behaviour with the split stack In-Reply-To: <202c6769-8f1d-c5f5-2938-f22f549c4105@sysmocom.de> References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org> <20190713014203.GX3429@nataraja> <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de> <202c6769-8f1d-c5f5-2938-f22f549c4105@sysmocom.de> Message-ID: <8c2ba432-f4fe-2c5b-026a-6252a43c0673@rhizomatica.org> Hi Oliver, I managed to test a bit, and just two issues in the log which I saw: When a phone try to connect (not present in the hlr db yet): 0000> hlr.c:204 IMSI='724056816211859': Creating subscriber on demand <0000> hlr.c:220 IMSI='724056816211859': Successfully assigned MSISDN='76342' <0003> hlr.c:510 IMSI='724056816211859': storing IMEI = 35345609112072 <0000> luop.c:161 LU OP state change: NULL -> LU RECEIVED <0000> luop.c:175 724056816211859: LU OP Tx Error (cause PLMN not allowed) And after giving "cs+ps" permission, when trying to set to "none" again, I get: <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:370 127.0.0.1:60216 sending data <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60210 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60216 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 <0007> input/ipa.c:390 connected read/write <0007> input/ipa.c:346 127.0.0.1:60210 message received <0000> hlr.c:651 Error while deleting subscriber data for IMSI 724056816211859 Anyway, in it is working as expected! I'll investigate the logs further. Cheers, Rafael Diniz On 7/16/19 4:27 AM, Oliver Smith wrote: > Hello Rafael, > > you're welcome. I've just merged the new VTY command and manuals update > to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual > > So if you rebuild your osmo-hlr packages from master, you should have > the command (if I understood correctly that you are building the > packages yourself, otherwise it will be in the nightly packages tomorrow). > > After a subscriber has been created on demand, with network access mode > set to "none", you can give the subscriber access to circuit and packet > switched services as follows: > > OsmoHLR> enable > OsmoHLR# subscriber imei 35761300444848 show > ID: 1 > IMSI: 123456789023000 > MSISDN: 58192 > IMEI: 35761300444848 > CS disabled > PS disabled > OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps > OsmoHLR# subscriber imei 35761300444848 show > ID: 1 > IMSI: 123456789023000 > MSISDN: 58192 > IMEI: 35761300444848 > > Cheers, > Oliver > > On 7/15/19 3:26 PM, Rafael Diniz wrote: >> Thanks a lot, Oliver! >> >> The VTY commands for changing nam_cs and nam_ps will be useful. >> ; ) >> >> Any problems I let you know! >> >> Cheers, >> Rafael Diniz >> >> On 7/15/19 5:08 AM, Oliver Smith wrote: >>> "check-imei-rqd early", not "check-imei early" >>> >>> On 7/15/19 10:05 AM, Oliver Smith wrote: >>>> Hey Rafael, >>>> >>>> On 7/13/19 5:55 PM, Rafael Diniz wrote: >>>>> Hi Harald, >>>>> >>>>>> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote: >>>>>>> Today I'm working on updating my NuRAN unit with the new osmo stack >>>>>> >>>>>> Can you clarify which particular model/unit that is? >>>>>> >>>>>> I would assume that the 'nightly' OE packages sysmocom provides should have >>>>>> all related features. >>>>> >>>>> It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by >>>>> hand the BTS and PCU against LC 1.5 headers. >>>>> >>>>>>> I'm writing just in case someone already put online a set of config >>>>>>> files with the parameters needed by such behavior set? >>>>>>> ; ) >>>>>> >>>>>> I would be careful with full configuration files, as they contain all kinds >>>>>> of settings which may or may not do what you want. The settings for >>>>>> subcsriber-create-on-demand are only 2-3, AFAIR. >>>>>> >>>>>>> ps: I have the new splip stack working fine here, I just need to modify >>>>>>> my setup with new features to support subscriber_create_on_demand. >>>>>> >>>>>> Then please simply use the config files you have and not start with >>>>>> something else just because you need to modify one or very few lines... >>>>>> >>>>>> See https://osmocom.org/issues/2542 where Oliver actually also points to >>>>>> a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf >>>>>> >>>>>> If yo have more specific questions, feel free to raise them here :) >>>>> >>>>> Fine, I'll just adapt my config - Thanks!! >>>> >>>> As Harald pointed out, the documentation could use some more examples. >>>> I'll update the docs accordingly, but to make your life easier, here are >>>> the configuration options relevant for your use case (with sending the >>>> IMEI to the HLR). >>>> >>>> osmo-msc.cfg: >>>> msc >>>> check-imei early >>>> >>>> osmo-hlr.cfg: >>>> hlr >>>> subscriber-create-on-demand 5 none >>>> store-imei >>>> >>>> >>>> This will create 5 digit MSISDNs for the subscribers, and disable CS NAM >>>> and PS NAM by default (circuit switched and packet switched network >>>> access modes). Subscribers can't make phone calls or use cellular data, >>>> so their phones will not connect to the network, but the entry in the >>>> HLR will be created. >>>> >>>> After a new subscriber was created, it will look like this in the VTY >>>> (I've replaced the real IMEI and IMSI with zeros): >>>> >>>> OsmoHLR> enable >>>> OsmoHLR# subscriber imei 00000000000000 show >>>> ID: 1 >>>> IMSI: 000000000000000 >>>> MSISDN: 58192 <- randomly generated >>>> IMEI: 000000000000000 >>>> CS disabled >>>> PS disabled >>>> >>>> The idea is now to enable CS and PS for the IMEIs that you know. Right >>>> now, the documentation says: >>>> >>>>> In order to do that, one can set the default NAM to none and manually >>>>> approve new subscribers by enabling their nam_cs and nam_ps parameters >>>>> (e.g. over the VTY). >>>> >>>> But as I was about to create an example of how these commands look like, >>>> I realized that VTY commands for changing nam_cs and nam_ps don't >>>> actually exist yet :\ So for now, these flags have to be changed >>>> manually in the sqlite database... change nam_cs and nam_ps to 1 in the >>>> subscriber table. Maybe this is still useful for testing. I will add the >>>> missing VTY commands shortly. >>>> >>>>> >>>>> Cheers, >>>>> Rafael Diniz >>>>> >>>> >>>> Cheers, >>>> Oliver >>>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From keith at rhizomatica.org Mon Aug 5 14:27:56 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 5 Aug 2019 16:27:56 +0200 Subject: interfacing core network to SIP world Message-ID: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> Hi all, Doing some testing recently with osmo-sip-connector, I noticed a few things that seem to be important regarding the user experience of a network with osmo-sip-connector. * The osmo-sip-connector is an external MNCC handler interface for one MSC. The MSC doesn't have any information about what is in the HLR. When the osmo-sip-connector sends a call towards the MSC, the msc does a VLR lookup: vlr_subscr_find_by_msisdn() in gsm_04_08_cc.c around line 1860. if that returns false we are doing mncc_release_ind() with GSM48_CC_CAUSE_UNASSIGNED_NR.? That is getting translated into a SIP 404, which informs the caller that the number was not found. Logical but it's not correct if the subscriber does actually exist in the HLR. Actually the same problem exists when using the internal MNCC, If you call a subscriber that has just switched off their phone, you'll get an Un Assigned Number error cause. That would be incredibly confusing for the users. In rhizomatica's case, the audio played back to the caller would be "The number you have dialed does not exist, please verify it", while it should obviously be "The number you have dialed is temporarily unavailable, please try again later." What we have done there is send the caller to go physically ask ask the callee why they canceled their phone service, when all they did was switch off the phone. SO: There was some discussion about this at the devcon, I want to outline some points here, hopefully I understand it right. * The osmo-sip-connector should ask the HLR if the number exists before forwarding the call to MNCC. * There may be more than one MSC, in which case the HLR would inform osmo-sip-connector about which MSC to use. * The osmo-sip-connector could either be SIP associated, or MSC associated, that is to say: a) one osmo-sip-connector per SIP UA, sip-connector talks to HLR, and has multiple connections to MSCs (UDP then, not Unix Socket?) or b) one osmo-sip-connector per MSC, in which case the SIP UA would have to somehow query the HLR to ask where to send the call.?? Does that all sound correct? and then.. still a doubt: IIUC,? in the traditional core network. When an MSC receives a MO SETUP from a local MS, and it does not have this number in the VLR, it should be querying HLR for routing info, (which may subsequently query another HLR) no? why are we only doing VLR lookup in the MSC? Is it simply "To be implemented" ? thanks! k/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Aug 5 16:30:14 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Aug 2019 18:30:14 +0200 Subject: interfacing core network to SIP world In-Reply-To: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> References: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> Message-ID: <20190805163014.GA11119@my.box> On Mon, Aug 05, 2019 at 04:27:56PM +0200, Keith wrote: > a) one osmo-sip-connector per SIP UA, sip-connector talks to HLR, and > has multiple connections to MSCs (UDP then, not Unix Socket?) Changing to an IP protocol reminds me of jolly's proposal we talked about in december, a kind of all-new osmo-sip-connector-and-more called osmo-cc. Can't seem to find a mail reference to that ATM... I haven't heard about it since December, but even if nothing has happened, would probably be worthwhile to take a look at the protocol that jolly already has mapped out in pretty high detail. The point is that the unix domain socket connection can take assumptions that the other side is on the same CPU and simply dump (packed) data structs into it, being sure that they come out intact on the other side. If we're talking UDP there should instead be a well defined protocol involved to properly encode and decode different sized integers (and so on and so on). Simply pasting the current mncc structs into UDP would be a pretty bad hack that is guaranteed to be unportable. Related, if I'm going to incorporate proper SDP codec negotiation in the osmo-sip-connector, I should probably keep that modularly separated from the unix domain socket protocol, and we should coordinate with this idea. > IIUC,? in the traditional core network. When an MSC receives a MO SETUP > from a local MS, and it does not have this number in the VLR, it should > be querying HLR for routing info, (which may subsequently query another > HLR) no? why are we only doing VLR lookup in the MSC? Is it simply "To > be implemented" ? Yes, these are leftovers of the OsmoNITB paradigm, being "I am the entire core network". If a subscriber isn't attached, it doesn't exist. You are right that there should be a distinction between "exists" and "is currently attached", and the latter part is simply not implemented. I'm currently not sure what 3GPP spec'd mechanisms the MSC or VLR have to query the mere existence of an unattached MSISDN, but you're correct to assert that that is missing. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Mon Aug 5 17:11:07 2019 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 5 Aug 2019 19:11:07 +0200 Subject: interfacing core network to SIP world In-Reply-To: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> References: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> Message-ID: <20190805171107.GG6727@nataraja> Hi Keith, thanks for getting this discussion started! On Mon, Aug 05, 2019 at 04:27:56PM +0200, Keith wrote: > There was some discussion about this at the devcon, I want to outline > some points here, hopefully I understand it right. [I don't recall participating in that discussion, so my feedback is just general in terms of "this is how it's supposed to be"] > * The osmo-sip-connector should ask the HLR if the number exists before > forwarding the call to MNCC. ACK. In the MAP world, the external call arrives at the G-MSC which then sends a "SendRoutingInfo" message to the HLR, which responds with all kinds of data, but most importantly the IMSI and the MSRN. The MSRN is a temporarily-allocated (land line) phone number at the MSC serving the subscriber. And before the HLR can return the MSRN, it requests that MSRN from the VLR/MSC (using the PROVIDE_ROAMING_NR request). See Section 21.2.1 of 3GPP TS 29.002 for the detailed ladder diagram. Steps 3..6 are optional, so it's 1 (IAM == INVITE) /2/7/8/9 > * There may be more than one MSC, in which case the HLR would inform > osmo-sip-connector about which MSC to use. > > * The osmo-sip-connector could either be SIP associated, or MSC > associated, that is to say: > > a) one osmo-sip-connector per SIP UA, sip-connector talks to HLR, and > has multiple connections to MSCs (UDP then, not Unix Socket?) > > or > > b) one osmo-sip-connector per MSC, in which case the SIP UA would have > to somehow query the HLR to ask where to send the call.?? > > Does that all sound correct? It all sounds correct to me. Given that MNCC is a local unix domain socket interface, osmo-sip-connector always has to be MSC-colocated. So I'm for option 'b'. We'd basically need a new instance which plays the role of the G-MSC: * receive the SIP INVITE, temporarily store it * ask HLR which VLR/MSC is serving that MSISDN * wait for HLR to return IMSI + MSRN (or rather in our case, instead of MSRN maybe in our case the IP address of the osmo-sip-connector serving that MSC/VLR?) * forward the SIP INVITE to the MSC-colocated osmo-sip-connector Not sure if it would have to sit in between the extenal SIP UA and osmo-sip-connector for the remaining duration of the call, or if it's possible in SIP that the response to the INVITE is originating from a different IP/Port than the INVITE was sent to. Probably it's possible in theory, but it will confuse the hell out of other implementations and/or state-tracking firewalls, NAT, etc. > IIUC,? in the traditional core network. When an MSC receives a MO SETUP > from a local MS, and it does not have this number in the VLR, it should > be querying HLR for routing info, (which may subsequently query another > HLR) no? why are we only doing VLR lookup in the MSC? Is it simply "To > be implemented" ? What happens in a traditional core network is that the call will be routed like any other land-line (non-mobile) phone call. So basically the IW-MSC (the MO counterpart of the G-MSC) will use the SS7/ISUP or SIP network to tr to route the call to the "B" subscriber. If that subscriber happens to be another mobile subscriber, it will end up at the G-MSC of that B-network, and the MT procedure described above will happen inside the B network. So, if we implement the G-MSC functionality that you originally described, we should get that part solved, too. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Mon Aug 5 17:38:09 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 6 Aug 2019 00:38:09 +0700 Subject: interfacing core network to SIP world In-Reply-To: <20190805171107.GG6727@nataraja> References: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> <20190805171107.GG6727@nataraja> Message-ID: Hi Keith, Neels, Harald, > * The osmo-sip-connector should ask the HLR if the number > exists before forwarding the call to MNCC. I don't think it's a good idea to mix call related stuff with subscriber management in... MNCC <-> SIP converter. The same can be done by OsmoMSC on receipt of MNCC_SETUP_REQ, so if a subscriber is not in the VLR's cache, it would send OSMO_GSUP_MSGT_SEND_SUBSCR_INFO_REQ (not implemented) to the OsmoHLR, and respond to OsmoSIPCon depending on the result. > * There may be more than one MSC, in which case the HLR > would inform osmo-sip-connector about which MSC to use. In commercial networks this problem is solved by the gateway MSC, which is a kind of entry point for all mobile-terminated connections. In Osmocom CNI we decided to turn the HLR into a kind of gateway for USSD and SMS, so it's responsible for the further routing to the target MSC. We may probably want to encapsulate MNCC protocol into GSUP, like we do for SS/USSD (MAP payload) and SMS (SM TPDU), so OsmoHLR would take care about routing between the MSCs. This would require adding one more message type, similar to SS/USSD - OSMO_GSUP_MSGT_PROC_MNCC_{REQ,RES,ERR}. But then, again, we would have to overload the HLR with call related stuff, what is probably even worse than overloading OsmoSIPCon with subscriber management... > [...] sip-connector talks to HLR, and has multiple connections > to MSCs (UDP then, not Unix Socket?) Rather TCP then. We already have OsmoTRXC (Control protocol) working over UDP, so we have to deal with retransmissions ourselves. We can lose a burst, or we can lose an RTP frame, but losing call related messages is critical IMHO. With best regards, Vadim Yanitskiy. From laforge at gnumonks.org Mon Aug 5 19:05:09 2019 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 5 Aug 2019 21:05:09 +0200 Subject: interfacing core network to SIP world In-Reply-To: References: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> <20190805171107.GG6727@nataraja> Message-ID: <20190805190509.GH6727@nataraja> Hi Vadim, On Tue, Aug 06, 2019 at 12:38:09AM +0700, Vadim Yanitskiy wrote: > > * The osmo-sip-connector should ask the HLR if the number > > exists before forwarding the call to MNCC. > > I don't think it's a good idea to mix call related stuff > with subscriber management in... MNCC <-> SIP converter. > > The same can be done by OsmoMSC on receipt of MNCC_SETUP_REQ, > so if a subscriber is not in the VLR's cache, it would send > OSMO_GSUP_MSGT_SEND_SUBSCR_INFO_REQ (not implemented) to the > OsmoHLR, and respond to OsmoSIPCon depending on the result. This is an interesting idea, though one would have to think more about what kind of implications this has in terms of staying as compatible as possible with what happens in MAP based traditional networks. In the end, whatever we do should be "easily translateable" to the MAP+ISUP domain, if ever needed. There are many possible configurations, such as: 1) Full Osmocom CNI networks wanting to interact with external entities / the SIP world 2) OsmoMSC with a GSUP-DIAMETER or GSUP-MAP converter attached to a real HLR/HSS. I don't think we have to consider non-Osmocom MSC with OsmoHLR, as that doesn't make sense (we don't speak MAP and don't do most of what people would exect from a real HLR Lucikily, the RAN doesn't impact any of this, so it doesn't matter whwether the BSC/RNC/HNBGW attached to the MSC is Osmocom or non-Osmocom. > > * There may be more than one MSC, in which case the HLR > > would inform osmo-sip-connector about which MSC to use. > > In commercial networks this problem is solved by the gateway > MSC, which is a kind of entry point for all mobile-terminated > connections. Well, only for MT calls arriving either via ISUP or SIP[-I], not really for anything else. Not for SMS, not for MAP signaling. > In Osmocom CNI we decided to turn the HLR into a > kind of gateway for USSD and SMS, so it's responsible for the > further routing to the target MSC. This is natural as both USSD and SMS are transported over GSM signaling plane and hence MAP in traditional networks. It doesn't mean that this has to be the same for call control. > We may probably want to encapsulate MNCC protocol into GSUP, > like we do for SS/USSD (MAP payload) and SMS (SM TPDU), so > OsmoHLR would take care about routing between the MSCs. This > would require adding one more message type, similar to > SS/USSD - OSMO_GSUP_MSGT_PROC_MNCC_{REQ,RES,ERR}. I really don't like that idea, sorry. Way too far from how 3GPP networks work. > But then, again, we would have to overload the HLR with call > related stuff, what is probably even worse than overloading > OsmoSIPCon with subscriber management... What about a dedicated G-MSC process as I suggested in my other mail? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Mon Aug 5 19:40:28 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Aug 2019 21:40:28 +0200 Subject: interfacing core network to SIP world In-Reply-To: <20190805163014.GA11119@my.box> References: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> <20190805163014.GA11119@my.box> Message-ID: <20190805194028.GB11119@my.box> On Mon, Aug 05, 2019 at 06:30:14PM +0200, Neels Hofmeyr wrote: > > IIUC,? in the traditional core network. When an MSC receives a MO SETUP > > from a local MS, and it does not have this number in the VLR, it should > > be querying HLR for routing info, (which may subsequently query another > > HLR) no? why are we only doing VLR lookup in the MSC? Is it simply "To > > be implemented" ? > > Yes, these are leftovers of the OsmoNITB paradigm, being "I am the entire core > network". If a subscriber isn't attached, it doesn't exist. Let me rephrase: back then the subscriber database was in the OsmoNITB and non-attached subscribers did exist. The inability to recognise unattached subscribers as existing crept in during the separation of the HLR. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Mon Aug 5 19:50:17 2019 From: keith at rhizomatica.org (Keith) Date: Mon, 5 Aug 2019 21:50:17 +0200 Subject: interfacing core network to SIP world In-Reply-To: <20190805171107.GG6727@nataraja> References: <5814e402-e84f-1853-762f-1d8c22abb2a7@rhizomatica.org> <20190805171107.GG6727@nataraja> Message-ID: <83773ea4-9c90-2e44-94c6-4b2b297d1439@rhizomatica.org> On 05/08/2019 19:11, Harald Welte wrote: > Hi Keith, > > thanks for getting this discussion started! :) > [I don't recall participating in that discussion, It was somewhat informal. >> * The osmo-sip-connector should ask the HLR if the number exists before >> forwarding the call to MNCC. > ACK. In the MAP world, the external call arrives at the G-MSC which > then sends a "SendRoutingInfo" message to the HLR, which responds with > all kinds of data, but most importantly the IMSI and the MSRN. The MSRN > is a temporarily-allocated (land line) phone number at the MSC serving the > subscriber. In the rhizomatica world, the call arrives at the PBX, (freeswitch in our case), on the "external" profile. The simplest thing freeswitch can do is to just bridge the call to the "internal" profile - the one facing the osmo-sip-connector, but in between? we do checking of the numbers, transcoding, accounting etc.. In our case, what freeswitch does is to call a python script which ultimately tells freeswitch where to bridge the call to. I see I'm getting a bit specific to rhizomatica use case, but do we have a python GSUP client? > > We'd basically need a new instance which plays the role of the G-MSC: > * receive the SIP INVITE, temporarily store it > * ask HLR which VLR/MSC is serving that MSISDN > * wait for HLR to return IMSI + MSRN (or rather in our case, instead of > MSRN maybe in our case the IP address of the osmo-sip-connector > serving that MSC/VLR?) This python could be our G-MSC. it could ask the HLR for the MSRN, or indeed do some funky ARP-style broadcast lookups that were discussed at one point, and based on that, do as you say: > * forward the SIP INVITE to the MSC-colocated osmo-sip-connector but this G-MSC inside python, inside freeswitch would not have to store the INVITE, but rather find out what the IP address is and then just send this info back to freeswitch. So yes, this creates a need to have some kind of PBX that's capable of running scripts in between the SIP "world" and the osmo-sip-connector but I do wonder sometimes about whether we should try to make something that's going to be SIP facing that is expected to handle everything a SIP UA might throw at it, given that there are already many tools out there that one can (and probably wants to) use to help bridge SIP to the core network. > Not sure if it would have to sit in between the extenal SIP UA and > osmo-sip-connector for the remaining duration of the call, I don't think so. I may not have the right terminology here but I'm pretty sure SIP is stateless. (I restart kamailio all the time and it does not affect ongoing calls) An in-dialog message can come from anywhere, as long as it has the headers that identify the Call-ID. I think this is what the Contact: header is for. > or if it's > possible in SIP that the response to the INVITE is originating from > a different IP/Port than the INVITE was sent to. Ah, I see. so that would be an in-transaction request, and I'm not sure about that being able to come from a different IP. > Probably it's > possible in theory, but it will confuse the hell out of other > implementations and/or state-tracking firewalls, NAT, etc. > >> IIUC,? in the traditional core network. When an MSC receives a MO SETUP >> from a local MS, and it does not have this number in the VLR, it should >> be querying HLR for routing info, (which may subsequently query another >> HLR) no? why are we only doing VLR lookup in the MSC? Is it simply "To >> be implemented" ? > What happens in a traditional core network is that the call will > be routed like any other land-line (non-mobile) phone call. So > basically the IW-MSC (the MO counterpart of the G-MSC) will use the > SS7/ISUP or SIP network to tr to route the call to the "B" subscriber. > If that subscriber happens to be another mobile subscriber, it will end > up at the G-MSC of that B-network, and the MT procedure described above > will happen inside the B network. > > So, if we implement the G-MSC functionality that you originally > described, we should get that part solved, too. OK, I think I'm already talking about too many things to also comment on this case. I think Vadim has an interesting proposal to deal with the MO case. k/ From roch at petaouchnok.org Wed Aug 7 13:46:06 2019 From: roch at petaouchnok.org (=?UTF-8?Q?Roch=2DAlexandre_Nomin=C3=A9?=) Date: Wed, 7 Aug 2019 06:46:06 -0700 Subject: Failure to activate sigtran stack when using IPA on osmo-bsc Message-ID: Hi, I?m trying to configure osmo-bsc to connect to an IPA based MSC and get a failure when activating the sigtran stack. Here?s the log: root at sysmobts-v2:/etc/osmocom# osmo-bsc -c /etc/osmocom/osmo-bsc.cfg <001d> ../../git/src/osmo_ss7.c:1269 0: ASP Restart for server not implemented yet! % Ignoring deprecated logging level everything % Ignoring deprecated logging level everything % dyn_ts_allow_tch_f is deprecated, rather use msc/codec-list to pick codecs <0011> ../../../git/src/vty/telnet_interface.c:104 telnet at 0.0.0.0 4242 <0013> ../../git/src/input/ipaccess.c:853 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports <0018> ../../../git/src/ctrl/control_if.c:866 CTRL at 0.0.0.0 4249 <0008> ../../../git/src/osmo-bsc/osmo_bsc_sigtran.c:427 Initializing SCCP connection to MSC msc-0 <0008> ../../../git/src/osmo-bsc/osmo_bsc_sigtran.c:437 CS7 Instance identifier, A-Interface: 0 <001e> ../../git/src/sccp_user.c:397 msc-0: Using SS7 instance 0, pc:0.23.3 <001e> ../../git/src/sccp_user.c:411 msc-0: Creating AS instance <0005> ../../../git/src/osmo-bsc/osmo_bsc_main.c:504 Failed to initalize sigtran backhaul. I used the configuration posted by Harald part of ticker https://osmocom.org/issues/2544 https://osmocom.org/attachments/3154/osmo-bsc.cfg.ipa and get the same result. How can I troubleshoot further in order to know what?s happening? Best regards Roch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Aug 7 18:41:27 2019 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Aug 2019 20:41:27 +0200 Subject: Failure to activate sigtran stack when using IPA on osmo-bsc In-Reply-To: References: Message-ID: <20190807184127.GG22334@nataraja> Hi Roch, my immediate response is that I don't really know what's the cause. We are testing the SCCPlite interface of osmo-bsc in our automatic tests every night, so I presume it's not fundamentally broken but maybe just some unexpected differences in configuration. The config file used in the tests can be seen at http://git.osmocom.org/docker-playground/tree/ttcn3-bsc-test/sccplite/osmo-bsc.cfg while the test suite (simulating MSC) uses this config: http://git.osmocom.org/docker-playground/tree/ttcn3-bsc-test/sccplite/BSC_Tests.cfg Maybe this helps to spot the differences? In case of doubt: * is there anything TCP/IPA at all? * can you post your config (at least the related sections)? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pespin at sysmocom.de Thu Aug 8 16:13:22 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 8 Aug 2019 18:13:22 +0200 Subject: 201908 Osmocom CNI Release Message-ID: Hi, I have been releasing new tagged versions of Osmocom CNI (Osmocom Cellular Network Infrastructure) related projects over last days this week. New released versions: libosmocore 1.2.0 libosmo-abis 0.7.0 libosmo-netif 0.6.0 libusrp 3.4.4 libgtpnl 1.2.1 osmo-trx 1.1.1 osmo-pcu 0.7.0 osmo-ggsn 1.4.0 osmo-pcap 0.1.1 libasn1c 0.9.32 libsmpp34 1.14.0 osmo-bts 1.1.0 osmo-hlr 1.1.0 libosmo-sccp 1.1.0 osmo-mgw 1.6.0 osmo-iuh 0.5.0 osmo-bsc 1.5.0 osmo-msc 1.5.0 osmo-sgsn 1.5.0 openbsc 1.3.1 osmo-sip-connector 1.3.0 Some patch releases may come tomorrow in the event some unexpected error shows up during repository build process. Please, to get the latest tags applied, remember to fetch them and clean up the .version related files. Something like this will do the job (be careful, git clean may remove some of your changes in the git repo): $ git fetch --tags; git clean -fxd Updated tags in OE meta-telephony 201705 will come during current ot next week. Regards, -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From mykola at pentonet.com Wed Aug 14 10:14:31 2019 From: mykola at pentonet.com (Mykola Shchetinin) Date: Wed, 14 Aug 2019 13:14:31 +0300 Subject: 3G handover (+ 35C3 experience) Message-ID: Hello, dear Community, Has anybody tested how cell handover works in 3G with Osmocom software? 3G network was set up for 35C3: I would like to ask whether anybody noticed if a cell was reselected "smoothly" by the phone when the user was moving or it was like a drop of a connection and reconnection to a different cell afterwards? So, basically, the question is: Does the handover work in 3G Osmocom? (single HNBGW and MSC/SGSN) Thanks. Kind regards, Mykola From nhofmeyr at sysmocom.de Wed Aug 14 14:46:44 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Aug 2019 16:46:44 +0200 Subject: 3G handover (+ 35C3 experience) In-Reply-To: References: Message-ID: <20190814144644.GA27905@my.box> On Wed, Aug 14, 2019 at 01:14:31PM +0300, Mykola Shchetinin wrote: > Hello, dear Community, > > Has anybody tested how cell handover works in 3G with Osmocom software? I am quite positive that no 3G handover could have been possible, because osmo-msc would need to (instruct its MGW to) redirect the RTP to a different femto cell, and no such code is implemented. I assume 3G handover when using femto cells (with an RNC each) uses the BSSMAP Handover Required (etc.) messages. We have only recently added inter-BSC handover on 2G, meaning that we have support for these BSSMAP Handover messages only since about May this year. It was duly tested for 2G, but so far there was no funding to investigate inter-RNC handover, i.e. on 3G. With the new BSSMAP Handover messages implementation in osmo-msc, we do have a good chance to enable inter-RNC handover without too much effort, only someone needs to spend time looking into it and testing. The first step would be to tickle an actual femto cell (e.g. nano3G) into sending a BSSMAP Handover Required to the MSC; then one could play through the handover procedure and implement any missing bits for the 3G code paths in osmo-msc. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Thu Aug 15 08:48:01 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 15 Aug 2019 10:48:01 +0200 Subject: 3G handover (+ 35C3 experience) In-Reply-To: <20190814144644.GA27905@my.box> References: <20190814144644.GA27905@my.box> Message-ID: <20190815084801.GJ3979@nataraja> Hi Neels, On Wed, Aug 14, 2019 at 04:46:44PM +0200, Neels Hofmeyr wrote: > The first step would be to tickle an actual femto cell (e.g. nano3G) > into sending a BSSMAP Handover Required to the MSC; then one could > play through the handover procedure and implement any missing bits for > the 3G code paths in osmo-msc. Just to avoid confusion: s/BSSMAP/RANAP/g on the 3G side. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Aug 15 19:27:05 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 15 Aug 2019 21:27:05 +0200 Subject: Diameter to GSUP translator Message-ID: <20190815192704.GH2319@nataraja> Hi all, as some of you know, I've been working on a small diameteer to GSUP translator, which allows us to connect a MME like nextepc-mme against osmo-hlr. The code is still a big ugly hack and needs cleanup, but today I finally got it to work for authentication and location update. In case anyone is curious how this looks like, I've attached a pcap file that includes the S1AP, DIAMETER, GSUP and GTPv2C traffic of an initial LTE registration happening on a setup running the following programs: * nextepc MME, SGW, PGW, PCRF * osmo_diameter2gsup * osmo-hlr The point of this is to enable networks to run a shared subscriber database for 2G, 3G and 4G, which is a very typical use case if you have existing Osmocom based network and want to extend it with LTE. We will test this translator extensively at the upcoming CCC Camp, where all three (2G, 3G and 4G) networks will be running. The sad part is that we don't yet have a common GGSN and P-GW, which means that the PDP/PDN context including the IP address will not persist when moving between 2G+3G on the one hand side and 4G on the other hand side. I expect to get the commit history cleaned up and plan to push the [Erlang] code to git.osmocom.org tomorrow. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Aug 15 19:27:49 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 15 Aug 2019 21:27:49 +0200 Subject: Diameter to GSUP translator In-Reply-To: <20190815192704.GH2319@nataraja> References: <20190815192704.GH2319@nataraja> Message-ID: <20190815192749.GI2319@nataraja> On Thu, Aug 15, 2019 at 09:27:04PM +0200, Harald Welte wrote: > In case anyone is curious how this looks like, I've attached a pcap file [...] Attachment was missing, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: 20190815-diameter2gsup.pcap Type: application/vnd.tcpdump.pcap Size: 5847 bytes Desc: not available URL: From laforge at gnumonks.org Tue Aug 20 07:04:57 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 20 Aug 2019 09:04:57 +0200 Subject: osmo-hlr VTY tests failing on master Message-ID: <20190820070457.GG2319@nataraja> FYI. I don't see any commit until the last one from Pau on August 13. It could of course also be a change in libosmocore? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An embedded message was scrubbed... From: jenkins at lists.osmocom.org Subject: Build failed in Jenkins: master-osmo-hlr ? a1=default,a2=default,a3=default,a4=default,osmocom-master-debian9 #2988 Date: Tue, 20 Aug 2019 00:54:30 +0000 (UTC) Size: 13112 URL: From pespin at sysmocom.de Tue Aug 20 08:43:26 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 20 Aug 2019 10:43:26 +0200 Subject: osmo-hlr VTY tests failing on master In-Reply-To: <20190820070457.GG2319@nataraja> References: <20190820070457.GG2319@nataraja> Message-ID: <4efd15b1-88f9-c968-f09e-2230656c35e3@sysmocom.de> Hi, it seems related to libosmocore d0b3b9edac978c91bf84aa2537aa24426685b1fb, where logp VTY command is added Mismatch: Expect: ' show talloc-context (application|all) (full|brief|DEPTH)' Got: ' logp (main|db|auc|ss|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf|lrspro) (debug|info|notice|error|fatal) .LOGMESSAGE' The problem is osmo-hlr test_node.vty doesn't skip library-related commands, so updating the lib can trigger this kind of issues. Quick fix is in libosmocore. Move the new command upwards: Expected: [ OsmoHLR> list show version show online-help list exit help enable terminal length <0-512> terminal no length who show history logging enable ... show logging vty show alarms <------ logp appears here after "show alarms" nowadays. show talloc-context (application|all) (full|brief|DEPTH) show talloc-context (application|all) (full|brief|DEPTH) tree ADDRESS show talloc-context (application|all) (full|brief|DEPTH) filter REGEXP show stats show stats level (global|peer|subscriber) show asciidoc counters show rate-counters show gsup-connections subscriber (imsi|msisdn|id|imei) IDENT show show subscriber (imsi|msisdn|id|imei) IDENT ] I submitted a patch to fix the issue: https://gerrit.osmocom.org/c/libosmocore/+/15244 vty: Register logp cmd next to logging commands -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From osmith at sysmocom.de Wed Aug 21 07:57:45 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Wed, 21 Aug 2019 09:57:45 +0200 Subject: Sample configs for reproducing osmo-nitb behaviour with the split stack In-Reply-To: <8c2ba432-f4fe-2c5b-026a-6252a43c0673@rhizomatica.org> References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org> <20190713014203.GX3429@nataraja> <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de> <202c6769-8f1d-c5f5-2938-f22f549c4105@sysmocom.de> <8c2ba432-f4fe-2c5b-026a-6252a43c0673@rhizomatica.org> Message-ID: <7cbad10f-a18d-b2db-2d15-4095ee7b99fe@sysmocom.de> Hello Rafael, sorry that it took me some time to answer, I was on holiday. On 8/3/19 7:17 PM, Rafael Diniz wrote: > When a phone try to connect (not present in the hlr db yet): > > 0000> hlr.c:204 IMSI='724056816211859': Creating subscriber on demand > <0000> hlr.c:220 IMSI='724056816211859': Successfully assigned > MSISDN='76342' > <0003> hlr.c:510 IMSI='724056816211859': storing IMEI = 35345609112072 > > <0000> luop.c:161 LU OP state change: NULL -> LU RECEIVED > <0000> luop.c:175 724056816211859: LU OP Tx Error (cause PLMN not allowed) This is expected if you have set the default access mode to "none" (something like "subscriber-create-on-demand 5 none" in osmo-hlr.cfg). The new subscriber was created, but a location update request fails because it is not allowed to access the (circuit or packet switched) network: https://git.osmocom.org/osmo-hlr/tree/src/hlr.c?id=28f0774e341c3dbe1045ca61a1dd3f1e903f55d0#n382 > And after giving "cs+ps" permission, when trying to set to "none" again, > I get: > > <0000> hlr.c:651 Error while deleting subscriber data for IMSI > 724056816211859 > <0007> input/ipa.c:370 127.0.0.1:60216 sending data > <0007> input/ipa.c:390 connected read/write > <0007> input/ipa.c:346 127.0.0.1:60210 message received > <0000> hlr.c:651 Error while deleting subscriber data for IMSI > 724056816211859 > <0007> input/ipa.c:390 connected read/write > <0007> input/ipa.c:346 127.0.0.1:60216 message received > <0000> hlr.c:651 Error while deleting subscriber data for IMSI > 724056816211859 > <0007> input/ipa.c:390 connected read/write > <0007> input/ipa.c:346 127.0.0.1:60210 message received > <0000> hlr.c:651 Error while deleting subscriber data for IMSI > 724056816211859 This looks like a bug. I've pasted your report here (please extend if you have more details): https://osmocom.org/issues/4163 > Anyway, in it is working as expected! I'll investigate the logs further. There is a word missing, but it seems that for the most part it is working as expected? ;) Thanks for the feedback! Cheers, Oliver > > Cheers, > Rafael Diniz > > > On 7/16/19 4:27 AM, Oliver Smith wrote: >> Hello Rafael, >> >> you're welcome. I've just merged the new VTY command and manuals update >> to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual >> >> So if you rebuild your osmo-hlr packages from master, you should have >> the command (if I understood correctly that you are building the >> packages yourself, otherwise it will be in the nightly packages tomorrow). >> >> After a subscriber has been created on demand, with network access mode >> set to "none", you can give the subscriber access to circuit and packet >> switched services as follows: >> >> OsmoHLR> enable >> OsmoHLR# subscriber imei 35761300444848 show >> ID: 1 >> IMSI: 123456789023000 >> MSISDN: 58192 >> IMEI: 35761300444848 >> CS disabled >> PS disabled >> OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps >> OsmoHLR# subscriber imei 35761300444848 show >> ID: 1 >> IMSI: 123456789023000 >> MSISDN: 58192 >> IMEI: 35761300444848 >> >> Cheers, >> Oliver >> >> On 7/15/19 3:26 PM, Rafael Diniz wrote: >>> Thanks a lot, Oliver! >>> >>> The VTY commands for changing nam_cs and nam_ps will be useful. >>> ; ) >>> >>> Any problems I let you know! >>> >>> Cheers, >>> Rafael Diniz >>> >>> On 7/15/19 5:08 AM, Oliver Smith wrote: >>>> "check-imei-rqd early", not "check-imei early" >>>> >>>> On 7/15/19 10:05 AM, Oliver Smith wrote: >>>>> Hey Rafael, >>>>> >>>>> On 7/13/19 5:55 PM, Rafael Diniz wrote: >>>>>> Hi Harald, >>>>>> >>>>>>> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote: >>>>>>>> Today I'm working on updating my NuRAN unit with the new osmo stack >>>>>>> >>>>>>> Can you clarify which particular model/unit that is? >>>>>>> >>>>>>> I would assume that the 'nightly' OE packages sysmocom provides should have >>>>>>> all related features. >>>>>> >>>>>> It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by >>>>>> hand the BTS and PCU against LC 1.5 headers. >>>>>> >>>>>>>> I'm writing just in case someone already put online a set of config >>>>>>>> files with the parameters needed by such behavior set? >>>>>>>> ; ) >>>>>>> >>>>>>> I would be careful with full configuration files, as they contain all kinds >>>>>>> of settings which may or may not do what you want. The settings for >>>>>>> subcsriber-create-on-demand are only 2-3, AFAIR. >>>>>>> >>>>>>>> ps: I have the new splip stack working fine here, I just need to modify >>>>>>>> my setup with new features to support subscriber_create_on_demand. >>>>>>> >>>>>>> Then please simply use the config files you have and not start with >>>>>>> something else just because you need to modify one or very few lines... >>>>>>> >>>>>>> See https://osmocom.org/issues/2542 where Oliver actually also points to >>>>>>> a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf >>>>>>> >>>>>>> If yo have more specific questions, feel free to raise them here :) >>>>>> >>>>>> Fine, I'll just adapt my config - Thanks!! >>>>> >>>>> As Harald pointed out, the documentation could use some more examples. >>>>> I'll update the docs accordingly, but to make your life easier, here are >>>>> the configuration options relevant for your use case (with sending the >>>>> IMEI to the HLR). >>>>> >>>>> osmo-msc.cfg: >>>>> msc >>>>> check-imei early >>>>> >>>>> osmo-hlr.cfg: >>>>> hlr >>>>> subscriber-create-on-demand 5 none >>>>> store-imei >>>>> >>>>> >>>>> This will create 5 digit MSISDNs for the subscribers, and disable CS NAM >>>>> and PS NAM by default (circuit switched and packet switched network >>>>> access modes). Subscribers can't make phone calls or use cellular data, >>>>> so their phones will not connect to the network, but the entry in the >>>>> HLR will be created. >>>>> >>>>> After a new subscriber was created, it will look like this in the VTY >>>>> (I've replaced the real IMEI and IMSI with zeros): >>>>> >>>>> OsmoHLR> enable >>>>> OsmoHLR# subscriber imei 00000000000000 show >>>>> ID: 1 >>>>> IMSI: 000000000000000 >>>>> MSISDN: 58192 <- randomly generated >>>>> IMEI: 000000000000000 >>>>> CS disabled >>>>> PS disabled >>>>> >>>>> The idea is now to enable CS and PS for the IMEIs that you know. Right >>>>> now, the documentation says: >>>>> >>>>>> In order to do that, one can set the default NAM to none and manually >>>>>> approve new subscribers by enabling their nam_cs and nam_ps parameters >>>>>> (e.g. over the VTY). >>>>> >>>>> But as I was about to create an example of how these commands look like, >>>>> I realized that VTY commands for changing nam_cs and nam_ps don't >>>>> actually exist yet :\ So for now, these flags have to be changed >>>>> manually in the sqlite database... change nam_cs and nam_ps to 1 in the >>>>> subscriber table. Maybe this is still useful for testing. I will add the >>>>> missing VTY commands shortly. >>>>> >>>>>> >>>>>> Cheers, >>>>>> Rafael Diniz >>>>>> >>>>> >>>>> Cheers, >>>>> Oliver >>>>> >>>> >>> >> > -- - Oliver Smith https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From rafael at rhizomatica.org Fri Aug 23 01:43:31 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Thu, 22 Aug 2019 22:43:31 -0300 Subject: Sample configs for reproducing osmo-nitb behaviour with the split stack In-Reply-To: <7cbad10f-a18d-b2db-2d15-4095ee7b99fe@sysmocom.de> References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org> <20190713014203.GX3429@nataraja> <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de> <202c6769-8f1d-c5f5-2938-f22f549c4105@sysmocom.de> <8c2ba432-f4fe-2c5b-026a-6252a43c0673@rhizomatica.org> <7cbad10f-a18d-b2db-2d15-4095ee7b99fe@sysmocom.de> Message-ID: Hi Oliver, > sorry that it took me some time to answer, I was on holiday. soon it will be my holiday too! > This looks like a bug. I've pasted your report here (please extend if > you have more details): https://osmocom.org/issues/4163 I will extend the report and take a look in the code to see what is going on. >> Anyway, in it is working as expected! I'll investigate the logs further. > > There is a word missing, but it seems that for the most part it is > working as expected? ;) Sorry for the typo - It is working as expected, yes! ; ) Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: