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
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
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
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
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
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
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
mgcp_client.h offers functions to generate endpoint names for wildcarded
request. This is used in osmo-bsc, lets now also add a function that can
generate e1-endpoint names.
Change-Id: Iec35b5bae8a7b07ddb3559f7114a24dcd10e8f14
Related: OS#2547
SDP is an optional part of MGCP messages. Do not fail when there is no SDP part.
Practically this is useful to compose simpler MGCP responses from TTCN3 tests.
osmo-mgw itself always includes SDP, so there is no real impact on operating
libosmo-mgcp-client with osmo-mgw from osmo-bsc or osmo-msc.
Change-Id: I608001626459ea72415fb142f857550bbb90c683
So far, both osmo-msc and osmo-bsc always pass endpoint names of the form
'...@mgw' to osmo-mgw. Allow configuring the 'mgw' part.
Note that the actual way to pass a differing name is to pass a composed
'rtpbridge/*@foo' to mgcp_msg_gen() in the struct mgcp_msg. So this merely adds
a common VTY config for the domain name part, changes to clients are necessary.
- add mgcp_client_rtpbridge_wildcard() (useful for AoIP endpoints)
- add mgcp_client_endpoint_domain() (useful for SCCPlite endpoints)
- add mgcp client vty cfg 'mgw endpoint-domain NAME'
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
Also: our MGCP clients osmo-bsc and osmo-msc use code dup to compose the
initial 'rtpbridge/*@mgw' rtpbridge wildcard. It should be defined by this API
instead.
This will be used by:
* osmo-msc I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
* osmo-bsc I492023e9dca0233ec0a077032455d9f2e3880f78
After these, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint on two separate osmo-mgw instances:
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
osmo-mgw-for-msc.cfg:
mgcp
domain msc
osmo-msc.cfg:
msc
mgw endpoint-domain msc
There can also be '0@bsc' and '1@msc' endpoints on one single osmo-mgw instance with:
osmo-mgw.cfg:
mgcp
domain *
and same osmo-{bsc,msc}.cfg as above.
(By default, everything will still use '@mgw')
Change-Id: Ia662016f29dd8727d9c4626d726729641e21e1f8
Remove public API that makes no sense anymore and is dead code.
I see the dropped API as a dead-end initial misconception of the early mgcp
client, and it doesn't really make sense to drag this stuff along. It has not
been used by osmo-msc,-bsc for a long time now, and just confuses the reader.
It is public API, yes, and older versions of osmo-msc / osmo-bsc will not be
able to compile against this, but even if it did, the resulting MGCP client
would not work with the current osmo-mgw: this API is still based on the
premise that the MGCP client dictates the MGW endpoint numbers, a concept that
cannot be used with the current osmo-mgw. Instead, osmo-mgw expects a
wildcarded endpoint upon CRCX and assigns its own endpoint names.
Also, the bts-base configuration is unused and a legacy of when osmo-bsc_mgcp
had explicit BTS and CN sides.
Change-Id: I98a9f1f17a1c4ab20cea3b08c7d21663592134d6
Instead of just silently truncating the conn ID if it is too long, rather
verify its length and return an error where applicable.
Adjust expected test output.
Change-Id: If2a1aab1f13e771a6705c430e3c75bd42477a23b
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
After call to mgcp_find_section_end(), actually check the proper variable to
evaluate its return value.
Show in mgcp_client_test output that the parsing errors are fixed, and enable
the assertion that no tests should fail.
Change-Id: I62a2453cd9e2e7d5408423161fa65ec9c9989f98
To show how the current code fails, add test_sdp_section_start() to
mgcp_client_test.c, and temporarily accept failing output. This will be fixed
in change I62a2453cd9e2e7d5408423161fa65ec9c9989f98.
Change-Id: I5c6d3566b8f6dbf04c0cd8b127423f5295c19f8d
So far, if an MGCP message is sent, the transaction gets enqueued, but there is
no way to end the transaction other than receiving a valid reply. So, if the
caller decides that the transaction timed out and tears down the priv pointer
passed to mgcp_client_tx, and if then a late reply arrives, the callback will
dereference the invalid priv pointer and cause a segfault. Hence it is possible
to crash an mgcp_client program by sending a late response.
Furthermore, if no reply ever arrives, we would keep the pending response in
the list forever, amounting to a "memory leak".
Add mgcp_client_cancel() to discard a pending transaction. The caller can now
decide to discard a pending response when it sees fit (e.g. the caller's
timeout expired). This needs to be added to OsmoMSC and OsmoBSC.
Add mgcp_msg_trans_id() to provide an obvious way to obtain the transaction id
from a generated MGCP message.
No public API is broken; but refine the negative return code from
mgcp_client_rx(): return -ENOENT if no such transaction ID is found, and still
-1 if decoding failed. This is mainly for mgcp_client_test.
Implement a test for mgcp_client_cancel() in mgcp_client_test.c.
Tweak internal mgcp_client_response_pending_get() to take only the transaction
id as argument instead of the entire mgcp message struct.
Found-by: dexter
Related: OS#2695 OS#2696
Change-Id: I16811e168a46a82a05943252a737b3434143f4bd
currently the only way to generate MGCP messages is to use
mgcp_msg_crcx(), mgcp_msg_mdcx() and mgcp_msg_dlcx(). All
three function take a fixed set of parameters via their
parameter list. There is no way to add or leave away optional
parameters.
add function mgcp_msg_gen(), this function takes a unified
message struct. The struct features a presence bitmask which
allows to enable and disable parameters as needed. It is also
possible to add new parameters in the future without breaking
the API.
Depends: libosmocore I15e1af68616309555d0ed9ac5da027c9833d42e3
Change-Id: I29c5e2fb972896faeb771ba040f015592487fcbe
The name "mgcpgw_client" referred to an MGCP gateway, which is rather an MGW
(Media Gateway). But this client code is more generally a client for the MGCP
protocol, independently from what the server program is called.
Rename the files as well as the function prefixes to drop the "gw". It is
purely cosmetic and not strictly necessary, but a good point in time for fixes
like this.
osmo-msc build will be adjusted by I093ad02ca0e532f659447c785e09678b3e6f220d.
osmo-bsc build will be adjusted by I6402c7cbe58dacae7630f7f03819f8102e54c699.
These should be applied right after this here is merged to avoid fallout.
Change-Id: I99f7faab637cfcc22ece64a1dbcbe590f2042187
Neels Hofmeyr
Pau Espin
Oliver Smith
Philipp Maier
Neels Hofmeyr