It was found in the field that some peers sends an X.213 IP address
consisting of 7 bytes (1byte IDP/AFI, 2byte ICP, 4 byte IPv4 address) insetad
of 20 bytes. This was until recently failing in osmo-hnbgw due to
missing decoding functionalitit in osmo-iuh.git. Cover it here.
Related: SYS#6623
Depends: osmo-iuh.git I507fb1605d976bd8573162e4fa81721245330184
Change-Id: I71323018d79a4f5778dc6e49488d75ae7c2c4cdc
When we check for an assignment failure in a RAB AssignmnetResponse, we
use decode_rab_flitms_from_resp_ies to search through the list of RAB
FailedItemsIEs for the RAB id we want to check. In case of failure, we
get a positive index back from this function. We then know that the RAB
that we checked for has failed bcause it was in the FailedItemsList.
In that case, we also must free the RAB FailedItemsIEs that
decode_rab_flitms_from_resp_ies has decoded. At the moment we also free
the RAB FailedItemsIEs also when decode_rab_flitms_from_resp_ies returns
with a negative return code, which may mean that the RAB was not found
or some other error occured. In this case we must not free since then
no valid RAB FailedItemsIEs are allocated.
Related: OS#6062
Change-Id: I755ba6599079810a048bf5b6d8947b5a9ffa622d
To ease linking C tests, introduce a libhnbgw.la that contains all of
osmo-hnbgw except the main() and friends.
(I wrote a test that I was going to add, but it turned out to be
obsolete -- now at least we may keep this preparation to add C tests
more easily.)
Change-Id: Id2a706a30fb459005c676bb29c196cf3a582fa01
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: Id5f88c331cf1dfd3f38120b4ef59ced9a563d4f0
Large RAN installations may benefit from distributing the RTP voice
stream load over multiple media gateways.
libosmo-mgcp-client supports MGW pooling since version 1.8.0 (more than
one year ago). OsmoBSC has already been making use of it since then (see
osmo-bsc.git 8d22e6870637ed6d392a8a77aeaebc51b23a8a50); lets use this
feature in osmo-hngw too.
This commit is also part of a series of patches cleaning up
libosmo-mgcp-client and slowly getting rid of the old non-mgw-pooled VTY
configuration, in order to keep only 1 way to configure
libosmo-mgcp-client through VTY.
Related: SYS#5091
Related: SYS#5987
Change-Id: I371dc773b58788ee21037dc25d77f556c89c6b61
ranap_rab_ass_req_encode() forms a msgb, then copies the data to a
buffer provided by the caller. Instead, just return the msgb. This
removes one unnecessary memcpy() and simplifies some code.
In ranap_rab_ass_test.c, actually ensure the correct size of the
returned data. See also the fix of expected test data in patch
Ifb98a52e56db1227a834c0d7b7a260314d9f547e
Related: SYS#5895
Change-Id: I85e715326e1d8f4f301f82f78da109f1a7a92f30
There is an extra zero octet at the end of the test data, which does not
get encoded back. The test currently does not detect this, but will in
upcoming patch I85e715326e1d8f4f301f82f78da109f1a7a92f30.
Related: SYS#5895
Change-Id: Ifb98a52e56db1227a834c0d7b7a260314d9f547e
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
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
Philipp Maier
Neels Hofmeyr
Vadim Yanitskiy
Neels Hofmeyr