GSUP: rename E_ROUTING_ERROR to ROUTING_ERROR
GSUP routing was introduced when adding the E interface. Hence that was the
first realm where routing errors could occur. I did notice back then that this
message type was special: it does not convey a response to a particular message
kind -- it does not make sense, for example, to return an Updating Location
Error cause, and do that for all conceivable message types. Instead, this tells
the sender that a deeper error exists, i.e. that the desired peer is completely
gone and unreachable.
I did not foresee though that for D-GSM, there would also be arbitrary GSUP
proxy routing, and that this error is not limited to E interface semantics.
From today's point of view, adding the "_E_" in the name was a mistake.
Remove that "_E_" to yield OSMO_GSUP_MSGT_ROUTING_ERROR (with unchanged message
type discriminator), but provide a #define linking the old name
OSMO_GSUP_MSGT_E_ROUTING_ERROR to the new one.
The only visible change should be that osmo_gsup_message_type_names[] now
returns the new name without "_E_". I am not aware of any regression test
fallout from that.
Change-Id: Ic8e8bd11522d6c51ac7aaf946516cbce26bc6e1e
diff --git a/include/osmocom/gsm/gsup.h b/include/osmocom/gsm/gsup.h
index 49ddb74..c883dfb 100644
--- a/include/osmocom/gsm/gsup.h
+++ b/include/osmocom/gsm/gsup.h
@@ -196,9 +196,11 @@
OSMO_GSUP_MSGT_E_CLOSE = 0b01000111,
OSMO_GSUP_MSGT_E_ABORT = 0b01001011,
- OSMO_GSUP_MSGT_E_ROUTING_ERROR = 0b01001110,
+ OSMO_GSUP_MSGT_ROUTING_ERROR = 0b01001110,
};
+#define OSMO_GSUP_MSGT_E_ROUTING_ERROR OSMO_GSUP_MSGT_ROUTING_ERROR
+
#define OSMO_GSUP_IS_MSGT_REQUEST(msgt) (((msgt) & 0b00000011) == 0b00)
#define OSMO_GSUP_IS_MSGT_ERROR(msgt) (((msgt) & 0b00000011) == 0b01)
#define OSMO_GSUP_TO_MSGT_ERROR(msgt) (((msgt) & 0b11111100) | 0b01)