Re: OpenBSC Digest, Vol 105, Issue 5

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