Signal-android: Signal automatically adds country to Service numbers

[karambir]

I have:

• [x] searched open and closed issues for duplicates
• [x] read https://github.com/WhisperSystems/Signal-Android/wiki/Submitting-useful-bug-reports

---

Bug description

In India(maybe also in other countries), there are some special numbers used for service providers to provide their services in an automated fashion(to distinguish themselves from users). Services like Banks, Credit Card companies etc use these to communicate with users. A typical number can be 56767 (ICICI bank) or 57575.

These numbers don't need country code in front of them. But signal app on android adds the code(+91 in my case) and the SMS is not sent. All other SMS apps work(including default AOSP and Google's) as expected.

Steps to reproduce

• Open Signal app
• Start a new chat to send message(SMS) to any service provider.
• Send any msg.

Actual result: Display _not sent_ error with country code added automatically. Retry will show same error.
Expected result: Country should not be added in these cases. Or at least when I am retrying, let me explicitly specify the full number(without +91)

Device info

Device: OnePlus ONE E1003 (onyx)
Android version: 6.0.1 (da37a46293, onyx-userdebug 6.0.1 MOB31K da37a46293 test-keys)
Signal version: 3.21.3

Link to debug log

https://gist.github.com/anonymous/d8c9637e04d99305de199956c5b11cdb

[FeuRenard]

This seems similar to #5456.

[karambir]

Tried searching for any current issue but didn't get keywords right :)

I am curious about what is the thought behind these types of bugs. Is this going to be fixed on a per operator/country basis like #4853? Or we have to just use other SMS apps for now?

[2-4601]

4853 seems like a clear duplicate. #5456 is probably due to the same reason and the following two comments are explicitly about service number issues like this. Then there's #5306 and #5078 that are about incoming SMS that have wrong country code added to them. Is the underlying cause the same in those or are those just related? I have no idea.

At least #4853 has a solution for the service numbers of two countries. So far people have reported this service number issue at least in Norway, Slovenia, Malaysia, Austria and Portugal.

[karambir]

So that is my question. Do I report a service number each time? Because in India there are too many

[2-4601]

Do I report a service number each time? Because in India there are too many

The fix is not service number specific. It's country and service number length specific.

[dcherian]

AFAIK, all Indian cellphone numbers are ten digits long, anything lesser than that is a landline which cannot handle SMS obv. So maybe that's a solution... only add +91 if number length == 10

[karambir]

@2-4601 India calls these numbers as Short codes. Various businesses have short codes of length 5,6 or 7(provided by telecom companies). But several govt organizations and services have short codes of length 3,4,5 or 6 digits( list of govt short codes http://www.dot.gov.in/access-services/allotment-short-codes, skip first table ). These short codes accepts SMS.

The fix is not service number specific. It's country and service number length specific.

I don't think just on the basis of length, it can be fixed.

[xprzemekw]

Same in Poland. Those are called short codes (https://en.wikipedia.org/wiki/Short_code), for example certain operator services relies on sending/receiving messages to/from short code numbers. When such message is received Signal prepends +CC (where CC is country code) to the number. Also sending SMS messages to such numbers fails. Even if I enter them correctly using keyboard, Signal inserts +CC and I can't force it to send message to the exact number I typed.

[tsdmgz]

I'll add for Philippines. I've seen five digit short codes in use.

Specific to Globe Telecom, there is a variant of using 14 digit numbers requiring subs to reply to confirm a transfer of credits to another sub. It follows the pattern of 2652{10,10}\d.

[ghost]

I am not able to send a SMS to 19872 in Poland.
Signal automatically changes the number to +4819872 which result in failure to send SMS.
The number has to be 19872 without country code.
Please fix this.

[karambir]

I don't think Signal can be used as default SMS app if your country has concept of short codes. Signal should just be used like just another chat app.

[ghost]

This is just ridiculous. Every other SMS app can handle these numbers but Signal can't, and you don't see a problem with it...
And the solution is really simple. Allow a user to decide whether they want a CC added or not.

[tsdmgz]

Read before but is this an issue that should go to https://github.com/googlei18n/libphonenumber instead?

[moxie0]

@tsdmgz Yes, that's the best way. When these things are fixed in libphonenumber they'll be fixed in Signal.

[ghost]

@tsdmgz
Ok, I can see that this is an issue with some library. So why not add an option to skip this step completely?
You know, like trust the user the know what they are doing and not automagically parse the number to be something else (in this case a wrong number). And send the message to the exact number the user typed.
I hate when an application is "smarter" than me and knows "better" than me what I want to do.
I want to send a message to XXXXX. Just send this message to XXXXX, as you were told, you stupid app. 😉

Image you wanted to send a message to donald.[email protected] and the email application would be "smarter" thay you and tried to send it to donald.[email protected] instead and you would not have an option to force sending to the exact email you typed. Really frustrating.

[ghost]

public class Test {
    public static void main(String[] args) throws NumberParseException {
        PhoneNumberUtil util = PhoneNumberUtil.getInstance();
        String number = "19872";
        String countryCode = "PL";
        Phonenumber.PhoneNumber phoneNumber = util.parse(number, countryCode);
        boolean shortNumber = ShortNumberInfo.getInstance().isPossibleShortNumberForRegion(phoneNumber, countryCode);
        System.out.println(shortNumber);
    }
}

This prints true. So how this is an issue with libphonenumber?

Also, I tried ShortCodeUtil.isShortCode with the number. Also got true.
So what am I testing incorrectly?

I am asking, because I wanted to post an issue on libphonenumber but I need to be able to reprodce it.

[moxie0]

I hate when an application is "smarter" than me and knows "better" than me what I want to do. I want to send a message to XXXXX. Just send this message to XXXXX, as you were told, you stupid app.

I understand that you're frustrated and that Signal isn't working the way you want it to. However, it's really not helpful for you to approach this problem with the assumption that we're idiots. From what I can tell, you have not been involved here in any way prior to this moment; showing up with the attitude of "what is wrong with you people" does not engender me to want to help.

In this case, I don't believe it's possible to simply "trust the user." There are many many different ways that a user could choose to format a phone number in different regions all around the world. There are also many many different ways that an SMSC or MMSC could choose to format a phone number in a message that it delivers. Somehow, we need to match incoming message addresses to outgoing message addresses in order to display them in the same thread. We also need to match what's in your address book with both of those so that we can display the correct contact information for the messages in that thread. We need to account for the fact that the user, SMSC, and MMSC could choose to change how they're formatting numbers in any of those places at any point. We need to store additional state like encrypted sessions, per-contact preferences, etc and also correlate that with numbers as they're displayed in all of these places.

The only truly universal format is E164, so we canonicalize everything into E164 in order to have a sane representation that's consistent everywhere.

The only place we can't do that is with short codes, so we try to detect them and canonicalize them differently.

This prints true. So how this is an issue with libphonenumber?

No idea, try writing your test with Address.fromExternal() and see

[ghost]

Please, don't be offended. I have put the smiley after "you stupid app" to show that I am joking.
Not the smartest way, I agree. Sorry for that.
Never make such "jokes" on the Internet or you may get misunderstood, my mom said. Should have listened. :wink:

[olemd]

This bug isn't only with short numbers either I think. I've stopped using Signal as my SMS-app because of this, but I'm fairly certain I've been able to send and answer _some_ short-numbers but not all.

Also, there's a thing with extra long numbers, apparently "normal" numbers with an appended identifier to allow plain "reply to this sms" to be handled properly based on the original message. These numbers appear to exceed 15 digits.

The normal sms-app handles this just fine, which makes me think that perhaps it doesn't normalize the numbers the same way? I would expect just about anything sms-ish to use PhoneNumberUtil.

[C-Makridis]

Another affected country seems to be Greece with 5 digit numbers.
My attempts to send sms to 54574 fail, since signal prepends +30 to it.
(sorry if I'm hijacking, but opening a new bug report seemed overkill to me)

[rLy07]

Not sure if I have the same problem but I was trying to send a message to a standard UK mobile number starting with 0796 xxxxxxx. And it got replaced with +360796 xxxxxxx which is (+36) the country code for Hungary (I'm from Hungary and using the phone in hungarian language but I have a UK sim). Getting messages from the same number works (it gets replaced by +44796 xxxxxxx).

[atenrok]

same in united states

[xprzemekw]

It seems latest Signal version I got installed from the Play store has this issue fixed. I was able to send SMS to the short code number, standard Android popup informing about possible charges was also present. Kudos guys:)

[manjiki]

@xprzemekw how many digits was the short code number? I am still having issues with 5-digit ones

[automated-signal]

GitHub Issue Cleanup:
See #7598 for more information.