Implement a proper subscriber connection mapping. Create a new
subscr_conn when one of the stored BSCs sends a conn.ind and use that
subscr_conn for all related connection-oriented messages with the same
RAN-side conn_id to send messages back and forth between BSC and MSC.
Add subscr_conn_get_next_id based on OsmoBSC's
bsc_sccp_inst_next_conn_id.
With this patch, it's possible to do a successful Location Updating
procedure between MS2 and MSC in the following network:
MS1 --- BTS1 --- BSC1 --.
BSCNAT --- MSC
MS2 --- BTS2 --- BSC2 --'
Related: SYS#5560
Change-Id: I1556aa665fbb0a97507f98794e74820731fa6935
Automatically send RESET to the MSC as the BSCNAT starts up. Try it
again if it fails, in case the MSC was not started yet or if the SCCP
connection was not up yet (right now it does not seem possible to get
notified when the SCCP connection is up).
Related: SYS#5560
Related: https://osmocom.org/projects/osmo-bscnat/wiki/AoIP_OsmoBSCNAT#RESET
Change-Id: Icfec3ec0168c7040e88a536fa48da339349fb6cf
Expect one MSC to be configured in the address book (part of the cs7
section in the config, see doc/examples/osmo-bsc-nat/osmo-bsc-nat.cfg)
and store it on start up.
Store the MSC in a list, as we may potentially support multiple MSCs in
the future. Also that makes it symmetric to the BSC list.
Don't use the stored MSCs in the forwarding logic just yet, a future
commit will replace the current forwarding code with proper connection
mappings.
Related: SYS#5560
Change-Id: I711df0c649728f1007857fbfda500ed5ef69287b
Oliver Smith