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.
It can be difficult to find the Timeslot/Multiplex for a higher
number virtual trunk. This would be used by default, but normally
the endpoint would be blocked on the switch already.
Instead of assuming which endpoints are blocked there is now a VTY
command to block those. Clean up the init of the trunks, the only difference
between Virtual and E1 is in the way to calculate the start port.
Reduce the number of endpoints to 32, 31 is the last one that can be
used on the E1 trunk, otherwise we move into TS 0 of the following trunk.
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.
The MSC workaround was added in 5960ba387a
but it has never worked as in 8fd28dbbe6 (earlier)
we were checking for link->conn != conn in the dispatch method. Move the
code over to the generic dispatch and check for NULL.
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).
Instead of hardcoding which timeslot is blocked we will just
use the blocked flag in an endpoint. This should fix call
handling for CIC on the trunk config.
We don't let CGUAs pass when handling circuit blocking and
unblocking locally. But we did let a CGU go through and then
we never sent the response back to the sender. Respond to a
CGU with the same content.
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.
After the expiry of T18 we should have collected the routing data
from the adjacent links and should be able to send SCCP packages
to remote endpoints.
The MSC we test is not sending an ASP Active when the
link is unblocked. If the m2ua_link has no connection
associated we will forgive the MSC and active it.
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.
Configure the routing of audio ports if mgcp_mgw is configured
to do this. This allows to have multiple trunks, make virtual
ports go to a specific trunk as well.
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.
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
Only restart the link test on this link in case the link
is present and we need to do things. The link up/down should
be controlled in a different way.
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 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.
Simplify the code and remove the standalone udt_relay application,
the job can be done with cellmgr_ng. This will happen after we have
settled for a new config file format.
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.
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.
The manpage says that -1 is the indication for error but on 2.6.12
we just ended up in a infinite loop as select shows the socket as
readable but a recvmsg does not give any data.
We do not have the multiple callbacks from SNMP under control
and we can only save the last request if the SNMP Session is
inside the link. This is mostly a workaround for Net-SNMP and
the missing documentation on the async functionality.
The semantic of a block is to take the physical
link down, call mtp_link_down and to make sure
that the link remains down and no packets are
forwarded there. The unblock call will reset the
link and this should get it back into operation
again.
This is the easiest way to support multiple links over UDP.
Specify the number you want and they will be initiated. All
these links will run via the same UDP port.
The VTY interface is used for three different application and not
every option will make sense for every app. In the long run we will
split the vty interface but for now we just qualify the application.
Do not block the application when doing a SNMP request. Work
with the results coming back from the callback. Right now a
link can only be taken down and up.
This is fixing a crash that is caused by the MTP link going
down/up and the main routines asking to send a reset to the
MSC. The sending of a reset is triggering the ping/pong
timeouts. In case there is no MSC connection we could crash.
Instead of sending SCCP TFP/TRA as a response to a TRA
the code will now send one as a response to the first
SLTA we receive in the linkset on the first link.
Holger Hans Peter Freyther
Harald Welte