|
|
SMS Server Tools 3 Community |
Welcome, Guest. The forum is currently read-only, but will open soon. |
Tue Oct 29, 2024 13:18 |
This topic is locked
Page: 1
Author |
Post |
|
#1 Mon Feb 28, 2011 13:27, 166 months ago.
|
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 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=basicConceptsQuote 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.
|
|
#2 Mon Feb 28, 2011 13:48, 166 months ago.
|
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.
|
|
#3 Mon Feb 28, 2011 14:56, 166 months ago.
|
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
|
|
#4 Mon Feb 28, 2011 17:47, 166 months ago.
|
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
|
|
#5 Mon Feb 28, 2011 19:23, 166 months ago.
|
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?
|
|
#6 Tue Mar 01, 2011 10:52, 166 months ago.
|
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
|
|
#7 Tue Mar 01, 2011 11:09, 166 months ago.
|
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)?
|
|
#8 Tue Mar 01, 2011 12:23, 166 months ago.
|
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)
|
|
#9 Tue Mar 01, 2011 13:00, 166 months ago.
|
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
|
|
#10 Tue Mar 01, 2011 13:33, 166 months ago.
|
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.
|
|
#11 Tue Mar 01, 2011 15:25, 166 months ago.
|
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) ?
|
|
#12 Tue Mar 01, 2011 17:03, 166 months ago.
|
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 ?
|
|
#13 Wed Mar 02, 2011 18:31, 166 months ago.
|
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
Time in this board is UTC.
|
|
|
|
|
|
|