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/.
Harald Welte laforge at gnumonks.orgHi 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 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. 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. > * 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. 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. > * 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? I'm not sure I'm following you here. > 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). 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, ... > > - The session_id/session_state: we still need to figure out how to avoid > > collisions in session_id numbers, as any peer may at any point re-use the > > same session_id. Vadim suggested using a TI flag that gets flipped between > > sender and receiver, but since there are more than two peers, I guess we > > should treat each session_id as subordinate to a Request's source_name. IOW, > > any peer owns the entire session_id number space itself for sending out > > Request message types, and a Response or Error message type echos this > > session_id back with the source_name then having become the destination_name; > > it is perfectly legal for two peers to use the same session_id and collisions > > are avoided by Request vs. Response/Error. Something like... > > To me this really sounds like re-implementing (parts of) TCAP (ITU T > Q.770-779) . 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, ... > 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). 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 at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)