This library is intended to collect all generic/common funcitionality
of all Osmocom.org projects, including OpenBSC but also OsmocomBB
The library currently includes the following modules:
bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer,
tlv_parse, linuxlist
msgb allocation error debugging had to be temporarily disabled as it depends on
'debug.c' functionality which at the moment remains in OpenBSC
During handover, we will not send RTP frames for quite some time. However,
the way the rtp_send code is structured, it will increment the timestamp
with a fixed amount every time we send a frame, independent how much wallclock
time has actually passed.
This code is a hack to update the sequence number and timestamp in case it
seems to be wrong. It makes handover much more reliable.
Instead of passing TRAU frames down the MNCC API to the call control
application like MNCC, we now decode the TRAU frame into the actual codec
frame. We do the same with the RTP packets in case of ip.access and
thus have a unified format of passing codec data from the BTS to
an application, independent of the BTS type.
This is only implemented for V1 full-rate at the moment, and needs
to be fixed.
This introduces a new LOGP() macro together with LOGL_* definition to
support multiple log levels (severities) throughout the codebase.
Please note that the actual logging system does not use them yet,
in this patch we simply introduce the new macros at the caller site.
Up until now, we only supported direct RTP streams between ip.access BTS.
With this commit, the user can specify '-P' to the command line to enable
a RTP/RTCP proxy inside OpenBSC. The nanoBTS will then send all their voice
data to OpenBSC, which will relay it to the respective destination BTS (which
can be the same BTS).
The default behaviour remains unchanged. Without '-P' on the command line,
RTP/RTCP is exchanged directly.
The rtp_proxy.[ch] code is intended to be used as a transparent
RTP/RTCP proxy, relaying the media streams from one ip.access BTS
to another. In an 'ideal' network, this is obviously not needed,
since the BTS's can send those streams directly between each other.
However, for debugging, 'lawful interception', transcoding or interfacing
a TRAU/E1 based BTS, we actually need to process those RTP streams
ourselves.
Holger Hans Peter Freyther
Harald Welte