You write - Currently %m is not used -- I propose making the %m the Escape Code.
This will be very useful for me as well. However, someone has to write the kannel code to get this to work - anyone out there who will do it and then add new changes to the Kannel source? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Beckman Sent: Wednesday, November 17, 2004 11:23 AM To: Rodrigo A. Cremaschi Cc: kannel users list Subject: Re: [Kannel-Users] Re: Retrieving the SMSC Message ID for a queuedmessage 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&res p=%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/ ---------------------------------------------------------------------------
