You only need to define it if:
1. You want to pass it as a parameter on sendsms.
2. It comes from an SMSC, so it doesn't really have a "name", only an
address, so you need to "name it".
In this particular case, since the meta-data value is defined on it's
way back to you, it will be available no matter if you defined it or
not.
Regards,
--
Alejandro Guerrieri
[email protected]
On 03/09/2009, at 20:46, Nikos Balkanas wrote:
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]
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
