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 }; 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. Ok, seems I got this wrong then. ENTITY_MSC_SMS <---[osmo-hlr]---> ENTITY_SMSC yes? 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_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. ack. so: ENTITY_MSC_USSD <---[osmo-hlr]---> ENTITY_EUSE 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

That's no problem. The MSC-A never changes and always remains in charge, the only difference is that before the DTAP messaging reaches the BSC and MS, it first gets "tunneled" via GSUP and the remote MSC, which merely acts as a proxy for the remote BSC. So it is identical to an intra- or an inter-BSC handover happening in the middle of a USSD session: the DTAP remains transparent between the unchanged MSC-A and the MS, the MS has merely hopped onto a different route for DTAP. Interesting to note / thanks for pointing out that a USSD request should still be directed at the vlr first. This complicates my idea of "Entity" a bit. To cut a long story short, I wrote a bunch of responses while completely re-thinking my idea while I wrote. The result of this is a long mail and this conclusion: I will add only a GSUP message kind IEI, which indicates the GSUP subsystem and allows demuxing GSUP messages without switch(msg_type)ing, and I will *not* name the source/destination entity at all. enum osmo_gsup_kind { OSMO_GSUP_KIND_SUBSCRIBER_MANAGEMENT, /* VLR <-> HLR, D-interface for accessing HLR/HSS data */ OSMO_GSUP_KIND_SMS, /* MSC <-> SMSC */ OSMO_GSUP_KIND_USSD, /* MSC <-> { VLR <-> HLR } <-> EUSE */ OSMO_GSUP_KIND_INTER_MSC /* MSC-A <--> MSC-{T,I}, E-interface for inter-MSC Handover */ }; With this, I can still figure out whether responses like a GSUP routing error are related to inter-MSC or not, while GSUP->MAP->GSUP conversion remains "trivial", and USSD routing remains implicit without naming each hop. That is the conclusion I reach below, and you don't really need to read the rest of this mail, unless anyone wants to follow my reasoning of how I ended up at that conclusion... Thanks for your valuable input, Vadim! ~N ~ + ~ + ~ (long reasoning for above choice follows...) On Sat, Mar 30, 2019 at 08:20:49PM +0700, Vadim Yanitskiy wrote: [..] I agree. Only, this would not end up being an OSMO_GSUP_ENTITY_VLR, because we're not sending a GSUP message to the VLR. Once it goes out past the VLR we get: I would then actually also introduce OSMO_GSUP_ENTITY_HLR_USSD. My idea there still is to separate the kinds of message to avoid demuxing by message type. But .. see below > > OSMO_GSUP_ENTITY_MSC_USSD <- OSMO_GSUP_ENTITY_HLR Ok, so, on the return path, we don't do all the hops MSC_USSD<-VLR<-HLR<-EUSE anymore, but the response in all cases goes directly to MSC_USSD, right? Makes sense. But. Maybe my idea of combining the message kind and the source/target entity is a bit clumsy. Now I am thinking it would make more sense to indicate the subsystem separately from the source and target entities: enum osmo_gsup_kind { OSMO_GSUP_KIND_SUBSCRIBER_MANAGEMENT, /* VLR <-> HLR, D-interface for accessing HLR/HSS data */ OSMO_GSUP_KIND_SMS, /* MSC <-> SMSC */ OSMO_GSUP_KIND_USSD, /* MSC <-> { VLR <-> HLR } <-> EUSE */ OSMO_GSUP_KIND_INTER_MSC /* MSC-A <--> MSC-{T,I}, E-interface for inter-MSC Handover */ }; enum osmo_gsup_entity { OSMO_GSUP_ENTITY_HLR, OSMO_GSUP_ENTITY_VLR, OSMO_GSUP_ENTITY_MSC_A, OSMO_GSUP_ENTITY_MSC_I, OSMO_GSUP_ENTITY_MSC_T, OSMO_GSUP_ENTITY_SMSC, OSMO_GSUP_ENTITY_EUSE, }; Next, I am reconsidering whether we really need the source and destination entity for any messages other than the E-interface at all. On the E-interface I want to explicitly distinguish between MSC-I and MSC-T. However, it is also a bit questionable how a MAP-to-GSUP converter would figure that out. Has to switch(message_type)... so maybe it's a bad idea to force this decision into a compatibility conversion. For all kinds other than E-interface it would be implicitly clear what the source/target entities are. The benefit of simpler demuxing into VLR/SMS/USSD code paths comes from the message kind, the entity kind adds no value. So I am considering three proposals: a) add an OSMO_GSUP_KIND_IEI with only the message kind (subscriber-management, SMS, USSD, E). Include the _KIND_IEI in all messages. b) Add a), and also add a separate OSMO_GSUP_ENTITY_IEI for source and dest entity (MSC-A, VLR, HLR, ...). Include the _KIND_IEI in all messages, but include the _ENTITY_IEI only for E-interface messages. c) add one OSMO_GSUP_ROUTING_IEI with all of kind, source and destination entity in a single information element. My first intuition was to go with c), but we would probably ignore the entity information for all but the inter-MSC messages. The second intuition is b), but when I consider that the entity info would be lost in a GSUP -> MAP -> GSUP conversion, I end up realizing that I should rather figure out MSC-T or MSC-I from the inter-MSC message kind and MSC state. So now I end up at a) -- only add a GSUP message kind IEI, which indicates the GSUP subsystem and allows demuxing GSUP messages without switch(msg_type)ing. Then we also don't need to figure out the next hop as in HLR or EUSE.