Hi Keith,
My question was targeting the Osmocom stack and not the (external) PBX. I already found some AMR patches for Asterisk (it seems it is still not part of mainline), will try to do that.
The second half of my question was somewhat vaguely tries to ask if it is possible to do AMR when the call is MO-MT directly, or maybe the MGW can do transcoding, so in a nutshell: maybe there is a solution to do GSM FR when the call is outbound from the mobile network and AMR when it is mobile to mobile. Or the transcoding path is also an option. Point is: about these capabilities there is very little information available about what is supported and what is not within the Osmocom domain.
Regards, Csaba
On 22/07/2023 05:37, Sipos Csaba wrote:
Hi Keith,
Hi.
(BTW, It doesn't help others to follow the thread when one replies without context and with a subject line of "OpenBSC Digest...")
My question was targeting the Osmocom stack and not the (external) PBX.
OK, Well there might be an issue in the question, "what codecs is osmo-sip-connecter offering to the PBX when I set "codec-list fr3 fr2 fr1"? Actually I'd need to check that, especially with some patches that are now in master but not released yet. With your setup, whatever versions it might be using, you can very simply verify by taking a look at your SIP, as I said before.
But given that you basically said it works with FR but not with fr3 in there, one can only assume you are offering AMR and the PBX is not accepting. So well, you need to target the PBX.
The second half of my question was somewhat vaguely tries to ask if it is possible to do AMR when the call is MO-MT directly,
Yes, of course, that will work if you take the PBX/external MNCC out of the loop, so having it work with the PBX in there requires that the PBX accepts AMR for pass-through. Many years have passed since I used asterisk, I don't remember how to configure it to do that, but it could well be possible. Maybe even without having asterisk look at the rtp stream at all. In times gone by FreeSwitch used to ship (maybe still does) with a default pass-through only AMR codec implementation.
so in a nutshell: maybe there is a solution to do GSM FR when the call is outbound from the mobile network and AMR when it is mobile to mobile.
Yes, these are actually questions that can get somewhat complex. To be honest, my level of clarity on it comes and goes depending on how much I have been looking at such code recently. Right now I have not, but I think we have most of the pieces of the puzzle. - We can offer codecs based on the RAN side. We can choose the RAN side based on the codecs offered in incoming SIP. We can HO from full to half-rate TCH inside the same BTS, (i think) so I guess we can renegotiate the channel speech mode. I don't think we can actually trigger SIP re-INVITE for codec renegotiation. Maybe we can, I'm not sure what happens if we HO a FR TCH to HR with that BTS defrag stuff.. Maybe we can't do that, I'd need to check.
I'm still not sure what's in master in relation to late negotiation, that is to say, we don't do channel assign and choose the RAN speech_mode until we get SIP 200 back from the PBX with sdp confirming the codec. That might be useful in the case where you don't establish early media on the MO call and you wait until the B-leg of the PBX answers and confirms codec. Let's say for example, you are going upstream a a round-robin of VoIP providers, and some of them support GSM-FR, so in the case you hit one, you want to use FR on the RAN and not do any transcoding. If on the other hand upstream offers you only PCMA/U, then maybe you choose to use AMR HR on the RAN site to conserve capacity, or as you say, you call eventually goes to another GSM RAN and so your B-leg in this case also maybe supports AMR.
Many possibilities, lot's of edge case stuff that I've long had full intentions of implementing.. + The gods of time and energy often have other plans
I'm actually not sure about the state of transcoding in the MGW, maybe somebody has WIP in a branch. Don't think so though. I saw something the other day about 3G to 2G, but I think it's "only" about the IuUP part. I do need (partly for another task) to get a little more familiar with the MGW code.
Point is: about these capabilities there is very little information available about what is supported and what is not within the Osmocom domain.
Possibly/Probably because such things are in active development.
k/
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
Hi Neels,
First of all much appreciate your detailed answer.
I will monitor the git channel so I can do some tests when a merge happens in this regard.
Until then, I found some out of tree codec support for Asterisk:
https://github.com/traud/asterisk-amr https://github.com/traud/asterisk-gsm-efr and even https://github.com/traud/asterisk-evs
The last one is not necessarily interesting for 2G, the first two I compiled in but never had enough time to test it as there are enough issues with the Nokia BTS support I can deal with. So I can only tell that AMR and EFR codecs are compiling and loading fine on the latest Asterisk. FYI the AMR module can do AMR and AMR-WB and transcoding, the EFR module can do passthrough and transcoding as well. Maybe this is interesting for others as well.
Regards, Csaba
-
Keith -
Neels Hofmeyr -
Sipos Csaba