RE: HTTP Module

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