Hi,
it came up again in gerrit again.
Currently the osmocom style states doxygen style comments should be done in the .c file.
Doxygen are those comments:
/*! a brief description of the function
* \param something Some description of the use
* \return 0 if ...
*/
Doxygen takes those comments and generates a html documentation of the code.
I would like to change it to have those in the headers files instead (when the function in included in a header file).
When using the doxygen comments only for doyxen, for sure, there isn't a difference between
having it in .c or in .h files.
But when using IDEs or language servers, they usually only parses headers files and
the .c files of the current active project (e.g. osmo-sgsn),
but not the .c files of other projects (libosmocore).
On the downside I only see the problem of increasing the size of header files, but I don't see
an issue in here.
Any thoughts?
Best,
lynxis
Hi,
I was going through the features of osmoepdg solution and thought to ask few questions regarding the implementations.
1. In most of deployment tunnel authentication is bypassed. So, even if UE send CERTREQ, it is getting ignored at ePDG. ePDG also doesn't send anything to UE.
Do you have any idea of how to implement that in strongswan or have you explored that earlier? I saw that in 3gpp 33.402 and RFC 5996, certificate things are optional.
However, I know that strongswan authentication is tightly coupled, so just trying understand if you have already bypass it by doing any changes in strongswan or atleast know how it should be done.
2. There are many error and status codes written in ePDG standard 24.302 clause 8. Have you mapped all EPC core error to corresponding IKEv2 error or status codes?
Thanks & Regards
Subhajit Chatterjee
New Delhi
Dear List,
With Domi we are working on some improvements on the Nokia Site E1
based BTS types, mainly focusing on the OML side.
Among many things (see the upcoming patches), one thing we would like
to add is to lock all TRX-es at BSC shutdown. The OML command
structures we already have, but when we added this part to the
shutdown_om() function we noticed that only the first TRX receives the
command, the rest does not. When we looked at the E1 capture even more
surprise: the capture file lacks the OML command of the first TRX
which we locked successfully (cross checked with BTS manager).
Enabling LAPD debug also indicates that there is no graceful shutdown
of the lapd links as well, which is my suspicion for the failing
locking of TRXes except of TRX1: the connection is just cut before the
last couple TRX lock commands can pass and we got just lucky with the
first one timing-wise.
I think Harald or Pau mentioned a new FSM which is likely not
implemented/backported for the Nokia BTS variant. The question is:
does the new FSM does a graceful shutdown or maybe handles it better
than the current code? I looked at the rbs2000 as an example also but
I don't see that the shutdown part is handled any different/ better.
At this point I have no idea if this is the expected behavior, a bug
or a missing feature? The fact we are missing an OML message in the
PCAP which clearly passed the E1 line kind of indicates a bug at least
there.
I am not sure but likely other BTS types might also benefit from a
graceful shutdown (eg. at least lock all TRXes). The Nokia variants
clearly do: without the TRXes locked, at the next BSC startup all the
unlocked TRXes inadvertently start random RSL bootstraps, even in the
middle of a site reset, filling the log with random errors.
Please let me know if there is any example code we should look at,
and/or what your opinion is about this subject in general.
Regards,
Csaba
Dear list,
FR calls between mobile phones are working fine, but when I change the
codec-list to
"codec-list fr2 fr1 fr3" or "codec-list fr3 fr1 fr2", I am getting a
Remote Transcoder Failure:
lchan(0-0-1-TCH_F-0)[0x630d01c78b80]{ESTABLISHED}: (type=TCH_F)
CONNECTION FAIL (cause=Remote Transcoder Failure [ 28 ])
In the BSC config:
codec-support fr efr amr
codec-list fr2 fr1 fr3
In the MSC config:
mncc-int
default-codec tch-f fr
default-codec tch-h hr
Both the phones and the BTS is FR/EFR/AMR capable.
I am fairly sure with Osmo-NITB at least EFR was working with these
phones and BTS some years ago.
If needed, I can provide a pcap.
If someone has an idea, please let me know.
Regards,
Csaba
As the owner of a manufacturing business, I’ve come to realize how crucial efficient logistics are. When I first started exporting products overseas, handling shipping on my own was a constant struggle. After partnering with a freight forwarding service https://www.cfipak.com/ , everything changed. They handle the complexities of shipping, customs, and delivery, allowing me to focus on production and growth. With their expertise, my shipments are now timely and cost-effective. If you're in manufacturing or any business with global reach, investing in a freight forwarding service will save you time and stress, helping your business thrive.
As the owner of a manufacturing business, I’ve come to realize how crucial efficient logistics are. When I first started exporting products overseas, handling shipping on my own was a constant struggle. After partnering with a <a href="https://www.cfipak.com/">freight forwarding service</a>, everything changed. They handle the complexities of shipping, customs, and delivery, allowing me to focus on production and growth. With their expertise, my shipments are now timely and cost-effective. If you're in manufacturing or any business with global reach, investing in a freight forwarding service will save you time and stress, helping your business thrive.
Dear list,
I wonder if anyone has access to Nokia Flexi BTS or Flexi EDGE /
Multiradio equipment and can provide access to it for the purpose of
adopting Osmo-BSC to support for these units?
In case someone has a unit like this (with whatever radio), please let me know.
Regards,
Csaba