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

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