Re: HTTP Module

So, I've finally managed to make it work using a couple of PHP scripts
and a MySQL table around kannel. The scripts wrap around kannel, so we
can use the same keyword-based routes as with the rest of our
connections, whilst implementing a sychronous interface to the
aggregator (yuk!).

What we ended up doing is:

1. Receive the MO from the aggregator on an "inbound.php" script.
2. This script calls the HTTP module (I use a propietary one we
developed that allows us to pass a ticket id on the binfo field and
has the validations/mappings that our aggregator requires, but I think
it could be adapted to use the regular kannel http module).
3. After that, it enters a loop with a 1 second sleep, querying the
database and waiting for the response row to appear.
4. Meanwhile, the HTTP module routes the message to each app depending
on the keyword. The app responds using a sendsms interface. This is
regular kannel working, of course.
5. The MT gets queued and the HTTP module POSTs to another PHP script
"response.php" (Because we configured it that way, of course).
6. This second script inserts a row on the database table with the
response data from the app. We are using the ticket id we've got from
the aggregator as primary key, so we can easily track things. We only
need the ticket id and message text in fact, but we insert a couple of
things we also have (mobile number, operator, etc) just in case...
7. The first script detects the newly inserted row, reads it, print it
on the page and delete it.
8. There is a configurable timeout of 30 seconds on the first script,
after that if we didn't get the response from kannel we end with an
error.

It seems to work fine, we'll see when we test it on production with a
lot of simultaneous messages, but I don't see why it shouldn't work...

If anyone's interested in the code, please let me know and I'll gladly send it.

Thank you again for your help.

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


On 4/1/06, Alejandro Guerrieri <[email protected]> wrote:
> René,
>
> I've just started implementing somewhat similar to your third approach
> before reading your mail. What I'm starting to do is
>
> 1. Receive the SMS on a dispatcher process (PHP).
> 2. The dispatcher "injects" the message on Kannel using a special HTTP
> module I've developed for the same aggregator (yes, on another short
> number they have an asynchronous interface! Don't ask...). That module
> allows me to pass a "ticket" on the "binfo" field. I use this to track
> messages from and to kannel.
> 3. The dispatcher module keeps waiting for the queue to populate with
> the ticket-indexed message. This I'll do it with periodically with a
> SELECT query.
> 4. I've configured the HTTP module to POST the MT's to another
> "response" process (PHP).
> 5. The response process uses the ticket to populate the MySQL queue
> with the app response.
> 6. The dispatcher then detects the newly added entry, get it, print it
> with the proper formatting and terminate the process.
>
> I think it will work (I've made a proof of concept using regular files
> instead of a MySQL table and it works ok!).
>
> Now I'm polishing some details, mostly error handling and queueing,
> but I think it will work like a charm.
>
> I'll post my findings on the list, just in case anyone else have a
> similar problem.
>
> Thank's for your help.
>
> --
> Alejandro Guerrieri
> Magicom
> http://www.magicom-bcn.net/
> LinkedIn: http://www.linkedin.com/in/aguerrieri
>
> On 4/1/06, Rene Kluwen <[email protected]> wrote:
> > Hello Alejandro,
> >
> > Starting with your last comment: Yes, doing this from PHP would be a much
> > simpler approach.
> > There's several ways within Kannel that can do the job.
> >
> > One is to use an sms-service that sends the proper reply. You need some
> > threading glue in between the receive_sms() & send_sms() function to
> > coordinate everything. But it can be done.
> >
> > Another is to queue all incoming messages in the send_sms() function.
> > You just add them to a gw_list.
> > Whenever an HTTP GET request comes in, you extract the message from the list
> > and pass it on in the reply body.
> >
> > A third option is to put every incoming message into a MySQL table. And use
> > PHP to do the actual GET request/response thingies.
> > This way you can put the protocol logic in PHP whilst yet retaining Kannel's
> > routing options.
> >
> > These are just three examples that I can come up with in a few mintues.
> > Probably there will be a lot more ways to do it.
> >
> > Cheers,
> >
> > Rene Kluwen
> > Chimit
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Alejandro Guerrieri
> > Sent: zaterdag 1 april 2006 17:26
> > To: [email protected]
> > Subject: HTTP Module
> >
> >
> > Dear List,
> >
> > I've developed a couple of HTTP modules in the past, to accomodate to
> > third partie's particular requirements. Most of them are propietary
> > (their specs are particular to us) but we are talking with a couple of
> > them about releasing the module so other people can connect to them
> > using kannel.
> >
> > Since most HTTP apis are asynchronous (one connection to us when a
> > message arrives and we establish a connection when we want to send a
> > message)wWe usually start from the "kannel" http module, change the
> > parameters and a few other things and we are done.
> >
> > They work fine and we didn't experience any particular issues with them.
> >
> > But now, a third party is asking us to use a "synchronous" connection.
> >
> > I mean: The third party connect to us using an HTTP GET and we should
> > respond on the reply to _that_ request with a line of text containing
> > the message we want to send. Then their system sends the message to
> > the originating number.
> >
> > I know it's an _horrible_ approach:
> >
> > It has no queuing, retrying, validation nor failure detection.
> > We can only respond to messages originating from them.
> > We cannot know if there were any issues with the sending (since I
> > don't get a "Sent" response from them).
> >
> > Anyway, it's what they've got and what they are asking to use, so our
> > hands are tied there.
> >
> > The problem is _how_ to implement this in an HTTP module. Since kannel
> > uses an asynchronous approach, I don't know where to start.
> >
> > AFAIK, when a message is injected from the HTTP interface, it arrives
> > at "kannel_receive_sms" and the message is put on the incoming queue
> > using "bb_smscconn_receive":
> >
> > ret = bb_smscconn_receive(conn, msg);
> > if (ret == -1)
> >  retmsg = octstr_create("Not accepted");
> > else
> >  retmsg = octstr_create("Sent.");
> > }
> >
> > And then the HTTP interface replies wit "Sent" or "Not accepted":
> >
> > reply_headers = gwlist_create();
> > http_header_add(reply_headers, "Content-Type", "text/plain");
> > debug("smsc.http.kannel", 0, "HTTP[%s]: Sending reply",
> > octstr_get_cstr(conn->id));
> > http_send_reply(client, HTTP_ACCEPTED, reply_headers, retmsg);
> >
> > At the end, cleanup is performed:
> > octstr_destroy(retmsg);
> > http_destroy_headers(reply_headers);
> >
> > Later on, the message is picked on the smsbox, processed and the
> > response is processed on a separate thread.
> >
> > The problem is, I'd need to respond _inmediately_ with the response on
> > the same HTTP connection. In other words, instead of "Sent" I'd need
> > to respond with the message I'd want to send.
> >
> > Is that possible? What would be the best approach to do that? AFAIK it
> > would need to keep the HTTP connection open and waiting for the smsbox
> > to respond, but how could I do that?
> >
> > I know I can do this easily from PHP or any scripting language, but
> > using kannel I can keep my routings (we have a _lot_ of them) on a
> > single place. Using PHP "glue" would mean we have to replicate all our
> > "sms-service" group logic outside kannel and I want to avoid that if I
> > can, since we many different regex-keywords on many short numbers
> > pointing to many apps and mantaining those settings on two different
> > places would be an daministrative nightmare.
> >
> > Any hints about this would be appreciated.
> >
> > Best regards,
> >
> > --
> > Alejandro Guerrieri
> > Magicom
> > http://www.magicom-bcn.net/
> > LinkedIn: http://www.linkedin.com/in/aguerrieri
> >
> >
> >
> >
>