neels has uploaded this change for review. ( 
https://gerrit.osmocom.org/c/osmo-hnbgw/+/34974?usp=email )


Change subject: allow second CS RAB Assignment Request
......................................................................

allow second CS RAB Assignment Request

In the field, we've encountered a so far unsupported scenario: after a
RAB Assignment Request and Response have successfully set up an RTP
stream, the CN sends *another* RAB Assignment Request to modify some SDU
parameters, omitting the transportLayerInformation IE (not modifying the
RTP address).

Detect a secondary RAB Assignment Request, and just forward it as-is:
the hNodeB is interested in the RAB configuration, osmo-hnbgw just needs
the RTP info, which is not even present in this use case.

Do not (yet?) support modifying the RTP address/port.

Related: osmo-ttcn3-hacks Iadaba0e5e82ad6d163ad509904ede213e2462d5c
Related: SYS#6624
Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
---
M src/osmo-hnbgw/mgw_fsm.c
1 file changed, 79 insertions(+), 0 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/74/34974/1

diff --git a/src/osmo-hnbgw/mgw_fsm.c b/src/osmo-hnbgw/mgw_fsm.c
index ddab0b5..3bbd8c6 100644
--- a/src/osmo-hnbgw/mgw_fsm.c
+++ b/src/osmo-hnbgw/mgw_fsm.c
@@ -683,6 +683,47 @@
        return 0;
 }
 
+static bool is_rab_ass_without_tli(struct hnbgw_context_map *map, 
ranap_message *message)
+{
+       RANAP_RAB_AssignmentRequestIEs_t *ies;
+       RANAP_ProtocolIE_ContainerPair_t *protocol_ie_container_pair;
+       RANAP_ProtocolIE_FieldPair_t *protocol_ie_field_pair;
+       RANAP_RAB_SetupOrModifyItemFirst_t _rab_setup_or_modify_item_first = { 
0 };
+       RANAP_RAB_SetupOrModifyItemFirst_t *rab_setup_or_modify_item_first = 
&_rab_setup_or_modify_item_first;
+       int rc;
+       bool ret;
+
+       ies = &message->msg.raB_AssignmentRequestIEs;
+
+       if (!(ies->presenceMask & 
RAB_ASSIGNMENTREQUESTIES_RANAP_RAB_SETUPORMODIFYLIST_PRESENT))
+               return false;
+
+       /* Detect the end of the list */
+       if (ies->raB_SetupOrModifyList.list.count < 1)
+               return false;
+
+       protocol_ie_container_pair = ies->raB_SetupOrModifyList.list.array[0];
+       protocol_ie_field_pair = protocol_ie_container_pair->list.array[0];
+
+       if (!protocol_ie_field_pair)
+               return false;
+
+       if (protocol_ie_field_pair->id != 
RANAP_ProtocolIE_ID_id_RAB_SetupOrModifyItem) {
+               RANAP_DEBUG
+                   ("Decoding failed, the protocol IE field-pair is not of 
type RANAP RAB setup-or-modify-item!\n");
+               return false;
+       }
+
+       rc = 
ranap_decode_rab_setupormodifyitemfirst(rab_setup_or_modify_item_first,
+                                                    
&protocol_ie_field_pair->firstValue);
+       if (rc < 0)
+               return false;
+
+       ret = rab_setup_or_modify_item_first->transportLayerInformation == NULL;
+       ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_RANAP_RAB_SetupOrModifyItemFirst, 
rab_setup_or_modify_item_first);
+       return ret;
+}
+
 /* Check if the message contains a RAB-ReleaseItem that matches the RAB-ID 
that is managed by the given context map */
 static bool is_our_rab_release(struct hnbgw_context_map *map, ranap_message 
*message)
 {
@@ -721,6 +762,14 @@
                initialized = true;
        }

+       /* After a normal RAB Assignment, another RAB Assigment may follow, 
modifying some RAB parameters. This second
+        * RAB Assignment may omit transportLayerInformation (remains 
unchanged). Simply forward this to RUA, without
+        * the need to adjust anything here. Allow this only when there already 
is an mgw_fsm with proper address. */
+       if (map->mgw_fi && is_rab_ass_without_tli(map, message)) {
+               LOG_MAP(map, DCN, LOGL_INFO, "Rx secondary RAB Assignment 
Request, forwarding as-is\n");
+               return map_rua_dispatch(map, MAP_RUA_EV_TX_DIRECT_TRANSFER, 
ranap_msg);
+       }
+
        /* The RTP stream negotiation usually begins with a 
RAB-AssignmentRequest and ends with an IU-Release, however
         * it may also be that the MSC decides to release the RAB with a 
dedicated RAB-AssignmentRequest that contains
         * a ReleaseList. In this case an FSM will already be present. */
@@ -791,6 +840,13 @@
                return -1;
        }

+       if (map->mgw_fi->state == MGW_ST_ESTABLISHED) {
+               /* This is a response to a second RAB Assignment Request, which 
only modified some RAB config on top of
+                * an earlier RAB Assignment. Just forward the response as-is, 
we already have our MGW set up and need
+                * no info from it. (i.e. we don't support modifying the RTP 
address.) */
+               return map_sccp_dispatch(map, MAP_SCCP_EV_TX_DATA_REQUEST, 
ranap_msg);
+       }
+
        mgw_fsm_priv = map->mgw_fi->priv;

        talloc_steal(mgw_fsm_priv, ranap_msg);

--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/34974?usp=email
To unsubscribe, or for help writing mail filters, visit 
https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-hnbgw
Gerrit-Branch: master
Gerrit-Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
Gerrit-Change-Number: 34974
Gerrit-PatchSet: 1
Gerrit-Owner: neels <[email protected]>
Gerrit-MessageType: newchange

Reply via email to