[asterisk-bugs] [Asterisk 0016508]: [regression] app_sms not working in 1.6.1.12 (same as 0012779)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16508 
====================================================================== 
Reported By:                shanselman
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   16508
Category:                   Applications/app_sms
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Target Version:             1.6.1.18
Asterisk Version:           SVN 
JIRA:                       SWP-617 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-12-23 05:40 CST
Last Modified:              2010-02-24 05:31 CST
====================================================================== 
Summary:                    [regression] app_sms not working in 1.6.1.12 (same
as 0012779)
Description: 
app_sms has reverted to the same issue as in entry 12779:-

chan_dahdi.c:     -- Requested transfer capability: 0x00 - SPEECH
app_dial.c:     -- Called g1/17094009
app_dial.c:     -- DAHDI/2-1 is proceeding passing it to
Local/17094009 at default-549e;2
app_dial.c:     -- DAHDI/2-1 is ringing
app_dial.c:     -- DAHDI/2-1 answered Local/17094009 at default-549e;2
pbx.c:        > Channel Local/17094009 at default-549e;1 was answered.
pbx.c:        > Launching SMS(1268466100) on
Local/17094009 at default-549e;1
app_sms.c:  sms argc 1 queue <1268466100> opts <> addr <> body <>
app_sms.c:  initial delay 300ms
pbx.c:   == Spawn extension (default, 17094009, 1) exited non-zero on
'Local/17094009 at default-549e;2'
app_sms.c:     -- SMS RX 93 00 6D
app_sms.c:     -- SMS TX 17 00
chan_dahdi.c:     -- Channel 0/2, span 1 got hangup request, cause 16
app_sms.c: ast_read failed
chan_dahdi.c:     -- Hungup 'DAHDI/2-1'

The messages never get sent (this is an upgrade from a 1.4 version of
asterisk which had no issues with the sms application).

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012779 [patch] smsq does not work in asterisk 1.6
====================================================================== 

---------------------------------------------------------------------- 
 (0118449) ploink (reporter) - 2010-02-24 05:31
 https://issues.asterisk.org/view.php?id=16508#c118449 
---------------------------------------------------------------------- 
Ok, I think I identified the problem.
I increased log verbosity and downloaded the ETSI specification document 
http://pda.etsi.org/pda/home.asp?wki_id=3Xm.CablLH019813K,Dms

Sadly, protocol 1 and 2 are not compatible and message numbers have
different meanings for both protocols. (ETSI blundered here imho)
Tho make the matter even more complicated, if the MSB is set in protocol
1, it means the message is NOT fragmented, but in protocol 2 this means the
message IS fragmented.

Shanselman got this communication:
SMS RX 93 00 6D
SMS TX 17 00

The received byte 93h is message type 13h with the msb set. The second
byte (00) indicates zero data length. Since a message with zero data length
cannot be fragmented (the spec is very clear about this) it must be
protocol 1 message 13h=DLL_SMS_EST "Indicates that the Data Link Layer
connection has been established."

The third byte (6D), however, is bogus. It is a data byte in a message
with zero data length and has no meaning for the specified message type.

Then asterisk transmits a 17h messages. According to the MSB logic, this
must be a protocol 2 message (it does not even exist in protocol 1).
Protocol 2 type 17h: "DLL_SMS_REL Command: Release request" ("The
DLL_SMS_REL is used to initiate the disconnection procedure.")
Asterisk may be confused about the protocol mixup

My case is a little different. I got:
SMS RX 93 00 6D
SMS TX 94 00

The RX is the same as with shanselman. This happens with messages received
from two very different systems (Siemens Gigaset and 17094009 message
center) so this must be a bug in the asterisk RX decoding logic.

The RX/TX are both protocol 1 messages, so that is ok.
In protocol 1, 14h means DLL_SMS_REL, so asterisk disconnects again
without sending SMS.

My best guess is that asterisk is confused over the extra bogus byte in
the RX. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-24 05:31 ploink         Note Added: 0118449                          
======================================================================