Re: [PATCH] custom MO Parameters for smsc-http

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>