28 Mar
2019
28 Mar
'19
5:14 p.m.
Thanks for your input!
Currently, my patch looks like this:
enum osmo_gsup_entity {
OSMO_GSUP_ENTITY_NONE = 0,
OSMO_GSUP_ENTITY_HLR = 1,
OSMO_GSUP_ENTITY_VLR = 2,
OSMO_GSUP_ENTITY_ESME = 3, (see below)
OSMO_GSUP_ENTITY_SMSC = 4,
OSMO_GSUP_ENTITY_MSC_SMS = 5,
OSMO_GSUP_ENTITY_EUSE = 6,
OSMO_GSUP_ENTITY_MSC_USSD = 7,
OSMO_GSUP_ENTITY_MSC_A = 8,
OSMO_GSUP_ENTITY_MSC_I = 9,
OSMO_GSUP_ENTITY_MSC_T = 10,
OSMO_GSUP_ENTITY_MAXVAL = OSMO_GSUP_ENTITY_MSC_T
};
MSC_B didn't make it. Instead I require more distinct MSC-A, MSC-I and MSC-T.
But these will only be used for actual inter-MSC messages. i.e., a USSD
response doesn't go to the MSC-A entity, since that would be the inter-MSC
forwarding subsystem. Rather, it would go to MSC_USSD. That again would figure
out which subscriber is involved and then possibly forward to a remote
ENTITY_MSC_I.
ENTITY_MSC_SMS <---[osmo-hlr]---> ENTITY_SMSC
I will adjust to drop ESME and fix the ENTITY_SMSC being on the wrong side.
Otherwise IMHO it should stay as I have it. Would you agree, or am I still
getting something wrong?
~N
I don't think we need to overload the entity types
with service types
I think we do.
We have various message types that are distinct to individual handlers -- SMS
go to gsm_04_11_gsup.c, USSD to gsm_09_11.c. This is not osmo-msc specific, if
any other MSC would implement these GSUP messages, the individual SMS, USSD,
... parts would always be handled in distinct code paths. So, we need to
demux when receiving GSUP from the HLR.
So far we demux by message type alone. But that means we *must* have distinct
message types for each subsystem. Even for identical semantics (like routing
error responses) we would need distinct msg_type, or other heuristics.
When I am adding this "entity" IE, I want to rather go all the way and make
demuxing in osmo-msc trivial:
static enum osmo_gsup_entity gsup_client_mux_classify(struct gsup_client_mux *gcm,
const struct osmo_gsup_message
*gsup_msg)
{
if (gsup_msg->destination_entity)
return gsup_msg->destination_entity; /* <-- this is the
"trivial" bit */
LOGP(DLGSUP, LOGL_ERROR, "No destination entity, trying to guess from message
type %s\n",
osmo_gsup_message_type_name(gsup_msg->message_type));
switch (gsup_msg->message_type) {
case OSMO_GSUP_MSGT_PROC_SS_REQUEST:
case OSMO_GSUP_MSGT_PROC_SS_RESULT:
case OSMO_GSUP_MSGT_PROC_SS_ERROR:
return OSMO_GSUP_ENTITY_MSC_USSD;
/* GSM 04.11 code implementing MO SMS */
case OSMO_GSUP_MSGT_MO_FORWARD_SM_ERROR:
case OSMO_GSUP_MSGT_MO_FORWARD_SM_RESULT:
case OSMO_GSUP_MSGT_READY_FOR_SM_ERROR:
case OSMO_GSUP_MSGT_READY_FOR_SM_RESULT:
case OSMO_GSUP_MSGT_MT_FORWARD_SM_REQUEST:
return OSMO_GSUP_ENTITY_SMSC;
default:
return OSMO_GSUP_ENTITY_VLR;
}
}
int gsup_client_mux_rx(struct osmo_gsup_client *gsup_client, struct msgb *msg)
{
[...]
entity = gsup_client_mux_classify(gcm, &gsup);
[...]
rc = gcm->rx_cb[entity].func(gcm, gcm->rx_cb[entity].data, &gsup);
which feeds directly into gsm411_gsup_rx(), gsm0911_gsup_rx(), ...
no further interpretation needed
}
If you instead keep the USSD and SMS subsystems in the same "entity", then we
still need to demux between those based on message type.
AFAIR, ESME is something specific to SMPP only.
Ok, seems I got this wrong then.
ENTITY_MSC_SMS <---[osmo-hlr]---> ENTITY_SMSC
yes?
Are there similar terms for USSD? Which is the
entity managing
USSD dialogs? which is the entity sending the USSD messages?
Here we have the following picture:
|- <-GSUP-> EUSE (foo)
MS / UE <-> RAN <-> MSC <-GSUP-> HLR <-GSUP-> EUSE (bar)
|- <-GSUP-> EUSE (zoo)
EUSE stands for External Unstructured supplementary Services Entity.
One can configure prefix-based routing in OsmoHLR, so USSD requests
coming from MS / UE can be routed to one of the connected EUSEs.
The following entity types from proposed enum are involved here:
- OSMO_GSUP_ENTITY_MSC_B, - OSMO_GSUP_ENTITY_HLR,
ENTITY_HLR should only ever appear if we actually interact with the HLR
database. When osmo-hlr merely does the GSUP routing, no ENTITY_HLR appears in
the messages. Only ultimate source and destination entities are named.
This also means we could at some point trivially separate GSUP routing from
the osmo-hlr process if we wanted.
- OSMO_GSUP_ENTITY_EUSE.
ack.
so:
ENTITY_MSC_USSD <---[osmo-hlr]---> ENTITY_EUSE
Thinking, in
fact if our osmo-msc wasn't siamese twins with
the SMSC we would have ESME <-> SMSC <-> MSC.
As Harald noted, at some point we would need to rip out the
internal SMSC functionality from OsmoMSC. At the moment, it
can be disabled from the VTY using 'sms-over-gsup' parameter.
From what I remember, a simplified SMS delivery in our MAP-less
stack (since we use GSUP and HLR as the router) should look
this way:
MS / UE (Alice) -> RAN -> MSC |-GSUP-> HLR |-GSUP-> OsmoSMSC
|
MS / UE (Sarah) <- RAN <- MSC <-GSUP-| HLR <-GSUP-| OsmoSMSC