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
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
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
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
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 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
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
Pau Espin
Philipp Maier
Harald Welte