SMS Server Tools 3
This site is hosted by Kekekasvi.com
 Menu
Basic information:
Additional information:
Support:
Get SMS Server Tools 3:
Additional Options

 Sponsored links

 Search
Custom Search

 Visitor locations
 
 SMS Server Tools 3 Community
Welcome, Guest. Please login or register. Tue Mar 09, 2021 04:07
SMSTools3 Community » Help and support Bottom

[answered] Massive sending Delivery Report

  This topic is locked

Page:  1

Author Post
Member
Registered:
Feb 2011
Location: Paris, France
Operating system name and version: Ubuntu 10.4
Version of smsd: 3.1.14
Smsd installed from: sources
Name and model of a modem / phone: Xdungle GPRS (Wavecom fastrack chip, same AT commands)
Interface: USB

Hello,
firstly, (especialy for keke) thanks for your support, I see that you are very active :D

Some of my question concern sms server tools whereas some are more specific to gsm modems.

I'm facing this problem :

When a large amount of sms are queued on a modem, I lost a lot of delivery report.
I made the test with a 280 sms sending.
87 delivery report were received.

Here is my config :

devices = GSM1
logfile = /var/log/smsd.log
loglevel = 7
autosplit = 3
store_received_pdu = 3
sent = /var/spool/sms/sent
store_sent_pdu = 3
#Modem configuration
[GSM1]
device = /dev/ttyACM0
incoming = high
baudrate = 115200
pin = 4284
#pin = 2684
primary_memory = SM
secondary_memory = SR
#init = AT+CNMI=1,0,0,2,0
init = AT+CNMI=2,2,2,1,0
report = yes
 
'smsdconf' Syntax Highlight powered by GeSHi


Is there any way to ask the operator to re-send a delivery_status ?
Perhaps send again the sms with a flag ?
cf http://www.developershome.com/sms/sms_tutorial.asp?page=basicConcepts
Quote
If the mobile phone does not receive the message submission report after a period of time, it concludes that the message submission report has been lost. The mobile phone may then re-send the SMS message to the SMS center. A flag will be set in the new SMS message to inform the SMS center that this SMS message has been sent before. If the previous message submission was successful, the SMS center will ignore the new SMS message but send back a message submission report to the mobile phone.

Is there anyway I could reduce this amount of report loss or is it un-avoidable when using a gsm modem ?

Also, perhaps is my configuration incorrect.
Warning message from smsd log :



Thanks in advance,
Be free of asking me for any details/logs etc.

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
You could use the modem setting report_device_details = yes, restart smsd and show those details from the log here.

I'll try to check this issue little bit later, right now I'm busy.

Member
Registered:
Feb 2011
Location: Paris, France
Topic owner
Hum,
I added this parameter,
but It don't seems to get any more details in the logfile

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Did you restart the smsd? Restart is required after configuration was changed.

In the log file, details are shown like this (iTegno 3000):

2011-02-28 19:43:37.160,7, GSM1: ## Start of device details
2011-02-28 19:43:37.160,7, GSM1: # Manufacturer identification:
2011-02-28 19:43:37.360,7, GSM1: -> AT+CGMI
2011-02-28 19:43:37.670,7, GSM1: <- WAVECOM MODEM
OK
2011-02-28 19:43:37.670,7, GSM1: # Model identification:
2011-02-28 19:43:37.870,7, GSM1: -> AT+CGMM
2011-02-28 19:43:38.179,7, GSM1: <- MULTIBAND  900E  1800
OK
2011-02-28 19:43:38.179,7, GSM1: # Revision identification:
2011-02-28 19:43:38.380,7, GSM1: -> AT+CGMR
2011-02-28 19:43:38.789,7, GSM1: <- 652a09gg.Q2406A 1489876 060706 17:19
OK
2011-02-28 19:43:38.789,7, GSM1: # New message indications, list of supported modes:
2011-02-28 19:43:38.989,7, GSM1: -> AT+CNMI=?
2011-02-28 19:43:39.301,7, GSM1: <- +CNMI: (0-3),(0-3),(0-3),(0-2),(0,1)
OK
2011-02-28 19:43:39.301,7, GSM1: # New message indications, current settings:
2011-02-28 19:43:39.501,7, GSM1: -> AT+CNMI?
2011-02-28 19:43:39.812,7, GSM1: <- +CNMI: 1,0,0,2,0
OK
2011-02-28 19:43:39.812,7, GSM1: # Preferred message storage, list of supported mem's:
2011-02-28 19:43:40.012,7, GSM1: -> AT+CPMS=?
2011-02-28 19:43:40.324,7, GSM1: <- +CPMS: (("SM","ME","BM","SR"),("SM","ME"),("SM","ME"))
OK
2011-02-28 19:43:40.324,7, GSM1: # Phonebook storage, available mem's:
2011-02-28 19:43:40.524,7, GSM1: -> AT+CPBS=?
2011-02-28 19:43:40.836,7, GSM1: <- +CPBS: ("SM","FD","LD","MC","ME","RC","MT","EN","SN")
OK
2011-02-28 19:43:40.836,7, GSM1: # List messages, list of supported stat's:
2011-02-28 19:43:41.036,7, GSM1: -> AT+CMGL=?
2011-02-28 19:43:41.348,7, GSM1: <- +CMGL: (0-4)
OK
2011-02-28 19:43:41.348,7, GSM1: # Delete message, list of supported values:
2011-02-28 19:43:41.548,7, GSM1: -> AT+CMGD=?
2011-02-28 19:43:41.860,7, GSM1: <- OK
2011-02-28 19:43:41.860,7, GSM1: # Phone activity status, list of supported stat's:
2011-02-28 19:43:42.060,7, GSM1: -> AT+CPAS=?
2011-02-28 19:43:42.372,7, GSM1: <- +CPAS: (0-5)
OK
2011-02-28 19:43:42.372,7, GSM1: # TE character set, list of supported charset's:
2011-02-28 19:43:42.572,7, GSM1: -> AT+CSCS=?
2011-02-28 19:43:42.884,7, GSM1: <- +CSCS: ("GSM","PCCP437","CUSTOM","HEX")
OK
2011-02-28 19:43:42.884,7, GSM1: # TE character set, current setting:
2011-02-28 19:43:43.084,7, GSM1: -> AT+CSCS?
2011-02-28 19:43:43.394,7, GSM1: <- +CSCS: "PCCP437"
OK
2011-02-28 19:43:43.394,7, GSM1: ## End of device details
 


Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
At least in theory it may be possible to get lost delivery reports with re-sending. A bit "reject duplicates" should be set, and also "message reference" should be defined. Currently those fields are not handled in the code. In the past some testing with "message reference" was done, and the result was that many modems do not use the given value. Because the internal counter is always used, re-sending with "reject duplicates" will not work. Also, multipart messages will make this feature even more complicated,

Assuming, that in the log you have not seen routed reports which are not handled, I think that the acknowledge may be the reason for the loss. In this case you could try if a modem setting routed_status_report_cnma = no makes any difference.

In the configuration you have primary_memory and secondary_memory defined. This is because there is SR memory available in your device, right? You also have "init = AT+CNMI=1,0,0,2,0", but it's commented out. Why is that? With this initialization Wavecom chip usually stored reports into the SR memory, and smsd can read them from there and routing is not required. You however have enabled routing with the current initialization, Is it because the SR memory does not work, or what is the reason?

Member
Registered:
Feb 2011
Location: Paris, France
Topic owner
Here is the device details log (didn't saw it firstly in the log) :



Quote
In the configuration you have primary_memory and secondary_memory defined. This is because there is SR memory available in your device, right? You also have "init = AT+CNMI=1,0,0,2,0", but it's commented out. Why is that? With this initialization Wavecom chip usually stored reports into the SR memory, and smsd can read them from there and routing is not required. You however have enabled routing with the current initialization, Is it because the SR memory does not work, or what is the reason?

I used init = AT+CNMI=2,2,2,1,0 because with init = AT+CNMI=1,0,0,2,0 I'm facing this problem :
I always get the same report (the first one) with the same message id.
Exemple of report logs when using init = AT+CNMI=1,0,0,2,0 :



Quote
In this case you could try if a modem setting routed_status_report_cnma = no makes any difference.

Using this parameter I only get one report and then, nothing.

Any ideas ?

Thanks

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
Probably your modem is broken, and at least the firmware should be upgraded...

When smsd is reading those multiple reports, can you show the log (with loglevel 7)?

Member
Registered:
Feb 2011
Location: Paris, France
Topic owner
With config :

devices = GSM1
logfile = /var/log/smsd.log
loglevel = 7
autosplit = 3
store_received_pdu = 3
sent = /var/spool/sms/sent
store_sent_pdu = 3
#Modem configuration
[GSM1]
device = /dev/ttyACM0
incoming = high
baudrate = 115200
pin = 4284
#pin = 2684
primary_memory = SM
secondary_memory = SR
init = AT+CNMI=2,2,2,1,0
report = yes
'smsdconf' Syntax Highlight powered by GeSHi




With config like :

devices = GSM1
logfile = /var/log/smsd.log
loglevel = 7
autosplit = 3
store_received_pdu = 3
sent = /var/spool/sms/sent
store_sent_pdu = 3
#Modem configuration
[GSM1]
device = /dev/ttyACM0
incoming = high
baudrate = 115200
pin = 4284
#pin = 2684
primary_memory = SM
secondary_memory = SR
init = AT+CNMI=1,0,0,2,0
report = yes
'smsdconf' Syntax Highlight powered by GeSHi


I didn't get the same issue (same report over and over).
But I only get one report when queuing several sms.
Log of 10 sms sending (i'm showing the only report incoming and some sms sending)



Member
Registered:
Feb 2011
Location: Paris, France
Topic owner
Adding something,

I just received a new delivery report :


Can I assume that the operator sent the report 2 hours later or is this a confusion on the message id (41) ?

Thanks

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
ThugAim wrote
I didn't get the same issue (same report over and over).

Okay, as the old log is not available, we cannot verify if that report was received three times from SMSC, or if the modem was "giving" it more than once.

Perhaps your modem is not broken, but the capacity is still small. It may be possible, that when lot of messages are received, and slots are filled up, SMSC will wait long time before re-trying delivery.

ThugAim wrote
Can I assume that the operator sent the report 2 hours later or is this a confusion on the message id (41) ?

Unfortunately yes, and actually there can be much longer delays with delivery reports (and with normal SMS too). Even some days, but it depends on the operator and the load of GSM network.

I think that you just have to live with this issue :(. Delivery reports are not the most priorized traffic on the network.

Member
Registered:
Feb 2011
Location: Paris, France
Topic owner
I see :'(

What modem would you advice me to choose in order to handle as best as possible the status report (with an important message queue) ?

Member
Registered:
Feb 2011
Location: Paris, France
Topic owner
Another question, the "Discharge_timestamp: 11-03-01 13:50:51" is the date when the operator sent the report back or when he delivered the sms to the phone ?



Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
It seems that the firmware of Wavecom chip is causing the problem. I was able to reproduce this kind of a problem with iTegno 3000. After SMS was sent, status report was received but it was very old one, not a correct and even not from correct number. After a while, the same status report was received again and again, even when any SMS was not sent. This looks like SMSC did not get the correct information from the modem, and therefore continued trying. After I moved the SIM into other modem, reports were read properly.

As far as I can remember, status reports with Wavecom chip were working properly couple of years ago. Perhaps the firmware is now outdated, and does not work properly with today's SMSC's.

ThugAim wrote
What modem would you advice me to choose in order to handle as best as possible the status report (with an important message queue) ?

I cannot recommend any specific modem. Some very new modem with a new firmware might be good, but I'm not a reseller.

ThugAim wrote
Another question, the "Discharge_timestamp: 11-03-01 13:50:51" is the date when the operator sent the report back or when he delivered the sms to the phone ?

It's a timestamp of "Status", the time when the message was successfully delivered or when it was discarded by the SMSC.

  This topic is locked

Page:  1

SMSTools3 Community » Help and support Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.