Hi, Alejandro's patch can be very useful as it gives flexibility to the Kannel user using HTTP and so +1 to have it in CVS.
By the way can you use POST if you would prefer to use it over GET? Rgds ---------------------------------------------------------------------- Date: Wed, 24 Jun 2009 00:53:10 +0200 From: Alejandro Guerrieri <[email protected]> Subject: Re: [PATCH] custom MO Parameters for smsc-http To: [email protected] Cc: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" 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> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.kannel.org/pipermail/devel/attachments/20090624/a463d72a/attachm ent
