Re: [PATCH] Pass meta-data from message to dlrs

Gustavo,

No, that wouldn't work.

In fact, you don't need to pass the value on the url. You need to pass  
the dlr-url with the %D parameter and kannel will get you back the ? 
smpp?dlr_status=X part on the dlr that is created when the carrier  
accepts (or rejects) your submit_sm.

In other words, you'd craft your sendsms like this:

http://localhost:13013/cgi-bin/sendsms?username=kannel&password=kannel&from=12345&to=12345678&smsc=mysmsc&text=Hello&dlr-mask=31&dlr-url=http%3A%2F%2Flocalhost%2Fmyapp%3Fmetadata%3D%25D

And kannel will call back the dlr-url, with the %D parameter loaded  
with the meta-data.

http://localhost/myapp?metadata=%3Fsmpp%3Fdlr_status%3D69%26

"69" may change depending on the command_status value of course.

Regards,
--
Alejandro Guerrieri
[email protected]



On 03/09/2009, at 19:32, Gustavo Mohme C. wrote:

> Hi Alejandro,
> This is great. It was exactly what we need. I have one question  
> though: what if we need to "watch" for several command-status  
> values, each one meaning a different thing(predefined by the SMSC of  
> course). Would it be valid to call the url in this way?
> ?smpp?my_own_field=1234&dlr_status=69&dlr_status=70&dlr_status=71&....
>
> Thanks,
> Gustavo
>
> On Thu, Sep 3, 2009 at 3:39 AM, Alejandro Guerrieri <[email protected] 
> > 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
> [email protected]
>
>
>
>
>
>
>
>
>