On 13/09/2023 16:13, Neels Hofmeyr wrote:
I just noticed that a release was made,
ignoring this remark in osmo-msc's TODO-RELEASE:
MNCC osmo-sip-connector should do full SDP via MNCC and be
released at the same time as the next osmo-msc, ask neels, thanks
https://gerrit.osmocom.org/c/osmo-msc/+/34386
There is no full SDP support in current osmo-sip-connector.
In fact the patch for that is just now becoming ready for merge:
https://gerrit.osmocom.org/c/osmo-sip-connector/+/16222
I guess we should get the sipcon patch merged, and follow up with another
sipcon release.
This prompted me to take a look at things again, and I'm afraid it is
still all a bit broken. I don't think it is OK to just hard code a
dynamic payload type and ignore the incoming SDP.
I guess the fact that nobody flagged this since the last release means
that nobody else is using osmo-msc + osmo-sip-connector + freeswitch
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.
MO calls are OK, because osmo-msc uses PT 112, and FS of course obliges
and matches, even though osmo-mgw is still rewriting that to PT 98 for
osmo-bts (why is that?)
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.
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.
k/
