Hi Neels, I had a brief look on your draft and have some remarks and thoughts about it (see below). I briefly checked the operations in 29.002 (mainly whether they provide a result or not) and they seem to match your message types. [...] The following questions come to my mind while reading this: * Why should this message router/server be part of the HLR? IMO these are completely separate things. So I'd rather put this functionality into a separate program/process. * What about adding a separate IPA protocol id for routing (proxying might came closer for the case given), that itself just carries other IPA messages of a different type along with source/destination_name and possibly other IEs that just relate to proxying (and possibly the session stuff, unless that went to another layer)? This could then be used with every IPA protocol and won't mess with the application layer. * What about security? Proxying will prevent conventional network monitoring tools and firewalls from working properly. Will it be possible to limit proxying to certain peers e.g. via configuration? BTW, the source and destination name IEs correspond to the global titles in the SCCP layer of SS7. There also exist means to address a destination logically (e.g. send this to the HLR that is responsible for that IMSI, see the E.214 numbering plan). To me this really sounds like re-implementing (parts of) TCAP (ITU T Q.770-779) . TCAP use transaction ids, one for every end of the 'connection' (origin and destination) where each tuple (origin, OTID) or (dest, DTID) identifies the transaction (note that in certain cases a peer can reply with a different origin, e.g. by replacing a E.214 by a E.164 GT). But TCAP is properly separated from the application layer stuff (MAP in that case). [...] While I like the idea to extend GSUP/IPA, I'm wondering whether at some point in the future it was better to just use the standard protocols (e.g. MAP/TCAP/SCCP, possibly on top of IPA, perhaps just MAP on IPA possibly combined with some restrictions concerning segmentation etc) instead of partly reimplementing all of them. At least I'd rather properly separate the session/proxying stuff from GSUP (still being a simplified MAP replacement). Jacob

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 Neels, I finally got a chance to catch up with various pending e-mails and hence this thread. On Mon, Jan 14, 2019 at 03:03:56AM +0100, Neels Hofmeyr wrote: I'm not the expert on Inter-MSC HO, but it looks fine to me, from what I know. the existing gsup router inside OsmoHLR already does half of the job: It checks the list of GSUP connections and can route a message by the IPA identity of the peer. This is what's used for routing between OsmoMSC[s]s and EUSE[s]. The only difference AFAICT in this inter-msc HO scenario is that the destination identity would be read from a GSUP IE. But the actual route lookup would be just like the existing code, using gsup_route_find(), or even better: the osmo_gsup_addr_send() high level function to which you simply pass the IP identity to which you want to transmit to. If that works: Great, problem solved! It makes filtering in wireshark so much easier to have the context in every message, so please keep it. Using one common/shared allocator function inside OsmoMSC shouldn't be a problem. Regards, Harald -- - 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 Oliver, On Tue, Feb 05, 2019 at 10:34:04AM +0100, Oliver Smith wrote: I would argue we should introduce a new "global title" IE which contains * BCD digits * nature of address / type of number * numbering plan indicator This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h This is the most flexible way to encode any MSISDN, IMSI, ... just my thoughts... -- - 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)

On Tue, Feb 05, 2019 at 04:26:54PM +0100, Oliver Smith wrote: I thought I had modeled this after the ASN.1 in 3GPP TS 29.002 for handoverNumber, which says: PrepareHO-Res ::= [3] SEQUENCE { handoverNumber [0] ISDN-AddressString and ISDN-AddressString ::= AddressString (SIZE (1..maxISDN-AddressLength)) -- This type is used to represent ISDN numbers. maxISDN-AddressLength INTEGER ::= 9 But my GSUP spec is certainly not an ISDN-AddressString. Instead, I got this from our live inter-MSC handover trace, where I see in wireshark: handoverNumber: 91940000000032 1... .... = Extension: No Extension .001 .... = Nature of number: International Number (0x1) .... 0001 = Number plan: ISDN/Telephony Numbering (Rec ITU-T E.164) (0x1) E.164 number (MSISDN): 490000000023 Country Code: Germany (49) Now I'm a bit confused about the discrepancy between the spec's ASN.1 and the trace we got (notably, also wireshark's dissector). What we see in the trace seems to match this instead, also 29.002: AddressString ::= OCTET STRING (SIZE (1..maxAddressLength)) -- This type is used to represent a number for addressing -- purposes. It is composed of -- a) one octet for nature of address, and numbering plan indicator. -- b) digits of an address encoded as TBCD-String. -- a) The first octet includes a one bit extension indicator, a -- 3 bits nature of address indicator and a 4 bits numbering -- plan indicator, encoded as follows: -- bit 8: 1 (no extension) -- -- bits 765: nature of address indicator -- 000 unknown -- 001 international number -- 010 national significant number -- 011 network specific number -- 100 subscriber number -- 101 reserved -- 110 abbreviated number -- 111 reserved for extension -- -- bits 4321: numbering plan indicator -- [...] I don't even know what this "1 = Extension: No Extension" is supposed to mean. Above, it simply defines that the bit should always be 1 and mean "no extension". wtf. If it's always 1 anyway, it wouldn't matter if we drop it. Now you know all the facts that I know, I'm currently not certain what would be the best to do. Can you figure it out? ~N