This method currently prepends the IPA header and sends
the data. In the future we might be able to use SCTP for
it.
We have to remove the IPA header from the static messages
for that to work.
This code is untested.
Sending a RLSD with SCCP failure makes the MSC free all the resources
(MGCP, audio channels), right now we are ignoring the RLC we get from
the network and print a unhandled message.
Attempt to find the message by transaction id, then patch
the response and use the IP/PORT of the local network, update
the ci with the one from the BSC.
This is currently not tracking any state of the MGCP and will
not handle two bsc's... this will need to happen later.
With this in we should be feature complete and now enter the
mode of making all of this work reliable and fixing thinko's
and other bugs.
* Forward a rewritten msg to the BSS. We change the IP and port
to point to the NAT instead of the core network. We also keep
track of the BSC and the transacition id.
* Handle the case where we have not found a SCCP connection and
need to send a response ourselves.
When losing the SCCP connection make sure that we free all
endpoints. The disconnection of the BSC should already make
sure they are closed but this makes sure everything is
properly reset.
For the nat we will have NAT and MGCP in the same process
and this commit starts with that. We are linking in the MGCP
code and one can embed MGCP config snippets...
* Return the SCCP connection. This will be needed to store the
assigned timeslot in there.
* Update code to work with this change
* This uncovered a bug in the CC handling, at the time the BSC was
passed it was still a null pointer and the code would have failed.
Moving it here means we can more easily test this code, there is one
behaviour change with the code that we only support paging messages
with one LAC and will silently ignore the others.
On a CC message we will need to remeber where the source local
reference of the network belonged so we can properly identify
the connection when receiving UDT messages.
When we disconnect from the MSC handle it by pushing the problem
to our connected clients. We will simply close all connections,
reject all new BSC connections and attempt to reconnect to the MSC.
Create a BSC<->MSC interface and use it for the BSC MSC IP and the
BSC NAT to reduce code duplication on handling reconnects to the MSC
and cleaning up the local state. The code is only partially tested
and will contain bugs. Currently both the BSC and the NAT will just
exit on connection loss and this way have the current behavior.
In case we disconnect with some pending operations we will need to
signal the MSC that something is wrong. This could be by sending a
RLSD directly, or a clear command. Another part of the fix is to
respond with a RLC on unknown RLSD messages.
* Provide access to the GSM0808 TLV attributes so we can use it in
the nat code.
* Read the PAGING message, if it is paged by LAC we go through each
LAC and then attempt to find the proper BSC connection and then
send the message to that BSC.
Based on the token the NAT/MUX is capable of figuring out
which LAC this BSC is supposed to satisfy. This will be
needed for messages like paging that can be done by LAC.
Holger Hans Peter Freyther