I'm considering writing an mmsbox(*), but until I go ahead and code it,
I need to get a few things straight about the architecture of Kannel,
and how an mmsbox would fit into it. Here' what I'm thinking about
doing:
Mobile phone submits MMS
mmsbox listening for HTTP requests receives MMS from phone
mmsbox decodes the MMS to an RFC-822-format mail.
mmsbox relays decoded MMS to an SMTP server.
The SMTP server either stores or relays the mail.
If it's a local user, the SMTP server somehow relays the mail
back to the mmsbox.
mmsbox sends notification to recipient with the appropriate
message ID.
Phone receives notification.
Phone makes request to URL from notification.
Kannel receives request for URL.
Message ID from URL is used to look up mail from IMAP storage
Fetched mail from storage is reconverted to binary MMS format.
Encoded MMS is sent in response to phone.
Does this look right?
>From what I can tell about Kannel, it currently communicates heavily
between the bearerbox and the smsboxes and wapboxes..
I suppose that the received MMS COULD be sent to the bearerbox, sent
either back to the same mmsbox or another mmsbox, and from there relayed
to the SMTP server.
Likewise, when a client tries to fetch a message, the request COULD be
received by mmsbox, sent on to bearerbox which asks either the same
mmsbox or another one to fetch the mail from storage and send it back to
bearerbox, which in turn sends it back to the mmsbox that got the
request and sends the response to the client.
This setup is MUCH more complex, adds a lot of internal network traffic,
BUT gives a lot of control back to the bearerbox, where I believe it
belongs, right?
*: I'm very keen on doing this, but as I work as a programmer for at
company that develops and hosts mobile solutions, I should ask my boss
for permission to develop this mmsbox for Kannel. He's however on
holiday, so right now I'm just spending my time thinking about how I
should design this.. BTW, how do you people convince your managers to
allow you to release this stuff under BSD license? My best arguments
right now are the fact that a bunch of VERY knowledgeable people will
review every little bit of design and code, and will probably be helpful
in perfecting the software at no cost to the company. What else can I
throw at them?
--
Søren Hansen <[EMAIL PROTECTED]>
