In change I55605ea083565b6950d0820e3f72c50c9dc19ffa, the default
number of endpoints was increased to 512, however the
configuration examples were not updated.
Related: OS#4711, SYS#5262
The manual does not say much about the endpoint naming, even though
osmo-mgw is oriented at RFC 3435 the endpoint names are specific to
osmo-mgw. In particular the E1/T1 endpoints and their overlapping need
The E1 trunk lacks the VTY commands force-realloc and rtp-accept-all.
However, the function that write the E1 trunk config includes those
commands. Also they would be applicable, so lets add those two commands
also for E1 trunks.
When a trunk 0 is created (which is legal) than it is impossible to
write this trunk back to the config. The reason for this that there is
still a filtering in place from the time where trunk 0 was not allowed.
This filter needs to be extended to filter only virtual trunk 0 but not
E1 trunk 0 out.
The graph "OsmoMGW used with OsmoMSC" shows a BSC entity that accepts
AoIP and RTP, however osmo-bsc has no RTP proxy functionality. It makes
probably more sense to remove the BTS from the graph and call "BSC" "2G
The graph "OsmoMGW used with OsmoBSC" shows an RTP and 3GPP AoIP going
to OsmoMSC, this is technically wrong since osmoMSC has no RTP proxy
functionality whatsoever. Since the graph is not so much about OsmoMSC
it makes more sense to label OsmoMSC with "core-network", then it makes
sense and correctly highlights the role of osmo-mgw on the BSS side.
The limitations section is outdated. We now have support for osmux and
E1 timeslots with trau frames. However, we did not mention that we still
have no transcoding as well.
To make clear which configuration changes (configure terminal)
apply when, add appropriate user attributes to VTY commands.
Related: SYS#4937, OS#1601
The initialization of the E1 line in mgcp_e1.c is controlled internally,
there is no need to expose the function mgcp_e1_init(), lets make it
static and remove the prefix mgcp_
There exist trunk_loop commands, which sets an trunk->audio_loop
variable, however all it does is to turn on a log message. There is no
actual implementation present. Lets set the VTY commands to
DEFUN_DEPRECATED and remove the variable.
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
libosmo-mgcp-client looks up this timer in a caller provided osmo_tdef
definition. So far, all of our libosmo-mgcp-client callers do not configure
such a timer, so that we always use the default timer value.
We have introduced X timers (negative numbers) to indicate Osmocom specific
timers, and reserve T timers for 3GPP specified ones. So now is still a good
chance to move this timer to the Osmocom X realm.
Remove a comment about this timer at an unrelated place. It is still described
It is currently done upon receival of RTP packets in rx_rtp for pure RTP
conns, but nothing similar is done for Osmux conns, which eventually
trigger a connection time out.
MDCX may provide a new remote address, which means we may need to update
our announced IP addr and re-bind our local end. This can happen for
instance if MGW initially provided an IPv4 during CRCX ACK, and now MDCX
tells us the remote has an IPv6 address.
It doesn't make sense to call the function several times since anyway we
are only binding during
Let's better calculate the local IP addr once and use that stored value.
THis is a previous step towards next commit updating the local IP addr
and re-bindng if encessary.
This commit allows for fully IPv6 systems to work fine. However, if a
remote endpoint still wants to use IPv4, it will fail since at this
point osmo-mgw still doesn't re-bind the local end of the connection to
an IPv4 after having initially bound it to an IPv6 one. This kind of
scenarios get fixed in next commits.
TODO: really bind the socket if a different IP address is requested.
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)
This is needed in case MGW changes the local IP address (for instance
because it initlaly offered an IPv4 address, and a client submitted a
remote IPv6 address, so MGW needs then to offer a local IPv6 address for
the RTP connection to be possible).
The API and related implementation fields are not used internally nor
externally, and only support IPv4. Let's simply deprecate the API and
drop all the uneeded implementation.
If "0.0.0.0", the default, is passed together with an IPv6 configured
address (ex: "mgw remote-ip ::1") in VTY, socket creation will fail due
to address version mismatch (because getaddrinfo() returns only an IPv4
address in the local result set).
If instead NULL is passed, then 2 entries are returned, one in IPv4 and
one in IPv6, and osmo_sock_init2 is smart enough to take one or another
when passed AF_UNSPEC.
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().
The VTY default for the number of endpoints is 32. This is sufficient
for small setups and lab testing, but for medium sized setupts the limit
might be reached soon. Lets increase the default to 512 virtual endpoints.