https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092017-08-15T17:51:29ZOpen Source Mobile CommunicationsOsmoMGW - Feature #2411: No support for RTP dynamic payload types - AMR/HR/EFR payload types are hardcodedhttps://projects.osmocom.org/issues/2411?journal_id=50052017-08-15T17:51:29Zlaforge
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul><p>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.</p>
<p>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.</p>
<p>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.</p> OsmoMGW - Feature #2411: No support for RTP dynamic payload types - AMR/HR/EFR payload types are hardcodedhttps://projects.osmocom.org/issues/2411?journal_id=50182017-08-15T22:08:23Zipse
<ul></ul><p>Yes, it looks like osmo-bts doesn't make assumptions about RTP PT and it's OsmoNITB who's responsible.</p>
<p>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.</p> OsmoMGW - Feature #2411: No support for RTP dynamic payload types - AMR/HR/EFR payload types are hardcodedhttps://projects.osmocom.org/issues/2411?journal_id=80422018-03-05T19:04:35Zlaforge
<ul><li><strong>Project</strong> changed from <i>OpenBSC</i> to <i>OsmoMGW</i></li></ul><p>Assigning this to OsmoMGW as in a "post NITB" setup the MGW is what terminates the externally-visible RTP packets.</p>