Hi Harald,

Thanks for the detailed explanation. I understand that house keeping is
very important in a growing code base like the Osmocom mobile phone stack.

The plans for osmux really match the use cases of sat. backhaul for
rural communities. Btw, one question I have, with LCLS, is it possible
to have zero voice traffic to MSC in a local call, right?

Rafael Diniz

On 03/06/2018 03:44 PM, Harald Welte wrote:
> Hi Rafael,
> On Tue, Mar 06, 2018 at 10:17:32AM -0300, Rafael Diniz wrote:
>> Does anyone have a working OsmoBsc_Nat with osmux working example? I
>> just want to take a look in osmux, so it doesn't matter if it's with old
>> NITB-era stack or new split stack.
> osmux was originally implemented in osmo-bsc + osmo-bsc_nat for SCCP-Lite
> You will need a MSC that implement SCCP-Lite in order to set it up.
> The "new" osmo-bsc and osmo-msc implement the much more recent and officially
> 3GPP specified "AoIP" over M3UA instead of SCCPlite.  While this setup is
> working, there is neither a bsc-nat for AoIP yet, nor is Osmux yet fully
> integrated into this configuration.
> The plan is to be able to have osmux as an alternative to native RTP/IP
> between the BSC-colocated OsmoMGW and the MSC-colocated OmsoMGW.  So 
> basically,
> OsmoMGW acts as a converter between classic RTP/IP and OSMUX.  In this
> case the user plane would be something like
> This plan has not been completed yet, but we are actively working
> towards it.  During past months, progress has been slow due to the large
> number of regressions and other bugs, which prompted our main attention
> towards implementing testsuites for the various Osmocom elements to
> achive higher overall code quality and to be able to maintain that
> quality by continuous automatic testing.
> If somebody for some reason wants to have an AoIP bsc-nat, then we would 
> likely
> also put an OsmoMGW to it.  This would look like:
> But currently there is no strong requirement or clear roadmap on this
> particular feature/functionality.
> More immediate priorities from current point of view are:
> * improve coverage of automatic testing of each Osmocom element
> * resolve bugs found by the existing test suites
> * automatic testing of dynamic PDCH switching
> * automatic testing of intra-BSC hand-over
> * support for inter-BSC hand-over on AoIP side in OsmoBSC + OsmoMSC
> * support for 3GPP LCLS (local call local switch) in OsmoBSC + OsmoMSC
> * support of Osmux in OsmoMGW for BSC and MSC co-located OsmoMGW
> * support for 3GGPP IuUP in OsmoMGW (for 2G-to-3G calls and vice-versa)
> Regards,
>       Harald

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to