do GSM FR when the call is outbound from the mobile
network and AMR
when it is mobile to mobile
This is the aim, but OsmoMSC is not entirely there yet.
In short, in OsmoMSC, the Mobile Terminated call leg is now quite intelligent
about choosing codecs, but the Mobile Originated side still needs [1] or [2]
implemented to make good choices.
More detail:
The codecs patches in OsmoMSC being discussed a lot lately came to be because
years ago I noticed that OsmoMSC ignored some of the important codecs
constraints, and it completely failed to communicate codecs to SIP. Voice calls
only worked out at all if both sides incidentally chose identical codecs.
IOW, dismal.
To fix that, the first step was to actually collect all indicators of codec
availability and constraints, within one call leg. (implemented)
The second step was overlaying these to find a resulting set of codecs that
agrees with all constraints, within one call leg. (implemented)
The third step is negotiating the codecs efficiently between the two call legs,
so that the remote call leg's constraints also are taken into account. (NOT yet
implemented on the MO side)
Current OsmoMSC (nightly) implements the first and second step. To complete the
third step, we still need [1] and/or [2]. Initially, I intended to include this
work in the codecs branch, but since it got little to no attention for years, I
never got to step three. This is the main reason why I can't just write "it
works" now and why this mail is as long as it is.
So we still need:
[1] very late assignment: Currently OsmoMSC still first assigns a specific
codec to the MO call leg, and only then starts talking to the MT call leg. So
if the remote call leg disagrees with that specific codec, things still fail as
they always did. OsmoMSC could instead do an MNCC Setup first, to get feedback
on available codecs from the MT call leg, *before* assigning a channel, hence
it could choose a codec that both sides support.
[2] re-assignment: Currently OsmoMSC does not re-assign an ongoing voice call
to a different codec. OsmoMSC could detect a mismatching codec from the MT call
leg and then re-assign the established voice channel to a supported codec.
[3] forwarding of SDP through OsmoSipConnector: this patch is still on branch
neels/codecs3 and not yet merged (for a specific reason related to Call Hold),
should be mergeable soon.
To make it specific to your question:
do GSM FR when the call is outbound from the mobile
network and AMR
when it is mobile to mobile
If the MO call leg is on the mobile side, you won't be happy: OsmoMSC+BSC will
so far still pick a codec for it too early, *independently* of the MT call leg.
So you'll "always" get the same codec result for mobile MO, outbound or
not.
If there is an inbound call from the PBX, you can be happy: OsmoMSC is now
capable of noticing that the inbound call supports only FR, and OsmoMSC+BSC
will then pick an FR codec. To really see that happening, we also need [3].
If we implement [1], and your PBX indicates only FR being available in the SDP
part of the "SIP OK (Invite)" response, then you'd limit codecs to FR for
any
mobile-to-outbound call.
If we implement [2], and your PBX indicates FR, OsmoMSC could re-assign an
already established AMR to use FR instead.
Or the transcoding path is also an option
Transcoding causes significant load, and is not implemented in Osmocom.
On CCC events, we typically used transcoding to interface with the POC folks
operating the DECT phones. IIRC we used a Kamailio to always transcode to some
or other PCM format and then forwarded to their FreeSwitch. We also hardcoded a
specific codec on the mobile side, AFAIR it was AMR. It worked, but is of
course unsatisfactory: we had to pick one codec for all mobile calls; to be
able to support 3G, we picked AMR; in consequence, very old phones supporting
only FR could not use voice on our network. That felt wrong. This was actually
the main hook and realization that made me want to improve OsmoMSC's codecs
handling in the first place.
Point is: about these capabilities there is very
little
information available about what is supported and what is not within
the Osmocom domain.
That is true, and the main reason is that until recently, pretty much only
hardcoding a single codec guaranteed working voice calls; and now, the
situation is improving but still quite a bit in flux.
I would love to continue working on this, so that my next mail answering this
question could just be "it all works now" =)
The next step is to get the OsmoSipConnector patch merged.
After that I'm not sure yet if we get funding for implementing [1] and/or [2].
It would make a huge difference for OsmoMSC users.
~N