Hi,
do I understand right that Claro use GET for MO and XML Post for DLR?
Thanks,
Alex
Am 23.06.2009 um 17:59 schrieb Franck LAMASUTA:
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>
