FreeCalypso > hg > themwi-system-sw
changeset 273:80a248def208
doc/Fake-NANP-numbers: article written
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 27 Nov 2023 21:45:05 -0800 |
parents | c78b8d6ce885 |
children | de440a88c23a |
files | doc/Fake-NANP-numbers |
diffstat | 1 files changed, 123 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/Fake-NANP-numbers Mon Nov 27 21:45:05 2023 -0800 @@ -0,0 +1,123 @@ +Running ThemWi system sw with fake NANP numbers +=============================================== + +As outlined in Use-outside-USA article, there is a possibility that some people +may potentially be interested in running our software outside of USA - yet +without any intention of connecting to their own country's public telephone +network. Given that ThemWi system sw was written for the primary purpose of +making our Osmocom-based GSM network function as a full-fledged member of USA +PSTN and USA SMS network, with full interconnection, it is not clear to this +Mother why someone would be interested in our sw without such interconnection +as their primary goal. Porting our sw from USA PSTN to national telephone +networks of other countries would certainly be a laudable goal, but operation +without any national PSTN interconnection at all, not so much - what is the +point then? + +It is possible, however, that some people may be interested in auxiliary debug +or test functions of ThemWi, such as single-leg GSM test calls (MT with +themwi-test-mtc, MO with test sink numbers) - or perhaps they may be interested +in our implementation of GSUP-based SMSC. It is also possible that some people +may wish to operate toy networks, without money-costing and politically- +complicated interconnection with their national PSTN, but may still be +interested in hobby-level peering interconnection with other hobbyist or +community networks. + +To address such strange-seeming use cases, ThemWi system sw supports the option +of operating with fake NANP numbers instead of real ones. Real NANP numbers are +those which one gets (rents for a small amount of money) from a PSTN-via-SIP +connectivity provider such as BulkVS - but those companies typically require +the customer to have physical and/or legal presence in USA or Canada, in order +to connect to USA or Canadian PSTN, even if that connection is made over public +Internet. Every real NANP number geolocates to some real location in USA, +Canada or one of the many smaller NANP countries. Fake NANP numbers, OTOH, are +completely made up, and do not correspond to any real location anywhere in North +America - but they superficially mimic the structure of North American Numbering +Plan, allowing software written for NANP to be used without major changes. + +NANP rules require every telephone number (TN) to take the form of NXX-NXX-XXXX, +where N is any digit in [2-9] set and X is any digit in [0-9] set. The first +NXX group is also called NPA or simply "area code" (NPA stands for Numbering +Plan Area), and the second NXX group is called the exchange; the first 6 digits +taken together, typically written as NPA-NXX, are also called the prefix. +Furthermore, neither of the two NXX groups (neither NPA nor exchange) is allowed +to be N11 - these codes are reserved for emergency and other special numbers. + +ThemWi system sw requires all presenting-as-NANP numbers to follow the rules +listed above, including fake NANP numbers - but the diff that sets fake NANP +numbers apart is the middle digit of NPA code. Per official NANP rules, this +middle digit can never equal 9 - thus NPA codes of form N9X (290-299, 390-399, +..., 990-999) specifically signify fake NANP numbers. + +Fake NANP numbers beginning with N9X are allowed in all contexts where real NANP +numbers are ordinarily expected. There is only one place in the current code +base where they are treated specially, and that one place is the routing code +in themwi-sip-out. As currently implemented, themwi-sip-out will route a call +addressed to a number beginning with +1N9X only if there is an explicit route +defined for that specific 1N9X prefix, i.e., a route with a prefix length of 4 +or more digits. If there is no such explicit route, and the only match is +either the main +1 route (for all of regular NANP) or the global E.164 default +route, the call is rejected with GSM48_CC_CAUSE_NO_ROUTE - the idea is that we +should never send calls to such fake NANP numbers to real PSTN-via-SIP +connectivity providers. + +Configuring your number database with fake NANP +=============================================== + +No matter what kind of numbers you end up using, you have to create a database +of locally owned numbers - this local number database is always a required item +for ThemWi system sw to work, as explained in more detail in Number-database +article. If you are going to operate with fake NANP numbers, the recommended +way to populate your number database is as follows: + +prefix N9X-NXX allow-abbrev + +suffix XXXX gsm-sub +suffix XXXX gsm-sub +... + +For N9X-NXX part in the prefix line, pick some prefix that follows these +numerical rules (80 possibilities for N9X and 800 possibilities for NXX, for a +total of 64000 possible fake-NANP prefixes), and each XXXX in a suffix line is +a 4-digit extension number you are defining for use by your local GSM +subscribers. You will then need to enter each MSISDN into OsmoHLR as 11-digit +1N9XNXXXXXX, just as if it were a real, globally-routable E.164 number in the +North American Numbering Plan - but having 'allow-abbrev' modifier included on +the prefix line will allow you to dial 4-digit extensions instead of full +fake-NANP numbers for internal calls. + +The other alternative of using ITNs (see Local-short-numbers article) is also +possible, but not recommended: themwi-sip-in and themwi-sip-out require NANP or +NANP-looking numbers, not ITNs, hence a network instance that uses only ITNs +will have no ability to gateway to any other networks, not even hobbyist +non-PSTN kind. + +Interconnection among hobbyist or community networks +==================================================== + +The real Themyscira Wireless network, operating with real NANP numbers in the +region of San Diego county, California, USA, is open to making peering-type +interconnections with other hobbyist or community networks, including those +hobbyist/community networks whose operators choose to not connect to any PSTN +themselves and operate with fake E.164 numbers instead. If you do operate with +fake E.164 numbers instead of real ones (real E.164 numbers are those that were +legitimately issued to you by your country's telephone numbering plan authority +or its subdelegates; any others are fake), the requisite condition for peering +interconnection with real ThemWi is that your fake E.164 numbers are guaranteed +to never conflict with any real ones. This condition is absolute with no +exceptions - as a real mobile telephone network participating in global, fully +interconnected worldwide PSTN, Themyscira Wireless MUST route every real E.164 +number to its rightful national or international destination, no exceptions +allowed. + +Fake NANP numbers as described in this article satisfy the requirement of not +conflicting with any possible real E.164 numbers, hence if you set up your own +instance of ThemWi system sw using such fake NANP numbers, you will be eligible +for peering interconnection with Themyscira Wireless, the real ThemWi. If you +wish to be able to receive calls from us, you will need to run themwi-sip-in on +a server with some public-facing static IP address (and be willing to accept SIP +calls from anywhere in the world, addressing your selected range of fake-NANP +numbers), and we will create a routing entry in our themwi-sip-out config, +routing your +1N9X prefix to your server. In the other direction, if you wish +to send calls to us, simply send them to sip.sandiego2g.org - as long as the +called E.164 number is one of ours, we accept calls from anywhere on the public +Internet, not just from our official USA PSTN connectivity provider.