[PATCH] Support for MO parameters on 'generic' HTTP SMSC - Second revision
alejandro.guerrieri at gmail.com
Thu Sep 6 16:08:19 CEST 2007
Ok, I'll fix it.
On 9/6/07, Alexander Malysh <amalysh at kannel.org> wrote:
> 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,
More information about the devel