Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multipart incoming SMSes are not concatenated #40

Closed
CpServiceSpb opened this issue Aug 20, 2017 · 15 comments · Fixed by #75
Closed

Multipart incoming SMSes are not concatenated #40

CpServiceSpb opened this issue Aug 20, 2017 · 15 comments · Fixed by #75

Comments

@CpServiceSpb
Copy link

CpServiceSpb commented Aug 20, 2017

There is Asterisk 13.12 at Ubuntu 14.04 LTS no-GUI x64 with Huawei E367 voice enabled with your chan dongle of git version at 20, August, 2017.
Two + received messages are "handled" separated +CMGR command (from Asterisk console I can see it) and are not concatenated to one long SMS.
That is message less than 160 symbols (for latin alphabet) or less than 70 symbols (for cyrillic) is received as one, but if is more than 160 or 70 symbols or some messages more than one, all these messages are not concatenated to one long SMS.

Kannel do so. I tested up for 5 parts.

@wdoekes
Copy link
Owner

wdoekes commented Aug 22, 2017

That would be correct. Handling of concatenated messages requires additional work either inside chan_dongle or by the application handling them (you).

Not only it has to keep the messages in a buffer until everything is retrieved, it also has to decide what/when to send when/if a part of the combined message is missing.

I don't have the time nor means to code this up for you, but I'd be willing to review and merge a PR.

@wdoekes wdoekes changed the title Multipart incoming SMSes with Huawei dongle are not concatenated ! Multipart incoming SMSes are not concatenated Aug 22, 2017
@oooo1
Copy link

oooo1 commented Aug 22, 2017

Not only it has to keep the messages in a buffer until everything is retrieved, it also has to decide >what/when to send when/if a part of the combined message is missing.
Criterion as I understand, two:

  • sender;
  • analyze total sms quantity and sms order part # fields of PDU - 3 of 6 for example.
    And look at kannel and playsms. It handles multipart sms correctly.

I think chan_dongle has to analize incoming SMS, if it is multipart, extract appropriate message fields as sender # and PDU fields as total sms and sms # in the chain and concatenate it.
And after that only is to move it to a dial plan otherwise it willl be as now - each part calls each sms context in a dial plan.
I think as you know chan_dongle well you will do it mor effectivelly and qcuicker then other folks.

@wdoekes
Copy link
Owner

wdoekes commented Aug 23, 2017

I think as you know chan_dongle well you will do it [more effectively] and [quicker than] other folks.

Possibly; although I'm not as intimate with all parts of the code as you may think. I just forked it and made a few minor edits.

But since I use it the least of everyone here (I don't have a dongle), it would be the least useful to me to create such an addition :)

@laigor
Copy link

laigor commented Aug 23, 2017

I suggest to set the channel variables indicating the number of the SMS part and the number of parts and then concatenate the SMS parts in the dialplan. This is easier to implement. Less changes to the module code.

@mcdull
Copy link

mcdull commented Aug 25, 2017

The SMS part is actually in the part of ${CMGR}. But I am not sure if it is in the exact location everytime.
For example.
+CMGR: 0,,40 0891683108707515F14005A10180F600087180529011642318050003710303300230104E2D56FD79FB52A83011000D000A
The message part is located at the second line position 59-62 = 0303
03 (Total message) - 03 (current message)

So it is, by theory possible to do it with the below Pseudocode in dial plan.

  1. Noop, incoming SMS
  2. System (echo "${CALLERID(num)}" >> /var/log/asterisk/smsmail)
  3. System(echo "${STRFTIME}" >> /var/log/asterisk/smsmail)
  4. System(echo "${BASE64_DECODE(${SMS_BASE64})}" >> /var/log/asterisk/smsmail)
  5. ExecIF(${CMGR:59:2) = ${CMGR:61:2),System(Mail the /var/log/asterisk/smsmail | delete the smsmail)
  6. Hangup

I have not gone through all the syntax and functions as I am completely new in Asterisk coding. But I always got some very long SMS so I would like to get rid of it.

My current problem is that asterisk seem have no search / find / instr function to determine the position of the the \r\n characters. The CUT function may work in the \n character is considered a valid delimiter but it is not.

@CpServiceSpb
Copy link
Author

Usefull (may be) link: Send and Receive Concatenated SMS in PDU mode

@rodriguescr
Copy link

This could help you maybe. https://github.com/asiacny/chan-dongle-extended

@garronej
Copy link

Do not try to use chan-dongle-extended. I decided to make the repo private untile I came up with a stable version. The repo of asiacny is a fork of my work that will not run.

Regards

@kalon33
Copy link

kalon33 commented Jan 11, 2019

@garronej any updates on this? Is this currently usable? how?

@garronej
Copy link

garronej commented Jan 11, 2019

Yes. It's usable and stable you can use it.
https://garronej.github.io/chan-dongle-extended-pages/

Unfortunately it's not open source just yet. I use it as dependency for a larger project and I am not sure I can make it opensource yet without jeopardizing my business.

@mcdull
Copy link

mcdull commented Jan 21, 2019

Yes. It's usable and stable you can use it.
https://garronej.github.io/chan-dongle-extended/

Unfortunately it's not open source just yet. I use it as dependency for a larger project and I am not sure I can make it opensource yet without jeopardizing my business.

thank you for your work. Is this solution work in multiple dongles environment? I have 5 dongles and the traditional code messed up everything by using local file as variable. And if the sms arrived at the same time from different dongles, the situation even worse. Sadly it does happen all the time as the carrier will sometimes broadcast the same messages to all SIM.

@garronej
Copy link

Hey @mcdull
In chan-dongle-extended everything related to SMS management have been entirely rewritten.
It should fix the issues you are currently having and if it does not I would be very interested in your feedback to fix it asap.
Please reach out to me at [email protected] I would be happy to help you deploy chan-dongle-extended in your environment.

@kalon33
Copy link

kalon33 commented Jan 24, 2019

@garronej is this backward compatible with asterisk-chan-dongle regarding config files?

@garronej
Copy link

garronej commented Jan 24, 2019

@garronej is this backward compatible with asterisk-chan-dongle regarding config files?

Well chan-dongle-extended manage the file dongle.conf in realtime.
When a modem is connected to the host it will automatically add a
new section to the config file.
You can however change the general and default section if you need to
change let's say context or dtmf.
If there is already a dongle.conf file when chan-dongle-extended is installed
all the parameters that does not interfer with chan-dongle-extended will be preserved.

Now if your question is "can I just install chan-dongle-extended and expect things to work?"
-For voicecalls: yes.
-You can still ( assuming dongle.conf [defaults] disablesms=no ) send/receive SMS like you used to but my module will not be involved in the process, so you will still have all the bugs.
-If you want the SMS concatenation feature and text encoding fix you will have to update your dialplan as described in my documentation ( and AMI supported )

Regards

@CpServiceSpb
Copy link
Author

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]

Additional test show that
The same error is also appeared while Sms from 1 part 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.

shalzz pushed a commit to shalzz/asterisk-chan-dongle that referenced this issue Apr 23, 2022
# This is the 1st commit message:

Create DONATIONS.txt
# This is the commit message wdoekes#2:

Update README.md
# This is the commit message wdoekes#3:

Update DONATIONS.txt
# This is the commit message wdoekes#4:

Update DONATIONS.txt
# This is the commit message wdoekes#5:

Update DONATIONS.txt
# This is the commit message wdoekes#6:

Update chan_quectel.h
# This is the commit message wdoekes#7:

Update README.md
# This is the commit message wdoekes#8:

Update cpvt.h
# This is the commit message wdoekes#9:

Add files via upload
# This is the commit message wdoekes#10:

Delete DONATIONS.txt
# This is the commit message wdoekes#11:

Update README.md
# This is the commit message wdoekes#12:

Update README.md
# This is the commit message wdoekes#13:

Update README.md
# This is the commit message wdoekes#14:

Add files via upload
# This is the commit message wdoekes#15:

Update README.md
# This is the commit message wdoekes#16:

Update README.md
# This is the commit message wdoekes#17:

Update README.md
# This is the commit message wdoekes#18:

Update README.md
# This is the commit message wdoekes#19:

Update README.md
# This is the commit message wdoekes#20:

Update README.md
# This is the commit message wdoekes#21:

Update README.md
# This is the commit message wdoekes#22:

Update README.md
# This is the commit message wdoekes#23:

Add files via upload

Added Simcom support
# This is the commit message wdoekes#24:

Update README.md
# This is the commit message wdoekes#25:

Update README.md
# This is the commit message wdoekes#26:

Added support for Quectel UAC configuration
# This is the commit message wdoekes#27:

Conf file when using UAC
# This is the commit message wdoekes#28:

Update README.md
# This is the commit message wdoekes#29:

Update README.md
# This is the commit message wdoekes#30:

Quectel CREG correction

chan_dongle code assumes 4 parameters in response to command and 3 for URC. However quectel provides 5 and 4 respectively. This fix helps pass on correct status of registration.
# This is the commit message wdoekes#31:

No force registration status

Due to CREG parse issues, earlier registration status was always kept on, now will show unregistered if not connected to network
# This is the commit message wdoekes#32:

Create readme.md
# This is the commit message wdoekes#33:

For compilation with openwrt sdk
# This is the commit message wdoekes#34:

Support for openwrt sdk compilation
# This is the commit message wdoekes#35:

Fix for lac and cell id

Ref IchthysMaranatha#6
Post fix values may have a trailing double quote for quectel devices
# This is the commit message wdoekes#36:

Updated call ids for simcom

Add call termination for call ids 1 and 2
# This is the commit message wdoekes#37:

comment for simcom audio

Added default audio port for simcom in comment
# This is the commit message wdoekes#38:

Integrated ALSA support for UAC

Integrated driver for ALSA added, no need for bridging additional Asterisk ALSA channel when using UAC mode. Please use non-ALSA integrated branch if there is no need for UAC and you wish to avoid alsa dependency when compiling and running
# This is the commit message wdoekes#39:

Update COPYRIGHT.txt

Attribute copyright for alsa code copied from chan_alsa.c https://github.com/asterisk/asterisk/blob/master/channels/chan_alsa.c
# This is the commit message wdoekes#40:

Update README.md
# This is the commit message wdoekes#41:

Conf file with UAC device support
# This is the commit message wdoekes#42:

UAC mode conf file
# This is the commit message wdoekes#43:

Added alsa-lib for compilation
# This is the commit message wdoekes#44:

Delete Makefile.in
# This is the commit message wdoekes#45:

alsa-lib dependency addition
# This is the commit message wdoekes#46:

Fix for simcom audio issues with immediate answer in dialplan
# This is the commit message wdoekes#47:

Note for Quectel serial audio

Added remark to disable gps messages
# This is the commit message wdoekes#48:

Added note for Pi users
# This is the commit message wdoekes#49:

Quectel creg formatting fix

Removed trailing double quotes in reporting lac/cid
# This is the commit message wdoekes#50:

add gitattributes
# This is the commit message wdoekes#51:

Send DTMF using AT command

Corrected at command for dtmf generation
# This is the commit message wdoekes#52:

Fix for busy on call rejection for simcom

For those who receive 'busy' additionally on call rejection when dialling out. Author only receives 'no carrier' on rejection. Reported and solved by @mpmc here IchthysMaranatha#22
# This is the commit message wdoekes#53:

Removal of redundant closetty
# This is the commit message wdoekes#54:

Update busy fix for call rejection

Updated fix as submitted by @mpmc here IchthysMaranatha#22
Author does not receive busy response on call rejection
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants