Clang and gcc have different names for this, but the check fails without
-Werror since clang only warns about unknown args.
The previous check led to a lot of "unknown arg" spam while compiling
with clang.
Change-Id: Iad6c16beed26d5fe8952d7d5a79a93845c391b48
The change I19f67db1c56473f47338b56114f6bbae8981d067 removes the
policy_cb and change_cb callback funtions, but it does not remove
the related ratecounters.
Change-Id: I53aa3c890555055466e86b09a359375a10d3be7b
The docstring in the VTY command that is used to remove MGCP client
instances lacks the NO_STR constant.
Change-Id: I53f3e763a77ed8be78c5a51b1472f4b70bade9d4
Related: SYS#5091
The interactive VTY commands to reconnect, block and unblock MGCP
clients from the pool are not displayed properly because the doctring
lacks the reference number.
Change-Id: I0367c33f5cd02978e3f14b1343dfaafa1ea62370
Related: SYS#5091
When the function mgcp_client_pool_vty_init is called with pool = NULL,
then it segfaults. Lets put an OSMO_ASSERT() on pool to make clear that
a pool must be present before initalizing the VTY on it.
Change-Id: I36893bf5341d4ad21161e92d2d25d284647f7d18
At the moment the MGCP Client only supports one MGW per application.
Depending on the requirements of the application one MGW might not offer
the performance needed. Lets add support for an MGCP Client pool that is
backward compatible to existing applications.
Change-Id: Icaaba0e470e916eefddfee750b83f5f65291a6b0
Related: SYS#5091
The function init_socket has an arbitrary retry count when opening the
socket. After each retry the local port is incremented by one. The
intention behind this is to find a useable local port in case the
configured port is used by another process.
The maximum number of retrys is hardcoded. The upcomming MGW pooling
patch requires to set the maximum retry count.
Change-Id: Ifd65511daa92fbe610f52da1c4c3b6a7c761d890
Related: SYS#5091
When the address is set to ANY, the address string is NULL. The log then
prints "(null)" where the address normaly would be. This looks odd, lets
print "(any)" instead.
Change-Id: I2ea138827ee5b9f40d352bf594364ee930520609
The vty always checks if global_mgcp_client_conf exists. (there is also
an assert This check about global_mgcp_client_ctx).
global_mgcp_client_ctx and global_mgcp_client_conf are populated before
the VTY commands are installed. Unleass the caller uses the API wrong
and calls mgcp_client_vty_init with NULL pointers there cannot be a
problem with unpopulated pointers. Lets remove the checks as they are
not needed.
Change-Id: I892d14c588573f76640453cb9c194594289b59f1
Related: SYS#5091
Depending on the usecase of osmo_mpcg_client it may be helpful to send a
DLCX to certain endpoints. Usually this would be a wildcarded endpoint
that resets the entire trunk to drop lingering RTP flows which may still
present after a restart/crash, but it might be also a group of specific
endpoints. The user may specify an arbitrary amount of endpoints where
the mgcp client will send a DLCX to. It does not matter if the endpoints
are wildcarded or not.
Change-Id: I47e7ff858d5067b46d52329be5f362ff61c0dff8
Related: SYS#5535
The rate counter and stats item groups, which are allocated in
mgcp_ratectr.c are freed using a talloc destructor that is set in the
context of the item we just allocated using the stats / rate counter API
functions. When we do that, we risk overwriting an already existing
talloc destructor. Lets instead implement own free functions and set
those as talloc_destructor from above (trunk and MGCP config)
Change-Id: Ifc5091e9f95cc721e58d1eb2e55b97102c497706
Related: OS#5201
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
The MGW domain name is usually checked while resolving the endpoint
after the trunk has been resolved. This was no problem before, but since
we allow wildcarded DLCX requests, which require only a trunk to work,
the check is not done correctly for wildcarded DLCX requests and invalid
domain names may slip through.
Checking the domain name earlier while the trunk is resolved makes sense
and it fixes the problem.
Change-Id: I9944a9103981fb5f4d0d8714ee2847ae020f76df
The logic when an endp pointer is guranteed and when we are able to
process the request without the endp pointer populated is qute complex.
This shows up as a bug to coverity.
Change-Id: I1d4221f2df13c43321d5466534485cf21f0d9010
Fixes: CID#237088
The request handler handle_delete_con currently rejects wildcarded DLCX
requests even though a wildcarded DLCX would be a valuable tool to
remove lingering connections from the trunk in case osmo-bsc has to be
restarted.
Change-Id: I5c2de6b2b61ee64ba9c0618fd20e8fc2fe6a5ed3
Related: SYS#5535
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
The function create_response_with_sdp calls add_params, which is rather short.
The code in there can also be put in create_response_with_sdp. The
decision whether the endpoint name (Z) should be added or not, should be
made by the caller.
Change-Id: I7e29c513f4386832646e96194ed6c2397405ed3b
Related: SYS#5535
There is not always an endp pointer present when mgcp_check_param() is
called but we always have a trunk pointer. Lets add a trunk parameter so
that the function can pick LOGPTRUNK when endp is not available.
Change-Id: I7327c5a105e7f0e20cabf64623ff9f36fd83bbb8
Related: SYS#5535
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
At the moment the MGCP request handling and message parsing is not
clearly separated. The function mgcp_parse_header() in mgcp_msg.c is
also responsible for resolving an endpoint. This leads to unclear layer
separation. We eventually end up in a situation where we can not execute
any request handler without beeing able to resolve an endpoint, however
this is necessary if we want to implement wildcarded DLCX resquests.
In the current situation a wildcarded DLCX is not possible to implement
as we always have to resolve a an to get to the trunk which we need to
iterate. However, we just can't resolve a free endpoint in a situation
where all endpoints on te trunk are in use.
We have to refactor the request handler so that the parsing in mgcp_msg
only extracts us the endpoint name. The resolving is then done in
mgcp_handle_message() in mgcp_protocol.c. Then we are able to decide
what to do if we are unable to resolve an endpoint but still be able to
resolve the trunk.
This patch does not change the behaviour of osmo-mgw yet, but it lays
the foundation for request handler implementations that can still
perform useful actions if no endpoint but a trunk has been resolved. A
wilcarded DLCX is such a case. It does not need an endpoint, just the
trunk.
Change-Id: I9f519d8a0ee8a513fa1e74acf3ee7dbc0991cdde
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
the various types of MGCP requests are implemented in request handlers
functions. The function pointers to those functions are held in an array
that is used to find the right handler and call it then. The struct used
to model the array is defined somewhat away from the array definition
and there is also a macro in between that does not help to make the code
more understandable. Lets refactor this a bit to have it more distinct.
Change-Id: I2ef167b2ac179d2b0683a27a095f9662fda460bf
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
To see state transitions and events on LMGCP DEBUG logging, actually set
the log_subsys of the mgcp_client_fsm.
Related: SYS#5529
Change-Id: I6e84d5f7b85752a7a54f17be1d074b01d1467f26
When the mgcp_client_endpoint_fsm terminates, do not directly pull each
conn FSM instance (mgcp_client_fsm) into oblivion as well. Those should
emit a DLCX and wait for the "OK" response before deallocating.
In programs using the mgcp client endpoint FSM (osmo-bsc, osmo-msc),
this gets rid of false LMGCP ERROR logging related to DLCX like this:
Cannot find matching MGCP transaction for trans_id 71998
Related: SYS#5529
Change-Id: I8fbfec5533e9be9cc7ea550df1e6639a0a215973
Upon mgcp_conn_delete(), we unparent the FSM instance. Instead of
setting the talloc ctx to NULL, place the deleting conn under the
struct mgcp_client talloc ctx.
Related: SYS#5529
Change-Id: Ia12749e0d7d520f24a967c2df9a4651267e1019e
osmo-mgw currently does only a very simple detection method for
wildcarded requests, but it makes sense to split this detection
off into a separate function so that it can be used from different code
locations and we still have it at one place only.
Change-Id: I27018c01afb8acabfcf5d435c996cc9806e52d6b
Related: SYS#5535
The function mgcp_rtp_end_config() takes an mgcp_endpoint as
parameter. The header file does not declare the mgcp_endp struct
and it also does not include mgcp_endp.h because that also would
cause problems. Since the endp parameter in mgcp_rtp_end_config()
is only a pointer we can simply forward declare it.
This patch will currently not change anythig, but it will prevent
compiler warnings when we remove the endp pointer from
struct mgcp_parse_data in a follow up patch
Related: SYS#5535
Change-Id: I07a4d6f9d5334b1f4cf4b262482b8a67b1384398
The rate counter group is currently only referenced by an index. In a
system with multiple trunks this makes it difficult to say which rate
counter group belongs to which trunk sinde the index that is used does
not necessarly corespond to a specific trunk.
Since rate counter groups can now get a human readable name assigned, we
should do that.
Also E1 specific rate counters only make sense for E1-trunks, so they
should not be present on the virtual trunk.
Change-Id: I5e7f0e9081a06af48e284afa5c36a095b2847704
The braces as put before this patch would read as {"is known", "is not
yet known"}, which is confusing the actual situation.
Change-Id: Icd1f22a9f4147a2758c2f068ecba46cf7f732604
The loop that resets all endpoints in read_call_agent() starts counting
at endpoint index 1, but it should begin counting at index 0
Change-Id: I82a385e547e54d82eff95213652317ed2fdaadd8
The logic in mgcp_keepalive_timer_cb() only sends dummy packets for
endpoints 1-N, leaving out endpoint 0, this is not correct it should
include all endpoints (0-N).
Change-Id: I99a9b572eac26780bc1286a8dd63c4c5652fda4f
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
Neels Hofmeyr
