Hello,

I don't think that the "ds=2" value is non-standard. In fact, it is described in the 
official 3gpp documentation, for example: 
http://www.3gpp.org/ftp/Specs/archive/27_series/27.005/27005-410.zip

Now, apart from the theoretical b/s, I *think* that your modem could work if you do 
the following change:

1) Edit org.smslib.modem.athandler.ATHandler.java
2) Modify the

this.terminators[10] = "\\+CDSI:\\s*\\p{Punct}[\\p{ASCII}]+\\p{Punct}\\p{Punct}
\\s*\\d+\\s";

declaration to read

this.terminators[10] = "\\+CDS:\\s*[\\p{ASCII}]*\\s*[\\p{ASCII}]*\\s*OK\\s*"

I just made this out of my mind, so the above regexp may need some adjusting to 
work. The point is to match the line:

<<
+CDS: 25
0006550B91XXXXXXXXXXXX808070217121808080702171718000
OK
>>

I see in your log.

If you see this working, I can create a separate at handler for your specific model.
Let me know.

(No comment was entered for this change.)

Any news?

Hello,

Sorry for this late answer.
Thank you for these explanations. Indeed, your proposal works well, although some
adjustments still should be done in the SMSLib :

- There's a conflict between the new terminator for "+CSD" indication, and generic
terminator[1], and the org.smslib.modem.AModemDriver.getResponse method finds that
such a "+CSD" indication matches with terminator[1]. There should be many ways to
solve this problem, and I'd like to have your personal feeling.
- In org.smslib.modem.AModemDriver.AsyncMessageProcessor.run method, I'm not sure a
"readMessage" call will retrieve the message for the status report. What do you think
about that ?

I will make further tests and give you the results once completed.
Thanks again for your help.

Hi,

Its good to hear that we are on the right track :)

About the conflict: yes, I see your point... If you can't figure out a regex for 
terminators[10] that is differentiated from [1], my recommendation would be to also 
modify smslib to iterate the terminators[] array in reverse order. This change 
should probably be implemented in any case, since the "natural" order is to iterate 
from a specific regex to a generic one. Its my fault that things are now done the 
opposite way.

From your question I guess that you have already spotted my assumption that the last 
4 terminators[] positions refer to the unsolicited events, so these last 4 regex 
should not move around...

As far as the second question, can you please give more details about why you think 
so? I am not aware of any problems there.

Thanks.

- Regarding the terminators, I had already reversed the iteration loop in the
getResponse method and it worked fine, as you expected too. So we can go on with this
behaviour : from the most specific to the most generic terminator.

- Regarding the second point, sorry I wasn't very clear indeed. Here are more details:

1. on one hand, for the "+CSDI" indication, the whole message could be retrieved in
the org.smslib.modem.AModemDriver.AsyncMessageProcessor.run method, with a call to
the gateway "readMessages" method, since it is stored. It works well.

2. on the other hand, the "+CSD" indication contains the incoming PDU frame, and the
status report is not stored. So any further "readMessages" call won't be efficient.
The event built in the ASyncNotifier, and containing the PDU frame in the response
field, could be forwarded to the ASyncMessageProcessor (add setProcess parameters ?)
Furthermore, I saw that the "+CSD" indication buffer already contains an ending "OK"
status. This is actually a problem, because after the "setEvent" call in the
getResponse method, SMSLib tries to read a final response. This was certainly always
working in the past, but in this special case, nothing more can be read, and it leads
to a TimeOutException when peeking a new char from the stream (=> modem reboot).

Let me know your recommendations about the way to implement this improvement.

Best regards.

( Second time I write this, now in notepad... Google throw me out the first time :< )

Hmm, this is getting more and more puzzling... Thankfully you remember that this 
mode does not actually store the data!

Ok, here is my initial thought:

1) You can remove the "OK" from the new regexp. In this case, the single 
terminating "OK" will be cought from the terminators[1] regexp.
2) Since the new regexp will now "catch" the "clean" data, you could modify the 
AsyncNotifier to pass the AsyncNotifier.Event class to the AsyncMessageProcessor. 
The latter could identify the case and create a new StatusReportMessage object from 
scratch (i.e. using the data from the Event class), and push it in the 
AsyncMessageProcessor.run().msgList list, before processing.

There is a problem, though... A big one.
As it stands now, the AsyncMessageProcessor works only if you have set your callback 
functions, because SMSLib is based on the assumption of the "persistency" of the 
modem's RAM, independently on whether the uncolicited events are processed or not. 
In this case (your case with the CSD indication) this also needs major refactoring. 
Because, now if someone does not have any callback functions defined, he would lose 
information.

If you are willing to give it a try, please work on the latest repo trunk - it would 
be easier to create the diffs.
Otherwise, I will try to work on this from next week.

What do you think?
Thanks.

OK, thank you for these remarks.

1) I'm going to test it and I will tell you the result.

2) I started the update of the SMSLib few days ago, for another purpose, since we
need additional features (EMS management), and it seemed to me that the library needs
few improvements to manage this type of short message. This is in progress, and we
are working with the lastest trunk repository.
I will take your remarks about the AsyncMessageProcessor into account, so as to
manage status reports for this Wavecom modem.
I'll try to give you a report next week (I'll be out of the office from tomorrow).

Thanks for all !

PS : for the EMS management, this is another issue, but if you have any
recommendations, please do not hesitate to tell me. We have to be able to configure
the whole User Data Header with a byte[], basically.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Hi,

First, I'm sorry for this very late answer.

1. The terminator we used in the AT handler for the CSDI indication is:
this.terminators[10] =
"\\+CDSI:\\s*\\p{Punct}[\\p{ASCII}]+\\p{Punct}\\p{Punct}\\s*\\d+\\s";
It worked properly so far.

2. About the status report management in case of CSDI indication, we successfully
updated the AsyncNotifier and AsyncMessageProcessor, as described below:

- AsyncNotifier.run:
// Add this before the INBOUNDSTATUSREPORTMESSAGE case
else if (event.getEvent() == AsyncEvents.INBOUNDSTATUSREPORTMESSAGEINDICATION)
    getGateway().getService().getLogger().logDebug("Inbound status report message
indication detected!");
    AModemDriver.this.asyncMessageProcessor.setProcess(event);
}

- AsyncMessageProcessor.run:
// After retrieving an event from the queue, modify the implementation
switch (event.getEvent())
{
    case INBOUNDSTATUSREPORTMESSAGE:
        PduParser parser = new PduParser();
        String payload = parser.parseStatusReportIndication(event.getResponse());
        Pdu pdu = parser.parsePdu(payload);
        if (pdu instanceof SmsStatusReportPdu)
        {
            StatusReportMessage msg;
            msg = new StatusReportMessage((SmsStatusReportPdu) pdu,-1,"");
            msg.setGatewayId(getGateway().getGatewayId());
            getGateway().incInboundMessageCount();
           
getGateway().getInboundNotification().process(getGateway().getGatewayId(),MessageTypes.STATUSREPORT,msg);
        }
        break;
        default:
            getGateway().readMessages(this.msgList, MessageClasses.ALL);
            for (InboundMessage msg : this.msgList)
            {
                switch (msg.getType())
                {
                    case INBOUND:
                       
getGateway().getInboundNotification().process(getGateway().getGatewayId(),
MessageTypes.INBOUND, msg);
                        break;
                    case STATUSREPORT:
                       
getGateway().getInboundNotification().process(getGateway().getGatewayId(),
MessageTypes.STATUSREPORT, msg);
                        break;
                    default:
                        break;
                }
        }
        break;
}

I'm sorry to put the code above as it, I have attached the AModemDriver class, since
I'm not sure at all if there are no other updates.
It is difficult to tell you exactly other updates we made on the library. Now, our
implementation manages EMS, and allows to interact with the binary content of a short
message.
Would you be interested to have a look on the whole custom SMSLib sources?

Thanks again for your support!

AModemDriver.java 29.8 KB   Download

EMS? Like logos, ringtones etc?

I don't work with these types of messages, but I am sure that many people would beg 
you to publish this code!

As far as the CDSI in-line handling, I will have a more detailed look in the 
following days. Thanks a lot :)

Hi,

Can you please attach the other source files as well?
There are some thing that I am missing, like the AGateway class (which you should 
have modified) etc.

Thanks and Happy New Year!

No answer.

Hi,

Sorry for this late answer, I apologize one more time.
You will find enclosed an archive containing the sources of our custom SMSLib.
These sources won't probably compile, since there are references to our own business
classes. But it may show you the updates we implement to get the SMSLib manage
special SMS (EMS, flash SMS, etc...).
Our needs required we refactor some part of the source code, to achieve these
results. Thank you for your indulgency, we tried to follow as much as possible the
SMSLib coding rules, but I'm not sure we did it well.

Best regards.

smslib-v3.3.0-B3-src-custom.zip 205 KB   Download

Thanks for the code! Set for review.

(No comment was entered for this change.)

(No comment was entered for this change.)

Does the smslib 3.4.1 already support delivery report for Wavecom 1206B ?
I can't seem to get it working.