When reading MGCP is failing (e.g. because the udp socket
is not connected yet) we would have freed the msgb but we
didn't return and then executed msgb_put on a dead buffer.
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.
Add code to change the ip and port for audio data inside
MGCP messages. This is needed because the BSS might be
behind the NAT and can not reach the network directly and
might be behind a nat so the announced sourceport is not
the one as we see it.
Move the conversion of GSM0808 timeslot and multiplex from
the bssap.c into the mgcp.h so it can be reused by multiple
users. The weird math comes from the mapping of the MSC...
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...
Make the source address mandantory and complain about
complain when it is missing. The address is mandantory
as it needs to be put into the MGCP messages...
* 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.
This test case tests connectiont tracking by sending
a CR, getting a CC, sending a DTAP, receiving a DTAP,
receiving a RLSD, sending a RLC. It verifies that the
messages are properly patched specially the references
at the BSC.
When sending a message to the MSC in the case of DT1
messages we only have the address of the MSC, so we
need to go with that, otherwise (e.g. in case of a CR, RLC)
we do have the source address and need to patch it.
When forwarding a message to the BSC we do receive
a msg that should contain the patched address, we need
to unpatch it...
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.
