This has several benefits:
* easily improving/changing the impelemntation later on (eg. by storing
a count instead of iterating the whole list).
* Remove code complexity from mgcp_protocol.c.
Change-Id: I77c298abf0a1488b91f58c9e76507ef8add0168e
There's no need to lookup (iterate over conns) for rtp_conn in endp, we
have it accessible in constant time.
While at it, simplify some accesses to the pointer after it.
Change-Id: I8316e76a1789d4a8eaa1eb89bdaf86e25dc0a1e8
Add a new mgcp_conn_get_conn_rtp() and use it everywhere instead of
accessing deep structure fields.
Change-Id: Iee2c19598e9570ea3b1ceba3cdfd2a5f5be2c954
These functions act on the endp object, hence prefix them with
mgcp_endp_* and move them to mgcp_endp.{c,h}.
Change-Id: Ifff01331db68998e9e23f99d8836d96022d550c2
All the code to free conns in an endpoint is really entanged, which also
makes it inefficient in several places because the list of conns is
iterated twice, or even ~N*2.
* Move code freeing the conn object to its own mgcp_conn_free()
function.
* Rename functions acting on endp to be mgcp_endp_* prefix, and move
them to mgcp_endp.{c,h}.
* Remove old mgcp_conn_free(endp, id) since it's not really needed
anymore.
Change-Id: I9a87a07699dd8aa7856d5036e9b95a4ddf699a15
This was added in e3d16bb775 14 years ago:
"""
[mgcp] Protocol extension to not generate answers.
For the NAT we want to send requests in a send and forget
way and we are not interested in seeing the answers, so tell
the gateway to not answer them.
"""
So this code is most probably related to osmo-bsc_mgcp time, and we
don't really need this feature in osmo-mgw, it really makes no sense.
Drop it.
Change-Id: Ica2d3d54cda41e0c6416913ab056843a0cd80c17
If user (VTY) configured the local IP address to use for MGCP, and that
IP address was not the one selected by kernel routing table lookup, the
IP address filled in the MGCP message would be wrong, not matching the
one sending the MGCP message.
Change-Id: I35624db853dc1f0fee85503105960613f70473c6
struct mgcp_client defined here has a field "struct mgcp_client_conf
actual", which is defined in osmocom/mgcp_client/mgcp_client.h.
Change-Id: I61a67c371dbcfab073fa75ba08a3cac0f46e0ac0
errno is positive, hence we need to change the value of "res" being
passed to strerror().
While at it, use thread-safe variant strerror_r().
Change-Id: Ibc278199bc8f66e5521bff72bad150f44716f3eb
This makes it easier to catch possible failures while running the test,
plus makes gcc on OpenSUSE_Factory happy and not warn.
Related: OS#5044
Change-Id: I01c3c84e58a11055f0e0a6955016dc2489c73379
The comment in struct mgcp_rtp_end says that the RTCP port number has to
be stored in network byte order. Such a port number is 16 bit long, so
let's use an uint16_t instead of an int here.
Related: OS#6527
Change-Id: I392b07b243389a78d4ad1d784cdfdc28ec59b487
The original code did E1 raw TS output by posting directly to
&ts->raw.tx_queue instead of calling e1inp_ts_send_raw();
doing so bypasses the call to driver->want_write performed in
e1inp layer. This approach worked for DAHDI where no
select-for-write is used; however, e1inp interface to osmo-e1d
does use select-for-write, hence applications like osmo-mgw
do need to use e1inp_ts_send_raw() API in order to work
correctly.
Change-Id: I6ce9a1dea6834632faf75059e85ca9a0c25d57c2
Currently, a CRCX in sendrecv mode results in:
DLMGCP ERROR endpoint:rtpbridge/2@mgw CI:7F4C8EDD CRCX: selected connection mode type requires an opposite end! (mgcp_protocol.c:1090)
But it is not actually practical, nor logical to require another conn
for the 'sendrecv' ConnectionMode.
Impractical: If I want to create two conns on an endpoint that both are
in 'sendrecv' mode, I have to send two CRCX, one for each conn. At the
time of the first CRCX, there cannot be any other conn, so I am
currently forced to send a different ConnectionMode in the CRCX,
followed by another MDCX later, just to change the first conn to
sendrecv.
Illogical: In a situation where two conns are currently in sendrecv
mode, if I now DLCX one of them, I can legally reach a state with a
single conn in sendrecv mode, just as currently forbidden for CRCX.
In general, MGCP is not forcing any particular number of connections.
Simply start forwarding RTP as soon as there is a remote conn, and not
require another explicit MDCX.
Related: SYS#6974 SYS#6907
Related: osmo-ttcn3-hacks I00fd854f058f7f53e2f579e8481ca2b9253f08e3
Change-Id: Ic089485543c5c97a35c7ae24fe0f622bf57d1976
Note, there are also ttcn3 tests sending the same to osmo-mgw being
submitted along with these patches, and the ttcn3 tests currently fail:
osmo-mgw rejects the connection mode "sendrecv" in the first CRCX.
Change-Id: Icdb1085b8e44ac4cff6c457163349b81e81bf765
In our GSM world, the packet time is 20 ms, hence 20 is the typical
value that we should test. Maybe we can do one test with 40 at most, but
we'll most probably never see anything else than 20 in practice.
Change-Id: Ia2292198bf6e3b72912afd69607654ca77fd549d
The only valid line endings are '\n' and '\r\n'.
We usually use '\r\n' like we were in MSDOS.
MGCP, RFC3435 3.1:
Headers and session descriptions are encoded as a set of text lines,
separated by a carriage return and line feed character (or,
optionally, a single line-feed character).
SDP, RFC8866 5:
The sequence CRLF (0x0d0a) is used to end a line,
although parsers SHOULD be tolerant and also accept lines terminated
with a single newline character.
There should probably be tests for '\n' line endings, but mixing them in
the same MGCP message is ridiculous.
Change-Id: I6d530535a3a5f1d1a0716ab9e4a8079ba1de242e
HRv1 support in OsmoMGW-E1 was previously broken (couldn't work
on either 16k or 8k subslots) because of inconsistency: the TRAU
frame type was set to OSMO_TRAU16_FT_HR, but the TRAU sync pattern
was set to OSMO_TRAU_SYNCP_8_HR. However, now that libosmotrau
has proper support for HRv1 TRAU frame encoding and RTP conversion
in both 16k and 8k formats, drive it correctly in OsmoMGW-E1.
While at it, change the code structure to avoid else-after-return.
Was the original code written and merged in a time before strict
linter checks?
Change-Id: Ifadbdc68905178c6ffdd673a6fb71c18610c9847
When osmo-hnbgw does not yet know the remote port, it wants to send a
CRCX to set up IuUP at the MGW, with the audio port set to zero.
Make sure osmo-mgw accepts port == 0.
Related: SYS#6907 SYS#6974
Change-Id: I42011c2e7256d372a37b6a2fe86af0153038e2d0
Re-add the m=audio line to SDP emitted from libosmo-mgcp-client, even if
the audio port is not set yet
Patch a5acaa68db introduced a presence
flag for the RTP audio port number. This flag, when unset, also omitted
the 'm=audio...' line completely, dropping the PT number definitions.
Correct:
m=audio 1234 RTP/AVP 96 <--- anounce 96
a=rtpmap:96 VND.3GPP.IUFP/16000 <--- further specify 96
a=fmtp:96 ... <--- further specify 96
When m=audio is missing, we only have orphaned rtpmap and fmtp entries.
They are supposed to further specify the 96 listed in 'RTP/AVP 96',
instead they are without context:
a=rtpmap:96 VND.3GPP.IUFP/16000
a=fmtp:96 ...
When the presence map indicates no port known, we still need to emit the
list of PT numbers; so we're forced to send a port of 0:
m=audio 0 RTP/AVP 96
a=rtpmap:96 VND.3GPP.IUFP/16000
a=fmtp:96 ...
This is an important fix for osmo-hnbgw, which sends the first CRCX with
an IUFP codec, at a time when the remote port is not yet known. osmo-mgw
requires an m=audio line to accept incoming IuUP Initializaition
requests. When m=audio is missing, osmo-mgw does not parse the IUFP
codec, and 3G voice fails completely. This mgcp-client patch will emit
valid codec config also when port == 0, fixing osmo-hnbgw voice, because
osmo-mgw will know about IUFP from the start.
Related: SYS#6907 SYS#6974
Related: osmo-mgw a5acaa68db
Change-Id: Id95b629453aec999100b5af821c6a0b9562bb597
Fix for:
range must end at an odd port number, autocorrecting port (16000) to: 16001
% Deprecated 'sdp audio-payload number <0-255>' config no longer has any effect
% Deprecated 'sdp audio-payload name NAME' config no longer has any effect
% Deprecated 'loop (0|1)' config no longer has any effect
Change-Id: I62a4fd119de48039c3c450d5323d8f9b7de8120f
I have verified that with AmbientCapabilities=CAP_SYS_NICE, setting
scheduling policy as described in the manual still works as expected.
Related: OS#4107
Change-Id: Ibb83c231231b39dc6732c0f375aeb3b21f3938ef
This way holes can be detected. In practice it's not much important
since it would be really strange that UDP fails for a while and then it
starts working out of the blue...
Related: SYS#6907
Change-Id: I8095f3505c859650c0b83abce405067bef745975
Previous commit add osmo_io changed mgcp_udp_send() implementation from
"return sendto()", which is documented as:
"return the number of bytes sent. Otherwise, -1 shall be returned"
to "return mgcp_udp_send_msg()", which in turn calls
"return osmo_iofd_sendto_msgb()", and which is documented as:
"\returns 0 in case of success (takes msgb ownership), -1 on error
(doesn't take msgb ownership)."
So successful return code changed from >0 (bytes sent) to ==0,
but forgot to update mgcp_send_iuup() return code path check (and also
some related function documentation calling mgcp_udp_send()".
This commit fixes all the related aspects of that return code change.
Related: SYS#6907
Fixes: 352b967d1b
Change-Id: I154e1e41cd02fd4d9b88ad98fc7c4d657246c589
Converting from osmo_fd to osmo_io allows us to switch to the new
io_uring backend and benefit from related performance benefits.
In a benchmark running 200 concurrent bi-directional voice calls with
GSM-EFR codec, I am observing:
* the code before this patch uses 40..42% of a single core on a
Ryzen 5950X at 200 calls (=> 200 endpoints with each two connections)
* no increase in CPU utilization before/after this patch, i.e. the
osmo_io overhead for the osmo_fd backend is insignificant compared
to the direct osmo_fd mode before
* an almost exactly 50% reduction of CPU utilization when running the
same osmo-mgw build with LIBOSMO_IO_BACKEND=IO_URING - top shows
19..21% for the same workload instead of 40..42% with the OSMO_FD
default backend.
* An increase of about 4 Megabytes in both RSS and VIRT size when
enabling the OSMO_IO backend. This is likely the memory-mapped rings.
No memory leakage is observed when using either of the backends.
Change-Id: I8471960d5d8088a70cf105f2f40dfa5d5458169a
The old approach was: rtp_data_net() reads a msgb from the incomging
socket, calls through whatever function chain and in the end free's it.
So none of the intermediate functions was permitted to take msgb
ownership.
This was a good choice as all processing would happen synchronously,
up to the point where that msgb was written on the output RTP socket.
Let's change this from passing msgb ownership throug the whole call
chain, through rx_rtp() to the various *_dispatch_rtp() functions.
This is required for upcoming migration to osmo_io, as in that case the
write (sendto) calls are asynchronous and hence msgb ownership needs
to be transferred.
Change-Id: I6a331f3c6b2eb51ea312ac6ef8c357185ddb79cf
the processing call-back is working with a raw buffer + length,
while we actually work with struct msgb. Let's simply pass the msgb
into the call-back, and the call-back can then do what they want with
the contents of that msgb.
Change-Id: I002624f9008726e3d754d48aa2282c38e3b42953
The existing support preparing the mgw for transcoding (which doesn't exist)
has some kind of method where the transcoding function might be called
multiple times in a row. However, as it is not used, it is not entirely
clear how it was intended to work. Let's remove this unused looping
feature which makes it hard to understand how upcoming osmo_io should
deal with it.
Change-Id: Ie1a629fd31c5ab806fc929d1e6b279c4be5b8246
The entire mgw has no transcoding support. So printing that message is
useless to begin with. And printing it for *every RTP packet* is even
more useless. Let's remove it.
Change-Id: If0ee2607404afc3a00665a5cf22a9e0eb62eb476
Before this patch, when an CRCX+MDCX wants to set a codec list that has
no match with the codecs for the other conn of that same endpoint,
osmo-mgw returns an MGCP "FAIL" response.
When a client wants to change the codec, it has to do that one RTP port
at a time. So osmo-mgw *must* allow to configure an MGCP conn with a
codec choice that mismatches the other conn.
This is crucial to allow codec negotiation in osmo-msc: if MO has
already assigned a specific codec, and later wants to re-assign to the
codec that MT has chosen, the codec needs to be changed at osmo-mgw.
This patch is the minimal fix required to get re-assignment to a
different codec to work (via osmo-msc). There is more work to be done
about this bit of code in osmo-mgw, but keep that to a separate patch.
In detail, before this patch, we fail both
- when a side has no codecs,
- or when there is no single match between codecs of the two sides of
the endpoint.
Remove only the second condition; after this patch, still fail when a
side has no codecs -- this allows mgcp_test.c to still pass.
Related: OS#6293
Related: osmo-msc I8760feaa8598047369ef8c3ab2673013bac8ac8a
Change-Id: I3d1163fe622bdd7dc42a485f796072524ab39db9
The new osmo_io framework means that we can [optionally] make use
of the io_uring backend, which greatly reduces the syscall load
compared to the legacy osmo_wqueue + osmo_select_main + read/write.
We only use features already present in the intiial osmo_io support
of libosmocore 1.9.0, so no entry in TODO-RELEASE is needed.
Closes: OS#5754
Related: OS#5755
Change-Id: I766224da4691695c023d4d08d042a4bbeba05e47
We already did a lookup from conn_src[i] and found a matching
codec_conn_dst, no need to do another reverse lookup to end up at the
same conn_src[i] codec.
Change-Id: Iecc7f22c551fd17b23db434fdb177266407d2621
