I notice this issue keep boomeranging,lol Maybe its time Kannel decides to implement support directly, rather than relying on dlr-url being provided with each sendsms (ie more msg overhead). We have since almost when starting our use of Kannel, added a int (4bytes) to the Msg structure, so the sendsms has just one extra parameter [ &transactionid=nnnnnn] Someone piped up last time with BS about memory use, hahaHaHa, if you store a dlr-url for each mesg, what is that? We exclusively use the service definitions for the dlr-url. Also the other boon is that when debugging, it is very very simple to discover which message i am at, because this tid value is right there..... Also wherever debugging and its relevant, the debug is adorned with the tid value printed, and the access logs. So easy to track messages, from sendsms, right thru to dlrs, back in your application. Also printing just one number ie [tid:nnnnn] far easier on the eye and parsing than always printing out a messy dlr-url and finding your unique part in that!!!
Please consider.......... ----- Original Message ----- From: "Stipe Tolj" <[EMAIL PROTECTED]> To: "Ben Suffolk" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, October 10, 2006 3:02 AM Subject: Re: Msg-id for tracking in Kannel 1.4.1 > Ben Suffolk wrote: > > > Sunil, > > > > This is possible, by you creating a unique ID and passing it as part of > > the dlr-url parameter. > > > > That is if you dlr-url was http://localhost/dlr.phpstatus=%d for > > instance, you would make it something like > > > > http://localhost/dlr.phpstatus=%d&uid=1234 > > > > Where you changed the uid on each message submission. This mean you > > have to padd the dlr-url with the submit,a s opposed to having it in > > the config file. > > Ben is right here. > > Kannel has internal UUIDs for messages, but does not provide them to the caller > layer (HTTP client calling sendsms interface). > > Reason: we allow flexibility to letting the caller define the UID from the > "outside" by the construct Ben describes for handling DLR-URLs. > > BTW, please refer to the user's guide for some more information on DLR handling. > > Stipe > > ------------------------------------------------------------------- > Kölner Landstrasse 419 > 40589 Düsseldorf, NRW, Germany > > tolj.org system architecture Kannel Software Foundation (KSF) > http://www.tolj.org/ http://www.kannel.org/ > > mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org > ------------------------------------------------------------------- >
