Hi, Would you still keep the sms.id as a DLR parameter as it's useful independent of the message_id, and add another parameter like the sms.id such as messageId, which can be used for the actual message_ids.
Thanks -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matthew Hixson Sent: Friday, January 28, 2005 9:46 PM To: [email protected]; Alexander Malysh Subject: Re: [Kannel-Devel] SMS message ids in DLR reports generated by Kannel On Jan 28, 2005, at 5:19 AM, Alexander Malysh wrote: >> What needs to be done is either: >> 1) Make the bearerbox add the dlr->ts field into the SMS Msg >> structure >> which is passed to the smsbox. Then the smsbox can forward that >> information via the dlr-url. >> OR >> 2) Link the sms.id (the newly added UUID for each SMS) to the >> dlr->ts by storing the sms.id in the dlr_entry. Then, when a >> DLR SMS is received that matches the message-id (i.e. dlr->ts), >> the DLR SMS sms.id is replace with the sms.id coming from the >> dlr_entry. Add a new function to the bearerbox (or create another >> box) which provides the sms.id -> dlr-ts functionality and >> then the smsbox can now return the message-id (or dlr->ts as >> referenced by the source code). >> >> The first option is easiest to implement but provides less future >> functionality (I'll get to that in a minute) as well as increases >> the size of the SMS Msg structure. >> >> The second option would provide alot more flexibility by creating >> a new function that could be used by external systems to lookup >> the mapping of sms.id to their message-id. At the same time, >> performance >> would not be hindered since the looks would only occur if the dlr-url >> requested the message-id information. For, option 2, I envision >> a system that could return the sms.id for an MT SMS. Then, the >> person holding the sms.id can query an xxxbox that can return >> the current status of the SMS because it can be mapped to >> the DLR. >> >> I've started outlining the necessary changes to implement option 2 >> already. If everyone thinks it's a bad idea and wants to implement >> option 1 then I can reverse gears and start working on that one. >> >> Opinions? > > I'm +1 for option 2 and it's already implemented in my private tree. > so I > would propose not to do double work and just be a bit patient... Hi Alex, when do you think you might check this in and what would you like on your pizza? Thanks, -M@
