aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2023-12-04mgcp-client: Transmit remote IP addr in CRCX if known and port=0pespin/cliPau Espin Pedrol2-59/+70
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-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
2023-09-22mgcp-client: Fix missing include in mgcp_client_pool.hPau Espin Pedrol1-0/+2
struct vty is used as a param but it is never defined. Change-Id: Ia27bb20a79966cb90e04720462d24a236a168ada
2023-09-12Bump version: 1.11.0.51-af67-dirty → 1.12.01.12.0Pau Espin Pedrol7-31/+100
Change-Id: I9b1272cacaeaf1213f9a372eda52aac560cfbde5
2023-07-10ASCI: Support conference briding with 1..n connectionsAndreas Eversberg4-31/+31
For each RTP packet that is received from a connection, the mode is checked whether receiving is allowed or not. If not it is discarded. In case of "confecho" mode, the RTP is also sent by the receiving connection. Then a loop is used to send RTP to all sending endpoints except the one that received the packet. Because we have a loop that allows to have 1..n connections, we have no maximum number of allowed connections anymore. Change-Id: Ic99a55ab5a3a6170e940403fadd52697e99f2f3a Related: OS#4853
2023-07-10ASCI: Add new mode for voice group/broadcast callAndreas Eversberg3-1/+5
The new mode "confecho" is similar to "sendrecv", except that it also echoes back RTP towards the sender. This is required for voice group or broadcast calls. Talker and listeners use the same timeslot, so that audio must be echoed from the talker to the listeners. It is different from "loopback", because a loopback only echoes back RTP towards the sender, but does not forward audio through the endpoint to the other connections. Also it does not forward RTP from senders of other connections. The current implementation of MGW does not support transcoding and mixing. This means that a sending connection must not send RTP that has been received by multiple receiving connections. The application that uses the MGW has to set the connection modes, so that only one connection receives RTP in case of a conference. Change-Id: I0639c663e119d85bef1010c7aa45e2f133a9daf0 Related: OS#4853
2023-06-30mgcp_client: tweak extract_codec_name() implementationNeels Hofmeyr1-5/+4
Instead of calling strlen() for every loop iteration, just use strchr() to find the position of '/'. Change-Id: Ifc7302b6c5f9288a622e33c3e8b5fe0e7037dbdc
2023-06-30mgcp: fix "L: a:" header parsing: heed ";" separatorNeels Hofmeyr1-2/+2
In the "L: a:" header, read the first codec name only up to the ";" separator, and ignore the rest. According to RFC-2705, the "L: a:" header may include multiple codecs like "GSM-EFR;GSM" in: L: p:20, a:GSM-EFR;GSM, nt:IN osmo-mgw can handle only a single codec here. Since recently, osmo-msc is our first client that may actually send more than one codec. This uncovered a bug that leads to failing voice calls: * osmo-mgw parses the entire list "GSM-EFR;GSM" as a single codec name, * puts that into the ptmap without scrutiny, * and even sends it back in the OK response, in the *SDP* part, as a single "GSM-EFR;GSM" codec entry. We do not care very much about the "a:" codec list, because we always establish codecs via SDP later. So all we need to fix this is: parse the first codec done correctly, and ignore the rest. Related: OS#6081 Change-Id: I0342e85b32ed89f3a1fdb6131c3c8ded8f47a455
2023-06-28mgcp_client: check rc of map_str_to_codecOliver Smith1-3/+8
Abort with error log when map_str_to_codec is -1, instead of writing it as unsigned integer into ptmap[i].codec. Related: OS#6074 Change-Id: I08b91c849d810fe3cdb72c0f6f2a558b7377deab
2023-06-28Cosmetic: fix a typoOliver Smith1-1/+1
Change-Id: I49f72acc3a42f6c7d50aeffdb1aef312c469d9f3
2023-06-27mgcp-client: Mark client as UP when keepalive request-interval/timeout is ↵Pau Espin Pedrol1-6/+16
disabled through VTY This way if keepalive becomes disabled for an MGW, it can be selected again (otherwise it would become non-selectable forever, and we already have a "blocked" config for that). Fixes: 563386e8bbf0bc6d9050d87f79208d6784e219cf Related: SYS#6481 Change-Id: I263d23885a1a967f844033f9810b96691b8e3b30
2023-06-27mgcp-client: Always mark client as UP if keepalive request-interval disabledPau Espin Pedrol1-6/+6
In the previous logic, if "keepalive request-interval" was disabled (value 0, default), then if the client was configured to send a DLCX on startup it would end up in state UP or DOWN depending on whether the MGW answered to that request. As a result, an MGW that wouldn't answer would be left forever in DOWN state since it would have been selected no more and there would be a keepalive configured to re-mark it as UP. Fixes: 563386e8bbf0bc6d9050d87f79208d6784e219cf Related: SYS#6481 Change-Id: I290f7436f48418ee25179951359c76208796e279
2023-06-15mgcp_client: pool: Only pick clients with an MGCP link considered to be UPPau Espin Pedrol1-4/+5
This way the user ends up picking a working MGW instance instead of one which is not reachable around the time. Related: SYS#6481 Change-Id: Ia3f451d3cd97851f65074408812b1ddc68f67056
2023-06-15mgcp-client: Add keepalive featurePau Espin Pedrol5-16/+219
The `keepalive` feature in libosmo-mgcp-client allows scheduling periodical queries on the MGCP layer in order to make sure it is reachable and hence obtain information on the state of the MGCP link. This patch only uses it to print the status on the VTY, but it will be used too in a follow-up commit by the MGW Pool when picking an MGW from the pool: MGWs whose link is considered to be DOWN are skipped. The feature consists of: - A `keepalive request-interval` which will trigger a transmission of an MGCP AuditEndpoint command targeting endpoint with name `keepalive request-endpoint`. This interval is updated every time any message is transmitted in the MGCP link, meaning the MGCP AuditEndpoint message is only triggered if no message has been transmitted since `keepalive request-interval` seconds ago. - A `keepalive timeout` considering the MGW to be non-reachable (link DOWN) if no message is received over that amount of time. The `keepalive` parameters are to be preferrably configured so that "keepalive request-interval" * 2 < "keepalive timeout". Example VTY configuration of `keepalive` feature in libosmo-mgcp-client: ---- mgw 0 ... keepalive request-interval 20 <1> keepalive request-endpoint null <2> keepalive timeout 50 <3> ---- <1> Transmit an MGCP AuditEndpoint message to the MGW if no message has been sent to it over last 10 seconds <2> The MGCP AuditEndpoint targets the `null` endpoint. This is a special endpoint available at OsmoMGW for those purposes, but any available endpoint can be configured and used instead. <3> Consider the MGCP link to be DOWN if no message is received from the MGW over the last 50 seconds NOTE: The `keepalive` feature is disabled by default, and must be explicitly configured in order to enable it. Related: SYS#6481 Change-Id: I3dc74c78548d017f272da863d5282dc5e0020ca3
2023-06-15mgw: Allow auditing speciall 'null' endpointPau Espin Pedrol6-8/+188
This is a special endpoint which can always be audited. This is useful for clients who wish to submit requests to osmo-mgw periodically to find out whether the MGW is still reachable. This endpoint will be used by libomso-mgcp-client as default target endpoint to implement such feature. This "null" Endpoint is osmo-mgw specific, not described in MGCP specs. Related: SYS#6481 Change-Id: Ia409b16e9211e6261e2e0f21288544289d6f3733
2023-06-14mgcp-client: Move some static functions further abovePau Espin Pedrol1-34/+34
This is a preparation commit for follow-up one, where some of these functions need to be used in other static functions. Related: SYS#6481 Change-Id: I3a00d8c47ec773390d9626364c4c75ca579f1508
2023-06-14mgcp_client: Introduce mgcp_client_conf_alloc(), deprecate ↵Pau Espin Pedrol7-10/+44
mgcp_client_conf_init() So far, the users of the old non-pooled API were in charge of allocating the struct mgcp_client_conf by themselves, then init them using mgcp_client_conf_init(). This causes a major problem, since it makes it difficult to extend the struct mgcp_client_conf structure to add new features, which may happen frequently. The MGW pool API doesn't have this problem, because the struct mgcp_client_conf is allocated as parts/fields of private structs defined in internal headers. Only pointers to it are used in public headers. Since it still has to internally initialize the conf fields, we still need the API to initialize it internally, and hence why is it marked as DEPRECTED_OUTSIDE instead of DEPRECATED. While some programs already moved to the new MGW pool infrastructure, they still use the old APIs to accomodate for old config files in order to be back-compatible, hence most users of libosmo-mgcp-client are affected. Introduce an API to allocate the conf struct internally, which, while still breaking the ABI, allows for a more relaxed update path where it's possible to extend the struct mgcp_client_conf at the end. Eventually the non pooled API should be gone and the struct mgcp_client_conf can then be moved to a private header, but for now let's add this small feature to avoid major ABI breakage. Change-Id: Iba0853ed099a32cf1dde78c17e1b34343db41cfc
2023-06-11mgcp_client.h: also add spec ref to the other 3gpp defined payload typesPhilipp Maier1-5/+5
Some payload type numbers are defined in 3GPP TS 48.103, let's put the spec reference between all of those so that it is immediately clear where those numbers come from. Change-Id: Ie9d949ee72286ee4de7590c99acc740011208466
2023-06-09mgcp-client: Drop unused struct mgcp_client fieldPau Espin Pedrol2-7/+0
Change-Id: I0b2c4a83ca0e59e54bf5e2af289e4e1fe4f0cf27
2023-05-31mgcp_codec: be sensitive about IuFP when checking codecsPhilipp Maier1-0/+10
When two codecs are checked for convertibility we insist that subtype_name and rate are equal since normally when those are different, we assume a completely different codec that will require a transcoder, which we do not have yet. However when IuFP is used, the call agent will always negotiate IuFP as VND.3GPP.IUFP with a rate of 16000, even though the IuFP payloads contain regular AMR at a rate of 8000. This means that if we detect IuFP on one side of the call leg and AMR on the other side of the call leg, we must not insist on equal subtype_name and rate. This fixes the following TTCN3 testcases: MGCP_Test.TC_two_crcx_mdcx_and_iuup_rtp MGCP_Test.TC_two_crcx_mdcx_and_iuup_rtp_rfci_unordered Related: OS#5461 Change-Id: I6bc1e6022efe21cb893ef213f3da35017960357d
2023-05-26systemd: depend on networking-online.targetOliver Smith1-0/+2
Related: SYS#6400 Change-Id: Ib6c78c76c5f13b9482428ce653a61b03b2aca1d3
2023-05-22mgcp_network: do not deliver RTP packets with unpatched PTPhilipp Maier1-12/+3
When a call leg is set up, then the call agent (e.g. BSC, MSC, etc.) will also negotiate a codec along with a payload type number. When sending RTP packets, each RTP packet must also contain the negotiated payload type number. To prevent the emission of RTP packets with an incorrect payload type number, ensure that no packet is sent when mgcp_patch_pt() fails. Change-Id: I013a24c1e0f853557257368cfab9192d4611aafa Related: OS#5461
2023-05-22mgcp_codec: fix codec decisionPhilipp Maier8-343/+376
Unfortunately OsmoMGW was never really tested with multiple different codecs on either side of the connection. While OsmoMSC and OsmoBSC only assign exactly one codec on each side this has never been a problem, however it might become a problem when a call agent assigns multiple codecs on one side. This has been observed in a setup where OsmoMGW had one leg towards an external call agent. Also due to recent upgrades to the TTCN3 tests we are now able to simulate different codecs on both sides to pinpoint issues. Testing has shown that OsmoMGW has difficulties with multiple codecs. The reason for this is that the function that makes the codec decision was not fully finished. So let's finish the codec decision function and let's also use that decision when patching the payload type of outgoing RTP packets. Related: OS#5461 Change-Id: I6c3291f825488e5d8ce136aeb18450156794aeb5
2023-05-22mgcp_codec: move mgcp_codec_decide downPhilipp Maier1-81/+81
In a follow up patch we intend to fix mgcp_codec_decide, since the fixed version of mgcp_codec_decide will use some functions below its current position let's move it down before fixing it to make reviewing the changes easier. Related: OS#5461 Change-Id: I2f2538ff912eae4d80d3b74b766e18c4da94d6b6
2023-05-18copyright: fix typo: sysmocom s/s.m.f.c./s.f.m.c./ GmbHVadim Yanitskiy2-3/+3
Change-Id: I0de7650ad119d9a5d2585e2af981c5f1ff8e7058
2023-04-25debian: set compat level to 10Oliver Smith2-2/+2
Related: OS#5958 Change-Id: If00d77a3b83fa7ba000a346f087a6baf1966fdff
2023-04-21mgcp_vty: add warnings for deprecated config optionsPhilipp Maier1-0/+7
We normally warn in case someone uses a deprecated config option Change-Id: I182f6579930a4e5ed79c8eb87501578ce7e89c15
2023-04-18Cosmetic: mgcp_client: fix typoOliver Smith1-1/+1
Change-Id: I8e44b4bb853ebac881cb51b9546505874cf8fa45
2023-04-15mgcp_client: simpler error handlingNeels Hofmeyr2-88/+76
add_sdp(), add_lco(): - do not msgb_free() within these functions. Just return error, and move the msgb_free() to the caller. - when failing to write to the msgb, directly return error. Change-Id: I904d56f56053952c2ebbbe5dca744fafa32b333e
2023-04-15mgcp_find_section_end(): skip spaces at start of SDPNeels Hofmeyr1-3/+3
Change-Id: I015e0347a268b61c0ca45d40754942f87b461c09
2023-04-13mgcp_network: fix apidocPhilipp Maier1-4/+3
Change-Id: I358e21e9a9ab33beb07a9adfd4a53145aadb997d
2023-04-04mgcp_client_pool: add mgcp_client_pool_empty()Oliver Smith2-0/+6
Check if the private struct mgcp_client_pool has an empty member_list. Clients that support both the legacy config and the pool config can use this to properly exit with error if pool members are configured, but no connection to any of the pool members can be established. Currently clients can't distinguish a config without pool members and a config with pool members that is broken and will fall back to using the defaults of the legacy config in both cases. Related: OS#5993 Change-Id: I009483ac9dfd6627e414f14d43b89f40ea4644db
2023-03-31tests: $(BUILT_SOURCES) is not defined, depend on osmo-mgwVadim Yanitskiy1-2/+2
Change-Id: I951ce2410614993a855336e6bb408cae1823ef9a
2023-03-27mgcp_codec: cosmetic: remove line break in api-docPhilipp Maier1-2/+1
We usually do not make a final line break on our api-doc strings. Change-Id: I025bbf36287ef014e294cc18a6435d7e2f9c1bff
2023-03-27mgcp_codec: refactor payload type converstionPhilipp Maier5-128/+203
in mgcp_codec.c we have a function mgcp_codec_pt_translate that is used to find the equivalent payload type number on an opposite connection. This is quite specific and the resulting payload type number may still belong to a codec that might require some form of conversion. Lets refactor this so that the function just finds a convertible codec for a given connection. This also opens up other usecases. The payload type conversion like we did it before can then be done with a few lines in mgcp_network.c Related: OS#5461 Change-Id: I085260a2ca8cfecdb58656b7a046c536189e238d
2023-03-27mgcp_codec: fix oa/bwe comparison in mgcp_codec_pt_translate()Philipp Maier3-23/+112
The function mgcp_codec_pt_translate is very strict when comparing the codecs to each other to find a matching payload type number to be used on the egress side. This poses a problem when one side uses AMR in bandwith-efficient, while the other side uses AMR in octet-aligned payload type format. To the pt translate function the difference in the payload format will appear as if the codec were different and eventually the payload type number cannot be translated. since osmo-mgw offers conversion between the payload type format it would be no problem to ignore the payload type format when making the translation decision. The only exception here would be if one side would announce AMR two times, the first time with octet-aligned and the second time with bandwith-efficient format. Then we would have to use the payload type number from the exact match. (and skip any formatconversion) To archive such an optimized decision we will first go through the codec lists and perform an exact match. If we don't get a match we go through the codec lists a second time, but this time we ignore the payload format. Change-Id: Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d Related: OS#5461
2023-03-22Revert "mgcp_codec: do not differentiate between oa and bwe when comparing ↵Philipp Maier3-13/+28
codec" This reverts commit e0058b7207e022b698aea10f96cc7c0b1209058a. The reason for this revert is that the solution in the reverted patch does not cover a situation where the other side announces both payload formats at the same time. It could be that the end facing to a transit network announces both formats under two different payload types. In this case no conversion would be necessary. Depending on the input format the output would be send to the transit network under the payload type that matches and no conversion would happen at all. This revert re-intruduces the problem that was fixed in the patch before. Therefore it must be merged together with the follow up patch (Ifbd201a2749009a4644a29bd77e1d0fc0c124a9d) that contains the proper fix. Change-Id: I0b2854ef2397f38606fab3425be586a3d0ca27d1 Related: OS#5461
2023-03-22mgcp_e1: cosmetic: rewrite commentPhilipp Maier1-1/+1
Change-Id: I405cf464c052a2ab1461c3a8ba96665a3bc30341
2023-03-22mgcp_e1: rename e1_send to e1_send_ts_framePhilipp Maier1-2/+2
The function name e1_send is very generic, lets make clear that one E1 timeslot frame is sent. Change-Id: I5fba7993860a63149a13d943edbfabc4008680ef
2023-03-14mgcp-client: Call osmo_fd_unregister() before closing and changing bfd->fdPau Espin Pedrol1-2/+2
Change-Id: I95fbcc21a18cadd2c06608cc39b9fe8e12c8bccf
2023-03-11tests: use -no-install libtool flag to avoid ./lt-* scriptsVadim Yanitskiy2-0/+2
This option should be used for any executables which are used only for testing, or for generating other files and are consequently never installed. By specifying this option, we are telling Libtool that the executable it links will only ever be executed from where it is built in the build tree. Libtool is usually able to considerably speed up the link process for such executables. Change-Id: I4bc03bdc1f2de2574558e2ad753e116486993a7f
2023-03-11*/Makefile.am: libraries shall not be in AM_LDFLAGSVadim Yanitskiy3-14/+5
Change-Id: Ie9df855ee09b0761bd617fab58ca26450ac0c754
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-25 06:20:20 +0000