Re: [PATCH] orig DLR bitmask passing back via DLR msg
Am 16.07.2015 15:45, schrieb Stipe Tolj:
Am 16.07.2015 14:15, schrieb Alexander Malysh:
I disagree to put it in dlr group because it has nothing with dlr
todo. To dlr group belongs submittime/donetime/errorcode etc. (means
any metadata that are DLR specific)
but original message is not related to DLR. If we think further about
your idea to put it in DLR group then if we want to keep e.g. message
body (don’t know the reason now
but just as example) then we will have message in DLR group? Sorry it
makes not sense for me.
ok, then let's do 'orig_msg' group, where we CAN eventually put any
value that has been passed at MT time. That's ok with me.
I don't want to stress the msg field passing back anyway, but orig DLR
bitmask is there in the DLR storage and can have a significant value
being passed back. So, let's keep it this way.
committed to svn trunk.
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
---
Re: [PATCH] orig DLR bitmask passing back via DLR msg
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
---
Re: [PATCH] orig DLR bitmask passing back via DLR msg
Hi Stipe,
Am 16.07.2015 um 12:09 schrieb Stipe Tolj st...@kannel.org:
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 ;)
ok, got it...
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.
I disagree to put it in dlr group because it has nothing with dlr todo. To dlr
group belongs submittime/donetime/errorcode etc. (means any metadata that are
DLR specific)
but original message is not related to DLR. If we think further about your idea
to put it in DLR group then if we want to keep e.g. message body (don’t know
the reason now
but just as example) then we will have message in DLR group? Sorry it makes not
sense for me.
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
---
Re: [PATCH] orig DLR bitmask passing back via DLR msg
Am 16.07.2015 14:15, schrieb Alexander Malysh:
I disagree to put it in dlr group because it has nothing with dlr todo. To dlr
group belongs submittime/donetime/errorcode etc. (means any metadata that are
DLR specific)
but original message is not related to DLR. If we think further about your idea
to put it in DLR group then if we want to keep e.g. message body (don’t know
the reason now
but just as example) then we will have message in DLR group? Sorry it makes not
sense for me.
ok, then let's do 'orig_msg' group, where we CAN eventually put any
value that has been passed at MT time. That's ok with me.
I don't want to stress the msg field passing back anyway, but orig DLR
bitmask is there in the DLR storage and can have a significant value
being passed back. So, let's keep it this way.
Stipe
--
Best Regards,
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
---
Re: [PATCH] orig DLR bitmask passing back via DLR msg
Hi Stipe,
first of all I don’t get the intension for this feature? Please explain.
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.
Alex
Am 10.07.2015 um 14:44 schrieb Stipe Tolj st...@kannel.org:
Hi list,
at the moment we don't pass back the original set bitmask when a DLR msg-sms
is send back to an smsbox connection, we just set the actual DLR even bit
in msg-sms.dlr_mask.
I would like to add the original DLR bitmask that was set when MT was
processed in the msg-sms.meta_data part, group 'dlr', name 'dlr_mask', to
allow smsbox applications to retrieve this information without the need to
locally store temporary data.
Please review and vote for committing.
--
Best Regards,
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
---
dlr-orig-bitmask.diff
[PATCH] orig DLR bitmask passing back via DLR msg
Hi list,
at the moment we don't pass back the original set bitmask when a DLR
msg-sms is send back to an smsbox connection, we just set the actual
DLR even bit in msg-sms.dlr_mask.
I would like to add the original DLR bitmask that was set when MT was
processed in the msg-sms.meta_data part, group 'dlr', name 'dlr_mask',
to allow smsbox applications to retrieve this information without the
need to locally store temporary data.
Please review and vote for committing.
--
Best Regards,
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
---
Index: gw/dlr.c
===
--- gw/dlr.c(revision 5138)
+++ gw/dlr.c(working copy)
@@ -91,6 +91,7 @@
#include sms.h
#include dlr.h
#include dlr_p.h
+#include meta_data.h
/* Our callback functions */
static struct dlr_storage *handles = NULL;
@@ -386,6 +387,7 @@
Msg*msg = NULL;
struct dlr_entry *dlr = NULL;
Octstr *dst_min = NULL;
+Octstr *dlr_mask;
if(octstr_len(smsc) == 0) {
warning(0, DLR[%s]: Can't find a dlr without smsc-id, dlr_type());
@@ -438,6 +440,17 @@
* route this msg back to originating smsbox
*/
O_SET(msg-sms.boxc_id, dlr-boxc_id);
+/*
+ * We will provide the DLR request bitmask in the DLR going back
+ * to the smsbox connection for processing. This allows smsbox
+ * connection type applications to avoid temporary storing and
+ * resolving data to pull up this information.
+ */
+dlr_mask = octstr_format(%ld, dlr-mask);
+msg-sms.meta_data = octstr_create();
+meta_data_set_value(msg-sms.meta_data, METADATA_DLR_GROUP,
+octstr_imm(METADATA_DLR_GROUP_BITMASK), dlr_mask,
1);
+octstr_destroy(dlr_mask);
time(msg-sms.time);
debug(dlr.dlr, 0, DLR[%s]: created DLR message for URL %s,
Index: gw/meta_data.h
===
--- gw/meta_data.h (revision 5138)
+++ gw/meta_data.h (working copy)
@@ -69,6 +69,7 @@
#define METADATA_DLR_GROUP_DONETIME donetime
#define METADATA_DLR_GROUP_SUBMITTIME submittime
#define METADATA_DLR_GROUP_ERRORCODE errorcode
+#define METADATA_DLR_GROUP_BITMASKdlr_mask
#define METADATA_SMPP_GROUP smpp
