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
There is considerable code complexity in place for this ancient hack.
It dates back to 5ea1bc77a3
"
mgcp: Allow to freely control the a=fmtp line for experiments
In case of AMR one can specify the available codecs out-of-band. Allow
to configure this line statically in the configuration file.
"
Looking in mgcp_test.c output, the fmtp-extra tests do not even make
sense: they result in fmtp for pt=126 being added, even though there is
no payload type 126 listed in the SDP...
Related: OS#6313
Change-Id: Icee0cd1f5a751fa760d5a9deca29089e78e7eb93
It seems to be a remnant from early openbsc_mgcp. There is only the
default implementation for this callback and it simply returns two
pointers. Simplify that.
Change-Id: I18dfd44c931540caf4ac360c08ed10e5f65b2165
Removing the duality of codecs[] and ptmap[] in structs mgcp_msg,
mgcp_response and mgcp_conn_peer has removed the need to "map" from
codec type enum to payload type number. They are stored together now.
Remove functions that are no longer used.
None of our osmocom users of libosmo-mgcp-client call these functions.
Change-Id: I84e5285831397c992af59deee12dea8458d16cc6
So far we allow only MGCP_MAX_CODECS-1 entries, because the parsing exit
condition hits only after the array size check. Instead, check the array
size a bit later, just before actually adding a valid entry.
This is verified to work as expected in upcoming patch
I842ce65a9a70f313570857b7df53727cc572b9e6 that adds a new
mgcp_client_test.c section for this.
Change-Id: I9a28da85e437f118026ea71a5a708e5758fff623
codecs[] is an array of enum osmo_mgcp_codecs.
ptmap[] is an array of { enum osmo_mgcp_codecs, unsigned int ptmap }.
MGCP lists first a bunch of payload type numbers and then specifies them
again for details, like the numbers 112, 96, 3 in this example:
m=audio <port> RTP/AVP 112 96 3
a=rtpmap:112 AMR/8000
a=rtpmap:96 VND.3GPP.IUFP/16000
a=rtpmap:3 GSM-FR/8000
So far we keep these lists in two separate arrays:
- codecs[], codecs_len stores the 'm=audio' list
- ptmap[], ptmap_len stores the 'a=rtpmap' list (and may omit some
elements present in codecs[])
This applies to both struct mgcp_response and struct mgcp_msg.
These are semantically identical, and the separation leads to checks,
conversions and dear hopes of correct ordering.
So let's keep only one list with both codec and payload type number in
it. The 'm=audio' list establishes the order of the pt numbers, and the
'a=rtpmap' list adds codec information to the established entries.
In the internal API structs mgcp_msg and mgcp_response, just drop the
codecs[] entirely.
In public API struct mgcp_conn_peer, keep the codecs[] array, mark it
deprecated, and provide a backwards compat conversion: if any caller
invokes mgcp_conn_create() or mgcp_conn_modify() with codecs[] still
present in the verb_info arg, then move codecs[] entries over to the
ptmap[] array in a sensible way.
(BTW, even mgcp_conn_create() and mgcp_conn_modify() are never called
from outside of libosmo-mgcp-client in any of our osmo-cni programs;
users call osmo_mgcpc_ep_ci_add() and osmo_mgcpc_ep_ci_request(), which
in turn may pass user-provided codecs[] lists on to mgcp_conn_create() or
mgcp_conn_modify().)
Tests for parsing the MGCP response are mostly missing. They will be
added in upcoming patch I842ce65a9a70f313570857b7df53727cc572b9e6,
because they will be using only the new ptmap API.
Related: OS#6171
Change-Id: I798e02c6663376d3d52f4a74fc4b32411ce95bed
As was pointed out during code review of a previously merged patch,
whenever we write something to the tailroom, we must use msgb_put().
Change-Id: Ibe1605631a94088bfd1f603f7043322ed5585ffe
We need to be able to terminate the received string in case it was
not nul-terminated by the sender (see mgcp_msg_terminate_nul()).
Change-Id: Icc878af7f671213bb516af62cb601914d86ff808
Fixes: CID#272990
The current statement:
msg->l2h + msgb_l2len(msg)
looks as follows, if we expand the msgb_l2len():
msg->l2h + msgb->tail - msg->l2h
so this is basically equal to msgb->tail alone.
Change-Id: I4f4b0f792bbeef94a5449c4a5843628a703a3d54
Related: CID#272990
There is an upcoming modification of structs mgcp_msg and mgcp_response.
When it is public API, it needs to be kept backwards compatible.
But no libosmo-mgcp-client caller (in the osmocom-cni world) has used
these structs in years and years. Everyone should use the higher level
osmo_mgcpc_* API only.
Move this legacy API to a private header, so we no longer need to worry
about compatibility there.
Related: OS#6171
Related: I798e02c6663376d3d52f4a74fc4b32411ce95bed
Change-Id: I6d8bdda5c2ffa236e94a0b6111de4dbfac923187
end.codec may be NULL, depending on whether a single matching codec
could be found or not, i.e. based on external input. So let's not crash
if an RTP packet arrives while end.codec == NULL.
Change-Id: I9bfb55a343b3f2b1459e0aba4ee71a6133b992b3
A client may know the IP address during CRCX but not yet the port, or it
may simply want to hint an initial IP address so that the MGW can better
guess when allocating a local IP address.
Related: SYS#6657
Change-Id: I30165dbac5e484011d0acf46af36f105954a501d
Do not refuse IuUP Initialization messages coming in on an RTP port if
the remote port is not yet known.
If an IUFP conn is not yet configured (pre-Initialization), allow rx
from any address or port.
An osmo-mgw client (eg. osmo-hnbgw) may wish to initially set a remote
IP address as a hint during CRCX, hence the IP address may already be
set while the port may be unset.
Related: SYS#6657
Change-Id: Idd833997abce46886e9664505b2776fa5dadc8db
