From djks74 at gmail.com Wed Jan 1 14:50:21 2020 From: djks74 at gmail.com (Sandi Suhendro) Date: Wed, 1 Jan 2020 21:50:21 +0700 Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!! In-Reply-To: References: Message-ID: Please try this and let me know. extensions.conf: (make sure you dial call with 5 digits since you make 5X.) [gsmsubscriber] exten=>_XXXXX,1,Answer() exten=>_XXXXX,2,Dial(SIP/GSM/${EXTEN}) exten=>_XXXXX,n,Hangup sip-custom-contexts.conf : change port to 5069 [GSM] type=friend host=127.0.0.1 dtmfmode=rfc2833 canreinvite=no disallow=all allow=gsm context=gsmsubscriber port=5069 osmo-sip-connector.cfg : app mncc socket-path /tmp/bsc_mncc sip local 127.0.0.1 5069 remote 127.0.0.1 5060 This should work actually and you can read here https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_with_Asterisk ps: sometime you need to adjust port with sip-connector. Let me know! Thanks. On Wed, Jan 1, 2020 at 5:34 AM Garrett Allen wrote: > Yes all works fine when not launching the setup with asterisk the MGW can > route calls just fine. Below are the configs for sip-custom-contexts.conf > and extensions.conf > > [GSM] > type=friend > host=127.0.0.1 > dtmfmode=rfc2833 > canreinvite=no > disallow=all > allow=gsm > context=gsmsubscriber > port=5062 > > extensions.conf is quite large so i will omit all that was there by > default and included is what i have added directly to the end of the file > > [gsmsubscriber] > exten=>_xxxxx,1,Dial(SIP/GSM/${EXTEN}) > exten=>_XXXXX,n,Playback(vm-nobodyavail) > exten=>_xxxxx,n,HangUp > > sip.conf is again default with just this library include at the end of the > file > > #include sip-custom-contexts.conf > > Thanks for the assistance > > > > > > nat=yes > > On Tue, 31 Dec 2019 at 16:16, Sandi Suhendro wrote: > >> Can you describe more your configuration and setup with asterisk? your >> sip connector settings, etc.. ? >> Sip.conf, sip-custom-contexts, extensions.conf ? >> >> You said it it works when using osmo-mgw for voice? >> >> On Tue, Dec 31, 2019 at 9:24 PM Garrett Allen < >> garrett.allen1990 at gmail.com> wrote: >> >>> Unfortunately it made no difference adding nat=yes to the asterisk >>> config. >>> >>> On Tue, 31 Dec 2019, 11:13 Sandi Suhendro, wrote: >>> >>>> Have you try adding : >>>> >>>> nat=yes >>>> >>>> ??? >>>> >>>> :) >>>> >>>> regards, >>>> Sandi / DUO >>>> >>>> On Tue, Dec 31, 2019, 09:20 Garrett Allen >>>> wrote: >>>> >>>>> Hi All >>>>> >>>>> I've used osmo-bsc in non standalone mode ie seperate components and >>>>> all works fine voice and sms work as should. However when introducing. sip >>>>> connector with asterisk the handsets will not make voice calls they just >>>>> constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms >>>>> on raspbian 10 below is Asterisk config. Any help would be appreciated. >>>>> >>>>> Gar >>>>> >>>>> [GSM] >>>>> type=friend >>>>> host=127.0.0.1 >>>>> dtmfmode=rfc2833 >>>>> canreinvite=no >>>>> disallow=all >>>>> allow=gsm >>>>> context=gsmsubscriber >>>>> port=5062 >>>>> >>>>> >> >> -- >> Best Regards, >> Sandi >> >> -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Wed Jan 1 15:13:09 2020 From: keith at rhizomatica.org (Keith) Date: Wed, 1 Jan 2020 16:13:09 +0100 Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!! In-Reply-To: References: Message-ID: <823620c3-8f29-0956-2789-79bfaf69ddaf@rhizomatica.org> On 31/12/2019 23:34, Garrett Allen wrote: > Yes all works fine when not launching the setup with asterisk the MGW > can route calls just fine. Below are the configs for > sip-custom-contexts.conf and extensions.conf Garrett, what would probably most help people to help you would be a pcap of traffic on the interface between your asterisk and osmo components. probably the loopback if you are running everything on the same box. Maybe just bring up the system, start a capture on all interfaces, make the call attempt and stop capture. should be enough. if it's more than a few kB, you can be nice to the mailing list (and the c02 levels!) by posting the pcap someplace and sending a link, rather than sending an attachment to everyone. best, k/ From garrett.allen1990 at gmail.com Wed Jan 1 21:50:49 2020 From: garrett.allen1990 at gmail.com (Garrett Allen) Date: Wed, 1 Jan 2020 21:50:49 +0000 Subject: Osmo Bsc (Seperate CNI) with Asterisk network busy!! In-Reply-To: <823620c3-8f29-0956-2789-79bfaf69ddaf@rhizomatica.org> References: <823620c3-8f29-0956-2789-79bfaf69ddaf@rhizomatica.org> Message-ID: Thank you both for your help, I managed to find my mistake while looking through the sip-connector config. All works great now :) have a happy new year :) Garrett On Wed, 1 Jan 2020, 15:13 Keith, wrote: > > On 31/12/2019 23:34, Garrett Allen wrote: > > Yes all works fine when not launching the setup with asterisk the MGW > > can route calls just fine. Below are the configs for > > sip-custom-contexts.conf and extensions.conf > > Garrett, what would probably most help people to help you would be a > pcap of traffic on the interface between your asterisk and osmo > components. probably the loopback if you are running everything on the > same box. > > Maybe just bring up the system, start a capture on all interfaces, make > the call attempt and stop capture. should be enough. if it's more than a > few kB, you can be nice to the mailing list (and the c02 levels!) by > posting the pcap someplace and sending a link, rather than sending an > attachment to everyone. > > best, > > k/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Tue Jan 7 14:13:19 2020 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 7 Jan 2020 15:13:19 +0100 Subject: Osmocom CNI release 202001 Message-ID: Dear all, I'm pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. libosmocore 1.3.0 osmo-gsm-manuals 0.3.0 osmo-pcap 0.1.2 osmo-ggsn 1.5.0 libosmo-abis 0.8.0 libosmo-netif 0.7.0 libosmo-sccp 1.2.0 osmo-sip-connector 1.4.0 osmo-hlr 1.2.0 osmo-trx 1.2.0 osmo-bts 1.2.0 osmo-pcu 0.8.0 osmo-mgw 1.7.0 osmo-iuh 0.6.0 osmo-bsc 1.6.0 osmo-msc 1.6.0 osmo-sgsn 1.6.0 openbsc 1.3.2 Tags for related Openembedded meta layers have also been updated and are waiting to be merged, hopefully today, and will be available in branch 201705. Other related components such as libgtpnl or libsmpp34 had no development at all since last release cycle so they don't show up here. As a reminder, last release cycle was done around August 2019. Have fun, -- - 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 laforge at osmocom.org Tue Jan 7 17:35:15 2020 From: laforge at osmocom.org (Harald Welte) Date: Tue, 7 Jan 2020 18:35:15 +0100 Subject: Osmocom CNI release 202001 In-Reply-To: References: Message-ID: <20200107173515.GL4127@nataraja> Hi Pau, On Tue, Jan 07, 2020 at 03:13:19PM +0100, Pau Espin Pedrol wrote: > I'm pleased to announce new tagged releases for Osmocom Cellular Network > Infrastructure components. Great, Thanks! Will you also write a related news item summarizing the most relevant changes? See e.g. https://osmocom.org/news/113 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 Wed Jan 8 17:48:33 2020 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 8 Jan 2020 18:48:33 +0100 Subject: Osmocom CNI release 202001 In-Reply-To: <20200107173515.GL4127@nataraja> References: <20200107173515.GL4127@nataraja> Message-ID: <68324a1a-631d-8bde-12c0-10c5b6414883@sysmocom.de> Hi all, You can find the related News entry here: https://osmocom.org/news/123 BTW, not sure why redmine doesn't want to convert "[[libosmo-ranap:osmo-iuh (+ OsmoHNBGW)]]" in the table as a link. -- - 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 laforge at osmocom.org Tue Jan 21 19:23:42 2020 From: laforge at osmocom.org (Harald Welte) Date: Tue, 21 Jan 2020 20:23:42 +0100 Subject: build2.osmocom.org hardware replacement Message-ID: <20200121192342.GF2351880@nataraja> Dear Osmocom community, in recent weeks (at least since mid-december) we've had some stability issues with build2.osmocom.org, the physical machine that runs the build2-deb8build-ansible and build2-deb9build-ansible LXCs used heavily by our jenkins. I've had to reset the machine, and now we finally have asked the hosting company to perform a hardware replacement. This has happened about 3 hours ago, and I hope the stability problems are gone now. Let me know if you still see anything odd related to build2. 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 osmith at sysmocom.de Thu Jan 23 11:09:47 2020 From: osmith at sysmocom.de (Oliver Smith) Date: Thu, 23 Jan 2020 12:09:47 +0100 Subject: Feedback to GSUP Proxy Cache concept Message-ID: Hi Neels, > D-GSM proxy cache -- if you have the time, feedback on this design document would be appreciated: http://git.osmocom.org/osmo-hlr/commit/?h=neels/dgsm&id=8071c561405a031f2048c4505d9ae20f3c14af4e > (when that commit is checked out, building osmo-hlr with manuals enabled should render the ladder diagrams in proxy_cache.adoc, which illustrate what I'm planning to implement) > (and disregard "(7) Skip the Insert Subscriber Data", as explained in the prose) I like that the key of the home HLR is not shared with the proxy HLRs. All in all, it sounds like a very smart solution! Some notes: * In the ladder diagrams, it shows that the AKAs are cached in both the MSC and the HLR. Why not just cache them in the HLR? * It might be a good idea to make AKA reuse optional with a VTY config option? * Potential use case: phone is home in village A, gets turned off, owner travels to village B with the phone, the link to village A is down. Phone gets turned on, then there will be no AKAs cached in village B's (proxy) HLR and the LU will fail. But there does not seem a way around this without sharing the keys (or without spaming other HLRs with AKAs for all subscribers in the HLR that they might use in the future, but that would just waste traffic). Regards, 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 nhofmeyr at sysmocom.de Thu Jan 23 16:32:23 2020 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 23 Jan 2020 17:32:23 +0100 Subject: Feedback to GSUP Proxy Cache concept In-Reply-To: References: Message-ID: <20200123163223.GA13314@my.box> Thanks for your feedback! On Thu, Jan 23, 2020 at 12:09:47PM +0100, Oliver Smith wrote: > Some notes: > * In the ladder diagrams, it shows that the AKAs are cached in both the > MSC and the HLR. Why not just cache them in the HLR? The MSC is the usual place where (normally 5) auth tuples are cached. That is done to reduce the amount of traffic to the HLR. The MSC requests 5 tuples, uses them up, then requests 5 more. When the MSC has used up its tuples, it needs new tuples *immediately*. That is where the HLR proxy can help out. This made me think, maybe we should just increase the tuple cache size in the MSC and request new tuples before they are all used up? It would be easier than introducing yet another tuple cache in the HLR. Nevertheless, what I like about having another tuple cache in the HLR proxy is: - OsmoMSC's VLR is volatile. The plan is to make the proxy cache persistent, so that it still works after a power outage. Meaning the proxy HLR tuple cache would be more resilient than the MSC cache. - Practically all D-GSM configuration is in a single place: OsmoHLR. No need to remember to also configure OsmoMSC's tuple cache. > * It might be a good idea to make AKA reuse optional with a VTY config > option? Yes, that is the plan, indeed. Also have it switched off by default, since it is in fact a security flaw which the user should consciously decide to use. > * Potential use case: phone is home in village A, gets turned off, owner > travels to village B with the phone, the link to village A is down. That is indeed a situation that cannot be solved with the current design. But it is possible to limit this problem so that it only happens the very first time that a subscriber visits another village after a long long absence: UMTS AKA has sequence numbers (SQN) which must not move backwards, but it does keep (normally 32) separate "slots" of SQN, to be used for different MSCs and SGSNs. So that if a user comes back from another MSC, it can still carry on with the older SQNs from this MSC without needing new tuples, because the two different SQN slots are managed distinctly. So, if we make the proxy cache keep the tuple data for a very long time, then, as soon as a subscriber has once in a cache lifetime shown up in village B, the next time it arrives in B with no link to A, it *can* connect immediately. I think there is a limit to how far the different SQN slots may diverge, but it should be possible to do this to a certain degree, by configuring the proxy. Thanks, it helps to discuss :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: