Dear Osmocom Community, I've spent some time the least few days to handle SCCPlite in osmo-stp, and to do some initial testing of interoperability of osmo-bsc-sccplite with osmo-msc. The result are a few commits to osmo-sccp.git and openbsc.git which I'll push into gerrit as soon as I'm on land again (sitting in an airplane right now). Once those commits are merged, we can run osmo-bsc-sccplite with osmo-msc via osmo-stp. Why is this needed? While we don't want to see or support any new osmo-bsc-sccplite deployments, we still have existing users that we need to continue to support. Supporting them is easier if we can test it better, and as Osmocom now has a MSc, it would be logical to have some [manual, automatic] testing setups this way. It also means that we hopefully can create testing setups for osmo-bsc_nat, which could so far only be tested (like osmo-bsc-sccplite) with live access to a "real" MSC at an operator. Right now, this of course only handles signaling, i.e. we should be able to test LU, SMS and call signaling, including hand-over. Voice stream handling between SCCPlite and M3UA-AoIP is unfortunately quite different and will need further code in osmo-msc as well as osmo-stp. But still this should be rather straight-forward as a later next step for full interoperability. == How to configure this === osmo-bsc-sccplite side On the osmo-bsc-sccplite side, the config file looks like this ---- msc dest 127.0.0.1 5000 0 <1> token mahlzeit <2> ---- <1> the IP address and port must be the IP:Port of where osmo-stp listens for IPA <2> this 'token' must be identical to the AS configured on osmo-stp === osmo-stp side On the osmo-stp side, the config file looks like this: ---- cs7 instance 0 xua rkm routing-key-allocation dynamic-permitted as mahlzeit ipa <1> routing-key 0 0.23.4 <2> point-code override dpc 0.23.1 <3> route-table system listen m3ua 2905 accept-asp-connections dynamic-permitted listen ipa 5000 <4> accept-asp-connections dynamic-permitted ---- <1> This defines an AS with the name 'mahlzeit' matching the osmo-bsc-sccplite token <2> The point-code on the BSC side is set to 0.23.4 <3> The point-code of the MSC side is set to 0.23.1 (the compile-time default of osmo-msc) <4> Bind IPA protocol to TCP port 5000 Please note that no point code information is configured on the BSC side in the case of SCCPlite. The SCCP calling/called party address in SCCPlite don't contain a PC but only SSN, and there is no M3UA/MTP3 label with point code information either. Hence, OsmoSTP will insert the point code information into both the SCCP level as well as the stp-internal routing label of each message. The MSC will receive a SCCP message with PC+SSN in a M3UA message with OPC and DPC in a way that enables the STP to route any responses back to the BSC. If you have multiple osmo-bsc-sccplite in such a configuration, they will all need to have a different point code, just like an AoIP speaking osmo-bsc. The difference is only that in SCCPlite the point-codes are configured on the STP side, while in the AoIP they are configured on the BSC side. === osmo-msc side No special configuration is required on osmo-msc at this point. In order to properly handle voice channels, we likely have to introduce some additional per-BSC configuration statements at a later point. Regards, Harald -- - Harald Welte &lt;laforge(a)gnumonks.org&gt; http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)