We need to decide which way to go with point codes, sccp- and ss7-instances.
pmaier and I have reached different conclusions and wrote patches going in
opposite directions, now we need to decide and cosolidate:
The MSC has various connections over SCCP: it serves BSSAP for several BSCs,
and RANAP for several HNBGWs.
BSC - A MSC:
BSC -}----------> BSSAP
BSC - -----> RANAP
/
HNBGW -}-/ IuCS
HNBGW -
1)
I went for exactly one point code at the MSC (say PC=1). There is exactly
one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate
sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to
the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up().
When comparing to the TCP/IP model, the paradigm here is that a PC is like an
IP address and the SSN like a port number. At the server, the MSC, I have one
PC (IP address) and listen on one SSN (port) per protocol served, and clients
all connect to the same PC+SSN, receiving separate connection IDs. I can also
use the calling address to know which client I'm talking to.
Hence I moved the osmo_sccp_instance creation up to "the top" and created two
sccp_user_bind()s, one for BSSAP and one for RANAP. This works in practice.
I can tear down and set up individual sccp_users (i.e. disable/enable IuCS or A
separately), and handling different clients is done by the conn_ids and
possibly keeping distinct osmo_sccp_addresses.
An pseudocode MSC VTY config for this scenario could look something like this:
msc
sccp local-pc 0.0.1
ssn-iucs $OSMO_SSN_RANAP ! -> to IuCS rx cb
ssn-a $OSMO_SSN_BSSAP ! -> to A rx cb
remote-bsc 1
pc 1.0.1
remote-bsc 2
pc 1.0.2
remote-hnbgw 1
pc 2.0.2
i.e. one local PC is configured, each protocol has its separate SSN, each
sccp_user_bind() serves all clients for that SSN.
This is the direction I took to add IuCS to AoIP.
2)
pmaier added VTY configuration for various point codes, and went the other way:
the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is
told the addresses of all known BSCs and) every time a BSC is configured via
VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a
distinct local PC for each BSC, and for each HNBGW.
In this model there still is a code problem I noticed while adding IuCS to AoIP
in OsmoMSC: if I call osmo_sccp_simple_client() a second time with a different
PC, the osmo_ss7_instance used is still the same (still id=1), and notes this
second PC as its global local PC. The messages received for the first client's
PC are then seen as remote and routed back out -> infinite message loop. A
solution here would be to either a) use a separate osmo_ss7_instance per
osmo_sccp_simpe_client() (simply add an ss7 instance id parameter to
osmo_sccp_simpe_client() and increment by one each time) or b) implement the
routing algorithm so that it notices the local PCs of several local SCCP
clients.
A VTY config for this scenario so far looks like this:
! define some addresses, referenced below
cs7 instance 1
sccp-address msc_local
subsystem-number 254
point-code 0.0.1
routing-indicator PC
sccp-address bsc_remote
subsystem-number 254
point-code 0.0.2
routing-indicator PC
sccp-address bsc_remote2
subsystem-number 254
point-code 0.0.3
routing-indicator PC
msc
bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote
bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote2
(I'm not sure whether it is possible to have several sccp_instances with the
same msc_local address, but we would find solutions for these petty issues once
we've decided which way to go.)
(I also think 'calling-addr' and 'called-addr' should rather be named
'local-addr' and 'remote-addr': depending on who calls who, the
calling-addr
can be the remote or the local one. That's also besides the point for now.)
My personal idea is that 1) is simpler: we have one ss7 instance per program,
no matter how many clients are served. I can still tear down and set up
individual sccp_users (i.e. disable/enable IuCS or A separately), and handling
different clients per SSN is done by the conn_ids and possibly keeping distinct
osmo_sccp_addresses of the clients. 2) seems to me easier to misconfigure and
it sounds to me like a paradigm of creating a whole new server for each client
that connects, so instead of using an ss7_instance's routing, we create
separate instances, each sending to only one counterpart.
But is 2) maybe the correct way to go for reasons I'm not aware of?
I notice that what I wrote is biased towards 1) because that's my POV, but this
is indended to be a neutral question.
We need a choice for 1) or 2) so that pmaier and I can adjust and merge our
patches accordingly. Can you help us decide, hopefully with some background
knowledge on how an SCCP network is intended to be set up?
Thanks!
~N