It makes perfect sense according to the SMPP specification. A connection is either bound as transmitter, receiver or both (transceiver).
A transmitter is for messages set to SMSC from ESME. A receiver is for messages from SMSC to EMSE. Transceiver does both. So a submit_sm is a request to SMSC from ESME and the EMSE will acknowledge via a sm_submit_resp. The deliver_sm is an SMSC originated message and will therefore go the receiver not the submitted. But all of this I am sure you know. I had not set up a receiver port because I had intended to be in transceiver mode but during all my testing I had commented out the transceiver-mode line so effectively had this in my config. #transceiver-mode = true As soon as I took away the comments and started up again I received all the deliver_sm from the SMSC that had been queuing. I have not submitted any logs or config because I have resolved my issue and what happened can be easily explained by the SMPP protocol. Everything seems to be working as designed. 2010/7/1 Nikos Balkanas <[email protected]> > Hi, > > Nope. The same way you were getting submit_sm_resp, you should have gotten > deliver_sm. What you say doesn't make much sense, but is difficult to say, > since you never submitted any logs. > > > BR, > Nikos > ----- Original Message ----- From: brett skinner > To: [email protected] > Sent: Thursday, July 01, 2010 10:26 AM > > Subject: Re: Open DLRs > > > Hi > > > I am assuming because I had bound as a transmitter and was sending > submit_sm packets that they were responding with submit_sm_resp. I think > that is according to SMPP 3.4 spec. The only problem is that I was not > getting the delivery receipts. It seems that Kannel treats the a positive > submit_sm_resp as a DLR to say enqueued. > > > Regards, > > > 2010/6/30 Nikos Balkanas <[email protected]> > > Hi, > > How then did you get the submit_sm_resp from the SMSc? > > > BR, > Nikos > ----- Original Message ----- From: brett skinner > To: [email protected] > > Sent: Wednesday, June 30, 2010 12:37 PM > > Subject: Re: Open DLRs > > > Hi > > > It turns out that I had commented out the section where I put the bind into > transceiver mode. Everything is working as expected. > > > Thank you for the help. > > > 2010/6/30 Nikos Balkanas <[email protected]> > > Hi, > > No. You have done all you needed from kannel's side. If not seeing > deliver_sm, try talking to your SMSc. > > > BR, > Nikos > ----- Original Message ----- From: brett skinner > To: [email protected] > > Sent: Wednesday, June 30, 2010 11:17 AM > Subject: Re: Open DLRs > > > > Hi Nikos > > > Thanks for your reply. That is the impression that I got. The only thing > that is a little confusing right now is that I am not seeing the temporary > DLRs in the MySQL table ever being removed. I am using SMPP and am testing > by sending to an actual SMSC and I am getting the message on my handset. I > see the submit_sm and submit_sm_resp in the logs. But no where do I see any > deliver_sm in the logs. Do I need to specify anything extra when calling the > sends_sms URL? (I didn't see any additional parameters in the user guide). I > have waited a couple of hours after I received the SMS on my handset and > still nothing from the SMSC and the DLRs are still in the table. > > > Last question: How does Kannel do the lookup to remove the DLR once it is > received? Does it use the smsc and the ts fields assuming you are using > SMPP? > > > Regards, > > > > 2010/6/30 Nikos Balkanas <[email protected]> > > Hi, > > The documentation is correct. DLR entries (internal to kannel but without > final status) are created and inserted when the SMS is accepted by the SMSc > and deleted when the external DLR (with final status) arrives from the SMSc. > This could last for the time it takes to deliver the SMS to the mobile. It > could be anything from a few minutes to a couple of days. If DLRs are in > memory, bb is restarted, and the final DLR from the SMSc is still pending, > the entries will be erased from memory. The result is that when the external > status DLR arrives from the SMSc, there is no corresponding entry to match > in kannel, and discarded. This doesn't happen if you use a DB for > dlr-storage. > > The DLR tables are to be used only internally by kannel. You can see the > DLR from bb access logs and you can even store it in your external web > application by specifying a dlr-url to your push SMS. You will have to > supply a msg-id to that dlr-url, unique for each MT, since msgid is internal > to kannel and not sent over the dlr-url. > > For more info read User's Guide. > > BR, > Nikos > > ----- Original Message ----- From: brett skinner > To: [email protected] > Sent: Wednesday, June 30, 2010 10:44 AM > Subject: Open DLRs > > > > Hi > > > Reading through the documentation I came across this statement: > > > This is problematic if bearerbox crashes or you take the process down in a > controlled way, but there are still DLRs open. Therefore you may use > external DLR storage places, i.e. a MySQL database. > > > Does that mean that the MySQL is temporary storage and that at some point > when the DLR is deemed to be closed that the row will be removed? If so then > > > When is a DLR closed? > Should we be using the MySQL table to get extra information about the DLR? > If not what should we be using? > Can we get Kannel to send us information about the fields in the DLR in the > URL. Such as message_id field from submit_sm_resp? > Thank you. I really appreciate all the help. >
