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@






Reply via email to