Re: [PATCH] Support for MO parameters on 'generic' HTTP SMSC - Secondrevision

Alex,

Didn't document it yet since it wasn't clear if it would make into CVS.

I'll do it right away and post it here.

Regards,

Alejandro

On 9/27/07, Alexander Malysh <[email protected]> wrote:
> Hi again,
>
> as I wrote patch looks good but I don't see userguide changes in the
> patch :) Please update userguide and I will apply this patch if no
> objections there.
>
> Alejandro Guerrieri wrote:
>
> > Did anyone reviewed this patch?
> >
> > On 9/7/07, Alejandro Guerrieri <[email protected]> wrote:
> >> The original condition was commented:
> >>
> >> +    if (/*user == NULL || pass == NULL ||*/ /* we don't need this
> >> anymore */
> >> +       octstr_compare(user, conndata->username) != 0 ||
> >> +           octstr_compare(pass, conndata->password) != 0) {
> >> +               error(0, "HTTP[%s]: Authorization failure",
> >>
> >> The piece of code you're referencing it's before the original (now
> >> commented) evaluation. The purpose is to truly make user and password
> >> optionals.
> >>
> >> And yes, you're absolutely right, it should be "||" to avoid
> >> octstr_compare on an undefined value.
> >>
> >> Thanks for pointing this out. I've uploaded a new patch here:
> >>
> >> http://www.magicom-bcn.net/kannel/full-mo-http-params-20070907.patch
> >>
> >> Regards,
> >>
> >> Alejandro
> >>
> >>
> >> On 9/7/07, Vincent CHAVANIS <[email protected]> wrote:
> >> > Hi alejandro,
> >> >
> >> > I'm wondering why this condition has been changed
> >> >
> >> > if (user == NULL || pass == NULL) {
> >> > user = octstr_create("");
> >> > pass = octstr_create("");
> >> > }
> >> >
> >> > into:
> >> >
> >> > if (user == NULL && pass == NULL) {
> >> > user = octstr_create("");
> >> > pass = octstr_create("");
> >> > }
> >> >
> >> > I think that we need to check both of these values.
> >> > if user = blah and password = NULL
> >> > we will do octstr_compare with password and this is not safe.
> >> >
> >> > Vincent.
> >> >
> >> > --
> >> > Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
> >> > Service Technique/Reseau - NOC
> >> > Developpement SMS/MMS/Kiosques
> >> > http://www.telemaque.fr/
> >> > [email protected]
> >> > Tel : +33 4 92 90 99 84 (fax 9142)
> >> > ----- Original Message -----
> >> > From: "Alejandro Guerrieri" <[email protected]>
> >> > To: "Alexander Malysh" <[email protected]>
> >> > Cc: <[email protected]>
> >> > Sent: Thursday, September 06, 2007 10:31 PM
> >> > Subject: Re: [PATCH] Support for MO parameters on 'generic' HTTP SMSC -
> >> > Secondrevision
> >> >
> >> >
> >> > > Done,
> >> > > Done,
> >> > >
> >> > > New version of the patch, using generic_receive_sms() instead of
> >> > > kannel_receive_sms()
> >> > >
> >> > > http://www.magicom-bcn.net/kannel/full-mo-http-params-20070906.patch
> >> > >
> >> > > Regards,
> >> > >
> >> > > Alejandro
> >> > >
> >> > > On 9/6/07, Alexander Malysh <[email protected]> wrote:
> >> > >> 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
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> > > --
> >> > > Alejandro Guerrieri
> >> > > Magicom
> >> > > http://www.magicom-bcn.net/
> >> > > LinkedIn: http://www.linkedin.com/in/aguerrieri
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> Alejandro Guerrieri
> >> Magicom
> >> http://www.magicom-bcn.net/
> >> LinkedIn: http://www.linkedin.com/in/aguerrieri
> >>
> >
> >
>
> --
> Thanks,
> Alex
>
>
>


-- 
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/
LinkedIn: http://www.linkedin.com/in/aguerrieri