Many thanks for your input! I don't really have strong opinions about any of these design questions. When extending the GSUP protocol I am mainly carrying out other people's ideas... On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote: So far osmo-hlr is the GSUP server. We've already introduced the concept of osmo-hlr as a router-thing concerning USSD services, towards external USSD providers. Adding a router in-between would change the topology, sort of like we added the osmo-stp for the A and Iu interfaces. osmo-hlr would then also be a GSUP client to the router instance, and osmo-msc and osmo-sgsn would have to add routing information to reach the HLR... That's (probably) backwards incompatible, not sure if we want to open that box now. Ok, that sounds like a sane idea. I wonder whether such a concept is already in use somewhere on the IPA protocol? A drawback I see is that we currently have numerous IPA implementations flying around, IIRC in libosmocore, libosmo-netif, libosmo-sccp; and at least two in python... extending the libosmocore one would probably be enough. I don't fully get the proxying idea. What's the purpose, to bridge messages for specific recipients through a NAT sort of thing? This is the first time I'm thinking about more than one HLR in Osmocom. I'm out of my depth here... Except that in TCAP, both sides invent an own ID for a dialogue. I'm planning to have just one ID sent back and forth, which the first Request specifies, and then remains the same from both sides. IIUC the standard stack has quite a lot of duplicated information and is a lot more complex than GSUP/IPA, and that is precisely the idea: implement a simpler protocol with sufficient information to still allow translating into the more complex standard stack, but saving us all the gory details that we would need for the full stack. I did not make this decision, which is probably also made on the grounds of getting something done in a reasonable time frame (this is work for a sysmocom customer). Well, personally, I would enjoy myself more when staying with GSUP for now and keeping things as simple as possible :) (because I would rather concentrate on osmo-msc's handover code) The session_id IE was already added for USSD. Proxying doesn't seem to be a goal at this point. Routing messages between GSUP clients could be changed into routing messages between IPA clients. That would match well in the sense that we already send the MSC's name via IPA during the initial IPA ID exchange. However, keeping routing within GSUP would make operations a bit simpler now, since all our patches modify just one protocol layer, and we have only one GSUP server implementation vs. the various IPA ones. My first and final word on this is that I don't worry/care much about which way we do these things, because I personally don't have a larger scheming plan for IPA and GSUP, so I would like to hear other opinions. Thanks again for your very interesting input! ~N

Hi Jacob, great to read something from you here again. Thanks for your input! On Tue, Jan 15, 2019 at 01:28:42PM +0100, Jacob wrote: The HLR already contains a GSUP message router these days, which is used to route messages e.g. to "EUSE" (External USSD entities). The same is happening also for External SMS entities, as Vadim has enabled GSUP based SMS transport in OsmoMSC recently. So yes, one can argue that the functionality is reasonably distinct and should be yet another program to run. However, as GSUP messages so far don't contain an explicit sender or recipient, OsmoHLR can perform message routing based on the IPA identities of the connected programs. So if a LU comes from one given MSC, the IPA identity of that MSC is stored in the HLR as sort-of replacement of the global title of the MSC. If a MO-USSD arrives at the MSC, we take a routing decision based on the USSD code and route it to an EUSE. The EUSE itself is again identified by its IPA identity as communicated over the related GSUP connection. Once the EUSE responds, we use the IMSI as lookup into the HLR database, and get the IPA identity of the MSC, to which we then route the response. So unless we want to have an explicit "routing header" on the GSUP side, the GSUP router must be inside the HLR. What was clear to me from the beginning is that we don't want OsmoMSC to have multiple GSUP connections and do the routing itself. The latter was proposed by Vadim, IIRC. However, this would make it only more difficult to introduce a central GSUP-to-MAP or GSUP-to-DIAMETER gateway. It's an option, yes. However, we already introduced USSD and SMS over GSUP which add the SESSION_STATE and SESSION_ID, see http://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h#n182 So rather than changing everything again in an incompatible way, I think the safe approach is to add whatever needed to GSUP itself. I'm not sure I'm following you here. YYs. We basically thought that we'd treat the IPA ID as a binary blob, so that the HLR could potentially also simply store a SCCP-encoded GT later on, if ever required. Let's think for example some external SMSC registering itself in the waiting list to be informed once the subscriber is back online, ... Ideally this is not the case. We just need the bare minimum that provides us with a separation of the indivivudal concurrent dialogues. I personally find the OTID/DTID approach of TCAP very difficult to follow, as there's normally only one of the two visible in each packet. Makes debugging hard, makes filtering in wireshark hard, ... By now we're using (connection oriented) SCCP aleready on the AoIP interface between OsmoBSC and OsmoMSC (via OsmoSTP in between). So speaking connectionless SCCP is certainly not a problem in terms of available osmocom infrastructure. TCAP, well, I once started a libosmo-tcap C implementation, which is still far from being complete. So lots of work would be required there. Using "just" the MAP encoding/decoding for the messages is an option, but we'd have to standardize on one specific MAP version for each application context, and we'd have to exclude segmentation as you suggest. Also, technically there's no problem with this as MAP is using ASN.1 BER, which we can speak without any problems from Lev Walkins' asn1c. The problem is that MAP doesn't contain the addresses (GTs) of the SCCP level, nor does it contain the session/dialogue notion of TCAP. So even if we used MAP as the inner messages, we'd still need the "routing" bits that were' talking about above. So switching to restricted-MAP-over-GSUP doesn't reduce the problem domain of SCCP+TCAP, responsible for routing and session/dialogue. The fundamental struggle that we have is the compromise between 1) staying if possible as close as possible to the 3GPP architecture, and 2) avoiding most of the complexities that go along with this. GSM is complex enough to set up, even without having to worry about SCCP etc. - Most of our users are not a public operator, and they have no SS7, no global titles, no point codes, etc. We tried hard with the AoIP interface, where we introduced lots of "magic" such as dynamic routing key registratio in OsmoSTP, etc. to ensure people can run OsmoBSC and OsmoMSC without having to know and configure all those bits - while at the same time allowing those with the skills (and requirements to talk to other MSCs) to do so. I don't think we did a perfect job on the A interface side, and I worry about introducing yet another of those interfaces. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Harald, On 2/5/19 11:13 AM, Harald Welte wrote: this sounds good to me. But I'm also curious about Neels' opinion about the matter, since he had drafted all these new messages. Where would the "extension" bit go, if we use the "global title" IE? Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

On 2/6/19 12:52 AM, Neels Hofmeyr wrote: After looking into the Wireshark dissector code, I came to the conclusion that the ISDN-AddressString is exactly what you are seeing in the dump. Furthermore, it is the same as the MSISDN. Then I've looked up the existing MSISDN IE in the GSUP spec [1]: (It also has a graph that looks like what you see in Wireshark.) So my conclusion is, that we can just drop the handover_number IE and use the existing msisdn_enc IE instead. Regards, Oliver [1]: https://git.osmocom.org/osmo-gsm-manuals/tree/common/chapters/gsup.adoc?id=… -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte