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 osmocom.orgHi Keith,
On Wed, Dec 04, 2019 at 02:36:43PM +0100, Keith wrote:
> > == DNS zone / .msisdn suffix ===
> >
> > One question I had was regarding the use of the .{msisdn,imsi} TLD. I would argue
> > it is probably besser to use something that fits within the existing DNS hierarchy
> > without contesting IANA's authority on gTLDs.
>
> I'd vote for, if at all possible, not making any link to/dependency on
> DNS hierarchy.
I'm not suggesting a dependency. You can always operate whatever DNS or mDNS on whatever
domain names in a network under your control. I just think it might be smart
to try to avoid using a global namespace that more "authoritive" users might
use for something else in the future, who knows.
The D-GSM mDNS will work irrespective of the public DNS system as we know it.
> > == GSUP keepalives / connection loss detection ==
> >
> > In the presence of unreliable back-haul mesh between villages, the GSUP
> > connection can also not be seen as reliable. We would expect to see TCP
> > stalls due to packet loss, etc.
>
> We don't envisage a separation between MSC and HLR over unreliable
> back-haul, but I think I'm missing something here. (I still need to
> actually implement a local setup and observe)
In an inbound roaming situation, you have the MSC (VPLMN) in one village and the
"authoritative" HLR for that subscriber (HPLMN) in another village.
--
- Harald Welte <laforge at osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)