Because of the issue parsing the MGCP request a '\0' was added to
the queue. This lead to the dtmf scheduler believing that a play
was in progress while the playing code didn't play anything. This
lead to the queue to be stuck and nothing being played at all.
Return the number of tones that should be played and stop using
strlen on the tones.
For some equipment it is the easiest to patch the assignment
complete message transported to the MSC. Add a VTY config to
enable this patching, create a testcase that tests that the
original message is truncated. The setting of the VTY option
has been manually tested. The entire system has not been end
to end tested.
Conflicts:
src/vty_interface.c
* Include stdlib.h before the snmp headers to have a free declaration
* Use sprintf(dest, "%s", str) to avoid format string attacks
* Avoid bogus assignment. This pattern was used for marking something
as unused in the past.
This is a hot fix to make CIC reading (and later status) work on
big endian machines. There might be a more elegant way to do it
and I will explore this later.
For the ISUP/MGCP handling we will need the same code, extract it
from the msc_connection. For the reading code callback is introduced
that will pass the MGCP message to the higher layer.
The RSIP has morphed from a global reset, to a per trunk reset and now
it is possible to reset specific ranges on a trunk. This will be used by
the ISUP filter code in the STP.
For legacy range == -1 will be used. This will reset all endpoints
on the trunk. Use OSMO_MAX on endpoint and number of endpoints in case
number_endpoints is 0.
This code will now free everything from the endpoint to endpoint + range
including endpoint+range.
There were several changes in the upstream code. These include
statistics, DTMF/RQNT, changes in the parsing code and re-transmission
handling. The last item is the main reason to do the merge now.
Create a simple queue for pending DTMF tones, play them using the
MTN API, and then send the next tones once the playback is complete.
The callback and scheduling is done from the same context so no locking
needs to be done.
Introduce a callback for the request and forward the signalrequest
to the callback. This is not a full implementation of MGCP RQNT.
Manual merge and backport from OpenBSC.
For a linkset define where SCCP/ISUP should be send. This config
should probably move up to the application part when real work on
the routing is done. Right now the sccp_opc/sccp_dpc need to stay
inside the mtp_layer3.c to be able to send a TFA for the reachable
OPC and it is easier to keep both (dpc/opc) in the same file.
* This changes bss_patch_filter_msg to return -1 or BSS_FILTER_DTAP
for DTAP messages. This way app_forward_sccp should continue to behave
the same besides now looking into DTAP messages.
* Introduce a direction in case we want to advertize FR into the BSS
side and HR into the other direction.
* Patch AMR HR3 and Fullrate/Halfrate capabilities in the Bearer
Capabilities. Add a test case that is patching the bearer capabilities
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.
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 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.
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.
Holger Hans Peter Freyther
Harald Welte