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
The following sequence of events was seen frequently in a osmo-mgw
instance running on the field with heavy traffic:
"""
endpoint:rtpbridge/1@mgw CRCX: creating new connection ...
mgcp_network.c:236 endpoint:rtpbridge/1@mgw CI:1C8CCFA9 Failed to send dummy RTP packet.
"""
Allegedly, that happens because at CRCX time the remote address may
still not be known, hence we end up trying to send a dummy rtp packet
to, for instance, host 0.0.0.0 port 0, which will of course fail.
Let's avoid sending it if the address is not yet known.
Similary, same issue could be seen during MDCX, since at MDCX we don't
necessarily need to have a valid addr+port (there could be several MDCX
and only last one set it).
Finally, the keepalive timer also needs the check, since it iterates
over all connections, and it could be that some is still not fully
configured.
Related: SYS#5498
Change-Id: I8ceafda691146823b12232b4a804b4ce74acbdc8
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
This is a preparation for next commit, where one of the function will
require an static function available before it in the file.
Moving the functions also make sense, in order to have the 3 mgcp send
functions together for more easy understanding.
This commit does small style changes to fix followint linter errors:
"""
src/libosmo-mgcp/mgcp_network.c:1036: ERROR:SPACING: space required after that ',' (ctx:VxV)
src/libosmo-mgcp/mgcp_network.c:1091: WARNING:BRACES: braces {} are not necessary for any arm of this statement
src/libosmo-mgcp/mgcp_network.c:1145: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
src/libosmo-mgcp/mgcp_network.c:1163: ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
src/libosmo-mgcp/mgcp_network.c:1204: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
src/libosmo-mgcp/mgcp_network.c:1226: ERROR:POINTER_LOCATION: "(foo*)" should be "(foo *)"
"""
Change-Id: Iff8dab942182a0d909519acddb86be75d9cda7ae
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
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
Generated with spatch with this and similat snippets:
"""
@@
expression E1, E2;
@@
- &E2->ctr[E1]
+ rate_c
Change-Id: I53b75ea8a88bc1ae4ceb479ed272865054de9665
When mgcp_udp_send() is called, the memory where *buf is pointing to is
never modified. It should be marked as const.
Change-Id: Iac90de5beb19bf52586ac6ffeab9eb5152edf339
So far an mgcp_client user can get the RTP address+port information that
the MGW has returned upon a CRCX. Add this function to return the other
RTP end, i.e. address+port that the MGW was told to send RTP to.
This will be used to fix the MGCP in osmo-bsc, which so far mixes up the
two RTP ends and compares the MSC's RTP address+port with the MGW's one
and hence fails to skip unnecessary MDCX.
Change-Id: Ibb488925827d9dc0ccb1f8d6d84728745d086793
A call agent may send a CRCX to create a connection in LOOPBACK mode but
without specifiying the destination address. In those cases the MGW
should deduct the destination address from the first incoming RTP
packet.
Unfortunately this is currently blocked by an OSMO_ASSERT that checks the
current sa_familiy against the sa_family from the incoming packet. This
makes no sense since the current sa_family is still uninitalized, which
is expected and not an error since the code that follows will initalize
it.
It also makes sense not to access the osmo_sockaddr struct members
individually but rather copy the address as a wohle.
Since the event only happens once and since it is also somewhat special
it makes sense to log the event as well.
Change-Id: I2dbd6f62170a7f62e5287d04a4ee6716b8786c26
Related: OS#5123
Sending a DLCX upon FSM cleanup is not unusual. Move the log about that
DLCX to INFO, and also print the endpoint and conn identifier.
Change-Id: Id723d949f101b66fb75296d01489d9dac350c7c8
If the mgcp_client_fsm gets terminated in ST_DLCX_RESP, it has already
sent a DLCX to the MGW. So do not send a second one.
I noticed the duplicate DLCX for the same endpoint conn identifier while
running TTCN3 tests and watching the network trace of test teardown.
Change-Id: I35e415f67946b73c74408afe265618cfe4f72b0b
With just one E1 line, the 'show mgcp' command outputs
several hundred lines to the vty. Add a 'active' parameter to
only show endpoints that are active.
Change-Id: I23a26b4fdc03d8b2469d293dd6c06ed83ce739e9
This is useful for affecting the 802.1Q PCP value without any separate
external packet filter rules for classification.
Change-Id: I69136c6dd114c24b1dace034e75dba5157bac37e
Depends: libosmocore.git I89abffcd125e6d073338a5c6437b9433220e1823
libosmocore If22988735fe05e51226c6b091a5348dcf1208cdf introduces
an even more convenient mechanism for specifying the DSCP of
an IP socket via OSMO_SOCK_F_DSCP()
Change-Id: If0b11dea08716ed3952a25b546b2a9bd013857bf
We have VTY options that allow to set the DSCP value. However, we
then call a function to set the TOS bits in the kernel. This is
very wrong. The DSCP is only the upper 6 bits of the 8-bit TOS
value, and hence we are mussing that translation.
As libosmocore now has a helper function osmo_sock_set_dscp(),
let's make use of it and don't care about the low-level details.
However, this means we need to finally remove the deprecated
alias for "rtp ip-tos <0-255>".
Closes: OS#5137
Change-Id: I9c18c90273be97aedd2ad212b82f650e35c32851
Depends: libosmocore.git Ia4ba389a5b7e3e9d5f17a742a900d6fd68c08e40
In I64ff22193ab2a95a9a7d66e9957a875d096e23de the soversion was
chhanged, but the spec.in file was not adjusted accordingly.
Change-Id: I45d7321adb2db8e7b9ea41b6bcf0c6cc59984a0e
In change I55605ea083565b6950d0820e3f72c50c9dc19ffa, the default
number of endpoints was increased to 512, however the
configuration examples were not updated.
Change-Id: I449a612065a5208c9f70ae74f594e8d45eb344cf
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
some explaination
Change-Id: I16265eb667221959a69f33701d024bd8d9b22040
The cunfiguration chapter does not say anything about E1 trunk
configurations, lets add a subsection that explains how an E1
trunk is added.
Change-Id: I4059771df0f115242398d1af499c837005a7dabc
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.
Change-Id: Ief2bc7502bb8d1e0f9c784d42edbe1aed5ffb728
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.
Change-Id: Iad6b577b5a711c35f98c477351fde567d8c87298
The trunk 0 was reserved for rtpbridge in earlier versions of osmo-mgw,
this was due to internal technical limitations which no longer exist.
Change-Id: Ic322f7dcf28db827187a4537e2634a887bd7b13b
Add a graph similar to "OsmoMGW used with OsmoMSC" that shows the
integration of a legacy E1 BTS into a AoIP network
Change-Id: I71dc2f4a188fbc25e81050be3dd4c83e1797e63d