search

atefsaeed2010 / asterisk-chan-dongle-01

Automatically exported from code.google.com/p/asterisk-chan-dongle
Other
0 stars 1 forks source link

receiving multipart sms . #141

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

1. receive multipart sms . 

if i receive multi part sms , suppos which have 3 parts , chan dongle will 
receive it separately and will execute the dial plan separatly for each of the 
parts . and the function BaseDecode64 can't decode it .

Original issue reported on code.google.com by alihmd....@gmail.com on 29 Jul 2013 at 6:35

GoogleCodeExporter commented 9 years ago 
i want if the dongle is to receive multipart sms , dongle should wait for the 
other parts of sms and then join all of the parts , then send it to the dial 
plan , any suggestion how can i achieve this . ?

Original comment by alihmd....@gmail.com on 29 Jul 2013 at 6:37

GoogleCodeExporter commented 9 years ago

Original comment by bg_...@mail.ru on 30 Jul 2013 at 6:42

GoogleCodeExporter commented 9 years ago 
Sorry, but chan_dongle is voice channel driver for asterisk, not part of 
SMSTools
or other SMS-aware applications.

No reasons for complete decoding, waiting for any undelivered parts (may be 
lost) at 
this level. 

Your request is same as 'i want my NIC driver do reassemble IP packets'.

Original comment by bg_...@mail.ru on 30 Jul 2013 at 6:45

GoogleCodeExporter commented 9 years ago

Original comment by bg_...@mail.ru on 30 Jul 2013 at 6:46

GoogleCodeExporter commented 9 years ago 
I have a small patch to parse SMS reference number, total parts and current 
part from User Data Header. These values will be populated into channel 
variables REF, MSG_PARTS and MSG_PART.

PS: I have other patches applied before. You may need to patch manually.

Original comment by gpuzan...@gmail.com on 10 Dec 2014 at 12:17

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
And the following during patching:

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- at_response.c.orig 2014-12-10 15:09:06.000000000 +0300
|+++ at_response.c      2014-12-10 14:12:17.000000000 +0300
--------------------------
Patching file at_response.c using Plan A...
Hunk #1 succeeded at 1185 (offset -1 lines).
Hunk #2 succeeded at 1201 (offset -1 lines).
Hunk #3 FAILED at 1248.
1 out of 3 hunks FAILED -- saving rejects to file at_response.c.rej

Original comment by evgeshka...@gmail.com on 27 Mar 2015 at 1:02