Yes you do! It seems strange but this is the truth as far as I know. However, I can't check MO yet because I'm still waiting for Claro to setup our account for MO... But I do make my tests with MT and DLR and I confirm that DLRs are transmitted with a POST.
Franck > -----Original Message----- > From: Alexander Malysh [mailto:malys...@googlemail.com] On > Behalf Of Alexander Malysh > Sent: Wednesday, June 24, 2009 11:20 AM > To: f.lamas...@cobratelematics.com > Cc: devel@kannel.org > Subject: 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> > > >
