Re: A DLR question

Andreas Fink <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <p05101203b8967cc9edb7@[193.53.0.55]>
>Hi list.
>
>I've got into some problems trying to implement DLRs for a module I'm
>writing. Kannel supports five DLR typs : accepted, rejected, buffered,
>accpeted by the SMSC and rejected by the SMSC. now I assume that the DLR
>entry should persist until a final state is achieved, that is -
>rejection (any which) or "accepted", but the DLR delete logic, as I see
>in the source files is like this :
>
>    if((typ & DLR_BUFFERED) &&
>    	((dlr_mask & DLR_SUCCESS) || (dlr_mask & DLR_FAIL)))
>	{
>	// don't delete
>	} else {
>	// delete
>	}
>that means that if I try to send DLR on anything except "buffered" - the
>DLR for that message will be lost. I don't think this is correct, as I
>am also implementing the SMSC_* type DLRs, and when a SMSC_SUCCESS is
>sent, I don't want the DLR to be deleted.


The issue here is that the code in dlr.c does NOT deal with SMSC_* 
type of DLRs. They are done directly in the driver. dlr.c does only 
handle messages which need to be stored a refrence ID temporarely.

Example:

- you send a message with full dlr enabled over EMI.
- EMI code sends message to SMSC and generates SMSC_SUCCESS if SMSC 
sends ACK or SMSC_FAIL if SMSC sends NACK.
- if it was ACK, it wil then call dlr.c functions to add the SMSC 
message ID to the databse. When the SMSC comes back with delivered or 
failed (note: this is not accepted or rejected but delivered to the 
phone or rejected due to wrong number, not reachable and expired or 
similar), the dlr.c code gets called again to get the corresponding 
URL back to be called by passing the reference number originally 
received in the ACK.


-- 

Andreas Fink
Fink-Consulting

------------------------------------------------------------------
Tel: +41-61-6932730 Fax: +41-61-6932729  Mobile: +41-79-2457333
Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland
E-Mail:  [email protected]  Homepage: http://www.finkconsulting.com
------------------------------------------------------------------
Something urgent? Try http://www.smsrelay.com/  Nickname afink
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.