[PATCH] Pass meta-data from message to dlrs

Alejandro Guerrieri <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
Hi,

This is a set of two patches, though they're both very simple and  
could have been mixed, I've preferred to split to honor the rule of  
not mixing features in a single patch.

Patch #1, kannel-drl-meta-data.diff allows meta-data to be passed when  
sending a message to come back into the "fake" dlr that kannel  
generates when the smsc accepts or rejects a message. It could be  
extended to work with the different dlr engines so the meta-data would  
be also passed on the intermediate and final dlr's delivered by the  
carriers (though it would require changes on the database structure to  
add a "meta_data" column of course. I'm not sure this would be needed,  
the dlr-url could be easily abused to pass application-specific  
parameters without much hassle.

Patch #2, kannel-dlr-command-status.diff builds on top of patch #1 and  
creates a meta data value called "dlr_status" that comes back on the  
"fake" dlr generated by kannel (This was the real reason why patch #1  
was created). The value there is the "command_status" value some  
people on the list needs to get from the submit_sm_resp PDU's.

Example usage:

On sendsms:

http://localhost:13013/cgi-bin/sendsms?username=kannel&password=kannel&from=12345&to=12345678&smsc=mysmsc&text=Hello&dlr-mask=31&meta-data=%3Fsmpp%3Fmy_own_field%3D1234&dlr-url=http%3A%2F%2Flocalhost%2Fx%3Fdata%3D%25D

Notes:

meta-data is urlencoded version of: ?smpp?my_own_field=1234
dlr-url is urlencoded version of: http://localhost/x?data=%D

So, after applying Patch #1, kannel would call the following url:

http://localhost/x?md=%3Fsmpp%3Fmy_own_field%3D1234

The "md" parameter, once urldecoded would look like:

?smpp?my_own_field=1234

You can pass as many parameters as you want of course and they would  
be added to meta-data along with any other fields you've defined on  
your smpp-tlv groups, etc.

So far so good, in fact you could pass this kind of stuff on regular  
url variables, but the goal of this patch was to allow to add stuff  
back from the smsc's response.

Now, with patch #2 also applied, the url returned would be something  
like this:

http://localhost/x?md=%3Fsmpp%3Fmy_own_field%3D1234%26dlr_status%3D69%26

The "md" parameter, once urldecoded would look like:

?smpp?my_own_field=1234&dlr_status=69&

In this case, dlr_status gets loaded with submit_sm_resp's  
command_status which was: 69 = 0x00000045 (Submit Failed).

The "sequence_number" could be added just as easily (not a bad idea  
imho). What do you think? "dlr_sequence" or "dlr_seq" would be ok?

I'm writing the userguide patch if this goes forward of course.

Comments?

Regards,
--
Alejandro Guerrieri
[email protected]
kannel-dlr-meta-data.diff (application/octet-stream, 1.1 KB)
Index: gw/dlr.c
===================================================================
RCS file: /home/cvs/gateway/gw/dlr.c,v
retrieving revision 1.59
diff -u -r1.59 dlr.c
--- gw/dlr.c	4 May 2009 21:35:53 -0000	1.59
+++ gw/dlr.c	2 Sep 2009 23:38:11 -0000
@@ -349,6 +349,7 @@
     dlr->service = (msg->sms.service ? octstr_duplicate(msg->sms.service) : octstr_create(""));
     dlr->url = (msg->sms.dlr_url ? octstr_duplicate(msg->sms.dlr_url) : octstr_create(""));
     dlr->boxc_id = (msg->sms.boxc_id ? octstr_duplicate(msg->sms.boxc_id) : octstr_create(""));
+    dlr->meta_data = (msg->sms.meta_data ? octstr_duplicate(msg->sms.meta_data) : octstr_create(""));
     dlr->mask = msg->sms.dlr_mask;
 
     debug("dlr.dlr", 0, "DLR[%s]: Adding DLR smsc=%s, ts=%s, src=%s, dst=%s, mask=%d, boxc=%s",
@@ -480,6 +481,7 @@
     dlrmsg->sms.msgdata = octstr_duplicate(reply);
     dlrmsg->sms.boxc_id = octstr_duplicate(msg->sms.boxc_id);
     dlrmsg->sms.foreign_id = octstr_duplicate(msg->sms.foreign_id);
+    dlrmsg->sms.meta_data = octstr_duplicate(msg->sms.meta_data);
     time(&dlrmsg->sms.time);
 
     debug("dlr.dlr", 0,"SMSC[%s]: DLR = %s",
kannel-dlr-command-status.diff (application/octet-stream, 899 B)
Index: gw/smsc/smsc_smpp.c
===================================================================
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.123
diff -u -r1.123 smsc_smpp.c
--- gw/smsc/smsc_smpp.c	2 Sep 2009 13:10:50 -0000	1.123
+++ gw/smsc/smsc_smpp.c	2 Sep 2009 23:38:17 -0000
@@ -1593,6 +1593,11 @@
             }
             msg = smpp_msg->msg;
             smpp_msg_destroy(smpp_msg, 0);
+            if (msg->sms.meta_data == NULL)
+                msg->sms.meta_data = octstr_create("");
+            meta_data_set_value(msg->sms.meta_data, "smpp", octstr_imm("dlr_status"),
+                                octstr_format("%d", pdu->u.submit_sm_resp.command_status), 1);
+
             if (pdu->u.submit_sm_resp.command_status != 0) {
                 error(0, "SMPP[%s]: SMSC returned error code 0x%08lx (%s) "
                       "in response to submit_sm.",
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.