It was observed that the SGs server is started before
the actual VTY configuration is parsed. For example:
sgs
local-port 9999
local-ip 127.0.0.1
vlr-name vlr.example.net
produces the following debug output:
<0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:29118
DLSS7 NOTICE <001e> osmo_ss7.c:1284 0: ASP Restart for server not implemented yet!
DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:9999
DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=127.0.0.1:9999
DMNCC DEBUG <0004> msc_main.c:604 Using internal MNCC handler.
The first startup is triggered by sgs_iface_init(), before reading
the VTY configuration, so the logging style is different. The next
two calls to sgs_server_open() are triggered during reading of the
VTY configuration by cfg_sgs_local_port() and cfg_sgs_local_ip().
Let's avoid starting the SGs server three times, and do it once,
after the VTY configuration is parsed. Also, keep the possibility
to change the binding parameters at run-time.
Change-Id: Ie0c31205ac48be7e50d0380a89833771b2708da4
Comparing an array to null is not useful, because the expression
will always evaluate as true. Let's just always write SGs server
address and VLR name, no mater whether default values are used
or not, same as we do for the HLR address and port.
Change-Id: If045e42fca0315b0777eb86c44bf934ce58b340b
Fixes: CID#190871 Array compared against 0 (NO_EFFECT)
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)
Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
Vadim Yanitskiy
Harald Welte