Project

General

Profile

Actions

Feature #2411

open

No support for RTP dynamic payload types - AMR/HR/EFR payload types are hardcoded

Added by ipse over 6 years ago. Updated about 6 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
07/30/2017
Due date:
% Done:

0%

Spec Reference:

Description

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.

Actions #1

Updated by laforge over 6 years ago

  • 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.

Actions #2

Updated by ipse over 6 years ago

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.

Actions #3

Updated by laforge about 6 years ago

  • Project changed from OpenBSC to OsmoMGW

Assigning this to OsmoMGW as in a "post NITB" setup the MGW is what terminates the externally-visible RTP packets.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)