A client may know the IP address during CRCX but not yet the port, or it
may simply want to hint an initial IP address so that the MGW can better
guess when allocating a local IP address.
Related: SYS#6657
Change-Id: I30165dbac5e484011d0acf46af36f105954a501d
A user reports crashes of osmo-bsc upon EV_MDCX. It turns out that there
is a lot of error reporting and a distinct possibility to get a NULL
return value because of external input. Terminate the FSM instead.
FSM termination is the proper way to report a bad error, it signals the
parent_term_evt to the FSM parent, which will then be able to act on the
failed MGCP operation.
Related: SYS#6632
Change-Id: Ia5d8a9aff565399a85a5b116d7029fedcab234e0
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: I98a3c0d5cfda2c4b020652efb4f445f8288342b6
At the moment the MGCP Client only supports one MGW per application.
Depending on the requirements of the application one MGW might not offer
the performance needed. Lets add support for an MGCP Client pool that is
backward compatible to existing applications.
Change-Id: Icaaba0e470e916eefddfee750b83f5f65291a6b0
Related: SYS#5091
To see state transitions and events on LMGCP DEBUG logging, actually set
the log_subsys of the mgcp_client_fsm.
Related: SYS#5529
Change-Id: I6e84d5f7b85752a7a54f17be1d074b01d1467f26
Upon mgcp_conn_delete(), we unparent the FSM instance. Instead of
setting the talloc ctx to NULL, place the deleting conn under the
struct mgcp_client talloc ctx.
Related: SYS#5529
Change-Id: Ia12749e0d7d520f24a967c2df9a4651267e1019e
Sending a DLCX upon FSM cleanup is not unusual. Move the log about that
DLCX to INFO, and also print the endpoint and conn identifier.
Change-Id: Id723d949f101b66fb75296d01489d9dac350c7c8
If the mgcp_client_fsm gets terminated in ST_DLCX_RESP, it has already
sent a DLCX to the MGW. So do not send a second one.
I noticed the duplicate DLCX for the same endpoint conn identifier while
running TTCN3 tests and watching the network trace of test teardown.
Change-Id: I35e415f67946b73c74408afe265618cfe4f72b0b
The error message: "abrupt FSM termination with connections still
present, sending unconditional DLCX..." implies a more serious problem
than in actually is. Even when connections are present on the
mgcp_client_fsm while it terminates, normal operation is still possible.
Lets change the loglevel to NOTICE and remove the "aprupt" from the
phrase.
Change-Id: I9749c024e208835bd4188bace13f723008de54c8
Related: SYS#5082
This way we can avoid the runtime overhead of checking whether or not
it is initialized over and over again. It also brings this code more
in line with other users of osmo_fsm_register().
Change-Id: Ia73ba8e46c13d925e88203e08a8966839e573183
API doc: require osmo_fsm_set_dealloc_ctx().
mgcp_client during delete: do not reparent the FSM when it is already
terminating.
I have recently discovered a vulnerability: if an endpoint FSM deallocates
during event handling of a successful MGCP response, this causes a
use-after-free; and once that is fixed, a state change on the already
terminated FSM causes a pointer corruption by using already cleaned data
structures. osmo_fsm_set_dealloc_ctx() fixes the use-after-free, and
osmo_fsm_set_term_stops_actions() fixes the pointer corruption.
Related: Ib7fce7b7d54dfb87af97544796680919e5929a50 (osmo-bsc),
I08c03946605aa12e0a5ce8b3c773704ef5327a7a (osmo-msc)
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Change-Id: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3
During FSM instance cleanup, a DLCX message composition may fail if a preceding
received MGCP message was missing parameters. If that occurs, don't crash, just
log an error and deallocate.
Change-Id: Ic1c3c4deeb4703b60e870af9d5d7be216a87fff8
During MDCX state is already changed to ACTIVATING but we still want to
send the local CID back to announce that we still use same local CID.
Change-Id: If182a48743ebe03f97caf9034e49b9947014bdf9
Move mgw_endpoint_fsm from osmo-bsc here as osmo_mgcpc_ep_fsm. Apply various
renames for consistency. Use osmo_tdef from libosmocore instead of osmo-bsc's
(so far) local T_defs API.
Change T23042 to T2427001, which is a slightly less arbitrary number and
slightly more extendable in the future (2427 corresponds to the default MGCP
port at osmo-mgw, 001 is the first MGCP timer and so far the only one).
Change-Id: I9a3effd38e72841529df6c135c077116981dea36
RFC3267 specifies two framing modes for AMR packets. An octet aligned
mode is specified where all fields of the AMR packets are aligned to
octet boundaries. The second framing mode is the bandwith efficient mode
where the fields are directly packed one after another.
- add paring/generation functions for related SDP fmtp parameters
- add conversion function to convert AMR payload
Depends: libosmo-netif I5b5a0fa644d8dbb1f04f9d7e35312683c7b3d196
Change-Id: I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
Related: OS#3807
Add conn_mode to struct mgcp_conn_peer, to allow setting an explicit connection
mode instead of implicit MGCP_CONN_RECV_ONLY / MGCP_CONN_RECV_SEND depending on
remote RTP port presence. Default to old behavior if this is left unset.
Rationale:
For IuUP Initialization, osmo-msc currently still uses a hack at osmo-mgw to
echo the IuUP Initialization back to the sender as an ACK. For sanity checking
reasons, this is done iff the CRCX created the CI in loopback mode. So, in
order to be able to switch to the mgcp_client_fsm in osmo-msc instead of
"manual" MGCP message composition and yet still be able to support IuUP and
IuCS, we need to be able to set the conn mode upon CRCX to loopback.
If we merged the IuUP patch (which is already on a branch somewhere) to
osmo-mgw, we wouldn't bother with this patch, but adding this conn mode choice
has these benefits:
- post-IuUP-fix osmo-msc versions can interop with older osmo-mgw IuUP for
IuCS.
- It is conceivable that some MGCP clients prefer explicit conn modes instead
of the implicit MGCP_CONN_RECV_ONLY / MGCP_CONN_RECV_SEND choice. This opens
the possibility to switch between conn modes with MDCX messages.
Change-Id: I26be5c4b06a680f25f19797407ab56a5a4880ddc
So far, MGCP_CONN_ID_LENGTH was often used as exactly the length of the
Connection Identifier. To indicate this length as a maximum, introduce the
MGCP_CONN_ID_MAXLEN and use it everywhere. Keep the old name as an alias.
Change-Id: I1117003c7614e98535d5c201d002e459c01bdc3f
The change Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57 has replaced the
functions make_crcx_msg_bind() and make_crcx_msg_bind_connect() with
make_crcx_msg() and add_audio(). When a bidirectional connection is
needed, the user calls add_audio() to add the remaining connection
details. Unfortunately add_audio() leaves the conn_mode struct member
unchanged. Which means the connection is still at MGCP_CONN_RECV_ONLY,
which will instruct the MGW not to forward any of the received packets.
- Make sure that conn_mode is set to MGCP_CONN_RECV_SEND when
add_audio() is called.
Change-Id: Id12de37797de5af5cc447642d2fbb1af7de680df
Closes: OS#3511
The format is
CRCX ...
C: ...
M: ...
X-Osmo-IGN: C
So far the only ignorable element is C, i.e. the CallID. Any other items may be
added in the future.
(I initially intended to also add '@' to ignore the endpoint name's domain
part, but in the osmo-mgw code base the domain part is verified long before any
additional headers are even parsed, so sparing that refactoring for now.)
The intention is that osmo-bsc will issue "X-Osmo-IGN: C" for all SCCPlite
calls, because we are unable to retrieve the CallID that the MSC sends to
osmo-mgw for the network side of the endpoint.
Testing with a specific SCCPlite MSC, I actually observe that all CallIDs are
1, even for concurrent calls. So, an alternative hacky solution would have been
to always pass CallID == 1 for SCCPlite connections from osmo-bsc.
Related: I257ad574d8060fef19afce9798bd8a5a7f8c99fe (osmo-bsc)
Change-Id: Id7ae275ffde8ea9389270cfe3db087ee8db00b51
Both make_crcx_msg_bind() and make_crcx_msg_bind_connect() were mostly
identical. Rather, compose the CRCX bits in one common function and just add
the audio bits in another.
Prepares cosmetically for adding X-Osmo-IGN header.
Change-Id: Ie51cc86e90ffeca5b66bcb8f6db0d389241abe57
The regular version of the mgcp_client supports the configuration of of
custom payload types. In case some corner cases require a specific
dynamic paylod type number that is not according to 3GPP standards has
to be used the user can override the standard settings. However the fsm
based variant of the mgcp_client does not have that feature but it
should have it as well.
- add struct members for ptmap config.
- pass configuration values down to the underlying magcp client.
Change-Id: If176a3719dd9e888da16196d5fc0bdb53cc2a5f2
Related: OS#2728
Related: OS#3384
The current implementation does not support any way to influence the
codec that is negotiated via SDP or LCO. The client statically
negotitates AMR on an invalid payload type number. Also we ignore
any codec information in the responses.
- Add struct members to allow setting of user defined codec information.
- Add struct members to retrieve parsed codec info from responses.
- Add code to generate codec information in SDP
- Add code to parse SDP codec info in MGCP responses
Change-Id: I78e72d41b73acfcb40599a0ff4823f17c3642059
Related: OS#2728
Related: OS#3334
Return the CI string allocated by the MGW and sent back during CRCX ACK.
So far the CI that identifies one connection of an MGW endpoint is "hidden"
behind mgcp_conn_* API. This CI string is however very interesting, for
logging, to be able to correlate with MGCP messages in network traces.
For osmo-bsc, there is an upcoming mgw_endpoint_fsm that will log the CI string
using this function.
Change-Id: I0c802c0cc3fa0aae9558bd7f15aad1cb9a8b12b2
Starting connections in loopback bode may cause confusion at the
receiving end when the connection is switched from looback into
an actual send-receive connection. The reason for this is by this
the SSRC of the RTP stream will suddenly change. For the majority
of usecases it is not necessary to loopback the incomming packets
back to the receiver in the beginning. So lets use receive-only
as a safe default.
- use MGCP_CONN_RECV_ONLY instead of MGCP_CONN_RECV_LOOPBACK
Change-Id: I44178434ee497bc1d5e9d5f6d92c13c1a09ae241
Related: OS#3104
The enum defining the event and state identifiers is prefixed with
"bsc_".
- coose a more conceise prefix
Change-Id: I662d8e4328911610e7d1943f1b623e96c3a8b3c1
The FSM lacks a proper definition of the FSM event names. This causes
problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Change-Id: Ic0990abea2e9fd92546e7b337b5ff3d6f0866321
Related: OS#2924
the client API is not very intuitive and requires a lot of extra
care when it is used from an osmo-fsm.
- Add an FSM that permits comfortable handling of an MGCP
connection.
Change-Id: I887ce0c15a831dffeb6251a975337b83942af566
Pau Espin
Neels Hofmeyr
Harald Welte
Philipp Maier
Neels Hofmeyr