On Wed, 17 Nov 2004, Rodrigo A. Cremaschi wrote:
I support the idea of retrieving the message_id as a proof the message was
handled to the SMSC. When we cannot use DLR's, due to an added traffic cost
for the SMSC, this is a near perfect solution for an ESME. I suggest simply
logging the message_id, no need to be part of the DLR mechanism.
Well, I don't know how you would be able to store it otherwise, except in
the log files. Frankly I'd rather have both (put the message ID in the
log file as well as pass it back via the DLR).
Right now I:
1. Queue the message by putting the info into a table in my DB.
2. Grab the row in the db and attempt delivery.
3. If successful, I get a DLR generated by Kannel which passes back a
DLR value of 8 (queued successfully).
4. If not successful, I get a DLR of 16 generated by kannel which tells
me that the message was rejected by my SMSC and why.
5. When the DLR is called, I update my table row with the important
information about that message.
If the kannel-generated DLR report was able to include the remote message
ID, I could update my table row with that information, creating a
permanant record of the SMSC message ID to my internal message ID,
enabling troubleshooting of a single message to be MUCH easier.
Right now kannel generates its own DLR report upon success or failure of
the message being sent to the SMSC (since the SMSBOX has accepted it
already as at least being a valid looking message).
That is where I would want to see the message_ID passed (if the message
was accepted/queued). On DLR reports generated by actual delivery
receipts from the carriers/aggregators, the message_ID would be blank,
allowing up to deal with it how you will in your own DLR php script.
Currently %m is not used -- I propose making the %m the Escape Code.
Beckman
----- Original Message -----
From: "Peter Beckman" <[EMAIL PROTECTED]>
To: "kannel users list" <[EMAIL PROTECTED]>
Sent: Tuesday, November 16, 2004 9:15 PM
Subject: Retrieving the SMSC Message ID for a queued message
There's been a lot of talk on the list about DLRs, delivery reports,
dlr-urls, dlrurls, etc. One thing I find sorely missing from the
functionality of the delivery report is the SMSC's message ID.
I give you an example:
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: SMPP PDU 0x8122a00 dump:
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: type_name: submit_sm_resp
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: command_id: 2147483652 =
0x80000004
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: command_status: 0 = 0x00000000
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: sequence_number: 63 = 0x0000003f
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: message_id: "1234abcd"
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: SMPP PDU dump ends.
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: DLR[internal]: Adding DLR
smsc=xxxxx, ts=1234abcd, src=12345, dst=12345678910, mask=31, boxc=default
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: SMSC[xxxxx]: creating DLR message
2004-11-16 xx:xx:xx [xxxxx] [x] DEBUG: SMSC[xxxxx]: DLR =
http://xxx.xxx/dlr.php?smsid=xxx&time=%t&to=%P&type=%d&smscr=%A&msgno=%I&resp=%a
I want 1234abcd to be passed back to be.
In this message, I didn't see anything that would lead me to believe that
the message_id passed back by my SMPP friend is able to be grabbed via
DLR.
Am I wrong? Or doesn't it exist?
Internally I'm tracking my messages via smsid that I pass via the DLR.
Beckman
--------------------------------------------------------------------------
-
Peter Beckman Internet
Guy
[EMAIL PROTECTED]
http://www.purplecow.com/
--------------------------------------------------------------------------
-
Este mensaje se dirige exclusivamente a su destinatario y puede contener
informaci�n CONFIDENCIAL sometida a secreto profesional o cuya divulgaci�n
est� prohibida en virtud de la legislaci�n vigente. Si ha recibido este
mensaje por error, le rogamos que nos lo comunique inmediatamente por esta
misma v�a o por tel�fono (54.11 5776-5000) y proceda a su destrucci�n.
N�tese que el correo electr�nico v�a Internet no permite asegurar ni la
confidencialidad de los mensajes que se transmiten ni la correcta recepci�n
de los mismos. En caso de que el destinatario de este mensaje no
consintiera la utilizaci�n de correo electr�nico v�a Internet rogamos lo
ponga en nuestro conocimiento de manera inmediata.
---------------------------------------------------------------------------
Peter Beckman Internet Guy
[EMAIL PROTECTED] http://www.purplecow.com/
---------------------------------------------------------------------------
