| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The current code was overly complex. It tried to iterate over
the list in a round robin and we had to keep track of the last
element, see if we remove that one, check if the list becomes
empty... This can all replaced by treating the double linked
list as a queue. We take the item at the front, do something
on it and then and then put it back to the list at the end.
|
|
1.) free every SAPI from 1-7 and wait for the confirmation
and then continue until all of them are freed. If the
SAPI is not torn down we will receive a timeout and then
we force the RF Channel Release...
2.) once SAPI is down we send the RR Release, SACCH Deact
3.) the abis_rsl will see that all SAPIs are down and then
will release channel...
|
|
|
|
Setting the state through a dedicated method allows us to
track the state transitions and check if they are done in
a proper way.
|
|
When we issue a RF Channel Release in case of a failure we receive
RLL release indications after the channel was tearn down and we
issue another RF Channel Release as a result. The channel allocator
might have already allocated this channel and we release the channel
again with another MS on it.
Make rsl_rf_chan_release take an error argument and make it set
a new state in case of an error and change the RF Channel Release
ack to not set the state back to none in case of an error but wait
for a timeout that is a bit higher than T3111.
I tested this with removing the battery during a phonecall and
waiting for the channel failure. With this test we only send the
release once.
|
|
|
|
It appears to be possible that we attempt to submit a DTAP
on a SCCP connection when we have a channel without the msc_data
assigned. This change should fix the crash (which is not well
understood), fix a memleak in the case of the queue being full.
|
|
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 the reset right away will upset the MSC and we
need to wait for the first contact.
|
|
For some mode of operation it can be acceptable to reallocate
an already allocated endpoint. This can be the case when we
only deal with one call agent that is keeping track of the
endpoint but slightly confused.
|
|
|
|
* Move to the new log code and update binaries
* Catch up with lchan changes from master
Conflicts:
openbsc/include/openbsc/Makefile.am
openbsc/include/openbsc/gsm_data.h
openbsc/src/Makefile.am
openbsc/src/bsc_rll.c
openbsc/src/chan_alloc.c
openbsc/src/debug.c
openbsc/src/gsm_04_08.c
openbsc/src/gsm_04_11.c
openbsc/src/gsm_subscriber_base.c
openbsc/src/handover_logic.c
openbsc/src/silent_call.c
openbsc/src/transaction.c
openbsc/src/vty_interface.c
openbsc/src/vty_interface_cmds.c
|
|
This allows that we can print the Nr. next to the lac
and it allows us to change the lac at runtime without
reconnecting the BSC.
|
|
Currently vty_interface.c is used for the BSC config, in case of
the MGCP Gateway or the BSC Nat process these logging commands are
not available. Move the commands to a new vty_interface_cmds.c file
to allow to share basic commands across different programs.
|
|
Currently vty_interface.c is used for the BSC config, in case of
the MGCP Gateway or the BSC Nat process these logging commands are
not available. Move the commands to a new vty_interface_cmds.c file
to allow to share basic commands across different programs.
|
|
Remove the code to parse port as we need to discover the
BTS behind the nat and most likely it will have a different
port than the one advertised by the BTS.
This reverts commit c6a1fe773d16eb20d4cb1d3097761419436f4537.
|
|
Cleanup all endpoints that belonged to a given BSC. This is
one part of the cleanup, the other is to bring down the SCCP
link properly.
|
|
|
|
E.g. when the underlying connection transport medium is gone
one needs to force to close SCCP connections, add this helper.
It will remove the connection from the list of connections and
it will free the data.
|
|
Extract the port from the BSS's MGCP Gateway so we know
where to forward the data to.
|
|
The MGCP protocol parsing is adding '\0' to make sure we do not
parse beyond where we should parse. This does not mix with strtok
or similiar routines.
For now we will read the msg into a global array first, then copy
it to the msgb for mgcp protocol handling and if we are required
to forward it to the MGCP we have a untouched copy we will modify
into our own msgb.
|
|
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.
|
|
|
|
This will be used by the NAT code to implement custom protocol
handling on top of that.
|
|
Listen on the MGCP gateway port and let our protocol stack
handle everything for now. We will need to have some more
control over things though.
|
|
In the case of the nat we only want to communicate with one
upstream call agent and this can now be configured.
|
|
|
|
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.
|
|
Make sure the MGCP attached to the BSC is resetting all
endpoints whenever the BSC is connecting to us as we assume
that all endpoints are available.
|
|
This will just call a callback and leave all the handling
to the application.
|
|
This message is ignored by the call agent and we were
sending this on the first request which we maybe should
not ignore...
|
|
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...
|
|
This information will be needed when we are trying to forward
MGCP connections to and from the BSC through the IPA protocol.
|
|
|
|
* 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.
|
|
This way one can create the bsc_nat structure in unit tests..
|
|
Move patching and reassigning of messages to a new file which
will making testing this functionality more easy.
|
|
|
|
This code simply enables the channel allocator to understand the
dynamic TCH/F / PDCH channel type as used by ip.access nanoBTS.
It does not actually try to switch the dynamic mode, but instead
sends signals to a (not yet present) dynamic switching algorithm.
|
|
We use the (currently unusued) flags member of the bts_trx_ts structure
to track if a dynamic TCH/PDCH is currently on PDCH mode or not.
|
|
The logging/debugging code is generic enough to move it into libosmocore
while keeping OpenBSC specific definitions in openbsc itself.
This commit uses the logging support present in libosmocore-0.1.2,
you will have to update your library to this version.
|
|
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.
|
|
Keep track of SCCP connections so we can clear them
when the MSC is going down.
|
|
We are still writing to the BSC directly and don't make real
use of this feature right now but we will need to do it.
|
