No support for RTP dynamic payload types - AMR/HR/EFR payload types are hardcoded
We haven't looked at the details, but I think it's worthwhile to file this bug to keep a note.
It seems OsmoNITB and OsmoBTS doesn't support dynamic RTP payload types (aka PT). Supporting dynamic PTs is a requirement to interface OsmoNITB/OsmoBTS with external SIP/RTP clients via MNCC socket if we want to use anything except GSM-FR.
Calls between OsmoBTS's work fine, because they always allocate the same PT - e.g. 98 for AMR. But when we deal with external clients we can't control PT allocation of the other side calls will fail or you will hear sound only in one direction (external party to OsmoBTS). Because the other party will ask to send AMR RTP with a PT it selects (e.g. 102 for the sake of an example),but OsmoBTS will send it with PT 98.
- Tracker changed from Bug to Feature
- Priority changed from Normal to Low
Inside osmocom we always used "fixed dynamic" RTP allocations. I wouldn't conside this a bug of OpenBSC (OsmoBSC or OsmoNITB), so I've reclassified this as a feature.
The IPA compatible abis/ip signalling (RSL CRCX/MDCX) allows to specify which RTP payload type to use, and AFAIK osmo-bts implements this. It's just that our BSC is always setting the same static values.
I think this ticket should be visited as part o the bigger picture, once we introduce a proper OsmoMGW that's co-located both with the BSC and the MSC.
Yes, it looks like osmo-bts doesn't make assumptions about RTP PT and it's OsmoNITB who's responsible.
Whether it's a bug or a feature depends on whether you consider SIP/MNCC clients as first class citizens or an optional bonus. In SIP world (or any other SDP based codec negotiation) you can't assume RTP PT of the other side, unfortunately.