Converting from osmo_fd to osmo_io allows us to switch to the new
io_uring backend and benefit from related performance benefits.
In a benchmark running 200 concurrent bi-directional voice calls with
GSM-EFR codec, I am observing:
* the code before this patch uses 40..42% of a single core on a
Ryzen 5950X at 200 calls (=> 200 endpoints with each two connections)
* no increase in CPU utilization before/after this patch, i.e. the
osmo_io overhead for the osmo_fd backend is insignificant compared
to the direct osmo_fd mode before
* an almost exactly 50% reduction of CPU utilization when running the
same osmo-mgw build with LIBOSMO_IO_BACKEND=IO_URING - top shows
19..21% for the same workload instead of 40..42% with the OSMO_FD
default backend.
* An increase of about 4 Megabytes in both RSS and VIRT size when
enabling the OSMO_IO backend. This is likely the memory-mapped rings.
No memory leakage is observed when using either of the backends.
Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a
There is considerable code complexity in place for this ancient hack.
It dates back to 5ea1bc77a3
"
mgcp: Allow to freely control the a=fmtp line for experiments
In case of AMR one can specify the available codecs out-of-band. Allow
to configure this line statically in the configuration file.
"
Looking in mgcp_test.c output, the fmtp-extra tests do not even make
sense: they result in fmtp for pt=126 being added, even though there is
no payload type 126 listed in the SDP...
Related: OS#6313
Change-Id: Icee0cd1f5a751fa760d5a9deca29089e78e7eb93
Removing the duality of codecs[] and ptmap[] in structs mgcp_msg,
mgcp_response and mgcp_conn_peer has removed the need to "map" from
codec type enum to payload type number. They are stored together now.
Remove functions that are no longer used.
None of our osmocom users of libosmo-mgcp-client call these functions.
Change-Id: I84e5285831397c992af59deee12dea8458d16cc6
codecs[] is an array of enum osmo_mgcp_codecs.
ptmap[] is an array of { enum osmo_mgcp_codecs, unsigned int ptmap }.
MGCP lists first a bunch of payload type numbers and then specifies them
again for details, like the numbers 112, 96, 3 in this example:
m=audio <port> RTP/AVP 112 96 3
a=rtpmap:112 AMR/8000
a=rtpmap:96 VND.3GPP.IUFP/16000
a=rtpmap:3 GSM-FR/8000
So far we keep these lists in two separate arrays:
- codecs[], codecs_len stores the 'm=audio' list
- ptmap[], ptmap_len stores the 'a=rtpmap' list (and may omit some
elements present in codecs[])
This applies to both struct mgcp_response and struct mgcp_msg.
These are semantically identical, and the separation leads to checks,
conversions and dear hopes of correct ordering.
So let's keep only one list with both codec and payload type number in
it. The 'm=audio' list establishes the order of the pt numbers, and the
'a=rtpmap' list adds codec information to the established entries.
In the internal API structs mgcp_msg and mgcp_response, just drop the
codecs[] entirely.
In public API struct mgcp_conn_peer, keep the codecs[] array, mark it
deprecated, and provide a backwards compat conversion: if any caller
invokes mgcp_conn_create() or mgcp_conn_modify() with codecs[] still
present in the verb_info arg, then move codecs[] entries over to the
ptmap[] array in a sensible way.
(BTW, even mgcp_conn_create() and mgcp_conn_modify() are never called
from outside of libosmo-mgcp-client in any of our osmo-cni programs;
users call osmo_mgcpc_ep_ci_add() and osmo_mgcpc_ep_ci_request(), which
in turn may pass user-provided codecs[] lists on to mgcp_conn_create() or
mgcp_conn_modify().)
Tests for parsing the MGCP response are mostly missing. They will be
added in upcoming patch I842ce65a9a70f313570857b7df53727cc572b9e6,
because they will be using only the new ptmap API.
Related: OS#6171
Change-Id: I798e02c6663376d3d52f4a74fc4b32411ce95bed
The `keepalive` feature in libosmo-mgcp-client allows scheduling periodical
queries on the MGCP layer in order to make sure it is reachable and hence
obtain information on the state of the MGCP link.
This patch only uses it to print the status on the VTY, but it will be used
too in a follow-up commit by the MGW Pool when picking an MGW from the pool:
MGWs whose link is considered to be DOWN are skipped.
The feature consists of:
- A `keepalive request-interval` which will trigger a transmission of an MGCP
AuditEndpoint command targeting endpoint with name `keepalive request-endpoint`.
This interval is updated every time any message is transmitted in the MGCP
link, meaning the MGCP AuditEndpoint message is only triggered if no message
has been transmitted since `keepalive request-interval` seconds ago.
- A `keepalive timeout` considering the MGW to be non-reachable (link DOWN) if
no message is received over that amount of time.
The `keepalive` parameters are to be preferrably configured so that
"keepalive request-interval" * 2 < "keepalive timeout".
Example VTY configuration of `keepalive` feature in libosmo-mgcp-client:
----
mgw 0
...
keepalive request-interval 20 <1>
keepalive request-endpoint null <2>
keepalive timeout 50 <3>
----
<1> Transmit an MGCP AuditEndpoint message to the MGW if no message has been
sent to it over last 10 seconds
<2> The MGCP AuditEndpoint targets the `null` endpoint. This is a special
endpoint available at OsmoMGW for those purposes, but any available
endpoint can be configured and used instead.
<3> Consider the MGCP link to be DOWN if no message is received from the
MGW over the last 50 seconds
NOTE: The `keepalive` feature is disabled by default, and must be explicitly
configured in order to enable it.
Related: SYS#6481
Change-Id: I3dc74c78548d017f272da863d5282dc5e0020ca3
This is a special endpoint which can always be audited. This is useful
for clients who wish to submit requests to osmo-mgw periodically to find
out whether the MGW is still reachable. This endpoint will be used by
libomso-mgcp-client as default target endpoint to implement such
feature.
This "null" Endpoint is osmo-mgw specific, not described in MGCP specs.
Related: SYS#6481
Change-Id: Ia409b16e9211e6261e2e0f21288544289d6f3733
So far, the users of the old non-pooled API were in charge of allocating
the struct mgcp_client_conf by themselves, then init them using
mgcp_client_conf_init(). This causes a major problem, since it makes it
difficult to extend the struct mgcp_client_conf structure to add new
features, which may happen frequently.
The MGW pool API doesn't have this problem, because the struct
mgcp_client_conf is allocated as parts/fields of private structs defined
in internal headers. Only pointers to it are used in public headers.
Since it still has to internally initialize the conf fields, we still
need the API to initialize it internally, and hence why is it marked as
DEPRECTED_OUTSIDE instead of DEPRECATED.
While some programs already moved to the new MGW pool infrastructure,
they still use the old APIs to accomodate for old config files in order
to be back-compatible, hence most users of libosmo-mgcp-client are
affected.
Introduce an API to allocate the conf struct internally, which, while
still breaking the ABI, allows for a more relaxed update path where it's
possible to extend the struct mgcp_client_conf at the end.
Eventually the non pooled API should be gone and the struct
mgcp_client_conf can then be moved to a private header, but for now
let's add this small feature to avoid major ABI breakage.
Change-Id: Iba0853ed099a32cf1dde78c17e1b34343db41cfc
Unfortunately OsmoMGW was never really tested with multiple different
codecs on either side of the connection. While OsmoMSC and OsmoBSC only
assign exactly one codec on each side this has never been a problem,
however it might become a problem when a call agent assigns multiple
codecs on one side. This has been observed in a setup where OsmoMGW had
one leg towards an external call agent. Also due to recent upgrades to
the TTCN3 tests we are now able to simulate different codecs on both
sides to pinpoint issues.
Testing has shown that OsmoMGW has difficulties with multiple codecs.
The reason for this is that the function that makes the codec decision
was not fully finished. So let's finish the codec decision function and
let's also use that decision when patching the payload type of outgoing
RTP packets.
Related: OS#5461
Change-Id: I6c3291f825488e5d8ce136aeb18450156794aeb5
add_sdp(), add_lco():
- do not msgb_free() within these functions. Just return error, and move
the msgb_free() to the caller.
- when failing to write to the msgb, directly return error.
Change-Id: I904d56f56053952c2ebbbe5dca744fafa32b333e
in mgcp_codec.c we have a function mgcp_codec_pt_translate that is used
to find the equivalent payload type number on an opposite connection.
This is quite specific and the resulting payload type number may still
belong to a codec that might require some form of conversion.
Lets refactor this so that the function just finds a convertible codec
for a given connection. This also opens up other usecases. The payload
type conversion like we did it before can then be done with a few lines
in mgcp_network.c
Related: OS#5461
Change-Id: I085260a2ca8cfecdb58656b7a046c536189e238d
The function mgcp_codec_pt_translate is very strict when comparing the
codecs to each other to find a matching payload type number to be used
on the egress side.
This poses a problem when one side uses AMR in bandwith-efficient, while
the other side uses AMR in octet-aligned payload type format. To the pt
translate function the difference in the payload format will appear as
if the codec were different and eventually the payload type number
cannot be translated.
since osmo-mgw offers conversion between the payload type format it
would be no problem to ignore the payload type format when making the
translation decision. The only exception here would be if one side would
announce AMR two times, the first time with octet-aligned and the second
time with bandwith-efficient format. Then we would have to use the
payload type number from the exact match. (and skip any formatconversion)
To archive such an optimized decision we will first go through the codec
lists and perform an exact match. If we don't get a match we go through
the codec lists a second time, but this time we ignore the payload
format.
Change-Id: Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d
Related: OS#5461
This reverts commit e0058b7207. The reason
for this revert is that the solution in the reverted patch does not
cover a situation where the other side announces both payload formats at
the same time.
It could be that the end facing to a transit network announces both
formats under two different payload types. In this case no conversion
would be necessary. Depending on the input format the output would be
send to the transit network under the payload type that matches and no
conversion would happen at all.
This revert re-intruduces the problem that was fixed in the patch
before. Therefore it must be merged together with the follow up patch
(Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d) that contains the proper fix.
Change-Id: I0b2854ef2397f38606fab3425be586a3d0ca27d1
Related: OS#5461
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I4bc03bdc1f2de2574558e2ad753e116486993a7f
While adding CSD, this failed for me in add_lco without a descriptive
log message, so add more error messages.
Related: OS#4393
Change-Id: I4873a2db95525aab3e13046b645dd8f90e951466
Before this patch, the free CID with the smallest number was always
selected to be used. This caused more or less the same subset of CIDs to
be used all the time, while the CIDs with bigger numbers were mostly
unused.
Let's distribute the use so that all CIDs are used roughly the same.
This has the advantage, among others, that the same CID will not be
re-used immediatelly after being freed if a new call is established.
It is useful to leave the CIDs unused for some time since the other end
peer may know of the call being tear down with some delay.
Hence if a new call is established immediately after the CID was
released, the same CID would be allocated and passed at the peer, which
would then detect that the old call (in its view still active) would
already make use of that remote CID.
Change-Id: I9dfbcc5e4b4c61ce217020e533d68fbcfa6b9f56
Related: SYS#6161
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
Let's use the port part of the struct mgcp_rtp_end->addr field instead
of keeping it separate. This makes it easier passing around and
using/checking the RTP remote address + port, and avoids confusion
having to check stuff outside of the address, with its port part
potentially unset.
Change-Id: I294eb5d85fae79bf62d36eb9e818426e187d442c
This makes all lines operating on rate groups way shorter. The "ctrg"
naming is already used in tons of places in osmocom code.
Change-Id: I745eddbf66e7d811bb73c8ae9bb54ea93073c71b
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I938669a78b4afa808ca4f741aee9919944aeb7f6
AMR that has the payload format bandwith-efficient is the same codec as
AMR that has the payload format octet-aligned. Its the same codec, and a
comparison of the codec info with the function codecs_same() should
return true (=equal).
The affected function codecs_same() is used by mgcp_codec_pt_translate().
When the egress payload type number is looked up, the ingress and egress
codec information is compared. When one end is using AMR in
bandwith-efficient format and the other end is using it in
octet-alingned format. Then the codec still must be recognized as the
same codec. Othersiwse the payload type number translation would not
work, even though the codec is the same on both sides.
Change-Id: I64731570c287a75d39c79c10e1bc09a37bdd54d6
Related: SYS#5834
There is no obvious reason why we would want to complicate the code by
caching pointers, since pointer traversal is probably not a performance
bottleneck, and if it is we should rather take a look at our dozens of
linked lists first..
Change-Id: I2456ba63598f76200d53e00223abf60bb36a49c0
Usually only one MGCP client per application is present. Then the log
lines from mgcp_client.c will be distinguishable without additional
information. When the application is using a pool of MGWs, then the
various MGCP Client instances become hard to distinguish.
- Add a possibility to set a description (name) for each MGW pool
member. When no description is set, use the domain name.
- Output the pool member name on each log line in mgcp_client.c
and mgcp_client_pool.c
Change-Id: I53ff5445c8e5faffa4ef908ffb1fdb1f47ea2904
Related: SYS#5091
The two callback functions policy_cb and change_cb are essentially dead
code. They also make the code more difficult to read and understand.
Lets remove them.
Change-Id: I19f67db1c56473f47338b56114f6bbae8981d067
We are currently counting events in rate counters, but there is
currently no way to get a sample of the current situation of the trunk
usage. In particular how many endpoints are currently in use.
This is a corrected version of:
Ib7b654168dc3512f55e45cc4755dc1f6f423d023
Change-Id: I6d3a74f6087512130d85002348787bffc672de81
Related: SYS#5201
This reverts commit 6bad138c96.
Reason for revert: heap-use-after-free during 'make check'
in mgcp_test.c test_retransmission()
Change-Id: I96792a719c9c7273676ab9ffe0b9e2aae4c23166
Related: OS#5201
We are currently counting events in rate counters, but there is
currently no way to get a sample of the current situation of the trunk
usage. In particular how many endpoints are currently in use.
Change-Id: Ib7b654168dc3512f55e45cc4755dc1f6f423d023
Related: SYS#5535
the trunk_nr is in struct mgcp_trunk. The trunk number can not be
negative and there is no magic value that makes use of the fact that it
could be negative. Lets use unsigned int to make this less irretating.
Change-Id: I5d0e1d76adb8c92d84331a0aca2496908e41d621
Related: SYS#5535
There is verbose debug logging on MGCP messages sent out to the MGW, but
none on received MGCP messages. Add Rx logging.
Related: SYS#5529
Change-Id: Id76230896aa87c1a12bd5ad87a62430c048a2873
On a deployed osmo-mgw with RTP traffic coming from a thirdparty
RTP source, it was usual to see log messages like following one from
time to time:
"The input timestamp has an alignment error of 159 on SSRC"
Doing a quick traffic analysis showed that the above mentioned RTP
source was generating traffic from time to time containing RTP packets
with the Marker (M) bit.
Those messages were logged because the verification & patching funcions
in osmo-mgw were not Marker-bit aware. Hence, this patch implements
support for Marker bit when handling RTP packets.
The Marker bit is usually used as a start of a talkspurt, and has to be
considered a syncrhonization point, where timestamp and relation to real
time don't need to match with last received RTP packet in the stream.
Related: SYS#5498
Change-Id: I1fb449eda49e82607649122b9b9d983a9e5983fa
use the recently new available API to check both remote address and
port, instead of only the port.
It doesn't make sense to configure a conn as sendrecv if we have no IP
address to send stuff to, similar to what was already being checked with
the port.
Change-Id: I6ce8cf52930d423d3db8c27251be8350a26a4ede
Several log messages showing "Failed to send dummy RTP packet." were
seen in a osmo-mgw on the field. Let's re-use the function to check and
provide more information on what's wrong to ease debugging.
Related: SYS#5498
Change-Id: Iee6ac1f4d24c131e3bf40c37e6fdc252e5208ec8
The functions add_lco and add_sdp assert when the codec string can not
be generated. This is the case when an unexpected codec is addressed in
the input parameter mgcp_msg for mgcp_msg_gen(). Even though the API
user is expected only to use the codec identifiers in mgcp_client.h the
check should not be done with an assert. Instead mgcp_msg_gen() should
just return NULL imediately.
Also all generation functions should not use magic numbers as return
codes. Instead constants from errno.h should be used. It is also
problematic that the return codes from msgb_printf are added up.
Depending. It makes more sense to use an OR operator since msgb_printf
only returns 0 or -EINVAL, so the end result will be -EINVAL if one or
more msgb_printf fail and not just a random negative value.
Change-Id: Ibb788343e0bec9c0eaf33e6e4727d4d36c100017
Related: OS#5119
The constant MGCP_DUMMY_LOAD is used ambigously. Sometimes it is used as
initalizer for an array, sometimes it is used as a single byte. Also the
name is not very expressive. Lets refactor this.
Change-Id: I21d96cefeeb647958bfa1e22a0ea030884746fad
Related: OS#4005
Generated with spatch with this and similat snippets:
"""
@@
expression E1, E2;
@@
- &E2->ctr[E1]
+ rate_c
Change-Id: I53b75ea8a88bc1ae4ceb479ed272865054de9665
This commit contains the bulky work of moving all address parsing to
support IPv6 together with IPv4.
Some specific patches required for full IPv6+IPv4 support requiring
behavioral changes come after this one.
Full Osmux IPv6 support is left out of the scope of this patch.
Depends: libosmocore.git Ie07a38b05b7888885dba4ae795e9f3d9a561543d (> 1.4.0)
Depends: libosmocore.git I59bf4b4b3ed14766a5a5285923d1ffa9fc8b2294 (> 1.4.0)
Change-Id: I504ca776d88fd852bbaef07060c125980db3fdd7
Existing mgcp_client_test code required the '.' to trigger the same code
path, since with this commit we do extra checks and without a dot the
address is not accepted as IPv4 by osmo_ip_str_type().
Change-Id: I936bf57d37f5f0607dfe7fc66c37e424c3793f9b
Due to the internal handling of the trunks it was not possible to allow
an E1 trunk that has the ID 0. However this limitation is no longer
present, so we now can allow an E1 trunk with ID 0.
Change-Id: I302c2007628f607033686e277c407232351e66ad
Related: OS#2659
The file mgcp_internal.h still contains mostly definitions and types
that are relevant for mgcp_network.c and mgcp_protocol.c. Lets give
the network and protocol module its own header files, also move stuff
that does not relate to protocol and network to the appropiate places.
Change-Id: I837eaad771ed7252304db4a81c37953b70766fff
Currently only the endpoint handling for E1 exists, but there is no
actual code behind it that handles the E1 traffic.
Change-Id: I6b93809b5ac7d01af55888347dd787b0bc997ae1
Related: OS#2659
Instead of numerous arguments (buf, len and context data), use a msgb, like
most other osmo programs do, with a msb->cb pointing at a context data struct.
This opens the future for adding/stripping IuUP header data from the msgb
easily.
(Checked to pass current ttcn3-mgw-tests.)
Change-Id: I3af40b63bc49f8636d4e7ea2f8f83bb67f6619ee
Harald Welte
Neels Hofmeyr
Pau Espin
Philipp Maier
Vadim Yanitskiy
Oliver Smith
Eric Wild
Neels Hofmeyr