Feature #6151
openosmo-msc: Ability to configure (VTY) the AMR(-WB) formats used in RAB-Assignment-Req
0%
Description
Right now, RAB-ASsignment-Req message is built in osmo-iuh.git and it is hardcoded to built an RFCI list basically containing AMR 12k2.
The interesting related code path is:
ran_iu_encode(RAN_MSG_ASSIGNMENT_COMMAND)
ran_iu_make_rab_assignment
ranap_new_msg_rab_assign_voice [osmo-iuh]
new_rab_par_voice
new_sdu_par_item
If you check new_sdu_par_item() in osmo-iuh.git (https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/src/branch/master/src/ranap_msg_factory.c#L556), you can see how the SDUs are added there, hardcoded.
Ideally, the RFCI list would be passed to ranap_new_msg_rab_assign_voice() from osmo-msc.
Then, from osmo-msc, an RFCI would be built based on:
- Whether the UE supports AMR or AMR-WB (CC Setup message, "Supported Codec List" IE)
- Whether osmo-msc is configured to serve AMR or/and AMR-WB on the VTY
- Whatever other restrictions on the other call leg
This would allow, for instance testing IuUP/AMR-WB calls.
If AMR-WB is selected, we probably need to update the SDP related paths to add "16000" after IUFP:
a=rtpmap:97 VND.3GPP.IUFP/16000Some related specs:
- 3GPP TS 25.413 (RANAP)
- 3GPP TS 25.415 (IuUP)
- 3GPP TS 26.103 (Speech codec List for GERAN anf UMTS)
- 3GPP TS 26.171, 3GPP TS 26.201, 3GPP TS 26.202 (AMR-WB)
- RFC 4867 (RTP for AMR, AMR-WB)
Updated by pespin 8 months ago
- Status changed from New to Feedback
- Assignee set to neels
Assigning to neels for feedback/opinion since he knows this part way better than I, specially regarding what VTY options we may want to integrate.
I can support with the implementation once it's clearer what do we want exactly.
Updated by neels 8 months ago
SDUs:
I am currently busy on the mentioned RAB Assignment composition code in
osmo-iuh.git, and will likely soon figure out a more flexible way to compose
the SDUs.
Concerning the AMR-WB support in osmo-msc:
I suspect from the grapevine that your current aim is to set up a singular lab
that needs to do AMR-WB only and which does not care about interop with 2G or
non-WB AMR. That's easy as a hack, not so trivial to achieve "properly"...
Naively said, it should be: add AMR-WB options to the lists of codecs and allow
configuring it as taking precedence over plain AMR. But the part making this
difficult is that so far configuring the order of preference for codecs exists
only in osmo-bsc.cfg, and we have no such thing for 3G. So far in 2G, osmo-msc
tells osmo-bsc which codecs are allowed, and osmo-bsc figures out which codec
is preferred. In 3G, osmo-msc has only AMR (even, so far, only exactly AMR
12k2), so until now, there was never a choice to be made. So it takes some
deeper thought how to add a codec preference config to osmo-msc, and
particularly how that affects 2G.
Next important aspect: to properly implement TFO codec interop would require a
working codec negotiation between MO and MT call legs -- as explained
elsewhere: so far, info on the MT codec capabilities arrive at the MO call leg
too late to have any effect, so we'd need to change the point of time where we
do Assignment on the MO's RAN, or we'd need to implement re-assignment to a
different codec in osmo-msc.
So far, the effect of any configuration of AMR vs AMR-WB added to osmo-msc
would be: either we always get AMR or always AMR-WB when MO is on 3G. Only
with proper codec negotiation will we be able to make a sane choice for
individual calls of what SDUs should be sent in the RAB Assignment, for TFO
(transcoder-free operation), and only then will it be any fun to have code that
flexibly chooses SDUs =)
Until then we might as well just use a custom-built osmo-msc + libosmo-ranap
for AMR-WB lab testing, with no intention to merge that to master. Much easier
and faster to achieve that.
Updated by neels 8 months ago
Update: it turns out that I need a vty option in osmo-msc to select 3G AMR rates to efficiently test rates for my current task.
I'm adding a bitmask to ranap_new_msg_rab_assign_voice() in libosmo-ranap, and a vty option in osmo-msc to globally set the RAB rates at the moment.
This is not eligible for merging to master as it is, because I am avoiding to be pulled into a refactoring effort in osmo-msc: most code paths do not yet properly communicate the sets of supported AMR rates for a call leg. So far, we are always using 12k2+SID on 3G, and for 2G a default configuration based on the local call leg's channel type (see enum gsm0808_speech_codec_defaults and ran_a_make_assignment_command()).
Instead, we need filtering useful AMR rates in the codec filter, which works with all of 2G, 3G, AMR and AMR-WB rates.
Skipping that for now.
These hacky dev patches so far just handle AMR rates, not AMR-WB. I'll let you know as soon as they work for me, so we can decide to add AMR-WB or not.
