Hi, please doesn't change kannel http mode. Please define new MO function for generic HTTP mode instead.
Alejandro Guerrieri wrote: > Hi, > > I've improved my patch and added extra flexibility. Now it's possible > to implement full clickatell functionality (including DLR's) by > properly configure the 'generic' http smsc. > > The patch is available here: > > http://magicom-bcn.net/kannel/full-mo-http-params-20070905.patch > > The patch allows for this new parameters on config: > > * This parameters allows to rename the proper MO parameters to > whatever you like: > > mo-from > mo-to > mo-text > mo-udh > mo-account > mo-binfo > mo-dlr-url > mo-dlr-mid > mo-flash > mo-mclass > mo-mwi > mo-coding > mo-validity > mo-deferred > mo-dlr-mask > mo-dlr-stat -> this special one allows you to rename the message_id > being returned by an external dlr confirmation, such as clickatell's > "status" parameter. > > For example, setting mo-from = whatever, then the "from" parameter > will be renamed "whatever". > > * This allows you to rename the return string the http generic smsc > returns: > > mo-ret-accepted > mo-ret-denied > mo-ret-unknown-dlr > mo-ret-missing-args > mo-ret-udh-mismatch > mo-ret-udh-long > mo-ret-auth-failed > mo-ret-dlr-accepted > mo-ret-dlr-denied > > For example, the mo-ret-accpeted allows you to change the "Sent." text > you get for anything else. > > Now comes the "new" features: > > id-from-reply -> When you send an MT message to an external http smsc > and you ask for a DLR, kannel "invents" a message_id. This parameters > allows you to get that message id from the external source, > effectively enabling the use of DLR's with clickatell. You must fill > this field with the text expected _before_ the message_id. In the case > of clickatell that's "ID:". So, if you get "ID:12345678" the > message_id will be "12345678". > > err-from-reply -> Same thing but for error id's. > > This 3 parameters allows you to map different external statuses to > kannel dlr statuses: > > dlr-success-regex -> maps to DLR_SUCCESS (0x08) > dlr-permfail-regex -> maps to DLR_BUFFERED (0x04) > dlr-tempfail-regex -> maps to DLR_FAILED (0x02) > > So, to implement clickatell's connectivity for MT and DLR's, you just > need to configure like this: > > group = smsc > smsc = http > system-type = generic > smsc-id = clicka > allowed-smsc-id = clicka > port = 15000 > send-url = > "https://api.clickatell.com/http/sendmsg?to=%p&from=%P&text=%b&api_id=NNNNNN&user=XXXXXX&password=PPPPPP&callback=3&deliv_ack=3&req_feat=8192"; > status-success-regex = "ID" status-permfail-regex = "ERR" > status-tempfail-regex = "TEMP" > mo-dlr-mid = apiMsgId > mo-dlr-stat = status > id-from-reply = "ID:" > err-from-reply = "ERR:" > dlr-success-regex ="(004|008)" > dlr-permfail-regex = "(001|005|006|007|009|010)" > dlr-tempfail-regex ="(002|003|011)" > > I'll explain a little more: > > send-url points to the clickatell http api. A few parameters are > hardcoded, like api_id, user/pass, etc. > status-*-regex (current kannel functionality) is used to detect > whether the message was accepted by clickatell's api. > > mo-dlr-* is used to map the DLR parameters to kannel's own. > > id/err-from-reply is used to fetch the message/error id on MT from > clickatell's http response. This is mandatory for DLR's only. > > dlr-*-regex is used to map the different possible responses to > different kannel DLR status. So, if kannel responds with "004" or > "008" a DLR Success will be sent (0x08 for Kannel). > > I don't have a two-way account for clickatell, so I couldn't test the > MO part, but it should be as simple as to map the proper parameters by > configuring mo-* parameters and maybe mapping some mo-ret-* strings > also. > > Last by not least, the goal of this patch wasn't to replace the > clickatell interface, but to provide a generic mean to implement other > SMSC's without writing source code and recompiling. The clickatell > example was just that, an example of the capabilities being added. > > I'd happily try to model other http smsc's (even extending the patch > to accomodate extra flexibility), just drop me a line in private and > send me docs about it. > > Regards, -- Thanks, Alex
