On Thu, Sep 14, 2023 at 12:49:46AM -0600, Keith wrote:

This prompted me to take a look at things again, and I'm afraid it is still all a bit broken.

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.

I guess the fact that nobody flagged this since the last release means that nobody else is using osmo-msc + osmo-sip-connector + freeswitch

Seems to be the case, yes, because I mostly find my own bugs a long time later.

On MT calls, I have one way audio and Freeswitch is logging:

 [ALERT] switch_rtp.c:5856 Invalid Packet SEQ: 23989 TS: 1641489638 PT:98 ignored  [ALERT] switch_rtp.c:5856 Invalid Packet SEQ: 23990 TS: 1641489798 PT:98 ignored  [ALERT] switch_rtp.c:5856 Invalid Packet SEQ: 23991 TS: 1641489958 PT:98 ignored  [ALERT] switch_rtp.c:5856 Invalid Packet SEQ: 23992 TS: 1641490118 PT:98 ignored

etc etc..

Anyway, Freeswitch asks for PT 98, [a=rtpmap:98 AMR/8000] and osmo-msc responds with [a=rtpmap:112 AMR/8000]

Freeswitch obliges and sends PT 112, which actually the osmo-mgw seems to change to 98 ?? before sending to the BTS, but freeswitch then ignores the PT 98 that osmo-mgw sends towards it.

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.

osmo-mgw is still rewriting that to PT 98 for osmo-bts (why is that?)

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.

As for the Invalid Packet SEQ, This is another thing, and I'm not sure.. (it's not the "problem" for the one-way audio), but as far as I'm aware I have osmo-mgw in as much of a pass-thru mode as it can be, so I don't know why freeswitch is complaining about the SEQ generated by osmo-bts.

I'm not aware of this at all...

We also need to pay attention to mode-set in the SDP and translate this to the modes in the chan assign (overriding vty config?) and also, preferably, set it in outgoing SDP.

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 <pespin@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

On Fri, Sep 15, 2023 at 09:21:14AM +0200, Harald Welte wrote:

Indeed, I can confirm this was mentioned at numerous sysmocom weekly reviews

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.

and for sure in IRC and/or jabber for at least a month, probably longer.

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.

I think the problem here is that you portray yourself as some external, non-sysmocom developer (which you are not).

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