Re: [PATCH] orig DLR bitmask passing back via DLR msg

Stipe Tolj <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Organization Kannel Software Foundation (KSF)
Message-ID <[email protected]>
Am 13.07.2015 17:50, schrieb Alexander Malysh:
> Hi Stipe,
>
> first of all I don’t get the intension for this feature? Please explain.

Hi Alex,

the intention was actually explained, let me enroll here. When the DLR 
gets back to an smsbox application, we get "only" the DLR event itself, 
i.e. DLR_SMSC_SUCCESS. Now the smsbox application needs to compare this 
to the original msg DLR bitmask to decide if there is any action to be 
taken, i.e. proxy this DLR to the downstream application or not. For 
this, the smsbox application needs to locally store the orig msg DLR 
mask. IF we would provide that orgi msg DLR mask in the DLR event msg 
itself, the smsbox application doesn't need any temporary storage and 
retrieval, since this is performed already logically from the DLR 
storage in bearebox.

I hope this shades some light on the intention ;)

> Even if we should forward back original dlr_mask of message, we should not do it in dlr group
> because original dlr_mask has nothing todo with dlr. Maybe create a new group ‚orig_msg‘ and
> put it inside but not in dlr group.

hm, I disagree here. The DLR is literally correlated to the DLR bitmask. 
If the bitmask wouldn't have been set, there would be no DLR event itself.

To go into your direction, I would suggest keeping it in the 'dlr' 
group, but renaming the field to 'msg_dlr_mask' to indicate this was the 
mask of the original message.

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

Kannel Foundation                 tolj.org system architecture
http://www.kannel.org/            http://www.tolj.org/

mailto:stolj_{at}_kannel.org      mailto:st_{at}_tolj.org
-------------------------------------------------------------------
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.