Chained SMS trouble...

[Marco Gaiarin]

Still i've some trouble to handle some messages, that came all garbled.

After some trial and error, i've found that there's no way to receive
''chained'' messages, eg messages that have more then 160 chars.

My dialplan have:

exten => sms,n,Noop(Incoming SMS from ${CID_NUM}: ${SMS})
exten => sms,n,Noop(Incoming SMS(b64) from ${CID_NUM}: ${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,Noop(Incoming SMS(raw) from ${CID_NUM}: ${CMGR})


In log i've found:

-- Executing [sms@dongle:4] NoOp("Local/sms@dongle-dc99;1", "Incoming SMS from XXXXXXXXXX: e_m_ABAZC]ICeKAj]Af[gAZ_Yi_AXk]O_AJA`SK]_AtKaa_AHSAXKiiKeKAFQK@HSMMSGSYKAdCaaeKgK]iCeKAR]A`_GQSAFCeCiiKeS]@ keie_aa_AHKm_AfGeSmKeKAZ_Yi_AHSA`S") in new stack
-- Executing [sms@dongle:5] NoOp("Local/sms@dongle-dc99;1", "Incoming SMS(b64) from XXXXXXXXXX: e_m_ABAZC]ICeKAj]Af[gAZ_Yi_AXk]O_AJA`SK]_AtKaa_AHSAXKiiKeKAFQK@HSMMSGS@`_SGQaeKgK]iCeKAR]A`_GQSAFCeCiiKeS]@ keie_aa_AHKm_AfGeSmKeKAZ_Yi_AHSA`S") in new stack
-- Executing [sms@dongle:6] NoOp("Local/sms@dongle-dc99;1", "Incoming SMS(raw) from XXXXXXXXXX: +CMGR: 0,,159 0791932350591211440C91932378532746000041709200115180A0050003220201A0F2B7FD0D0A83DA6137392C2F83EA6ED0BC3D07B5DF6CFA1BC4AEBBCF6F5019044F97DD6F90BE0C87BF41E434885DA6D3CBF232688C2E83082072DA6C4E8FD3EC32481E86C3E5E579D94D0FCBCBA0B41B047F8FD169D0382C0FD3E96579DA0582D6E574F91B0E7F83C865FB1B341FCBD3F6B2BC0C6ABFD9F437889C06C1D30610FC9D1EA30B") in new stack

and:

-- Executing [sms@dongle:4] NoOp("Local/sms@dongle-6a54;1", "Incoming SMS from XXXXXXXXXX: @f_Y_A^eCAP_AfkaKeCi_ARAFK]i_gKggC]iCAFCeCiiKeS]") in new stack
-- Executing [sms@dongle:5] NoOp("Local/sms@dongle-6a54;1", "Incoming SMS(b64) from XXXXXXXXXX: @f_Y_A^eCAP_AfkaKeCi_ARAFK]i_gKggC]iCAFCeCiiKeS]") in new stack
-- Executing [sms@dongle:6] NoOp("Local/sms@dongle-6a54;1", "Incoming SMS(raw) from XXXXXXXXXX: +CMGR: 0,,68 0791932350591211440C919323785327460000417092001161803705000322020240F337FB0D7ACBC320F41B34AFC3CBF230FD0D4A83C66537FD3D2FCFE761373D0C1A87E5613ABD2C4FBB00") in new stack

I've tried to feed the PDU data from ${CMGR} into an online PDU decoder, and
decode perfectly.


Someone can provide some info? Ora someone have ''offloaded'' SMS
decoding into external script/tools?


Thanks.

--
Marco ``Gaio'' Gaiarin | LUG Pordenone (http://www.pordenone.linux.it)
P.zza S. Tommaso, 20 | Lilliput BBS (http://bbs.lilliput.linux.it)
Cimpello di Fiume Veneto | Azione Cattolica - Concordia-Pordenone
33080 Pordenone (Italia) | (http://www.accanto.org)
Tel. +39-0434-56-1305 | http://www.gaiarin.it/ ga...@linux.it

[Marco Gaiarin]

> Someone can provide some info? Ora someone have ''offloaded'' SMS
> decoding into external script/tools?

Ok, i've done some experiments.

1) seems there's out there many PDU decoding library, but most are
online, coded in javascript or C#, and so rather complex to use in an
offline setup.
I've found:

a) http://search.cpan.org/~johanvdb/GSM-SMS-0.163/lib/GSM/SMS/PDU.pm in
perl, but i was not able to use it.

b) https://github.com/pmarti/python-messaging/ in python, and seems to
work well.


2) seems to me that chan_dongle can do flawlessy some simple SMS
decoding (single messages, not so strange charsets, ...), but fail
when have to handle some complex one.
I think also that chan_dongle DON'T have to be a perfect sms gateway,
so this behaviour could be perfectly well-suited: chan_dongle is able
to decode simple SMS and handle it directly in dialplan, for complex
one we can offload to some specific tool.

But... how can i determine if chan_dongle have ''failed'' the decoding
of SMS? A natural approach would be that ${SMS} is empty, so we can use
${CMGR} and offload the conversion.



But generally... how you can handle ''complex'' sms? It is my dongle
that fail (K3765)? Or it is a general trouble?


Please, provide me some feedback, thanks.

[Michael Toop]

Why not just offload the decoding to python in the Asterisk dial plan?

I can try do it for you if you would like?

--
You received this message because you are subscribed to the Google Groups "dongle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chan_dongle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alejandro Donato]

My 2 cents.

I use to have an SMS server with PlaySMS running on it and four dongles,
working flawlessly from outside of asterisk. So, maybe, you can try to
send and recieve SMS outside asterisk to check modem capaibilites.

You can test it with smstools3, for example.

Hope this helps

El 29/07/14 a las #4, Marco Gaiarin escribió:

[Marco Gaiarin]

Mandi! Michael Toop
In chel di` si favelave...

> Why not just offload the decoding to python in the Asterisk dial plan?

1) I don't know python. ;-)

2) considering that i'm working on a project with limited resources
(=OpenWRT), seems rather dumb to me to offload SMS handling when it
work, and seems rather smart insted to have bultin some ''simple'' SMS
decoding, and offload only complex cases (that, indeed, are very few).


I'm not a C language programmer, so it is for me very complex to
understand where chan_dongle decode SMS, and if there's some place
where i can add some code.


Current chan_dongle developer are subscribed to that list? Can provide
some feedback on my idea, eg:

1) if possible, determine if chan_dongle is able to decode a sms
correctly

2) and if not, put ${SMS}='' (or add a variable ${SMS_DECODED}, it is
the same) so we can offload the decoding?

Thanks.

[Marco Gaiarin]

Mandi! Alejandro Donato

In chel di` si favelave...

> I use to have an SMS server with PlaySMS running on it and four
> dongles, working flawlessly from outside of asterisk. So, maybe, you
> can try to send and recieve SMS outside asterisk to check modem
> capaibilites.

So you are running, on the same ttyUSBXX devices, both can_dongle and
an external SMS gateway and they not clash?

> You can test it with smstools3, for example.

Anyway, my idea is not to buld a full SMS gateway solutionor something
like that; i need only to be sure that received SMS get parsed
correctly.

[Alejandro Donato]

When chan_dongle takes dongles control, cannot be used by another app
(in practical environment without modifying it) In the SMS server, i
don't use Asterisk. So, i suggest you to test with smstools3 the modem
functionality, to check if the error is something in the modem
operation/configuration or a "missdecode" in chan_dongle.

In other way, asterisk dialplan allows you to run external scripts and
process the results. The sequence can be:

chan_dongle SMS in -> send it to external script decoder from dialplan
and waits for result -> chan_dongle process the result.

Michael Toop offers to do it, if you can determine the problem is the
builtin decoder in chan_dongle. And maybe, both of you can help to solve
the issue definitively.


El 30/07/14 a las #4, Marco Gaiarin escribió:

[Leo]

Michael,

If you could show how to pass the PDU outside of Asterisk for external processing, this would be very much appreciated.

Likewise, for getting new PDU back in.

[Marco Gaiarin]

Mandi! Alejandro Donato
In chel di` si favelave...

> When chan_dongle takes dongles control, cannot be used by another
> app (in practical environment without modifying it) In the SMS
> server, i don't use Asterisk. So, i suggest you to test with
> smstools3 the modem functionality, to check if the error is
> something in the modem operation/configuration or a "missdecode" in
> chan_dongle.

Ah, ok, now it is clear.

> In other way, asterisk dialplan allows you to run external scripts
> and process the results. The sequence can be:
> chan_dongle SMS in -> send it to external script decoder from
> dialplan and waits for result -> chan_dongle process the result.

Exactly. My addon/idea is to arrange that work ONLY for ''complex''
messages, leaving SMS decoder of chan_dongle do their work simple
tasks.

I suppose that it is not so simple to distinguish ''simple'' from
''complex''... i've tried to send a simple message (that decode
perfectly):

-- Executing [sms@dongle:4] NoOp("Local/sms@dongle-bd2a;1", "Incoming SMS from XXXXXXXXXX: Scusate. Prova.") in new stack
-- Executing [sms@dongle:5] NoOp("Local/sms@dongle-bd2a;1", "Incoming SMS(b64) from XXXXXXXXXX: Scusate. Prova.") in new stack
-- Executing [sms@dongle:6] NoOp("Local/sms@dongle-bd2a;1", "Incoming SMS(raw) from XXXXXXXXXX: +CMGR: 0,,33 0791932350591211040C919323785327460000417013715490800FD3717D1EA6975D20A8FC6D0FBB00") in new stack

and the smstools online PDU decoder
http://smstools3.kekekasvi.com/topic.php?id=288
say me:

SMS DELIVER (receive)
Receipt requested: no
SMSC: 393205952111
Sender: 39XXXXXXXXXX
TOA: 91 international, Numbering Plan: unknown
TimeStamp: 31/07/14 17:45:09 GMT +02:00
TP-PID: 00
TP-DCS: 00
TP-DCS-desc: Uncompressed Text, No class
Alphabet: Default (7bit)

Scusate. Prova.
Length: 15


while if i try to decode the ''multipart'' messages of my original email, i get:

(part 1)
SMS DELIVER (receive)
Receipt requested: no
SMSC: 393205952111
Sender: 39XXXXXXXXXX
TOA: 91 international, Numbering Plan: unknown
TimeStamp: 29/07/14 00:11:15 GMT +02:00
TP-PID: 00
TP-DCS: 00
TP-DCS-desc: Uncompressed Text, No class
Alphabet: Default (7bit)
User Data Header: 05 00 03 22 02 01

Provo a mandare un sms molto lungo e pieno zeppo di lettere che è difficile rappresentare in pochi caratteri. Purtroppo devo scrivere molto di più poiché
Length: 160

(part 2)
MS DELIVER (receive)
Receipt requested: no
SMSC: 393205952111
Sender: 39XXXXXXXXXX
TOA: 91 international, Numbering Plan: unknown
TimeStamp: 29/07/14 00:11:16 GMT +02:00
TP-PID: 00
TP-DCS: 00
TP-DCS-desc: Uncompressed Text, No class
Alphabet: Default (7bit)
User Data Header: 05 00 03 22 02 02

solo ora ho superato i centosessanta caratteri.
Length: 55

So, seems to me that a difference came from the presence of a 'UDH'
part in the message:
http://smstools3.kekekasvi.com/index.php?p=udh
http://en.wikipedia.org/wiki/User_Data_Header

> Michael Toop offers to do it, if you can determine the problem is
> the builtin decoder in chan_dongle. And maybe, both of you can help
> to solve the issue definitively.

...now that i've understood what you mean, i can safely reply that this
is surely not needed: provided the fact that chan_dongle can emit the
raw PDU, and that the raw PDU decode correctly with external tools,
surely there's some trouble in the PDU parser of chan_dongle.


And, again, i think that a better approach would be not to try to
''fix'' it, but simply offload complex decoding to external tools.


Thanks.

[Marco Gaiarin]

Mandi! Leo

In chel di` si favelave...

> If you could show how to pass the PDU outside of Asterisk for external
> processing, this would be very much appreciated.
> Likewise, for getting new PDU back in.

...providing that chan_dongle export the ${CMGR} variable that contain
the output of the raw +CMGR command, and so contain the PDU, it is a
matter of a ''scripting exercise'' to build an AGI script that parse
the PDU and redefine the ${SMS} variable (or define a new one).

It is only because i don't know python...

[Leo]

Unfortunately hoping CMGR is filled is difficult mechanism to rely on, as we first must rely on our SMS context being fired by chan_dongle.

Many of chan_dongle's SMS issues are expressly related to parsing failures long before the SMS context is fired. Therefore any system command relying on 'sms' won't be fired either :(.

For example, I receive a message from a recipient that just has letters for their origin number, I receive "WARNING[16023]: at_response.c:1207 at_response_cmgr: [dongle0] Error parsing incoming message '+CMGR: 0,,34" (Can't parse OA). This is never sent to the SMS context extension. I could pass this to an external PDU decoder without concern, but the problem is getting it there in the first place.

[Marco Gaiarin]

Mandi! Leo
In chel di` si favelave...

> Many of chan_dongle's SMS issues are expressly related to parsing failures long
> before the SMS context is fired. Therefore any system command relying on 'sms'
> won't be fired either :(.

I'm really not a prorammer, and not a C programmer, but i think it is
not so hard to have chan_dongle return ''something'', at least ${CMGR},
in sms context...

[Paco Gil]

use asterisk manager....

[Marco Gaiarin]

Mandi! Paco Gil

In chel di` si favelave...

> use asterisk manager....

?! Sorry, but really i've not aunderstood what you mean... surely i can
use AMI to *SEND* SMS, but i'm a bit confuse on how to use it to
*RECEIVE* them...

[Paco Gil]

read asterisk manager event --> DongleNewCMGR

http://wiki.e1550.mobi/doku.php?id=usage#manager_events

[Marco Gaiarin]

Mandi! Paco Gil
In chel di` si favelave...

> read asterisk manager event --> DongleNewCMGR
> http://wiki.e1550.mobi/doku.php?id=usage#manager_events

Oh, i was not aware of AMi events... but seems that there's too little
docs around; looking at:

http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/AMI_id248378.html#AMI_id248782

seems to me that i've to poll for them. So still i've not understood
how better this way will be in respect to using ${CMGR} and an AGI
script in dialplan...

[Paco Gil]

Hi Marco,

your problem is you are not a programmer but want to build software as if you were an engineer :). I think you should contact to a more experienced person...

regards,

[Marco Gaiarin]

Mandi! Paco Gil
In chel di` si favelave...

> your problem is you are not a programmer but want to build software as if you
> were an engineer :).

Ahem, strictly speaking i'm a 'ingegnere' (B.Sc. in Computer
Engineering).
Simply i'm mostly a sysadmin, with mostly lost knowledge on computer
languages... ;-)

> I think you should contact to a more experienced person...

I'm doing that, expecially for building the python PDU AGI script i'm
talking about.


But i hope also on some feedback here...

[domini...@googlemail.com]

Hi Marco,

could you solve the problem? 

greetings

[Marco Gaiarin]

Mandi! dominikbenner via dongle

In chel di` si favelave...

> could you solve the problem? 

I've ''solved'' (circumvent) the problem using my 'smsfix' script.

But, try please the latest chan_dongle sources from wdoekes repository:

https://github.com/wdoekes/asterisk-chan-dongle

that have many fix also fror PDU decoding.

--
Marco ``Gaio'' Gaiarin | LUG Pordenone (http://pordenone.linux.it)

[Dominik Benner]

This updated chan_dongle works perfect for me! Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "dongle" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chan_dongle/NAlQ4ne8sSU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chan_dongle...@googlegroups.com.