[PATCH] Pass meta-data from message to dlrs

Alejandro Guerrieri aguerrieri at kannel.org
Thu Sep 3 21:13:56 CEST 2009


Oh, I see, I've attached the ~ backup file from vim. This are the  
right files, just in case:


--
Alejandro Guerrieri
aguerrieri at kannel.org



On 03/09/2009, at 21:06, Alejandro Guerrieri wrote:

> Oh, that must have filtered into the patch. Weird :P
>
> Sorry, it's safe to remove it.
>
> Regards,
> --
> Alejandro Guerrieri
> aguerrieri at kannel.org
>
>
>
> On 03/09/2009, at 20:56, Gustavo Mohme C. wrote:
>
>> Hi Alejandro,
>> I get this error after applying your patch.
>>
>> gw/dlr.c: In function ‘dlr_add’:
>> gw/dlr.c:352: error: ‘struct dlr_entry’ has no member named  
>> ‘meta_data’
>> make: *** [gw/dlr.o] Error 1
>>
>> After editing /gw/dlr_p.h and adding meta_data to the struct  
>> dlr_entry, it compiled with no complaints. Is this the correct  
>> thing to do?
>> I was patching the latest kannel snapshot....
>> Thanks,
>> Gustavo
>>
>> On Thu, Sep 3, 2009 at 3:39 AM, Alejandro Guerrieri <aguerrieri at kannel.org 
>> > wrote:
>> 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
>> aguerrieri at kannel.org
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.kannel.org/pipermail/devel/attachments/20090903/f68a92c2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kannel-dlr-command-status.diff
Type: application/octet-stream
Size: 899 bytes
Desc: not available
URL: <http://www.kannel.org/pipermail/devel/attachments/20090903/f68a92c2/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.kannel.org/pipermail/devel/attachments/20090903/f68a92c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kannel-dlr-meta-data.diff
Type: application/octet-stream
Size: 1146 bytes
Desc: not available
URL: <http://www.kannel.org/pipermail/devel/attachments/20090903/f68a92c2/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.kannel.org/pipermail/devel/attachments/20090903/f68a92c2/attachment-0002.html>


More information about the devel mailing list