Concatenated SMS support; Complete locking and single shift tables

[magcks]

Resolves #40

[magcks]

The test fails because smsdb.c is not compatible with asterisk 1.6. Fixing this is currently not relevant for me. Probably someone else can fix this or you just remove 1.6 from the travis stuff.

[wdoekes]

Thanks for the PR.

It's nice that you're willing to make the effort to share your changes.

I have a few reservations:

• you have quite a big changeset here, which in fact contains two changes (Concatenated SMS support and Complete locking and single shift tables). It would've been nice if you had cut those up into separate PRs, as they would've been easier to review and merge separately;
• feel free to rebase and squash fixup commits (if there are fixups left before merge, I'll squash the entire thing instead; in a perfect world, there was a commit for the tables, one for the added smsdb and one for the concatenated sms; allowing easier review);
• code style is generally good, although I'd like to see https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines#CodingGuidelines-Codeformatting for all new and changed code;
• I'm not that fond of adding -std=gnu99, but I won't object.

As for the actual functional changes:

• adding sqlite3 dependency should not be a problem, as asterisk has a hard dependency on it itself;
• I did not check that everything/anything works, I'm assuming you did 😛

Also, I committed 923db63 for you so travis won't complain about 1.8 failing.

[magcks]

You're welcome.

Sorry for the messed up commits and the stupid force-pushes. In my opinion it doesn't make sense to split up the PR, as correct message splits require correct and fast GSM7 encoding which the original code doesn't offer.

I will definately check up the coding style to match with the asterisk guides. chan dongle itself sould compile with -std=c99, but asterisk has some GNU extensions in there.

sqlite3: Yup. I just copied their astdb stuff.

Yeah. Kind of. Receiving works without any problems. Sending works with GSM7 and I checked the payload with some online tools. Didn't had enough money on my test SIM card so send more test messages ;p But yeah: We should definately send an unicode message before merging this PR.

[magcks]

Okay. I think I resolved all formatting issues. I also checked sending messages again. UCS-2 single and concatenated works as well as both types of GSM7 messages.

[turbozapekanka]

Thank you guys for contributing to this project.
I'm using this fork and can test if necessary

[wdoekes]

Thanks @magcks for the updates. It might take a couple of days before I get a chance to look at this again.

@turbozapekanka : the more testing the merrier 👍

[magcks]

If I find time today, I will look over squashing and rebasing my PR.

There are still one other major thing I changed on my local repository. I currently seperating the hex coding from the actual PDU packing for robustness reasons (sprintf with %02x seems to be a bad Idea if there is no check for > 255, etc.) and finished the timestamp and SCA parsing. I am also planning to get rid of the return [error string] lines to resolve the FIXMEs at the delivery report code. Should I include some of this into this PR or should I open up a new one once I am finished?

[wdoekes]

Should I include some of this into this PR or should I open up a new one once I am finished?

If you're changing code you're already touching here, then you might as well append it to this PR.

But generally, a separate PR is preferred, for readability/inspectability. You could PR it on top of your own branch (this one) if you want, then you can work with the intended (new) version, and we can merge both when ready.

[magcks]

I will put the new stuff into a seperate PR.

I rebased my PR. There is currently nothing to add from my side anymore.

[CpServiceSpb]

I downloaded and built git version on March, 09.
Long sms consised of 3 parts, all in Rusian letters was received successfully.
But when I sent sms even from 1 English letter, I got the folloein error:

`[Mar 10 13:03:56] ERROR[3400]: json.c:607 ast_json_vpack: Error building JSON from '{s: s, s: s}': Invalid UTF-8 string.
[Mar 10 13:03:56] ERROR[3400]: Got 11 backtrace records

0: /usr/sbin/asterisk(ast_json_vpack+0xb0) [0x55ac0e136690]

1: /usr/sbin/asterisk(ast_json_pack+0xa5) [0x55ac0e136745]

2: /usr/sbin/asterisk(ast_channel_publish_varset+0x2c) [0x55ac0e24394c]

3: /usr/sbin/asterisk(pbx_builtin_setvar_helper+0x217) [0x55ac0e1af597]

4: /usr/lib/asterisk/modules/chan_dongle.so(+0x2e498) [0x7fb85c155498]

5: /usr/lib/asterisk/modules/chan_dongle.so(+0x21e89) [0x7fb85c148e89]

6: /usr/lib/asterisk/modules/chan_dongle.so(+0x227d2) [0x7fb85c1497d2]

7: /usr/lib/asterisk/modules/chan_dongle.so(+0x2890d) [0x7fb85c14f90d]

8: /usr/sbin/asterisk(+0x599634) [0x55ac0e29b634]

9: /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7fb8622c16db]

#10: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7fb8617fa88f]`

[CpServiceSpb]

The same error is also appeared while 1 Sms with Russian letters are received.
And there is the old received Sms text in the buffer just after new one.
I think the buffer is not cleaned.

[magcks]

Thanks for your comments @CpServiceSpb . Can you please tell me the content of the PDU? You can log the content using
ast_log(LOG_WARNING, "PDU: %s\n", str);

in at_parse.c#322

Thanks! :)

[CpServiceSpb]

Thanks for your comments @CpServiceSpb . Can you please tell me the content of the PDU? You can log the content using
ast_log(LOG_WARNING, "PDU: %s\n", str);

in at_parse.c#322

Thanks! :)

Are you sure to insert in at_parse.c, line 322 ?