> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hi all,
we need to wrap up the DGSM work and get it to a state that can be merged to
master.
There are still open issues that I am not sure how to solve, which I've
mentioned on some occasions, but it seems to not have been loud enough.
I would easily choose one way, but am not sure about others' opinions.
(1) One open point is the GSUP peer identification. I've added a comment
explaining it in https://gerrit.osmocom.org/c/osmo-hlr/+/16459/9
Me personally, I would strip down basically all of that complexity again and go
with the simplest solution, a nul terminated size limited char string for GSUP
peer id. The patch became what it is because vague requirements were thrown in
the mix and I tried to accomodate them, and now it ended up being a rather ugly
shim around a simple char string, really.
(2) Another open question is the freeing behavior in osmo_gsup_req (for proper
async handling of DGSM, and to ensure proper GSUP responses). I've added a
comment explaining that in https://gerrit.osmocom.org/c/osmo-hlr/+/16205/29
The gist for both issues is that I could write patches that would have a large
ripple effect throug many files and follow-up patches, but if we again disagree
on the outcome, the work would multiply.
So, DGSM works and is ready, except that we need to agree on what will be
accepted by review. I need opinions to be able to complete this (or possibly a
"go" to do whatever I think is right and merge that).
Thanks!
~N
Hello:
I installed the osmo-NITB on ubuntu18.04, including
osmo-trx,osmo-bts,and openbsc.
I run these three applications in three terminals successively, it seems
ok, but the tx/rx leds on usrp-b210 hardware platform are not lighted,
and the print message in the osmo-trx terminal shows :
Thu Apr 30 15:28:28 2020 DTRXCTRL <0002> Transceiver.cpp:832
[tid=139871716352896][chan=0] command is 'POWEROFF'
Thu Apr 30 15:28:28 2020 DTRXCTRL <0002> Transceiver.cpp:977
[tid=139871716352896][chan=0] response is 'RSP POWEROFF 0'
I try to send some commands on another terminal which launch a telnet
session which connects to the osmo-bts control interface(port number is
4238) , but it not working.
what can i do next?
thanks a lot.
$ git clone git：//git.osmocom.org/osmo-trx $ git branch * master $
./configure ... checking for LIBOSMOCORE... no configure: error: Package
requirements (libosmocore >= 1.3.0) were not met: No package
'libosmocore' found Consider adjusting the PKG_CONFIG_PATH environment
variable if you installed software in a non-standard prefix. Then, check
the information of libosmocore: $dpkg -l |grep libosmocore ii
libosmocore:amd64 0.9.0-7 amd64 Open Source MObile COMmunications CORE
library (metapackage) ii libosmocore6:amd64 0.9.0-7 amd64 Osmo Core
library $ sudo apt-get install libosmocore ... libosmocore has already
been the newest version (0.9.0-7)。 why???what can i do?
Appreciate that the Osmocom Docker configurations exist principally for
automated testing and here it may not make sense, but I wondered if
builds are published to a registry?
The Makefile in the make project located in the docker-playground repo
sets docker.io as registry and has a target for docker push. Also see
OBS Release.key files in project sub-directories, but couldn't find
container builds being published anywhere.
Was hoping I could just pull containers for the latest project versions,
without cloning and building the containers in docker-playground.
Also saw the comments from 2017 on Docker shortcomings and assuming SCTP
works OK now in Docker networking?
Regards,
Andrew
Dear Mr. Welte,
In order to be more familiar with the further development of the osmo-euse file, I need to know which libraries and which programming style I should use to be on the right track.
Is it possible to provide me please the some lines of your code which is sending the USSD code via the GSUP client to hlr and called up data from OSMO-HLR?
I need this for my master's thesis (Education Purpose), so I don't need a license for it.
Many thanks for your consideration,
Reza
Hi all,
I am new to the use of the Osmocom project, it is indeed a very nice job.
I am currently trying to set up a configuration with a Asterisk PBX server and I have 2 questions:
1/ RTP configuration
The SIP part (sip-connector vs Asterisk connection) works well so far, the communication starts but with no audio.
I noticed that the RTP flux is sent to localhost instead of my server address (set as remote in sip-connector.cfg) and I was wondering if there is any possibility to send the RTP flow to an address which is not localhost ?
sip
local 0.0.0.0 5069
remote 127.0.0.1 5060
2/ codec issue
In a configuration where all the Osmocom servers (MSC, MGW, BSC…) and Asterisk are on the same machine, it got a message from my asterisk server, saying that no codec can be found to start a communication. By default, the wiki/manuals states that gsm has to be used but perhaps I am missing something in the BSC configuration, especially in the codec choice.
<--- SIP read from UDP:10.184.10.162:5069 --->
INVITE sip:899@127.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.184.10.162:5069;rport;branch=z9hG4bKpe1UXZU1amUja
Max-Forwards: 70
From: <sip:422@0.0.0.0:5069>;tag=vyQKX32r72ZyQ
To: <sip:899@127.0.0.1:5060>
Call-ID: cd65c5a0-fdbf-1238-51a9-000c29cfd753
CSeq: 949096397 INVITE
Contact: <sip:10.184.10.162:5069>
User-Agent: sofia-sip/1.12.11devel
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Length: 133
v=0
o=Osmocom 0 0 IN IP4 127.0.0.1
s=GSM Call
c=IN IP4 127.0.0.1
t=0 0
m=audio 4016 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=sendrecv
<------------->
--- (13 headers 8 lines) ---
Sending to 10.184.10.162:5069 (no NAT)
Sending to 10.184.10.162:5069 (no NAT)
Using INVITE request as basis request - cd65c5a0-fdbf-1238-51a9-000c29cfd753
No matching peer for '422' from '10.184.10.162:5069'
== Using SIP RTP CoS mark 5
Got SDP version 0 and unique parts [Osmocom 0 IN IP4 127.0.0.1]
Found RTP audio format 3
Found audio description format GSM for ID 3
[2020-04-20 17:38:19] NOTICE[14918][C-00000015]: chan_sip.c:10957 process_sdp: No compatible codecs, not accepting this offer!
Thanks for your help
Laurent
