D-GSM merge / open question on GT vs. IPA name

Hi Neels, some week[s] ago, you mentioned that the D-GSM merge is blocked around the question on how the Global Title vs. IPA-name is to be resolved. Sorry for not getting back any sooner, but I am simply not finding the required amount of time to investigate this topic at the moment. My personal opinion is that it should be a binary blob (buffer + length) and nobody should make any assumptions about the contents. This way we can store whatever we want in it, and I believe we're increasing possible use cases where our HLR would have to work with "stateless" translators between GSUP and MAP. After all, let's say we receive a LU from a subscriber roaming in MAP-land, then that request arrives with the GT of the MSC/VLR. If we can natively "digest" such values, then the translator would not require any state beyond the currently processed transaction (LU/ISD). If we can not, then the translator would have to keep long-term state such as tables to map MAP-GT to IPA name or the like. And that's of course more effort there, and volatile state that you'd need to synchronize in case of high availability or fail-over scenarios, etc. I of course also know none of this is any current use case that any of the sysmocom customers is funding sysmocom (and hence you) to spend time on. So in the end, I'll leave it to you to decide. If you think the effort for becoming "buffer+length" aware is relatively minimal (let's say up to two days?) then by all means, implement that. If you think it's more work, then please go for the faster route of not considering non-NUL-terminated strings as identifiers for "GSUP" peers. In any case, I am happy to merge the D-GSM patch series once you think it should be merged. I put it in your trusted hands. After all, we had a tagged release only 7 commits ago (well, 5 of those are actually already D-GSM related) in osmo-hlr, and should there be any fall-out from the merge, we still have quite some time until some new tagged release will happen a few months down the road. Thanks! 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)