Attention is currently required from: fixeria, pespin.
Hello Jenkins Builder, pespin,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed: Code-Review+1 by pespin, Verified+1 by Jenkins Builder
Change subject: s1ap_proxy: handle_ies(): pass IEI path to handle_ie() ......................................................................
s1ap_proxy: handle_ies(): pass IEI path to handle_ie()
This patch prepares for a follow-up change adding E-RAB MODIFY REQ/RSP.
We need to be able to match the IEs unambiguously, because the same IEI may be used in different contexts and thus have different meaning, sometimes within the same PDU. The E-RABItem IE is such an example:
* 9.1.3.5 E-RAB RELEASE COMMAND ** contains an E-RABToBeReleasedList IE *** contains E-RABItem IEs
* 9.1.3.7 E-RAB RELEASE INDICATION ** contains an E-RABReleasedList IE *** contains E-RABItem IEs
So far we handled this duality by passing the release kind via the #proxy_state record ('rel_kind' field) and it worked. But soon in follow-up changes we'll have to deal with other PDUs:
* 9.1.3.4 E-RAB MODIFY RESPONSE ** contains an E-RABModifyListBearerModRes IE ** may contain an E-RABFailedToModifyList IE *** contains E-RABItem IEs
* 9.1.3.9 E-RAB MODIFICATION CONFIRM ** may contain an E-RABFailedToModifyList IE *** contains E-RABItem IEs ** may contain an E-RABToBeReleased IE *** contains E-RABItem IEs
A universal approach allowing to match and handle IEs properly depending on the context is to maintain the full IEI path in handle_ies() and pass it to handle_ie().
Change-Id: I35528a91f7dbf321ad1a0811f1bbcdfb529d3530 --- M src/s1ap_proxy.erl 1 file changed, 59 insertions(+), 38 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/erlang/osmo-s1gw refs/changes/13/39113/2