Hi all,
I'd like to draw attention again to the state of codecs handling in OsmoMSC master.
The reason being that the recent IuUP changes create conflicts with the
neels/mncc_codecs3 branch.
I fear that we are currently doing the same thing that we discourage everyone
else from doing: keeping an important branch on the side and not upstreaming it.
There is recurrent overhead on rebasing the branch.
Facts about OsmoMSC: master neels/codecs_mncc*
heeds MS Bearer Cap from ComplL3 NO YES
logically combines codec constraints NO YES
communicates available codecs to/via SIP NO YES
worked at last congress NO YES
has the last IuUP patches YES NO
I think the reasoning for completing that codecs work and merging the branch is
compelling. Can we somehow achieve that before OsmoMSC diverges further?
I could start maybe by holding a talk on it in an OsmoDevCall? That way I've
read all of the code again and can explain what the patch does why, to ease
review. Or maybe spend that time on merging the code instead? Or both? :)
~N
Dear Osmocom community,
It's my pleasure to announce the next OsmoDevCall on
January 14, 2022 at 20:00 CET
at
https://meeting4.franken.de/b/har-xbc-bsx-wvs
This meeting will have the following schedule:
20:00 meet + greet
20:10 presentation "Codesc in OsmoMSC, MNCC and SIP" by neels
21:00 unstructured supplementary social event [*]
Attendance is free of charge and open to anyone with an interest
in Osmocom or open source cellular technologies.
More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall
Looking forward to meeting you on Friday.
Best regards,
Harald
[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
I have a SysmoISIM-SJA2 which I believe doesn't have a CAT application and
doesn't support the SUSPEND APDU (per the manual). Given that, is there any
way to reset/refresh the card through APDU commands (or through any other
means)? Would something along the lines of deactivating and then
reactivating the USIM application work?
Thanks,
Bryan
Dear Osmocom community,
today our mailing list server lists.osmocom.org has finally been migrated
from mailman2-on-freebsd to mailman3-on-linux. This also included a variety
of changes to DNS. I'll spare you the details, but everything _should_ be up
and running now.
* The List-Id headers should not have changed.
* all list subscriptions + user accounts have been converted.
* old 'static html' archives are still available (read only) at URLs like
https://lists.osmocom.org/pipermail/baseband-devel/
* old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel
are redirected to their respective modern counterparts
In case you notice any mailing list related problem, please don't hesitate to
contact me.
Happy hacking,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
those harmonics) must be above:
-30 dBm @ 30 kHz span above 1 GHz
-36 dBm @ 30 kHz span below 1 GHz
In case of UmTRX without an amplifier it's enough to use a ceramic or
SAW duplexer to bring harmonics below those levels.
For those buying UmTRX's as a lab package of universal UmDESKs, we
offer to buy an external ceramic duplexers. These improves coverage
and solves the out of band noise issues.
For those buying band-specific UmDESK's, we use SAW duplexers, which
are even more efficient in reducing out of band noise.
>> A calibrated USRP N200 running osmo-trx passes RF spectrum and
>> modulation accuracy requirements of 3GPP 05.05 by very large margins
>> and is competitive with commercial GSM equipment in this regard. Other
>> SDR devices are also capable to varying degrees.
>
> The policy of FCC vs. European Union is quite different. There are more
> norms that apply in Europe.
You're obviously more proficient in European norms. Could you point me
to a link where we could find these differences between the ETSI
published GSM Standard and European harmonized norms?
It would be a very good addition to the OpenBSC wiki's "Standards" page.
--=20
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
http://fairwaves.ru
> Anyway, I thought that the GPRS support is part of the OpenBTS
> development, and any hardware that can run OpenBTS is also capable of
> doing GPRS, but it is clear, that there are differences in the level
> of support, even between SDR like devices.
The majority of the code of osmo-pcu has been contributed by or on
behalf of sysmocom. If you take a look at the development of the PCU
for the last 6 months you will clearly see that sysmocom is doing all
the work. Just like with OpenBSC a lot of others benefit from our work
though. ;)
> I still think that it would be nice, to clarify all this packet data
> related stuff on the site.
* When an external protocol changes, the version number needs to
change. I added MNCC protocol versioning as OpenBSC and LCR were
out of sync and then funny things happened. This one line change
of the version number can save you hours in debugging!
* When a new feature is added, ask for a testcase. E.g. specially
the E1 bit fiddling as it is so rarely used that it is likely
to bitrot.
* Check the error paths. Developers tend to only test with a single
phone, not run into error paths, not force them to be taken during
development (faul injection).
* For things like device work-arounds ask if they are really necessary,
e.g. I have my doubts for the RTP timestamp handling.
* General code hygiene. Don't have the action take place four tabs in
in a thousand line code method, don't use magic numbers, don't repeat
yourself etc. Code is read a lot more than it is written. Besides smaller
methods being easier to write unit tests for, they are easier to
understand/review.
I have merged two patches from this patchset but they required multiple
rounds and my spare time is really limited.
cheers
holger
