> 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
> On 13 Jul 2016, at 12:21, Max <msuraev(a)sysmocom.de> wrote:
>
Hi all,
> After looking at the code, I don't think reusing table implementation
> would be easy - the approaches are too different as well as underlying
> data structures.
okay. then we will need to use the tree based version and from my point of view we should do it the following way:
* Remove osmo_t4_decode (and related routines) from libosmocore (last step)
* Make the tree based decoder ready in terms of the surrounding style
* Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU)
@Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore
@Radisys:
I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here.
In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU.
Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them.
The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests.
Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same.
Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions.
kind regards
holger
Hi!
I've asked about it before but this seems to have been lost in
communication.
The question is basically how to enable multi-TRX support for
osmo-bts-trx using phy/instance infrastructure similar to other bts?
What I've tried so far is documented in
http://projects.osmocom.org/issues/1648 but it did not result in working
setup yet.
In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with
its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and
correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's
missing to make this actually work are greatly appreciated.
--
Max Suraev <msuraev(a)sysmocom.de> 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
Hi Max,
Thanks for your reply!
> I think extending utils/conv_gen.py is the way to go because it will
> allow us to have concise description of the convolutional codes in one
> place and as close to the description in standards as possible.
Ok, I will keep your opinion in my mind.
> Could you specify which files exactly are you referring to? Also you can
> use 'git blame' to clarify authorship.
No problem, they are:
- gsm0503_conv.c
- gsm0503_interleaving.c
- gsm0503_mapping.c
- gsm0503_parity.c
- gsm0503_tables.c
Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'.
Thank you for this hint, this command is very usable! :)
> I don't think library functions should do any sort of logging by itself
> (unless it's a logging functions of course :)
> Instead they should return clearly distinguishable values and let caller
> do the logging as they see fit.
I am agree with you. It's time to use return codes.
Have a nice day!
With best regards,
Vadim Yanitskiy.
Today, I've taken a quick look at the coverity stuff, because so far I've only
seen coverity reports on the Iu code. I see now that actually all of the other
osmocom components are also tested by coverity.
So far I'm only seeing the "Osmocom" coverity project, which contains only the
iu build. In fact that's a bit of a misnomer -- I assumed that "Osmocom" would
contain all of the osmos, it should be more like 'Osmocom-3G' or 'Osmocom-Iu'.
The other osmos are in coverity projects named "libosmocore", "osmo-bts", etc:
https://scan.coverity.com/projects?utf8=%E2%9C%93&search=osmo
I see there are "add me to project" buttons e.g. here
https://scan.coverity.com/projects/libosmocore
so I'm trying that now.
Wouldn't it make sense to redirect all the coverity reports to a mailing list?
Probably best would be a new mailing list, to avoid noise on openbsc@, like the
gerrit-log@ list.
Are these coverity reports a matter of secrecy, to avoid publishing security
holes before we fixed them, in which case the coverity mailing list should be
invite-only?
~Neels
Hi,
While ruining osmo-bts and osmo-trx via VTY we tried to change parameter
like Band ,ARFCN MS max power.
We observed that once ARFCN is changed on VTY TRX does not switch to new
ARFCN.
Same behavior has been observed with Band and MS-Max-Power and RF-Locked
0/1 parameter.
Request someone who is running osmo-stack has controlled network ,please
reply or any document/pointer is appreciated.
BR
Dhananjay
Hi,
I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, as
in the attached trace. The connector replies with 0.0.0.0 RTP IP and
0/unknown codec and then ends the call. I am seeing the following log:
"
Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001>
mncc.c:334 call(1073741832) can not be found
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> app.c:104
Unknown ptmsg(0). call broken
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001>
mncc.c:312 leg(5001) rtp connect failed
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:245
Ending leg(0x91ec30) in con
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001>
mncc.c:304 leg(1073741832) can not be found
Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:186
leg(0x91ec30) got bye, releasing.
"
This issue happens *after* *recently* *updated* *packages* to:
"
ii osmocom-nitb 0.15.1.20160922 amd64
GSM Network-in-a-Box, implements BSC, MSC, SMSC, HLR, VLR
ii osmo-sip-connector 1.20160922 amd64
MNCC to SIP bridge for osmo-nitb
"
On the osmo-nitb side I am seeing logs [1].
I suspect a bug in the osmo-sip-connector code. Can someone confirm this?
[1] http://pastebin.com/giG0HHha
Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
