To make clear which configuration changes (configure terminal)
apply when, add appropriate user attributes to VTY commands.
Change-Id: I2d9487801b3b78f94577264b56d217c926ef76a9
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_
Change-Id: I6aba1c55c9b1d729709ee1fba2994c77bd848a9b
The VTY command "bind early" is deprecated but it prints an error
message and the DEFUN is not set to DEFUN_DEPRECATED.
Change-Id: I594a87d2f63826a9d7b4f6a380586b08b3b79518
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.
Change-Id: I72b0f8b908e32643e6e3db6ac024371b13c074a1
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
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
at osmo_mgcpc_ep_alloc().
Change-Id: If097f52701fd81f29bcca1d252f4fb4fca8a04f7
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.
Change-Id: Id592d7db7b9399a497176e0d28cc826b3bce48c0
Otherwise some state is kept, like the previous CallId, which may then
provoke issues next time the endpoint is to be used.
Change-Id: I3ac4f4542c1c8c877127c64acce6c82b458f697f
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.
Change-Id: Iaed424e2c209e1753e1f579752fc684aaad7a512
It doesn't make sense to call the function several times since anyway we
are only binding during
allocate_port()->mgcp_bind_net_rtp_port()->bind_rtp()->mgcp_create_bind()->osmo_sock_init2().
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.
Change-Id: I803b99c5e5fe0f92a5bf6796d8c25df88d1608e6
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.
Change-Id: I8ed94bd3f674f498e6ba315f44a351fff9c1be15
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
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).
Change-Id: Ie964412b81fe6e10914790baaea724ca5f772adc
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.
Change-Id: I905d4c4efabb6b4a4bc5c02e956808777243cadc
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
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.
Change-Id: I55605ea083565b6950d0820e3f72c50c9dc19ffa
Related: OS#4711
The struct member trunk->e1.line is never set. Also it is always
possible to use e1inp_line_find() to get a pointer to the e1.line.
Lets remove it.
Change-Id: Id4ff52285917ce3885b8dad3a16270999c9da0aa
The E1 timeslot initalization may fail silently in the last steps. There
is an error code returned, but no log lines are printed. This can make
debugging difficult.
Change-Id: I9aab17fc1ba6666c81b14035a8f1f17e5a55adaf
It contained name from a different program, probably due to main.c being
copied over during project start.
Change-Id: I4bfa40eec0277705f5d3335d779bff35518470a8
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
When endpoints become unavailable when MDCX/CRCX/DLCX are executed on
them a major problem may be the cause, lets make sure that those events
are logged.
Change-Id: I059b7e29f960e75a53bfb5dfb2b83ab3d79e84f3
The function e1inp_line_update() is called without assigning its return
code to the rc variable.
Change-Id: Ia72ea2dca210b038766151d547f66b7b7139a2c4
Fixes: CID#212160
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
The function allocate_port() has pointer a variable end, it even does an
OSMO_ASSERT on it, but it never uses it. Lets remove it.
Change-Id: I369361389c6276e5511c683ebd630093713bdd37
This problem was noticed while running several LCLS test cases from
ttcn3-bsc-test. Every test case makes osmo-bsc leak at least two
chunks named 'struct mgcp_response_pending'.
Here is the related osmo-bsc output with additional debug messages:
DRLL ERROR mgcp_client_fsm.c:525 MGCP_CONN(to-MSC)[0x612000016120]{ST_READY}:
MGW/DLCX: abrupt FSM termination with connections still present,
sending unconditional DLCX...
DLMGCP DEBUG mgcp_client.c:1010 mgcp_client_next_trans_id(id=35): new trans ID
DLMGCP DEBUG mgcp_client.c:918 mgcp_client_pending_add(id=35): allocated and queued
DLMGCP DEBUG mgcp_client.c:962 Queued 53 bytes for MGCP GW
DLMGCP DEBUG mgcp_client.c:725 Tx MGCP: r=127.0.0.1:2427<->l=127.0.0.1:2727:
len=53 'DLCX 35 rtpbridge/1@mgw MGCP 1.0\r\nC: 5\r\nI:'...
DLMGCP ERROR mgcp_client.c:704 Failed to read: r=127.0.0.1:2427<->l=127.0.0.1:2727:
111='Connection refused'
The MGCP client FSM enqueues a DLCX from its fsm_cleanup_cb(), and
terminates. Thus if the remote MGCP peer becomes unavailable (e.g.
due to a network failure), we would never get a response, and since
the FSM is already terminated, nobody would pop and free() the
response handler from the queue (mgcp->responses_pending).
As a simple workaround, let's avoid allocating dummy entries of
'struct mgcp_response_pending' without a response handler. The
only case where an MGCP message is sent without a handler is
exactly during the FSM termination.
Change-Id: I83938ff47fa8570b8d9dc810a184864a0c0b58aa
Related: OS#4619
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
_talloc_zero_array is not supposed to be called by the API user. Lets
use talloc_zero_array instead.
Related: OS#2659
Change-Id: I27549585016a7998e9233c52f6d86429fc75f509
At the moment the number of possible E1 endpoints (depends on the number
of E1 timeslots that should be used) is hardcoded and the configuration
of the number of virtual endpoints has an off-by-one problem.
For the E1 timeslots one might choose not to occupy all E1 timeslots of
once. A one TRX E1 BTS usually requires 3 E1 timeslots. One as D-Channel
timeslot and two to cover the voice channels. The voice channels
timeslots need to be set up in osmo-mgw, while the D-Channel timeslot
must not be touched. The VTY config needs to be able to reflect that.
Change-Id: I73b31e3c236a61ea0a6f76ef5ff98ce589f52c77
Related: OS#2547
At the moment, the trunk prefix is checked twice. Lets re-arange the
code a bit so that the check only happens once.
Change-Id: I91fb8cf6e3b077ba8f18fdbcd071275c6fd7cacd
Related: OS#2547
There are 15 possible subslots (not all at the same time) in one E1
timeslot. Lets use a define constant for that.
Change-Id: If7cb74e486946aff09e22abf8a8885bf0693f34e
Related: OS#2547
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
Harald Welte
Philipp Maier
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr