aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc/msc_mgcp.c
AgeCommit message (Collapse)AuthorFilesLines
2018-10-08msc_mgcp: move mncc struct initalization to where its actually neededPhilipp Maier1-9/+11
The function _handle_error() initalizes a struct gsm_mncc variable on startup. The initalization accesses mgcp_ctx->trans->callref. All this is done before the assertion on mgcp_ctx. Later in the code one finds an if which tests on mgcp_ctx->free_ctx. This is the only part of the code that accesses the mncc struct variable. We should move the initalization there as well. - Move initalization of struct gsm_mncc mncc into the if body that uses it. Change-Id: I86983eabd999c4275dcc0e4a169ef2aa1e33c747 Related: OS#3635
2018-09-28fix a use-after-free in msc_mgcp.c:_handle_error()Stefan Sperling1-10/+10
Move code which needs to test the mgcp_ctx->free_ctx flag upwards such that it runs before we're calling functions which will potentially free mgcp_ctx. The code being moved up takes effect only in case mgcp_ctx won't be freed, so there should be no functional difference. Change-Id: I5df17c19e2a68c019f7eaf582b14585caa54b32a Related: OS#2885
2018-08-07mgcp: use codec information returned with ASSIGNMENT COMPL.Philipp Maier1-14/+6
When the assignment completes a choosen codec is returned. At the moment we do not use this information. - add struct members for codec info (both, RAN and CN) - parse codec info in BSSMAP ASSIGNMENT COMPLETE - use codec info on mgcp Since the MNCC API is not complete yet, we currently only use the codec info only on the internal MNCC yet. Change-Id: I9d5b1cd016d9a058b22a367d0e5e9f2ef447931a Related: OS#2728
2018-07-26cosmetic: typos in log and commentNeels Hofmeyr1-6/+6
Change-Id: I2416d9a45e88f4317aa8e6644f5581a6f4f119c8
2018-07-26Iu MGCP: no need to loopback on the cn sideNeels Hofmeyr1-8/+0
Change-Id: I501a7846c76dd703beb3991362b1ccbd62dfd155
2018-05-29mgcp: hack to keep IuUP workingPhilipp Maier1-0/+40
Since change If9a81d057f73150e483286472e73c45e7a453a6d removes the RTP loopback at the beginning. This also means that the Hack we do to run the IuUP negotiation via looping back the first few RTP packets will not work anymore. However, we should keep that hack as long as we do not have IuUP support in the MGW. - Start RTP connection in loopback mode for IuUP Change-Id: I4c7d90de4dc87e8baf7cf4a0c69d0e9e8c92e27b
2018-05-29mgcp: do not start connections in loopback modePhilipp Maier1-2/+2
When the MSC creates the connections for the BSS side and for the PBX Change-Id: If9a81d057f73150e483286472e73c45e7a453a6d
2018-04-11msc_mgcp: do not send wildcarded DLCX messagesPhilipp Maier1-5/+25
If an error on the MGW side occurs, the MSC may send out a DLCX command that contains a wildcarded endpoint name. Wildcarded DLCX commands are legal in principle but not in the context of an error on a single endpoint. Apart from that osmo-mgw is (not yet) capable to handle wildcarded DLCX command. The problem is caused by a wrong error handling. When the first (RAN) CRCX fails the error handling logic tries to perform a DLCX, but since we did not receive a specific endpoint name yet, the buffer containing the endpoint name is still initalized with the wildcarded enpoint name, but the error handler and the code that generates the DLCX is not aware of that. - Perform a check in the error handler function that checks if a DLCX can be made (a specific endpoint name is set - Correct the flags in the code that handles the first CRCX so that no DLCX is requested in the case of error Related OS#2882 Change-Id: I64c2a82016d854ad446fd49a5d76a28324e8bd4b
2018-04-11msc_mgcp.c: log endpoint name instead of pointerPhilipp Maier1-3/+3
The logtext currently logs the pointer (address) of the string variable that holds the endpoint name, rather then the endpoint name itself. - Use %s instead of %p in format string Change-Id: I01b3d07aeedd72be60361249a5bf80fbb68b7bb8
2018-03-17msc_mgcp.c: Fix several wrong ptr printf fmtPau Espin Pedrol1-5/+5
Fixes several of these type of warnings: include/osmocom/core/fsm.h:123:38: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘char *’ [-Wformat=] LOGP((fi)->fsm->log_subsys, level, "%s{%s}: " fmt, \ ^ src/libmsc/msc_mgcp.c:277:71: note: format string is defined here "CRCX/RAN: creating connection for the RAN side on MGW endpoint:0x%x...\n", mgcp_ctx->rtp_endpoint); ~^ Change-Id: I17b7bed8fc39612286ba66f250b6b26da01d38c0
2018-03-16msc_mgcp: to not access higher layers after releasePhilipp Maier1-4/+9
The higher layers (gsm_04_08.c) are informed errors occur. But it is not checked if the call was already released. If an error occurs after the call control stack calls msc_mgcp_call_release() then the higher layers might already have cleaned up and the code accesses memory that is already freed (trans) - fix use after free by guarding the call to mncc_tx_to_cc() Change-Id: I78f1b6a9149488a4ad3f120c1e190a83c07d4b89 Related OS#2881 Related OS#2882
2018-03-14mcgp: let the MGW allocate the MGCP endpointPhilipp Maier1-22/+27
osmo-msc still uses endpoints that are allocated locally by the MGCP-Client. Since osmo-mgw now supports the more comfortable, dynamic variant we should make use of it. - Replace the endpoint numer allocation by the client with a wildcarded CRCX. Use the endpoint that is assigned by the MGW. Related: OS#2710 Change-Id: Iee3e446b6689626516f01c521abe3d4603cd3e13
2018-03-14msc_mgcp: use more conceise error msg on truncationPhilipp Maier1-7/+7
When a truncation check (osmo_strlcpy()) fails handle_error() is called with MGCP_ERR_NOMEM as cause code. Which finally results in an "out of memory" message. MGCP_ERR_NOMEM is only used for failed truncation checks, so it makes sense to choose a message that describes the cause of the problem better. - rename MGCP_ERR_NOMEM to MGCP_ERR_TOOLONG - replace error message string Change-Id: Ifedb85c1933a30b2aa491b495119919f45782e2c
2018-03-14mgcp: be sure that pending mgcp transactions are canceled before freePhilipp Maier1-0/+7
When the FSM reaches ST_HALT it frees itsself and all context information but it is not ensured that there are still pending MGW transactions that might hit late and eventually cause a use after free situation. - if an MGW transaction is still pending, cancel it. Change-Id: I8ff55e48a95cc4c556a97ad2593bad1cc1aa69bd
2018-03-14msc_mgcp: fix mgw timeout handlingPhilipp Maier1-40/+58
When the MGW does not respond to an MGCP message then the mgcp FSM terminates, but the CC handler (gsm_04_08.c) is not informed. This lets the CC handler think that the MGCP connection would be successful, so it also does not take any action to release the non functional connection. - make sure the CC handler is always informed on any kind of error, especially on MGW timeouts Change-Id: I3fcd0d71fad53274e82f6d87c80042d06283bc5d Related OS#2881 Related OS#2882
2018-02-26msc_mgcp: Add FSM event namesPhilipp Maier1-0/+13
The FSM (fsm_msc_mgcp) lacks a proper definition of the FSM event names. This causes problems when inspecting the FSM using the VTY. - Add proper FSM Event names Closes: OS#2924 Change-Id: I6823756a63b08a71e5518130e49751aa073dbcd2
2018-02-19libmsc: Pretend MNCC requested release in handle_error()Daniel Willmann1-0/+11
Send a release request to the MS so the connection does not stay open indefinitely. Change-Id: I7669d29cf5be3e4a60a1d121edbfcf9056f6d82b
2018-02-10MGCP: Response code 250 is *not* an error for DLCXHarald Welte1-1/+2
Change-Id: I9f64996bfff09561f253115681ed63ee87b90ef3 Closes: OS#2923
2018-02-08increase RAN timeout in MGCP FSMPhilipp Maier1-3/+2
The MGCP FSM implements a timeout when waiting for the RAN to complete the call (assignment complete, alerting, connect...). This timeout is currently set to 10sec. This means if the other end did not pick up after 10sec, the MGCP connection will be lost while the phone keeps ringing. When the other end finally picks up, the call gets disconnected. This behavior is odd and requires a proper fix. For now increasing the timeout to 120sec. will decrese the probability that he problem occurs. - Increas RAN timeout to 120sec (2 min). Change-Id: I5a11d53f9701d9b11b18d7026ff2241c7c0b57f5
2018-02-05mgcp: use osmo-mgw to switch rtp streamsPhilipp Maier1-0/+1078
in the current implementation we still use osmo-bsc_mgcp, which has many problems and is also obsoleted by osmo-mgw. integrate osmo-mgw and re-implement the current switching using an osmo fsm. Depends: osmo-mgw Iab6a6038e7610c62f34e642cd49c93d11151252c Depends: osmo-iuh I3c1a0455c5f25cae41ee19229d6daf299e023062 Closes: OS#2605 Change-Id: Ieea9630358b3963261fa1993cf1f3b563ff23538
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 03:27:29 +0000