Re: messageid DLR parameter

Stipe Tolj wrote:

> Alexander Malysh wrote:
> 
>> Hi Davy,
>> 
>> Davy Chan wrote:
>> 
>> 
>>>1) Not everyone needs a DLR for every SMS sent.
>>>2) This solutions would force the SMS Msg struct passed back and forth
>>>   between the bearerbox and the smsbox to increase in size with
>>>   data that might not be relevant.
>>>3) This solution cannot be abstracted and used for all SMSC interfaces
>>>   (unless all you want is the 'ts' field reported for every SMSC).
>>>4) Kannel is not ONLY an HTTP<->SMPP gateway...It is also HTTP<->CIMD,
>>>   HTTP<->EMI/UCP, HTTP<->SEMA, SMPP<->CIMD, SMPP<->EMI/UCP, SMPP<->SEMA,
>>>   CIMD<->EMI/UCP, CIMD<->SEMA. Therefore, adding SMSC protcol specific
>>>   things to the smsbox can hinder compatibility.
>>>
>>>Yes, it's easy to make a quick hack to add the message-id to the
>>>SMS Msg struct for people ONLY connected via SMPP. But, what about
>>>the others?
>> 
>> 
>> yep, you are right here...
> 
> +1.
> 
>>>Would it not be a better idea to implement some mapping system
>>>between the UUID and the DLR's? After all, you get the UUID
>>>upon submission of the SMS via the sendsms function. I was planning
>>>on implementing this but it appears Alex trumped me on it and is
>>>trying to move his implementation from his private source tree to Kannel.
>> 
>> 
>> the only I can say, I'm sorry but have no time at least this week to do
>> this, again sorry!!! Davy if you have time for it just do it, if not
>> please wait a bit... The idea is pretty simple:
>> 1) extend dlr table for uuid
>> 2) store uuid in the table (dlr.c) (for this task you must change all
>> dlr_XXX.c)
>> 3) in dlr.c::dlr_find if dlr found retrieve uuid from backend and copy it
>> into newly created dlr message id (extend all dlr_XXX.c)
>> 
>> so you then receive in dlr original uuid from the message sent.
>> 
>> p.s. please don't forget to update userguide and examples in doc/examples
>> ;)
> 
> which means Alex, you want to have the DLR MO message the *same* UUID as
> the orginal transported message?

right

> 
> This doesn't solve the problem about uniqueness for messages that are
> transported in the same second? right?

that was never my goal... and you will never solve this problem with some
protos like emi.

> 
> Stipe
> 
> mailto:stolj_{at}_wapme.de
> -------------------------------------------------------------------
> Wapme Systems AG
> 
> Vogelsanger Weg 80
> 40470 DÃŒsseldorf, NRW, Germany
> 
> phone: +49.211.74845.0
> fax: +49.211.74845.299
> 
> mailto:info_{at}_wapme-systems.de
> http://www.wapme-systems.de/
> -------------------------------------------------------------------

-- 
Thanks,
Alex