This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comNi Neels, Sorry for late reply, I am experiencing a big lack of free time :/ > I would much rather have an explicit destination entity advertised in the GSUP > messages, and an explicit common GSUP MUX stage. In other words, the VLR of > osmo-msc shouldn't act as a GSUP forwarder, it should merely be one of the GSUP > consumers, and shouldn't even be involved when the messages are intended for > inter-MSC, for USSD or for SMS use. ACK. I like the idea of having source / destination IEs for routing purposes. I was also thinking about having separate GSUP-connections for both MSC and VLR, but since VLR is a part of MSC, I don't see any benefits from this approach. > Still would like to get input on naming: > For SMS, we have the SMSC and ESME entities. Correct, but AFAIR, ESME is something specific to SMPP only. In case of GSUP (and MAP) we always deal with SMSC. Therefore, I think we don't need OSMO_GSUP_ENTITY_ESME entity at all. > 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, - OSMO_GSUP_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 So we have the following entity types involved here: - OSMO_GSUP_ENTITY_MSC_B, - OSMO_GSUP_ENTITY_HLR, - OSMO_GSUP_ENTITY_SMSC. For more details, please see: https://git.osmocom.org/osmo-gsm-manuals/tree/common/chapters/gsup_mo_sms.msc https://git.osmocom.org/osmo-gsm-manuals/tree/common/chapters/gsup_mt_sms.msc > MSC-SMS / MSC-USSD I don't think we need to overload the entity types with service types they provide. In other words, instead of MSC-SMS / MSC-USSD we can use single OSMO_GSUP_ENTITY_MSC_B. With best regards, Vadim Yanitskiy.