Reset the FSM to idle when receiving a clear command from the MSC during
ST_WAITING_FOR_ASSIGNMENT_COMPLETE.
Related: SYS#5560
Change-Id: Ic0589be21f0ee4dbbbe0ffa6b0acdbe152909700
Insert the BSCNAT's MGW into phone calls by replacing the AoIP
transport layer address IE inside BSSMAP Assignment Request and
Assignment Confirm. Accomplish this with a new subscr_conn_fsm that
parses and stores the original ass_req / ass_conf messages, communicates
with the BSCNAT MGW, and then creates new ass_req / ass_conf messages
based on the original ones but with new RTP information.
With this patch it is possible to do a successful voice call with the
following network:
MS1 --- BTS1 --- BSC1 --.
| | BSCNAT ----------- MSC
| | | | |
'-- MGW-BSC1 --|-- MGW-BSCNAT --- MGW-MSC
| |
MS2 --- BTS2 --- BSC2 --' |
| | |
'-- MGW-BSC2 ------'
Related: SYS#5560
Related: https://osmocom.org/projects/osmo-bscnat/wiki/Ladder_diagrams_for_key_procedures
Change-Id: I7e491aada6f5db0eb35ef2039869c6ba07f9ca3b
Instead of having RAN/CN as parameter, make the function a bit simpler
and only allow RAN. The motivation for this change is, that for MGW a
similar function is required, and it was recommended in code review to
rather duplicate the short function instead of making it more complex.
I'm dropping the CN part here since it wasn't used anyway, and if used
in the future, the function could be duplicated for CN as well.
Related: SYS#5560
Change-Id: I77b0ef33f94c401d24f38eb8d79e1007234e0ab4
Add functions to parse the BSSMAP part of BSSAP messages, and in theory
do other things than just forwarding the messages depending on the
BSSMAP message type. This will be used in follow-up patches to change
the AoIP transport layer address in Assignment Request and related
messages.
Related: SYS#5560
Change-Id: I3e2599a9a07925afdbe69f7b8dbcec227681dfa2
Prepare to use osmo_mgcp_ep_alloc in a future patch, which requires
using osmo_fsm_set_dealloc_ctx(OTC_SELECT) for deferred FSM deallocation
(see the warning in src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c).
Related: SYS#5560
Change-Id: I97abf88fa64cc1a4906f356c57912593d4366a37
Instead of segfaulting later on, properly exit if the bsc_nat_fsm does
not start. One reason for having it fail could be a missing mgw pool
config block.
Related: SYS#5560
Change-Id: Ia8bbe6ae908d5c3ce49f71b43c950497aeebb6d6
Make the MGW pool configurable in the VTY and connect to each configured
MGW instance on start up. This is in preparation for the
subscr_conn_fsm, which will allocate own MGCP connections while
processing BSSMAP assignment request and related messages.
Related: SYS#5560
Change-Id: I6030a1f5a9d5fb06f148b2a2e03ae57bcb6b3766
In the test setup, let the real BSC and virtual BSC use the same codec.
With this the voice frames are successfully sent back by the virtual MS.
When using a different codec, since transcoding is not implemented in
OsmoMGW, the stream becomes invalid in MGW-MSC and gets dropped by BTS1,
never reaching the virtual MS.
Related: SYS#5560
Change-Id: I78d666ad77c03459f5369b64e651e47ce1d4f12c
I've considered only forwarding to specific BSCs based on the cell
identifier list inside the paging. For that, the cell identifier would
need to be stored beforehand (read it from location update? or put it in
vty config?) and I'm not sure if it is required, so don't do this for
now and extend it later if needed.
Related: SYS#5560
Related: https://osmocom.org/projects/osmo-bscnat/wiki/AoIP_OsmoBSCNAT#PAGING-BSC
Change-Id: I2532d94aab82d136b932d57fa53c8ecf2d8d1fd9
Almost all functions in bssap.c actually handle bssmap, so name them
accordingly.
Related: SYS#5560
Change-Id: Ib583b64187bcf3138399e7a099248ee79492bb03
Use the proper function to print BSSMAP names, so it doesn't say
"unknown 0x52" etc.
Related: SYS#5560
Change-Id: I353a9d13b14de6d0ba9aabe8cb3057dd7a98cb51
Use LOGL_ERROR and word them the same way as the not implemented
message in sccp_sap_up_cn and sccp_sap_up_ran.
Related: SYS#5560
Change-Id: Ice8d67a30064a91d68256f43dcfb052d237e5594
Rename the function from sccp_sap_get_peer_addr_in to get_peer_addr to
make the code using it slightly more readable. The _in at the end of
the function is not needed anymore, this was used to differentiate from
peer_addr_out which was used in the caller code before the connection
mapping was implemented in I1556aa665fbb0a97507f98794e74820731fa6935.
Now instead of peer_addr_out, subscr_conn->bsc->addr or
subscr_conn->msc->addr are used.
Rename variable arguments to sccp_inst and addr to be consistent with
the variable names in the callers.
Related: SYS#5560
Change-Id: Ie023360724254be54cbaac4490b0341dfe68399f
Describe the manual testing that can be done with osmo-dev with the
changes up to I78ef36c72ff9a7b801e922eccc89dc44fbba7f23.
Related: SYS#5560
Change-Id: I3c3369b6d1a50ec3af19ee826cf2f94530d5d7fd
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
Once a BSC has sent a RESET to BSCNAT, store it. This will be used in
future patches to build connection mappings between MSC and BSCs, and to
block messages from BSCs that did not send a RESET.
I've considered using a FSM, but at least right now there doesn't seem
to be multiple states worth storing. We only have the BSC before it has
done the RESET (and then it's simply not in our list) and after it did
the RESET (in the list).
Don't use the stored BSCs in the forwarding logic just yet, a future
commit will replace the current forwarding code with proper connection
mappings.
Related: SYS#5560
Change-Id: Icd7316c49ef26fb45ad45a2ccc1a7916bfb0a387
As suggested in code review, create sub-structs for cn and ran. The
following patches will fill them up with mscs, bscs etc.
Related: SYS#5560
Change-Id: I6a3cc0d837a3d89e7153c2296812df0863f3471f
The sccp_inst was only used to differentiate between CN / RAN. Instead
of passing that, pass an enum and add bsc_nat_print_addr_cn and _ran
defines to keep it short.
This is in preparation for refactoring struct bsc_nat as suggested in
code review.
Related: SYS#5560
Change-Id: I3c6046a6726c31bf137223c46c2c96b3898ad324
Let the BSCNAT directly reply to RESET sent from BSC with RESET ACK.
bssap_ran_handle_reset() is a bit empty right now but will be used in a
future patch to store the BSC.
Related: SYS#5560
Related: https://osmocom.org/projects/osmo-bscnat/wiki/AoIP_OsmoBSCNAT#RESET
Change-Id: I3223409e25c93b625d67634caf68efe9772e2558
Make it a bit shorter, it's clear that this refers to the local address
of the OsmoBSCNAT in CN/RAN.
Related: SYS#5560
Change-Id: I3083374d589487ed960507e7a431c45914afc5dd
Prepare for future patches where more will happen in the callback
function. Split it up into two functions, one for CN and one for RAN, so
we don't need to constantly think through both cases while
changing/trying to understand the function.
Related: SYS#5560
Change-Id: I8eb8f24ad33a59de8fbaf512547d389ee86c13dc
After implementing more functionallity (see follow-up patches), it
became clear that this macro is not so useful:
* Using the macro creates unnecessary overhead,
'LOG_SCCP(sccp_inst, peer_addr_in,' is much longer than 'LOGP('
* The RI and SSN are always the same, so it's not useful to print them
all the time, this is the generated prefix:
'(RI=SSN_PC,PC=0.23.3,SSN=BSSAP from CN)'
Related: SYS#5560
Change-Id: I49187d4e3d804c4786ee52eaebdd911e6c6cfa6c
Shorten them and don't use the LOG_SCCP macro anymore that will be
dropped in a follow-up patch. Change the level to DEBUG.
Related: SYS#5560
Change-Id: I85f65ad3c15a10958fbfe97aef00fc386e85ef63
Move the log message outside of the switch case to make it a bit
shorter. Use LOGP instead of LOG_SCCP, because the latter is about to
get removed in a follow-up patch.
Related: SYS#5560
Change-Id: I1f181ff38f86d83969da4e9d3da72dd9d69d298a
Categorize includes by:
* (library includes)
* Osmocom includes except for OsmoBSCNAT
* OsmoBSCNAT includes
Order the includes in each category alphabetically, and remove empty
lines between them. This allows me to keep them consistent, and with
empty lines removed between these categories it doesn't look
inconsistent if there is only one include from two categories in one
file, but multiple includes from the same category in another file.
While at it, also have one empty line after the license header in all
c, h files, and one after the includes.
Related: SYS#5560
Change-Id: I1a7b95ccb0c87fd53645c72f0c02449e8403043b
conn.ind happens before conn.conf, so use the same order in the switch
statement.
Related: SYS#5560
Change-Id: Ibdb5a9b092ab481f35cf5920f3635fdf4a9b85c2
Get ss7_inst once and store it inside bsc_nat_sccp_inst to avoid
multiple calls to osmo_ss7_instance_find().
Related: SYS#5560
Change-Id: I9a8b69fb3df17c85a67958fbca88948573d39694
This name seems more fitting, since the code mostly interacts with the
sccp addr and scu contained in the struct.
Related: SYS#5560
Change-Id: Id0f965811eff0eb7b387d5ae2eec2451d6d8e415
Fix the logic to not always return src->local_sccp_addr. What we need to
know is the peer's address.
Related: SYS#5560
Change-Id: I0055c0fafe672db5ce7a616d94c8964e8d58968f
Implement a simple version of forwarding Connection Request, Connection
Confirm, Data Form, Released SCCP messages. This is still assuming that
there is just one BSC, one MSC, the same connection ID is used in RAN
and CN. Future patches will add a mapping between RAN and CN sides and
allow multiple BSCs.
With this patch it is possible to perform a call between two MS in the
following network structure:
MS1 --.
BTS --- BSC --- BSCNAT --- MSC
MS2 --'
Related: SYS#5560
Change-Id: I3df79e4dfaa60f4fd098961ee57cda71e9773b82
Split this code into an extra function, as it will be used by other
message types in sccp_sap_up too (following patches).
Related: SYS#5560
Change-Id: I6bc59445d65f812ccd46eb33dd6cca6b34dd0867
Only in connection-less messages, the called party address is always the
address of the receiving peer. Prepare for connection-oriented messages
by renaming:
dest_called -> peer_addr_out
peer_addr -> peer_addr_in
Related: SYS#5560
Change-Id: Ib58a4e8eb8beca23cb9f11c46576f8b17bb66f3c
This is already done by the SCCP stack, as Harald explained it:
"Think of a TCP socket where you have already bound a socket and then
still do recvmsg to check if the destination address is what you expect."
Related: SYS#5560
Change-Id: Id9bfbf38a61ef66a4246f752ef487d8a09fea173
Add an initial implementation of sccp_sap_up, that assumes one BSC and
one MSC, and successfully forwards RESET and RESET ACK between both.
Related: SYS#5560
Depends: libosmo-sccp I0f38b0d038b0dd8cd355e7284e5b56d438811bd9
Change-Id: I4af398bb433341a98f818822e6c3af28b6d9dacd
Remove unnecessary bsc_nat_vty_go_parent function, and use
osmo_ss7_vty_go_parent instead. Without the latter, it segfaults while
attempting to parse a config segment like this:
cs7 instance 0
point-code 0.23.3
asp asp-clnt-OsmoBSCNAT-CN 2905 0 m3ua
remote-ip 127.0.0.1
local-ip 127.0.0.3
sccp-address msc # segfault here, vty->index == NULL
routing-indicator PC
point-code 0.23.1
Related: SYS#5560
Related: https://gerrit.osmocom.org/c/osmo-bsc-nat/+/26659/comment/c99b8cca_865449aa/
Change-Id: Iee6ece062f11694acb771463be7effb7342e92f2
Create the initial FSM that starts and stops two SS7 instances (one for
CN, one for RAN), and binds an sccp user to each.
Related: SYS#5560
Depends: libosmocore I81c64a7ae440304522c2179c212023a566ddced8
Change-Id: I7d52fa649c397582b18a1a7dcc40bb407f3b2c97
It was decided to write OsmoBSCNAT with 3GPP AoIP support from scratch,
in a separate repository from OsmoBSC. The previous codebase was too
heavily tied into legacy SCCPlite code and had been removed from
osmo-bsc.git in Ia05dc76336a64a7f08962843b9a7cc19f2c83387.
Related: OS#2545
Change-Id: Iae5d37483dcb9db00578d5c9cd1736f08754a65e
Oliver Smith