Feature #3994
closedttcn3: would be nice to be able to template GSUP messages as struct templates, in the same way we do with BSSAP, RSL, DTAP and all other messages
70%
Description
In ttcn3, a GSUP message contains a sequence of IEs.
That makes it hard to wildcard individual IEs, particularly to allow an IE to be both present or not present.
- A wildcard is not specific to the IE kind.
- the position of other IEs is affected.
- it is virtually impossible to build templates by extending other templates for GSUP.
Instead, if GSUP messages were placed in a struct with members (like it happens with e.g. BSSAP messages), it would be far easier to wildcard individual members.
Currently, something like this is needed:
private function f_gen_tr_ss_ies(
template hexstring imsi,
template OCT4 sid := ?,
template GSUP_SessionState state := ?,
template octetstring ss := ?
) return template GSUP_IEs {
/* Mandatory IEs */
var template GSUP_IEs ies := {
tr_GSUP_IE_IMSI(imsi),
tr_GSUP_IE_SessionId(sid),
tr_GSUP_IE_SessionState(state)
};
var integer last_idx := 3;
/* Optional SS payload */
if (istemplatekind(ss, "*")) {
ies[3] := *;
last_idx := last_idx + 1;
} else if (not istemplatekind(ss, "omit")) {
ies[3] := tr_GSUP_IE_SSInfo(ss);
last_idx := last_idx + 1;
}
ies[last_idx] := tr_GSUP_IE_Message_Class(OSMO_GSUP_MESSAGE_CLASS_USSD);
last_idx := last_idx + 1;
return ies;
}
Note that IE indexes in the sequence is involved, also conditionals, and combining several IE types blows up the complexity.
Also, for each individual application, a separate function needs to be written.
Instead, if GSUP were a struct with named members, writing the expectations is trivial, and templates can be easily built upon others, e.g.:
template PDU_GSUP tr_GSUP_SS := tr_GSUP {
.ss_payload = *,
.message_class = *
};
What would be needed is a layer that iterates IEs and places the extracted values in a struct with named members,
instead of a sequence of IE templates.
