Commit Graph

201 Commits

Author SHA1 Message Date
Neels Hofmeyr 17b5701f19 mgcp_test: fix false negatives in test output
If one test fails, do not print failure for all following tests as well.

Change-Id: I196880b4b34a672ef45042c25f89bc1684363567
2024-02-06 03:17:50 +01:00
Neels Hofmeyr d0dbda4106 drop cfg 'sdp audio fmtp-extra'
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
2024-02-06 03:04:10 +01:00
Neels Hofmeyr afbe872045 tests/mgcp: add update_exp target
Change-Id: I1ea7e881fe13429762bf31507d8d23fe58e241b3
2024-02-06 03:00:50 +01:00
Neels Hofmeyr c053e07336 Revert "drop (now) unused code"
This reverts commit 2b30cbdfa8.

Reason for revert: Older versions of osmo-msc were actually calling map_codec_to_pt().

Change-Id: Ifff31012b327d40ed0b1559d5cf4f320784a4061
Related: https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master/1792/console
2024-01-11 19:40:27 +00:00
Neels Hofmeyr 2b30cbdfa8 drop (now) unused code
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
2024-01-05 02:44:58 +01:00
Neels Hofmeyr c9df010416 mgcp_client_test: add test_parse_response()
Change-Id: I842ce65a9a70f313570857b7df53727cc572b9e6
2024-01-05 02:44:58 +01:00
Neels Hofmeyr cc2f7937ed client: collapse codecs[] and ptmap[]; allow codec variants
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
2024-01-05 02:44:58 +01:00
Neels Hofmeyr 5d0e07112f mgcp_client_test: fix function name
Change-Id: I213f9b2713ff80a16603b8342c204cb546cc782d
2023-12-08 05:57:37 +00:00
Pau Espin 563386e8bb mgcp-client: Add keepalive feature
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
2023-06-15 16:46:46 +02:00
Pau Espin af0f58fac7 mgw: Allow auditing speciall 'null' endpoint
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
2023-06-15 11:08:50 +02:00
Pau Espin 8e8d59ff0e mgcp_client: Introduce mgcp_client_conf_alloc(), deprecate mgcp_client_conf_init()
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
2023-06-14 10:59:50 +02:00
Philipp Maier 4c4d227624 mgcp_codec: fix codec decision
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
2023-05-22 11:18:45 +02:00
Neels Hofmeyr 45fe47cea7 mgcp_client: simpler error handling
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
2023-04-15 00:56:06 +02:00
Vadim Yanitskiy d358ca14a9 tests: $(BUILT_SOURCES) is not defined, depend on osmo-mgw
Change-Id: I951ce2410614993a855336e6bb408cae1823ef9a
2023-03-31 11:56:02 +00:00
Philipp Maier 9dd80ca1f8 mgcp_codec: refactor payload type converstion
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
2023-03-27 17:50:18 +02:00
Philipp Maier 621e8666ff mgcp_codec: fix oa/bwe comparison in mgcp_codec_pt_translate()
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
2023-03-27 13:12:50 +02:00
Philipp Maier ec967d74f7 Revert "mgcp_codec: do not differentiate between oa and bwe when comparing codec"
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
2023-03-22 17:12:44 +01:00
Vadim Yanitskiy e1da8c9d2c tests: use -no-install libtool flag to avoid ./lt-* scripts
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
2023-03-11 04:47:20 +07:00
Oliver Smith 0dbaaadc06 mgcp_client: mgcp_msg_gen: add more error logs
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
2023-02-27 08:30:08 +00:00
Oliver Smith 169d50ed4a Fix various typos
Change-Id: Iba7851a5bdb0ce2ce6852a8fa035b72515d7b0a1
2023-01-24 13:23:21 +01:00
Pau Espin 310e41cdf3 osmux: Rotate over available Osmux CID when allocating a new one
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
2022-11-15 18:10:28 +01:00
Harald Welte 9befdeb673 Support building with -Werror=strict-prototypes / -Werror=old-style-definition
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
2022-11-03 12:53:20 +01:00
Pau Espin 5ffd127384 Get rid of separate rtp_port field
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
2022-10-04 14:44:44 +02:00
Pau Espin daf5bcea99 mgcp_conn: rename field s/rate_ctr_group/ctrg/g
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
2022-09-22 21:21:12 +02:00
Vadim Yanitskiy 1c69fb0f14 tests: use 'check_PROGRAMS' instead of 'noinst_PROGRAMS'
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
2022-04-13 19:55:34 +03:00
Philipp Maier e0058b7207 mgcp_codec: do not differentiate between oa and bwe when comparing codec
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
2022-02-16 17:17:45 +01:00
Pau Espin 2c40164ff0 Define mgcp_rtp_end.output_enabled as bool
Change-Id: I55f7796ef774f86050041f2c5e3a2f8f7d1f56df
2022-01-03 12:29:39 +01:00
Eric Wild fbf78d13f1 endp: do not cache cfg pointer
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
2021-09-14 18:33:24 +02:00
Philipp Maier df9192efee mgcp_client: add MGW name as logging context
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
2021-09-14 07:01:04 +00:00
Philipp Maier 39889e4389 mgcp_protocol: get rid of policy_cb and change_cb
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
2021-08-05 10:00:59 +02:00
Philipp Maier 124a3e0b34 mgcp_ratectr: add stats items to monitor trunk usage
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
2021-08-03 15:05:46 +00:00
Neels Hofmeyr 268568593e Revert "mgcp_ratectr: add stats items to monitor trunk usage"
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
2021-07-21 17:07:14 +00:00
Philipp Maier 6bad138c96 mgcp_ratectr: add stats items to monitor trunk usage
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
2021-07-20 17:00:09 +02:00
Philipp Maier d70eef6421 mgcp_trunk: use unsigned int instead of int as trunk_nr
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
2021-07-20 16:34:50 +02:00
Neels Hofmeyr d57310731f mgcp_client: add logging on received MGCP messages
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
2021-07-15 11:36:15 +02:00
Pau Espin b066bd0c86 Take into account Marker bit when patching RTP stream
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
2021-07-08 10:18:15 +00:00
Pau Espin d6769ea207 Fail rx MDCX sendrecv with invalid remote addr
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
2021-07-07 14:12:35 +00:00
Pau Espin a24dcc61d7 mgcp_send_dummy: Check RTP destination is available before attempt tx
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
2021-07-07 14:12:35 +00:00
Pau Espin 8358c4ba07 constify some function arg pointers
Change-Id: I7a7560fad96719da01f1ee30eea0be0e52c60e99
2021-07-07 13:44:39 +02:00
Philipp Maier 7d86d4c523 mgcp_client: fix error handling in mgcp message generation
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
2021-06-11 15:16:13 +02:00
Philipp Maier b3d14eb552 mgcp_network: refactor MGCP_DUMMY_LOAD
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
2021-06-07 20:14:35 +00:00
Pau Espin 907744e2fc Use new stat item/ctr getter APIs
Generated with spatch with this and similat snippets:
"""
@@
expression E1, E2;
@@
- &E2->ctr[E1]
+ rate_c

Change-Id: I53b75ea8a88bc1ae4ceb479ed272865054de9665
2021-06-04 17:57:34 +02:00
Pau Espin ace0b946ff tests: Replace deprecated API log_set_print_filename
Change-Id: I761d2bf99aa5a009ff489584d804634e58588125
2021-02-19 13:33:52 +01:00
Pau Espin a790f0c082 mgw: Initial IPv6 support
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
2020-09-07 18:12:59 +02:00
Pau Espin 9dc73593a3 mgcp_client: Allow submitting and parsing IPv6 addr in SDP
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
2020-09-07 15:55:30 +02:00
Philipp Maier 0653cc8a7c mgcp_trunk: drop "trunk 0" limitation
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
2020-08-20 06:21:41 +00:00
Philipp Maier 993ea6be7a get rid of mgcp_internal.h
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
2020-08-10 22:56:59 +02:00
Philipp Maier 889fe7f203 mgcp_e1: finish E1 support, add E1 support from libosmoabis
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
2020-08-10 22:56:59 +02:00
Neels Hofmeyr 51b42ff2e1 refactor: use msgb to receive, pass and send RTP packets
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
2020-07-21 16:13:23 +00:00
Philipp Maier 06ea49159e mgcp_test: remove trunk2 from unit-test
Some of the unit-tests initalize a second trunk (trunk2) but the test
never do anything with this trunk. Lets remove it.

Change-Id: I228aa45160152091baac9d9c2e6486b774278b6a
Related: OS#2659
2020-07-16 11:57:45 +00:00