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@
