Re: [PATCH] Meta-data support for SMPP resp PDUs

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

attached is the announced patch for this functionality.

Alex



Am 24.01.2014 um 09:54 schrieb Alexander Malysh <[email protected]>:

> Hi Stipe,
> 
> as usual I'm writing some critic for this patch. I do like this functionality BUT I don't like how this
> patch implemented, I don't like this _real don't _real functions because we have already to much of them
> and have to start to cleanup it. The second issue is with va_args where it's not needed and at this place it's
> not needed.
> 
> We have such patch at GTX and I will try to extract this from our sources this weekend but in a nutshell it works as follows:
> 
> * sent sms with dlr_mask SMSC_CONN_SUCCESS
> * submit_sm
> * submit_sm_resp -> pack TLVs into meta to the sent sms
> * bb_smscconn_(sent|failed) -> generate DLR  SMSC_SUCCESS and put meta_data from sent sms into resulting DLR
> * smsbox forward it to application
> 
> -> no complex va_args , no _real functions needed. This is then really clean.
> 
> Btw. The same technic we use for the HTTP , e.g. to pack all CGI params into meta_data for the later processing in the application.
> 
> Alex
> 
> 
> Am 21.01.2014 um 19:52 schrieb Stipe Tolj <[email protected]>:
> 
>> Hi list,
>> 
>> this is a patchset in reference to a request that Paulo Correia made in the users@ mailing list, [Msg-Id: <[email protected]>].
>> 
>> The basic idea is: in SMPP (and other protocols too), we may have meta-data parts (optional TLVs in SMPP) that we get on the "Sent SMS" event, hence in the submit_sm_resp PDU for SMPP. At the moment we don't have a construct to pass this meta-data in the corresponding intermediate DLR SMSC SUCCESS event that we pass to smsbox.
>> 
>> The attached patchset allows this at least for optional TLVs coming inside submit_sm_resp. I don't see a clean way to do this for the bind resp PDUs though.
>> 
>> The patchset SHOULD be not intrusive, adding only the feature and not changing any standard behavior. Please review and vote for commit.
>> 
>> Stipe
>> 
>> -- 
>> -------------------------------------------------------------------
>> Kölner Landstrasse 419
>> 40589 Düsseldorf, NRW, Germany
>> 
>> tolj.org system architecture      Kannel Software Foundation (KSF)
>> http://www.tolj.org/              http://www.kannel.org/
>> 
>> mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
>> -------------------------------------------------------------------
>> <smpp-resp-pdu-optional-tvls.diff>
>
smpp_resp_meta.patch (application/octet-stream, 2.6 KB)
diff --git a/gw/dlr.c b/gw/dlr.c
index c197b65..7dbd0ad 100644
--- a/gw/dlr.c
+++ b/gw/dlr.c
@@ -517,6 +517,7 @@ Msg* create_dlr_from_msg(const Octstr *smsc, const Msg *msg, const Octstr *reply
     dlrmsg->sms.boxc_id = octstr_duplicate(msg->sms.boxc_id);
     dlrmsg->sms.foreign_id = octstr_duplicate(msg->sms.foreign_id);
     time(&dlrmsg->sms.time);
+    dlrmsg->sms.meta_data = octstr_duplicate(msg->sms.meta_data);
 
     debug("dlr.dlr", 0,"SMSC[%s]: DLR = %s",
                 (smsc ? octstr_get_cstr(smsc) : "UNKNOWN"),
diff --git a/gw/smsc/smsc_smpp.c b/gw/smsc/smsc_smpp.c
index fa6a7ce..35c167c 100644
--- a/gw/smsc/smsc_smpp.c
+++ b/gw/smsc/smsc_smpp.c
@@ -598,7 +598,7 @@ static Msg *pdu_to_msg(SMPP *smpp, SMPP_PDU *pdu, long *reason)
              * So we just look decoded values from dcs_to_fields and if none there make our assumptions.
              * if we have an UDH indicator, we assume DC_8BIT.
              */
-            if (msg->sms.coding == DC_UNDEF && pdu->u.deliver_sm.esm_class & ESM_CLASS_SUBMIT_UDH_INDICATOR)
+            if (msg->sms.coding == DC_UNDEF && (pdu->u.deliver_sm.esm_class & ESM_CLASS_SUBMIT_UDH_INDICATOR))
                 msg->sms.coding = DC_8BIT;
             else if (msg->sms.coding == DC_7BIT || msg->sms.coding == DC_UNDEF) { /* assume GSM 7Bit , reencode */
                 msg->sms.coding = DC_7BIT;
@@ -785,7 +785,7 @@ static Msg *data_sm_to_msg(SMPP *smpp, SMPP_PDU *pdu, long *reason)
              * So we just look decoded values from dcs_to_fields and if none there make our assumptions.
              * if we have an UDH indicator, we assume DC_8BIT.
              */
-            if (msg->sms.coding == DC_UNDEF && pdu->u.data_sm.esm_class & ESM_CLASS_SUBMIT_UDH_INDICATOR)
+            if (msg->sms.coding == DC_UNDEF && (pdu->u.data_sm.esm_class & ESM_CLASS_SUBMIT_UDH_INDICATOR))
                 msg->sms.coding = DC_8BIT;
             else if (msg->sms.coding == DC_7BIT || msg->sms.coding == DC_UNDEF) { /* assume GSM 7Bit , reencode */
                 msg->sms.coding = DC_7BIT;
@@ -1746,6 +1746,12 @@ static int handle_pdu(SMPP *smpp, Connection *conn, SMPP_PDU *pdu,
             }
             msg = smpp_msg->msg;
             smpp_msg_destroy(smpp_msg, 0);
+
+            /* pack submit_sm_resp TLVs into metadata */
+            if (msg->sms.meta_data == NULL)
+                msg->sms.meta_data = octstr_create("");
+            meta_data_set_values(msg->sms.meta_data, pdu->u.submit_sm_resp.tlv, "smpp_resp", 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.