Bug in 4G incoming calls in the USA

☎️ Ringo (MAKERphone)
#1

Here in the USA when using my new 4G module (SIM7600A), when an incoming call occurs, the phone number in the response from the SIM7600A to the AT+CLCC command does not necessarily contain a leading + symbol; for example, when I call my Ringo phone from my cell phone, the response string looks like this:
+CLCC: 1,1,4,0,0,“1215xxxxxxx”,129
See, no + symbol!

Because of this, the incoming number is mis-extracted (potentially as garbage) in the notification and the call log, and will not match the corresponding contact, because the contacts are required by the firmware to have a leading + symbol.

So it is necessary to add two lines of code to MAKERphone.cpp to allow incoming calls to work properly with or without the leading + symbol (because elsewhere in the world, the + symbol is apparently always provided).

Therefore I suggest changing the two lines of code in MAKERphone.cpp member function incomingCall() that currently read:

    uint16_t foo = localBuffer.indexOf("\"+", localBuffer.indexOf(",1,4,0,0")) + 1;
    number = localBuffer.substring(foo, localBuffer.indexOf("\"", foo));

to the following 4 lines (the 2 lines marked FCP are added; the other 2 are the same):

    uint16_t foo = localBuffer.indexOf("\"+", localBuffer.indexOf(",1,4,0,0")) + 1;
    if(!foo) foo = localBuffer.indexOf("\"", localBuffer.indexOf(",1,4,0,0")) + 1; // FCP
    number = localBuffer.substring(foo, localBuffer.indexOf("\"", foo));
    if(number[0] != '+') number = '+' + number; // FCP

This insures that an incoming call from a number without a leading + symbol will be properly extracted, and furthermore converted to a number with a leading + symbol for matching with contacts.

This is hardly the best code for the circumstance, but it’s a quick and dirty fix until someone can improve this code to work properly in the USA and elsewhere. For example, blocked (*67) incoming calls are not handled well by this code or this function.

1 Like
Caller I'd issues
#2

Hey Frank,

Thank you very much for your input!

We’ll look into it and see what can we do. :smiley:

Cheers, :sweat_smile:
Robert

#3

I added a line to deal with blocked calls yielding an empty string (which therefore has no number[0] element). The slightly improved code fragment now looks like this:

// Begin FCP Plus Symbol Optional
uint16_t foo = localBuffer.indexOf("\"+", localBuffer.indexOf(",1,4,0,0")) + 1; // Stays the same
if(!foo) foo = localBuffer.indexOf("\"", localBuffer.indexOf(",1,4,0,0")) + 1;  // Added
number = localBuffer.substring(foo, localBuffer.indexOf("\"", foo));            // Stays the same
if(number == "") number = "BLOCKED";                                            // Added
else if(number[0] != '+') number = '+' + number;                                // Added
// End FCP Plus Symbol Optional
#4

Wow, thanks for addressing and correcting this issue on such short notice.

The testing we did in the US and Canada didn’t reveal this issue - we’ve always received the AT+CLCC command with a leading + in the contact number.

We’ll include the changes you provided, but I am unsure about when.
It would help us a lot if you could make a pull request on our github repository.

If you’re unsure how to do this, check out this tutorial on how to fork our repository, and how to open a pull request.

1 Like
#5

Yes, the + issue is intermittent. Apparently, at Ting/T-Mobile’s whim, they either send the + or not - it can stay one way or the other for days. On US phones the + is virtually never entered (but is allowed) on outgoing in-country calls, and always removed from incoming in-country calls. Apparently a bit of pretentiousness because we were number 1 and Alexander Graham Bell invented the phone here. :slightly_smiling_face: Turns out this applies to Ting/T-Mobile on 2G also. Dunno about other carriers.

1 Like
#6

Do you know if the 001 is necessary in calls?

*I always use 1 when I call a number, but idk with my Ringo yet. I’ll have to see if it works on my trip.