Closed magcks closed 4 years ago
magcks
commented
4 years ago 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.
magcks
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago Thank you guys for contributing to this project. I'm using this fork and can test if necessary
wdoekes
commented
4 years ago 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 :+1:
magcks
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago 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
commented
4 years ago 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
CpServiceSpb
commented
4 years ago 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
commented
4 years ago 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
commented
3 years ago 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 ?
Resolves #40