Bug in 4G incoming calls in the USA

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

Hey Frank,

Thank you very much for your input!

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

Cheers, :sweat_smile:

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

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

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

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.