respect dynamic RTP payload types of external SIP
As keith reported in OsmoDevCall on June 11, when an external SIP entity sends a SIP INVITE with SDP for AMR using a dynamic PT, osmo-sip-connector still sends AMR audio using a different (actually unassigned for this call/session) PT.
I guess this relates to the fact that 3GPP uses "pseudo static" PTs for the different codecs, i.e. it has defined that certain PT numbers from the dynamic PT range actually statically represent 3GPP codec types. Within Osmocom, we are sticking to the latter and may not have considered "Real" SIP/SDP compatibilty on the external interface.
Updated by neels over 2 years ago
It's not sipcon sending the payload type number in the AMR audio, it's the
osmo-mgw. What is necessary is actually connecting in the first place the codec
negotiation in SIP with the one in osmo-msc; hence configuring osmo-mgw correctly.
We have never had proper translation between the codec known in osmo-msc and
the codec negotiated by SIP.
As per #1683, the osmo-sip-connector should be transparent about SDP, and the
MSC should figure out codec and payload type numbers. Using SDP-via-MNCC should
implicitly solve this issue.
I have a set of patches almost ready that rewire MSC's codec figuring, adds SDP
via MNCC and makes sipcon transparently forward SDP between external SIP entity
and osmo-msc. They are the ominous "codec patches" lying around for years.
I would actually very much like to finish up and merge these patches, because
they solve a huge amount of codec issues and were already tested at congress,
but so far it's not happening working time wise.
Updated by neels over 1 year ago
currently working again on said osmo-msc patches (neels/codecs) that improve on the codec selection,
and introduce transparent SDP through osmo-sip-connector and MNCC.
I hope that the correct PT numbers will end up in the MGW "for free" when that branch is merged.