Hi, sorry for delay (too high workload :()
no this new feature (note not a bug fix) was not commited to cvs yet... it will be posted to devel ML and then commited if no objections would be there (I will try to get some spare time to extract this from my tree hopefully this weekend)... Matthew Hixson wrote: > Just wondering if the message_id DLR parameter fix has been checked > into CVS. If not does anyone know when this might be available? I'm > happy to test it for you. > -M@ > > On Feb 1, 2005, at 1:10 PM, Hillel Bilman wrote: > >> 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@ >> >> -- Thanks, Alex
