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

Sorry Alex,

#1 You know that better than me. No.

One more question. Is meta-data available always or you need to first define 
tlvs? This reflects to command-status availability.

Nikos
----- Original Message ----- 
From: "Alejandro Guerrieri" <[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, September 03, 2009 9:30 PM
Subject: Re: [PATCH] Pass meta-data from message to dlrs


> For #1, does any other smscs implement meta-data already?
>
> For #2, command_status is an smpp specific parameter, it's meaningless  on 
> other smscs.
>
> Regards,
> --
> Alejandro Guerrieri
> [email protected]
>
>
>
> On 03/09/2009, at 20:21, Nikos Balkanas wrote:
>
>> Hi Alex,
>>
>> Looks good, but should it be limited only to smpp? What about other 
>> smscs?
>>
>> BR,
>> Nikos
>> ----- Original Message ----- From: "Alejandro Guerrieri" 
>> <[email protected]
>> >
>> To: "Kannel Devel" <[email protected]>
>> Sent: Thursday, September 03, 2009 11:39 AM
>> Subject: [PATCH] Pass meta-data from message to dlrs
>>
>>
>>> 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]
>>>
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>>
>>>
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>>
>>>
>>
>