Problem "a" could be easily solved by using a patch I've proposed that
allows you to pass parameters on your get-url's by using individual
meta-data values.
That would fix the limitations towards parameters not being present
(charge, timestamp, charset or anything you need to pass from send-sms
or any SMSC):
http://www.blogalex.com/archives/182
[Nobody ever replied to it]
For example, your get-url would become:
http://host:port/my-script/?.....&charge=%#http#charge#×tamp=
%#http#timestamp#&charset=%#http#charset#
The format is %#group#parameter#
Then, when using send-sms to send a message, you should pass those
parameters as meta-data on the "http" group (urlencoded of course):
?http?charge=1×tamp=20090623123456&charset=whatever
I'm successfully using it to pass specific TLV parameters from SMPP
binds to http services (on that case, I'm using "smpp", but here you
could use whatever you want instead of "http", I'm just using
something meaningful).
Regarding the rest of the parameters, it's starting to get overly
complicated, but I do see your point. Perhaps we should identify
recurring missing elements among different implementations and try to
establish a method as simple as possible. The names should be self-
describing as well.
Something that would simplify things would be to have some sort of
"service definition" group, just like modems.conf does for at modems,
where you define "templates" for http-smsc's and then from the conf
file you just have to invoke a template (and modify whatever needs to
be modified from the original template, overwriting the defaults
inherited from there). Just a thought...
Regards,
--
Alejandro Guerrieri
[email protected]
On 23/06/2009, at 17:59, Franck LAMASUTA wrote:
Hi all,
I'm still trying to use the generic code for our Claro HTTP
connection...
The attached table describes how it works currently with all
protocols. It highlights some issues.
a) Clickatell variables
This protocol uses some variables which are not available in the
generic part: "charge", "timestamp" and "charset".
I don't know if there is a good reason to manage "charge" for a DLR.
If yes, it is easy to use "binfo" in the generic DLR code to do the
same thing.
I think "timestamp" is not so useful, it is replaced in all the
other cases by the current time.
Finally, "charset" is simply stored in sms.charset but not actually
used in clickatell_receive_sms().
b) Claro DLR
Claro sends a DLR with a HTTP POST and puts the relevant data in XML
format in the body (see attached file).
Currently, in the generic code, all the variables are read from CGI
variables coming from the GET query. It is compatible with all
previous specific protocols but not with Claro.
I would like to manage a bunch of new configuration variables
(generic-source-xxx, one per generic-param-xxx) to specify if the
value should be read from the CGI variable or from the body.
For example, if generic-source-to = "body", then generic-param-to
will be processed as a regex and a gw_regexec() will be done against
the body (exactly like I did for the generic-foreign-id-regex
variable in the last patch) to get the recipient's number.
If these new variables are not defined in the configuration file,
the current behaviour will be kept.
c) DLR status
The status is translated for Clickatell and Xidris protocols:
Clickatell:
4 or 8 => DLR_SUCCESS
1, 5, 6, 7, 9 or 10 => DLR_BUFFERED
2, 3 or 11 => DLR_FAIL
else => DLR_SMSC_FAIL
Xidris:
"DELIVERD" => DLR_SUCCESS
"ACCEPTD" => DLR_BUFFERED
else => DLR_FAIL
The status should also be translated for Claro (from SMPP status).
To solve the problem, 3 new configuration variables could me
managed...
For Clickatell they should be defined like this:
generic-dlr-mask-external = "1;2;3;4;5;6;7;8;9;10;11"
generic-dlr-mask-internal =
"BUFFERED
;FAIL
;FAIL
;SUCCESS;BUFFERED;BUFFERED;BUFFERED;SUCCESS;BUFFERED;BUFFERED;FAIL"
generic-dlr-mask-defaut = "SMSC_FAIL"
For Xidris they should be defined like this:
generic-dlr-mask-external = "DELIVERD;ACCEPTD"
generic-dlr-mask-internal = "SUCCESS;BUFFERED"
generic-dlr-mask-defaut = "FAIL"
A one-to-one translation could be done from an external value to get
the matching internal value.
If no match is found in the external list, the default value is used.
If these lists are not defined, no translation is done (current
behaviour for "dlr-mask").
That's all...
Any comments or better ideas are welcome! ;)
Franck<http_xxx_receive_sms.pdf><Claro_DLR_body.xml>
