From 242693d960b3cb7f1c07dd6066dc65a97e192fe4 Mon Sep 17 00:00:00 2001 From: penmetsaa Date: Fri, 12 Nov 2021 12:11:45 +0530 Subject: [PATCH] Update FAQ as per changes made to MX dialling patterns and metadata. (#2693) This is inspired from b/205606725 and older b/111967450 where MX stopped supporting all additional dialling codes. --- FAQ.md | 57 +++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/FAQ.md b/FAQ.md index 1914d0f72..ff2e849b5 100644 --- a/FAQ.md +++ b/FAQ.md @@ -312,24 +312,26 @@ We'd love to consume machine-readable numbering plan data (assigned ranges, carrier & geo mappings). If you can connect us with partners in the industry to achieve this, please do so. Thanks! -### Why is this number from Argentina (AR) or Mexico (MX) not identified as the right number type? - -Certain countries' mobile and/or fixed line ranges may overlap, which may make -accurate identification impossible without additional and explicit context such -as a mobile prefix. We rely on this prefix being present to correctly identify -the phone number type (rather than returning -[`FIXED_LINE_OR_MOBILE`](#fixed_line_or_mobile) in ambiguous cases) until our -metadata can be fine-grained enough to detect when a user has omitted it. - -For example, when calling a mobile line from a fixed line in Argentina, you need +### Why is number from Argentina (AR) or Mexico (MX) not identified as the right number type? + +Certain countries' mobile and/or fixed line ranges may overlap or too granular, +which may make accurate identification impossible. Eg: Argentina and Mexico. +We tried incorporating such granular data (prefix of 7 digit for a 10 digit +number). However, due to very high maintainance to keep the data fresh and +also leading to significant increase in metadata size, we are supporting +ranges/prefixes only at higher level. More details in [Argentina](https://issuetracker.google.com/issues/78443410) and +[Mexico](https://issuetracker.google.com/issues/74517266) triaged issues. + +@Argentina, +When calling a mobile line from a fixed line in Argentina, you need to dial 15 before the subscriber number, or 9 if you're calling from another country. Without these additional digits, your call may not connect at all! -Similarly, Mexico has different mobile prefixes needed when calling from a fixed -line such as 044 when calling locally, 045 when calling from another state, and -1 when dialing from another country. +We rely on these additional and explicit context such as a mobile prefix to +correctly identify the phone number type (rather than returning [`FIXED_LINE_OR_MOBILE`](#fixed_line_or_mobile) +in ambiguous cases). -Moreover, these countries have different possible lengths for area codes and +Moreover, Argentina has different possible lengths for area codes and subscriber numbers depending on the city, which further complicate matters (e.g. Buenos Aires is 11 followed by eight digits, but Río Gallegos is 2966 followed by six digits). @@ -342,25 +344,40 @@ prefix, the user may not supply the mobile prefix. We are aware of these issues but fixing them is not trivial. In the meantime, we recommend the following workarounds to support affected users. -* If you know an Argentina or Mexico number is mobile (e.g. if you're doing - signups with device numbers or will send them an SMS verification code), - follow these steps: +* If you know an Argentina number is mobile (e.g. if you're doing signups with + device numbers or will send them an SMS verification code), follow these steps: * For raw input strings: * Parse a raw input string into a `PhoneNumber` and follow the next instructions for `PhoneNumber` objects. * For `PhoneNumber` objects: * Check that the library validates a `PhoneNumber` as mobile, by calling `getNumberType`; - * If not, format it in national format and prepend a `9` for Argentina - or a `1` for Mexico; + * If not, format it in national format and prepend a `9` * Parse the modified string and if the library validates it as mobile, accept the resulting `PhoneNumber` as canonical. * Consider prompting for type (mobile or not) in the phone number input UI. -IMPORTANT: Do not add a leading 1 or 9 for displaying or formatting the numbers. +IMPORTANT: Do not add a leading 9 for displaying or formatting the numbers. Depending on the use case, other tokens may be needed. The library will do the right thing if the phone number object is as intended. +@Mexico, +Mexico used to have such additional prefixes (1, 02, 045, ...) for dialling +mobile numbers internatioanlly, fixed-line to mobile nationally.. As these +dialling patterns were deprecated, we have continued to maintain mobile and +fixed-line ranges at higher level, returning type as [`FIXED_LINE_OR_MOBILE`](#fixed_line_or_mobile) + +### Why Mexico (MX) numbers in older dialling formats are accepted as valid ones? +Though library has stopped supporting below older dialling codes in the canonical +form and formatting results, we are lenient in parsing the number, i.e removing +all older codes. +- 1 -> in E.164 international diallings +- 01, 02, 044 and 045 -> for local/national diallings + +This is because we found the older dialling codes supported even after deprecation +period, so we decided to support them for longer time. However, we will stop this as +part of [this issue](https://issuetracker.google.com/issues/205606725). More details there. + ### Why are Bouvet Island (BV), Pitcairn Island (PN), Antarctica (AQ) etc. not supported? We only support a country if: