I know what you are saying now. Go for it. Better forensics is always good. 
Sometimes I feel like csi.



On Sep 19, 2008, at 8:30 AM, "Alejandro Guerrieri" <[EMAIL 
PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:

No, we're talking about getting the carrier's message id into the equation.

The internal ID is enough in much cases, but if you need to discuss with the 
carrier about a particular MT message, having "their" message ID as well helps 
a lot. You'll still need you internal ID of course: you cannot guarantee that 
the carrier will send you unique identifiers, for example. Relying on third 
parties for your own unique ID's is a very bad idea IMHO.

This is not by any means intended to replace the internal ID, just to 
complement it for the people that may need to track the carrier's message ID.

Regards,

Alejandro

On Fri, Sep 19, 2008 at 12:09 PM, Christian Jensen <<mailto:[EMAIL 
PROTECTED]>[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
I always put my internal id as a parameter in the dlr url. Is this the same 
thing you guys are talking about? Tracking your own mt messages?

________________________________
From: Alejandro Guerrieri <<mailto:[EMAIL PROTECTED]>[EMAIL 
PROTECTED]<mailto:[EMAIL PROTECTED]>>
Sent: September 19, 2008 6:42 AM
To: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> 
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>
Cc: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> 
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>
Subject: Re: [PATCH] message_id from submit_sm_response on DLR's

Kannel uses the message_id internally to track DLR's (otherwise it would be 
impossible to hit the same record twice).

The message_id translates to the "ts" field on the DLR table, my patch only 
makes that field visible on the dlr scope so it can be stored elsewhere (e.g. a 
"sent" table).

What you propose is regarding MO? Of course there's no DLR's for MO (you don't 
need  a delivery report over a message you've just received, do you? ;) ).

For MO, the only way I know to track the carrier's ID is the 
"receipted_message_id" TLV, and you should be able to read it by using the 
meta-data patch.

Check the SMPP 3.4 specs and/or ask your carrier for proper values (afaik, the 
tag address is 0x001E and max length is 65 octet-strings, but YMMV).

Regards,

Alejandro

On Fri, Sep 19, 2008 at 3:24 AM, Ken Bellars <<mailto:[EMAIL PROTECTED]>[EMAIL 
PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
Hi Alejandro,

This is coming just at the right time for us. It will definitely help
us keep track of specific messages sent. Also, i was wondering if
there is a way the messages id can be known (or sent back to the url)
once the sms has been sent to Kannel!

If this is possible, then upon sending, the sender can keep track of
the message id, and also update same when Kannel hits the dlr-url
again.

On 9/19/08, Alejandro Guerrieri <<mailto:[EMAIL PROTECTED]>[EMAIL 
PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:
> Hi,
>
> Proposed patch adds support for the "%w" key on DLR's, to get the message_id
> from the SMSC on SMPP connections.
>
> Explanation: When Kannel sends an MT over an SMPP connection, a submit_sm
> PDU is sent. The carrier responds with a submit_sm_response, carrying a
> "message_id" attribute. If we have  proper dlr-mask set, this event (the
> carrier accepting the message) causes Kannel to hit the dlr-url (even if the
> carrier's not sending DLR's).
>
> After applying the patch, a new parameter %w could be added to the dlr-url,
> which will be loaded with the message_id from the SMSC. This can be useful
> to correlate sent messages with the carriers response.
>
> Here's the patch:
>
> <http://www.magicom-bcn.net/kannel/smpp-response-message-id.patch> 
> http://www.magicom-bcn.net/kannel/smpp-response-message-id.patch
>
> Regards,
>
> Alejandro
>


--
Regards,
Kenny


"Whosoever desires constant success must change his conduct with the
times."-Niccolo Machiavelli


Reply via email to