Submit_sm_resp is originated on the SMSc. Therefore it, is sent over the
Receiver. Where does it say on the SMPP spec that responses are transmitted
differently than requests?
Nikos
----- Original Message -----
From: brett skinner
To: [email protected]
Sent: Thursday, July 01, 2010 3:23 PM
Subject: Re: Open DLRs
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.
