On Thu, Sep 14, 2023 at 12:49:46AM -0600, Keith wrote: Yes, it is not finished. We now have the basic ability to overlay and pick supported codecs in osmo-msc, but a lot of details need to sill be polished to make complete sense. My current list: - Make sure for external MNCC that the payload type numbers and codecs match up between the two call legs' SDP. I just now had to fix it for internal MNCC, and it occurred to me that it must be a problem for external MNCC too: https://gerrit.osmocom.org/c/osmo-msc/+/34412 - Make selection of AMR rates a first-class citizen of MSC's codecs filter. Related: 3G AMR and AMR-WB, and 3G<->2G TFO also for TCH/H compatible AMR-HR. - Implement later Assignment on MO, or Re-Assignment on codec mismatch, so that MO and MT can properly negotiate codecs. Seems to be the case, yes, because I mostly find my own bugs a long time later. Seems to report exactly what I recently noticed about payload type numbers. Our ttcn3 tests do only single call legs and don't verify voice, and my lab tests usually have the same payload type numbers on both sides, so i didn't notice this oversight so far. I don't really know, historical reasons or maybe BTS limitations? I just know there has been this difference in PT numbers between BTS and CN for a very very long time. I'm not aware of this at all... Yes, exactly. That's what I'm currently working on with the background of 3G-2G TFO. I'm sorry that even after the codecs effort you still don't have a completely working osmo-msc, but I think the very big obstacles are out of the way, and we should be able to fix these things relatively easily. I'll be revisiting and enhancing the new codecs filter for these aspects in the near future. I find it encouraging that you identified two of the things I'd like to fix as important (PT, AMR mode-set=...). ~N

Hi, forgot to say, as a reference for future releases: Please try to avoid leaving tasks which require interaction or extended resolution time to be done at release time. It already takes a considerable amount of time to tag everything, adapt ttcn3 tests, update OE recipes, prepare release announcements, etc. and it is desirable being able to do so in the shortest possible amount of time, so that the whole process is done as atomically as possible. Regards, Pau -- - Pau Espin Pedrol &lt;pespin(a)sysmocom.de&gt; 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

On Fri, Sep 15, 2023 at 09:21:14AM +0200, Harald Welte wrote: The sysmocom internal weekly review is not the proper forum to discuss the open osmocom community's releases, because there is no open access to that meeting. I did not see or notice any such. I should not have to carefully read all IRC backscroll to get this information. ~N

About the release, this was not optimal, but also not such a big problem. I wanted to name the problem, but there is no deep emotion involved here. I appreciate the release effort made by others, and I assume the point was heard. That is sufficient for me. This is exactly *not* the point. The point is that a FLOSS community needs its own reliable and independent forum to discuss e.g. releases, so that any contributors can participate. Contributing to Osmocom and being a sysmocom employee are two distinct roles, and we want to make these orthogonal. Of course they are not, but our express aim is to keep these roles neatly separate, in order to empower the community. I absolutely do not want to discuss sysmocom employee role aspects here, please refrain from bringing that into this public forum. It is not appropriate, and puts me in a weird spot. My hat *here* is FLOSS community member, employed or not. ~N