rcell 4.0.5 firmware known issues – questions

[Steve van der Burg]

I’m contemplating upgrading my modems to 4.0.5, but would like some more details on this, from the release notes:

– SMS Command API ignores 6 character password limit, does not fail if SMS is
longer than 160 characters, has issues depending on location of spaces and can
not view view/delete inbox/outbox.

Please clarify “does not fail if SMS is longer than 160 characters”. Does that mean that it still passes it onto the provider? Or does it break it into chunks (multiple messages) and send those, like the SMS spec seems to indicate?

Also, “has issues depending on location of spaces” doesn’t sound good. Does this mean that I can expect seemingly-random SMS delivery failures depending on the content of the message?

…Steve

[Mike McNeil]

Hello Steve,

“Does not fail if SMS is longer than 160 characters”
– If using the API to send SMS messages you do not receive the 400 error fail message because of the length limit. The message will sometimes send and truncate at 160 other times it will not send at all. Note: In the WebGUI the SMS truncates at 160 characters.

“Has issues depending on location of spaces”
– This involves using the API for the SMS Commands function, the reboot, checkin, ping, etc … commands. For example, sending the SMS command “p<space><space>password<space>#reboot” through the API causes issues compared to the documented “p<space>password<space>#reboot”.

You did not mention what version of MTR code you were using, but these issues have likely been in the firmware since the API SMS Commands were implemented in 3.4.5.

Regards,
Mike

[Steve van der Burg]

Okay, thanks for clarifying. I’m using 3.7.3.

Although we’re in production with 4 rcell modems now, and sending about 1800 SMS messages a day in total across those modems, I’m really not happy with my inability to build a useful, robust service using interactions with, and information from, the REST API.

I’ve also seen a lot of buggy behavior that has led to missing SMS messages. Just yesterday, a modem failed to send an SMS and then failed to send each message after that (for 2 hours). Once I rebooted the modem it then was able to send every “failed” message except the first one.

Aside from bugs, my first issue has to do with the modem API’s inability to tell me whether “failed” means “failed to hand the SMS off to the provider (that the modem’s SIM belongs to)” or “provider told me that this message can’t be sent (in the case of a phone number that can’t be messaged)”.

The second and HUGE issue is the inability to track a message. When I submit an SMS request to the modem I should get its GUID back in the response. That would give me a way to poll the sent box and tie outcomes for messages there to messages that I have sent.

When polling the sent box, each message’s status should include the number of retries attempted so far (not the “retries” setting, which is what it seems to return now). Also, I’d like documentation on the retry schedule (eg. does the modem retry all ‘failed’ messages that haven’t hit the retry limit once per minute, does it back off and try less and less frequently per failed message, etc).

[Mike McNeil]

Hello Steve,

I’m not aware of the exact capabilities or specifics concerning the MTR’s SMS API abilities. I would recommend you create a Support Case at https://support.multitech.com and we can try to get the proper people included on the case.

Regards,
Mike

[Steve van der Burg]

Doing that now.

Thanks,
…Steve

[Author]

Posts