Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
Replace the domain name with a new name domain that can be configured
via the VTY interface.
|
|
This change is coming from OpenBSC and was adjusted to mgcp_ss7
|
|
A virtual trunk is identified by a virtual domain name.
|
|
MGCP RFC 3435 does not specify that the Connection Id must be
generated with any kind of random. It must uniquely identify
the connection of an endpoint. So we can make it per trunk group
or could even have it per endpoint.
The code does not support multiple connections on the same endpoint
right now but the spec allows it.
|
|
Create the endpoints as soon as possible, configure static ports
after we are through with the parsing of the VTY config.
|
|
The endpoint offset is needed for two reasons, first the API is 0
based here while we are normally 1 based, second because of the trunks
the first usable endpoint would be '2' (0 is CRC, 1 is signalling), but
this endpoint offset falls apart when we would block timeslots inside
this range.
Remove the endpoint offset, in each endpoint we will store the HW DSP
Port (1 based API) and then subtract one to get to the 0 based API for
the Simple API. Print a warning when someone is using the endpoint offset.
|
|
|
|
It appears that it is possible to have a stale SCTP connection
and this added LOGL_NOTICE and the VTY interface might help to
identify this situation in the future (the mean time of failure
is about five month).
|
|
|
|
We don't want the input change any state on the linkset and will
drop them if we think our application is not reachable.
|
|
We need some way to forward the failure of one link to another but
they are not normally routed so we can not send a TFP. Right now we
will simply stop responding until both links are up. This should make
the SLTM fail and trigger a re-alignment on both sides. The key here
is that the 2 * SLTM timeout needs to be higher than it takes to re-align
the link. I'm not sure this code will work.
|
|
Right now for the virtual trunk 0x0 and 0x1F is blocked, for the
E1 like interface we have 0x0 and 0x1 blocked. This should start
to be configurable in the future.
|
|
With this commit we can have more than 30 endpoints that will work. We
ignore the blocked endpoints 0x1 and 0x1f for each trunk and calculate
everything from the right start point.
|
|
* Upstream has a separation of BTS and NET side for RTP ports and
can allocate them dynamically.
* Upstream has gained the concept of trunks. We will now have various
trunks to connect audio things.
* We will now be able to utilize multiple trunks and have the endpoints
used properly.
|
|
In a backtrace it is confusing to see variables called link and link
and one is a mtp_link and the other is a mtp_link_set.
|
|
Right now we assume that the source of an application with
SCCP state tracking is a linkset. Send the message to that
linkset.
|
|
For the SSP functionatilty we will need to have the timers T18
and T20. In the period of T18 we will collect TFP/TFR/TFA for the
reachable nodes of the system. Each of this node will send us a TRA
when it is finished. Right now we assume to only have one node and
stop the T18 after the TRA of this node. Then we would need to send
the TFP/TFR we have collected. On the expiry of the T20 timer we
will need to send our TRA and notify local users.
For more complex routing we will need to have a shared routing
cache and remember which SSNs and OPCs are reachable and have inter
linkset notifications.
|
|
This new interface allows to have multiple linksets, msc
connections and ways to connect those in one instance of
the osmo-stp. Forbid to reset linksets without an app.
|
|
This is a interim solution until we have the new and all mighty
new config file format. This should work for now, makes the init
abit harder to understand though.
|
|
This should avoid us getting an error as we are sending the
SLTM too fast. In one way this makes sense, on the other hand
we already have too many states and should remove some variables
|
|
This change allows to run multiple links over the same SCTP
connection or multiple SCTP connections. It does not yet
support fail over handling or load balancing but that seems
possible now.
|
|
|
|
We might want to be able to change the type of a link at
runtime. Decouple the link and the actual type of the link.
|
|
Stop hardcoding the supported ssn's inside the mtp_layer3.c and
make it possible to allow to configure this in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is in preparation of splitting the MSC part and the
nat logic for the upcoming config rewriting.
|
|
We want to be able to support multiple links over different SCTP
connection and in the future also over the same connection. This
is the first step to separate the SCTP connection handling from the
link handling inside these messages.
|
|
|
|
In preparation of the VTY code change, make the mtp linkset
a child of the bsc.
|
|
Allocate the bsc with talloc to have a nice root context for
everything in the system.
|
|
|
|
Start removing the static names for the linkset
|
|
Move the MSC related information out of the bsc_data and update
the code to use this BSC configuration. This is greatly cleaning
up the code and in theory there might now be two BSC and two MSCs
that one application can handle (minus the missing VTY config)
|
|
|
|
This can be useful to test out certain messages without having
any of the linksets be fully connected. It is not possible to
get the result. In the future this code should reply with an
M2UA error message if something went wrong.
|
|
Add an option to decide if we should handle GROUP BLOCK and RESET
messages inside the STP or if we should forward those as well.
|
|
The mib was patched to send link up/down in case of failures,
only put a link service when the MIB tells us the link is
up, the failure case should only happen for remote links
failing. We will reset and go through link alignment.
|
|
|
|
|
|
Remove the _set from the API, call it from the mtp_link.c. This
will fix the statistics for outgoing packets.
|