If an error on the MGW side occurs, the MSC may send out
a DLCX command that contains a wildcarded endpoint name.
Wildcarded DLCX commands are legal in principle but not
in the context of an error on a single endpoint. Apart
from that osmo-mgw is (not yet) capable to handle
wildcarded DLCX command.
The problem is caused by a wrong error handling. When the
first (RAN) CRCX fails the error handling logic tries to
perform a DLCX, but since we did not receive a specific
endpoint name yet, the buffer containing the endpoint name
is still initalized with the wildcarded enpoint name, but
the error handler and the code that generates the DLCX is
not aware of that.
- Perform a check in the error handler function that
checks if a DLCX can be made (a specific endpoint
name is set
- Correct the flags in the code that handles the first
CRCX so that no DLCX is requested in the case of error
Related OS#2882
Change-Id: I64c2a82016d854ad446fd49a5d76a28324e8bd4b
The logtext currently logs the pointer (address) of the string
variable that holds the endpoint name, rather then the endpoint
name itself.
- Use %s instead of %p in format string
Change-Id: I01b3d07aeedd72be60361249a5bf80fbb68b7bb8
Fixes several of these type of warnings:
include/osmocom/core/fsm.h:123:38: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘char *’ [-Wformat=]
LOGP((fi)->fsm->log_subsys, level, "%s{%s}: " fmt, \
^
src/libmsc/msc_mgcp.c:277:71: note: format string is defined here
"CRCX/RAN: creating connection for the RAN side on MGW endpoint:0x%x...\n", mgcp_ctx->rtp_endpoint);
~^
Change-Id: I17b7bed8fc39612286ba66f250b6b26da01d38c0
The higher layers (gsm_04_08.c) are informed errors occur. But it
is not checked if the call was already released. If an error occurs
after the call control stack calls msc_mgcp_call_release() then
the higher layers might already have cleaned up and the code
accesses memory that is already freed (trans)
- fix use after free by guarding the call to mncc_tx_to_cc()
Change-Id: I78f1b6a9149488a4ad3f120c1e190a83c07d4b89
Related OS#2881
Related OS#2882
osmo-msc still uses endpoints that are allocated locally by the
MGCP-Client. Since osmo-mgw now supports the more comfortable,
dynamic variant we should make use of it.
- Replace the endpoint numer allocation by the client with a
wildcarded CRCX. Use the endpoint that is assigned by the
MGW.
Related: OS#2710
Change-Id: Iee3e446b6689626516f01c521abe3d4603cd3e13
When a truncation check (osmo_strlcpy()) fails handle_error()
is called with MGCP_ERR_NOMEM as cause code. Which finally
results in an "out of memory" message. MGCP_ERR_NOMEM is only
used for failed truncation checks, so it makes sense to choose
a message that describes the cause of the problem better.
- rename MGCP_ERR_NOMEM to MGCP_ERR_TOOLONG
- replace error message string
Change-Id: Ifedb85c1933a30b2aa491b495119919f45782e2c
When the FSM reaches ST_HALT it frees itsself and all context
information but it is not ensured that there are still pending
MGW transactions that might hit late and eventually cause a use after
free situation.
- if an MGW transaction is still pending, cancel it.
Change-Id: I8ff55e48a95cc4c556a97ad2593bad1cc1aa69bd
When the MGW does not respond to an MGCP message then the mgcp FSM
terminates, but the CC handler (gsm_04_08.c) is not informed. This
lets the CC handler think that the MGCP connection would be successful,
so it also does not take any action to release the non functional
connection.
- make sure the CC handler is always informed on any kind of
error, especially on MGW timeouts
Change-Id: I3fcd0d71fad53274e82f6d87c80042d06283bc5d
Related OS#2881
Related OS#2882
The FSM (fsm_msc_mgcp) lacks a proper definition of the FSM event
names. This causes problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Closes: OS#2924
Change-Id: I6823756a63b08a71e5518130e49751aa073dbcd2
The MGCP FSM implements a timeout when waiting for the RAN to complete
the call (assignment complete, alerting, connect...). This timeout
is currently set to 10sec. This means if the other end did not pick
up after 10sec, the MGCP connection will be lost while the phone keeps
ringing. When the other end finally picks up, the call gets
disconnected.
This behavior is odd and requires a proper fix. For now increasing the
timeout to 120sec. will decrese the probability that he problem occurs.
- Increas RAN timeout to 120sec (2 min).
Change-Id: I5a11d53f9701d9b11b18d7026ff2241c7c0b57f5
in the current implementation we still use osmo-bsc_mgcp, which
has many problems and is also obsoleted by osmo-mgw.
integrate osmo-mgw and re-implement the current switching using
an osmo fsm.
Depends: osmo-mgw Iab6a6038e7610c62f34e642cd49c93d11151252c
Depends: osmo-iuh I3c1a0455c5f25cae41ee19229d6daf299e023062
Closes: OS#2605
Change-Id: Ieea9630358b3963261fa1993cf1f3b563ff23538
Philipp Maier
Pau Espin
Daniel Willmann
Harald Welte