aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2 daysiuup: Increment RTP hdr seqnr even if Tx over UDP failsHEADmasterPau Espin Pedrol1-1/+1
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
2 daysFix IuUP RTP hdr seqnr field not incrementedPau Espin Pedrol3-10/+10
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: 352b967d1bee4b3bc51ecc383306bad0fc5b7fbf Change-Id: I154e1e41cd02fd4d9b88ad98fc7c4d657246c589
2024-04-02Convert RTP/RTCP/OSMUX I/O from osmo_fd to osmo_ioHarald Welte7-169/+204
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
2024-03-20cosmetic: make linter happyrhizomatica/testingHarald Welte1-4/+4
Change-Id: Iec8404061588b848f9e597bf4112d6df9597de95
2024-03-20Change msgb ownership in processing of received msgbHarald Welte5-39/+111
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
2024-03-20remove osmo_fd from mgcp_create_bind()Harald Welte3-14/+16
preparation for osmo_io Change-Id: I4a3b66a14fdfbc867daca0f0a05f694d5e0d7b66
2024-03-20simplify unused transcoding/processing call-backHarald Welte3-13/+6
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
2024-03-20remove strange loop for non-existant transcoding supportHarald Welte1-56/+50
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
2024-03-20don't log useless "transcoding disabled" messageHarald Welte1-1/+0
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
2024-03-19mgw: Add our usual SIGABRT, SIGUSR1 signal handlersHarald Welte1-0/+27
This is mostly related to talloc reports. Change-Id: Idc35444d2b8a0bc52c267b468dfa3c1b59f9187a
2024-03-19mgw: do not fail MGCP on codec mismatchNeels Hofmeyr1-1/+11
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
2024-03-07migrate mgcp_client from osmo_wqueue to osmo_ioHarald Welte3-55/+57
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
2024-02-06mgcp_test: fix false negatives in test outputNeels Hofmeyr1-2/+6
If one test fails, do not print failure for all following tests as well. Change-Id: I196880b4b34a672ef45042c25f89bc1684363567
2024-02-06tweak DEBUG logNeels Hofmeyr1-2/+2
Printing the debug log line a little later will include the MGCP verb information. Change-Id: Icb230cf4d623cdbc4ab52bd52d2a72525c0168c7
2024-02-06mgcp_codec_decide: remove redundant lookupNeels Hofmeyr1-8/+7
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
2024-02-06drop cfg 'sdp audio fmtp-extra'Neels Hofmeyr8-85/+17
There is considerable code complexity in place for this ancient hack. It dates back to 5ea1bc77a3947f541d576f95e7ecc7249fc65b9b " 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
2024-02-06drop get_net_downlink_format_cbNeels Hofmeyr4-20/+2
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
2024-02-06tests/mgcp: add update_exp targetNeels Hofmeyr1-0/+3
Change-Id: I1ea7e881fe13429762bf31507d8d23fe58e241b3
2024-01-29Convert README to README.md and expand like in other projectsHarald Welte4-26/+104
Let's align with structure and content of README.md in other osmo-* projects. Change-Id: Id9a78ccc0d10f0e3a9d832ac4c4988cfbb8ddb3c
2024-01-26build: include README into the release tarballVadim Yanitskiy1-0/+1
Change-Id: I4e302914340467e8c047d60ab862267f4e94acad
2024-01-11Revert "drop (now) unused code"neels6-5/+177
This reverts commit 2b30cbdfa83c20045ef92f53e88441dda185591b. Reason for revert: Older versions of osmo-msc were actually calling map_codec_to_pt(). Change-Id: Ifff31012b327d40ed0b1559d5cf4f320784a4061 Related: https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master/1792/console
2024-01-05drop (now) unused codeNeels Hofmeyr6-177/+5
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
2024-01-05mgcp_client_test: add test_parse_response()Neels Hofmeyr2-0/+257
Change-Id: I842ce65a9a70f313570857b7df53727cc572b9e6
2024-01-05client SDP: more verbose error loggingNeels Hofmeyr1-5/+16
So far it was pure guess work to find out why a message fails. Change-Id: Ibc6343db82281789004c140ba98d99e5f6f73d83
2024-01-05client: allow MGCP_MAX_CODECS entriesNeels Hofmeyr1-4/+4
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
2024-01-05client: collapse codecs[] and ptmap[]; allow codec variantsNeels Hofmeyr7-74/+175
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
2024-01-05client: deprecate legacy APINeels Hofmeyr1-5/+9
Change-Id: I7409907dafbb2fe905fee9bc22d6870056bf3022
2023-12-23build: move mgcp/*.h to noinst_HEADERS, drop RPM libosmo-mgcp-develNeels Hofmeyr2-15/+3
We only install the mgcp_client/ headers. Related: OS#6300 Change-Id: Ie0f79222bd1702097c12193dcf7a0462805cfc4a
2023-12-19client: safely handle dealloc on event dispatchNeels Hofmeyr1-2/+34
See also the long in-code comment. Related: OS#6302 Change-Id: I6f1c0f6a26f9cd6993dc1910a44070ec0438e636
2023-12-17mgcp: correctly put NUL character in mgcp_msg_terminate_nul()Vadim Yanitskiy1-1/+1
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
2023-12-17mgcp: reserve once byte for '\0' in mgcp_do_read()Vadim Yanitskiy1-1/+2
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
2023-12-17mgcp: simplify getting msgb tail in mgcp_msg_terminate_nul()Vadim Yanitskiy1-1/+1
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
2023-12-08client: move some items to internal headerNeels Hofmeyr4-65/+78
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
2023-12-08fix possible NULL deref on early mediaNeels Hofmeyr1-2/+3
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
2023-12-08mgcp_client_test: fix function nameNeels Hofmeyr1-2/+2
Change-Id: I213f9b2713ff80a16603b8342c204cb546cc782d
2023-12-07mgcp-client: Transmit remote IP addr in CRCX if known and port=0Pau Espin Pedrol2-31/+42
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
2023-12-05IuUP: Allow Initialization with set rem IP address and unset rem portPau Espin Pedrol1-1/+2
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
2023-12-05check_rtp_origin: drop special case for legacy IuUP hackNeels Hofmeyr1-23/+7
We have proper IuUP support and everything about this legacy hack should be purged. The purpose of this function is to validate that RTP is coming from the expected address and port. To allow that legacy IuUP hack, which is no longer needed, we punched a hole into this validation, by adding this special case for loopback mode (suddenly we don't care who or what sends RTP and bounce it back to anyone). So let's get rid of this hole that was only needed for very early 3G voice hacking. Instead, we permit RTP for IuUP Initialization regardless of the RTP loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b Related: SYS#6657 Change-Id: I158dd046fdfcb10392cde3de8cc88dd095a05b40
2023-12-05IuUP: allow Initialization from any address if not yet setNeels Hofmeyr1-0/+12
Do not refuse IuUP Initialization messages coming in on an RTP port if the remote IP address is not yet known. If an IUFP conn is not yet configured (pre-Initialization), allow rx from any remote address if the remote IP address is not yet known. If we refuse the IuUP Initialization, a 3G RNC may fail to set up a RAB. We will know the remote address only *after* assigning a RAB succeeded. So the IuUP Initialization must be allowed before knowing all addresses. At the time of writing, CRCX for IUFP are sent to osmo-mgw in either LOOPBACK or in RECVONLY mode: - current osmo-msc: recvonly - osmo-msc <= v1.10.0: loopback - osmo-hnbgw: loopback IuUP Initialization should work regardless of that. See also next patch I158dd046fdfcb10392cde3de8cc88dd095a05b40 IuUP is one layer below the loopback/send/recv decision for RTP; IuUP is always terminated at the MGW, while the AMR payload carries through. Related: alternative patch Idd833997abce46886e9664505b2776fa5dadc8db Related: SYS#6657 Change-Id: I6c365559a7bd197349f0ea99f7a13b56a4bb580b
2023-12-05cosmetic: Fix line indentationPau Espin Pedrol1-1/+1
Change-Id: I85e47894aa0ed54dbf22a7a88d8cbeadaad4b248
2023-12-04mgcp_network: Improve err logging when rtp pkt from unexpected origin comes inPau Espin Pedrol1-17/+9
Change-Id: Id9b60395df667ae9898c23cbc2afe56ac7e8b0e5
2023-12-03systemd,manual: set LimitNOFILE=65536Neels Hofmeyr2-0/+18
A typical OS imposed limit is 1024 open FD, which can bee too low when there are hundreds of concurrent voice calls. In systemd service file, set a super high limit of 65536. In osmo-mgw's user manual, add section 'Configure limits' describing this in detail. Related: OS#6256 Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71 Change-Id: I46512517bc3b5bb90cac7643e7ac73afba398d36
2023-12-01Use uniform log format for default config filesAndreas Eversberg2-0/+16
Related: OS#6272 Change-Id: I82ee4ce3c961976526a792862061c237a372e31b
2023-11-30client: replace two assertions with graceful error handlingNeels Hofmeyr1-2/+10
A user reports crashes of osmo-bsc upon EV_MDCX. It turns out that there is a lot of error reporting and a distinct possibility to get a NULL return value because of external input. Terminate the FSM instead. FSM termination is the proper way to report a bad error, it signals the parent_term_evt to the FSM parent, which will then be able to act on the failed MGCP operation. Related: SYS#6632 Change-Id: Ia5d8a9aff565399a85a5b116d7029fedcab234e0
2023-11-15mgcp_parse_audio_port_pt(): fix buffer overflowNeels Hofmeyr1-1/+1
Change-Id: I18c78d15eb1593f404b4741248225b68878b463f
2023-11-02vty and log: also show local port for RTP connsKeith Whyte1-32/+16
Before: CONN: (1226/rtp, id:0xD94316AD, ip:127.0.0.2, rtp:2344 rtcp:2345) After: CONN: (1226/rtp C:D94316AD r=127.0.0.2:2344<->l=127.0.0.1:4002) While changing that string, also include these changes for consistency and readability: - use the same r:...<->l:... format as osmo_sock_get_name(). - Instead of 'id:0x' use the actual MGCP format 'C: 9B686BE3'. - drop the commas - drop RTCP port: it is always RTP+1 and always an odd number. Rationale: The CONN pairs associated with each endpoint show remote RTP ports. When osmo-mgw is being used by both BSC and MSC, one side of the pair is showing the internal loop connection inside osmo-mgw, while my intuition suggested this connection pair is showing me the RTP port tuple of a single RTP stream. Adding the local port to the display makes it more clear, IMHO. Seeing the local port can also help to correlate the MGW vty dump with a capture of RTP. Implementation: I first tried directly using osmo_sock_get_name_buf() on conn->u.rtp.end.rtp.fd, but that might hide already known information when the fd is not actively used yet (before SDP): the local address and port would then be shown from the fd, not from conn->u.rtp.end.local_addr/_port == hidden before the fd is set up. Patch-By: whytek, nhofmeyr Change-Id: Ib89a6779e1d68c6600f00699d4303f6c0ee07132
2023-11-01add mgcp_conn_rtp_type_names[]Neels Hofmeyr2-0/+12
First use in upcoming Ib89a6779e1d68c6600f00699d4303f6c0ee07132 Change-Id: If3d8bc68a3b26d3aa0ba7eedeab67b820889ed54
2023-09-28Bump version: 1.12.0.3-58d5b → 1.12.11.12.1Oliver Smith2-1/+10
Change-Id: Iefb000582a139ff53c4afbf94e1299e26ceeac44
2023-09-27mgw: Configure IuUP if codec set during MDCXPau Espin Pedrol1-0/+4
The mgcp client may first configure the connection to use RTP-AMR, but after setting up another call leg may find out that both legs are IuUP and hence want to forward the IuUP between the 2 connections instead. In that case, an MDCX with codec VND.3GPP.IUFP would be set. Until now, osmo-mgw didn't take that scenario into account, and it was only upgrading the rtp conn to iuup internally during CRCX. As a result, in the mentioned scenario osmo-mgw would continue to output RTP instead of IuUP after the MDCX with VND.3GPP.IUFP, which is wrong. Related: SYS#6578 Change-Id: Ic94bf90f54d8ba3e65a2cd52734867847f3a60c2
2023-09-26mgcp-client: Introduce API osmo_mgcpc_ep_local_name()Pau Espin Pedrol2-0/+25
Change-Id: I18d7bdf650c0ec87ae16ed4944aed9f495400137
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 19:30:31 +0000