Let's have a unified way of freeing the FSM instance once it was
allocated, otherwise it's far more difficult to understand and maintain.
Change-Id: I8883e737fa112cff57834abae7ef272388a54edb
The error handling of the error path was wrong. Let's remove the "fi"
variable to avoid more of such errors. Furthermore, add an assert to
clarify for the reader that the map->mgw_fi will be freed before
allocating a new FSM instance below.
Change-Id: I9d3bca552bfa77f5e18f75bedad8d422f74df1f8
This is misleading for readers since it may access variables which may
be uninitialized or in a wrong state. Furthermore, we want to pass some
other variable name in a follow up patch.
This effectively allows the compiler to warn about uninitialized used of
a fi var in line 661.
Change-Id: Id694f51bb2918fd27da87b3f4a905727cd7f5de6
In mgw_fsm_handle_rab_ass_resp(), a NULL mgw_fi is handled as error,
but the error handling fails to return. The function continues to
dereference mgw_fi. Add missing return.
Related: SYS#5995
Change-Id: I3e98dc3a00145ec1f71c678bbf45debfd4276237
It is reported that a third-party SGSN is rejecting SCCP CR when the
SCCP message part exceeds a certain length. The solution is to first
send an SCCP CR without payload, and send the payload in a DT later.
Add config option
hnbgw
sccp cr max-payload-len <0-999999>
If the RANAP payload surpasses the given length, osmo-hnbgw will first
send an SCCP CR without payload, cache the RANAP payload, and put that
in an SCCP DT once the SCCP CC is received.
The original idea was to limit the size of the entire SCCP part of the
message, but I'm currently not sure how to determine that without
copying much of the osmo_sccp code. I figured using a limit on the RANAP
payload is sufficient. To avoid the error with above third-party SGSN,
the easy solution is to set max-payload-len to 0, so that we always get
a separate SCCP CR without payload.
Related: SYS#5968
Related: I827e081eaacfb8e76684ed1560603e6c8f896c38 (osmo-ttcn3-hacks)
Change-Id: If0c5c0a76e5230bf22871f527dcb2dbdf34d7328
There can be SCCP primitives without payload data, e.g. an "empty" SCCP
Connection Request.
Patch 'mgw_fsm: add MGW support to osmo-hnbgw' added RANAP message
decoding that lacks a guard against NULL data. Fix that: do not try to
decode NULL data.
Related: SYS#5968
Change-Id: Id755e769e82ace7203460ea1b3c847c2c90d41bf
Upcoming patch adds to this function. Let me first combine those four
LOGP() to a single one, use proper osmo_sccp_addr_to_str_c(OTC_SELECT).
To be able to use OTC_SELECT, switch hnbgw.c to osmo_select_main_ctx().
Related: SYS#5968
Change-Id: I1e0ea0a883e8cf65e6cfb45ed9b6f3d8fb7c59eb
The spec permits RAB AssignmentRequests with multiple RABs at a time.
Even though one voice call is assigned only one RAB in practice. Since
the current FSM implementation only supports a 1:1 scenario, lets check
if the MSC really assigns only one RAB and block RAB Assignments that do
not fit in this scheme.
Change-Id: I0f1d868fd0b4dc413533d6fcc5482862825181be
Related: OS#5152
While the FSM is created the RAB Assignment Requests is checked and
parsed. In case of failure the context is freed, but the CN is not
informed about the problem. The RAB AssignmentRequest will then most
likely time out. However, lets make sure the call is released by re
requesting an IU Release.
Change-Id: I1904f7e95d86bbcecee14f8721bd4075d0e33ab4
Related: OS#5152
osmo-hnbgw lacks support for an co-located media gateway. This makes it
virtually impossible to isolate the HNB from the core network properly.
Lets add MGCP support to osmo-hnbgw so that it can control a co-located
media gateway to relay the RTP streams between HNB and core network.
Change-Id: Ib9b62e0145184b91c56ce5d8870760bfa49cc5a4
Related: OS#5152
A RANAP RAB-AssignmentRelease may contain a ReleaseList. In order to
detect that a RAB is about to be released we need to be able to check if
the RAB we are dealing with is contained in such a ReleaseList.
Change-Id: I5b67cc2d35d11de7a09e66c181a1fdd5a58c75bb
Related: OS#5152
A RANAP RAB-AssignmentResponse may contain a FailedList. In order to
detect that a RAB Assignment failed at the HNB we need to be able to
check if the RAB we are dealing with is contained an such a FailedList.
Change-Id: I4319f7caa45ea758ccd792cc8570521df075cf45
Related: OS#5152
The parser functions currently ignore the rab_id. An exception is
ranap_rab_ass_req_ies_extract_inet_addr, which extracts the rab_id
of the first RAB. To make the handling of the RAB assignment parsing
more robust lets add a rab_id parameter to the other functions. This
parameter can then be used to ensure thet the correct RAB is handled.
Change-Id: I2259ffce9f4b508c555d60618c5983ac6294e0ae
Related: OS#5152
The RANAP RAB AssignmentRequest and AssignmentResponse contains the
IP-Address and the IP-Port for the RTP voice stream. In the comming MGCP
implementation we will have to extract and replace this information.
Lets add functions that do that in a convinient way.
Change-Id: I58b542bf23ff5e1db2ccf6833fec91d9ba332837
Related: OS#5152
Pau Espin
Neels Hofmeyr
Philipp Maier