Hi Soren, ok, here are my comments. I did code the mmsbox on Wapme site ;)
S�ren Hansen schrieb: > > 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 correct, this would be via WAP GW or standalone. > mmsbox listening for HTTP requests receives MMS from phone correct, mmsbox receives the MM1 PDUs that are in the MMS Encapsulation format. > mmsbox decodes the MMS to an RFC-822-format mail. correct, MMS Encapsulation is similar to WSP headers. Bring the messages to an internal representation (we cann it MMSEncap) and use functions to convert to MIME. MIME code is partly integrated into Kannel already (AFAIR). > mmsbox relays decoded MMS to an SMTP server. correct, in case the recipient is addresses via an email address. You should think of having an exim module that can "dock" to Kannel or your mmsbox. > The SMTP server either stores or relays the mail. that's the email case, ok. Actually out of scope for mmsbox. > If it's a local user, the SMTP server somehow relays the mail > back to the mmsbox. why this? bearerbox is supposed to be the "routing engine" for Kannel. Hence let the mmsbox pass the MMS message in Kannel msg representation to bearerbox and let bearerbox decide to which MM4 link the messages is transported. In this sense you can have the same modularity for MM4 connections as the ones for SMSC. Simply addopt the SMSCConn abstraction layer structure and make an MMSCConn structure out of it. (we do it this way and it's terrific from the architecture side). Actually this should be abstrated again to an higher level, so you have generical MSCConn (messaging service center connection) and then define via callbacks the spefic messaging operations. > mmsbox sends notification to recipient with the appropriate > message ID. correct. Therefore you can utalize 2 ways: a) mmsbox acts as PI (push initiator) towards PPG (wapbox). This is the "architecturely clean way". b) mmsbox connects as smsbox instance to bearerbox and passes the UDH binary encoded MMS M-notification PDUs directly to bearerbox for SMSC connection transport. > Phone receives notification. yep. Hopefully it understands the PDU. Some vendors are still messing things up here. > Phone makes request to URL from notification. correct. Again via WAP GW or directly. > Kannel receives request for URL. > Message ID from URL is used to look up mail from IMAP storage ok, in case you use an mbox format mail spool directory to actually "store" your MMS localy, you can utalize IMAP for this. But why this overhead? Simply put the messages in binary MMS Encap PDU representation to a local spool directory and name the files with the UUIDs (message-ids). Then it's trivial to look for them an fetch it for transport to the receivers. > Fetched mail from storage is reconverted to binary MMS format. yep. > Encoded MMS is sent in response to phone. yep. > Does this look right? so long, this is the basic way, yes. You missed some things that come with the "advanced version": While the receiver gets the notification, he could decide to postpone the download. This is also send as MM1 PDU to the mmsbox HTTP server. In this case you "could" notify the sender via a specific MMS notification about that postpone event of it's receiver. Also, when the final receiver fetches the MMS, the originator may have registered to receive delivery report for this, which is again a MMS notification via binary SMS. (See the specific MMS Encap PDUs for MM1 links) > >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. correct. mmsbox can be treated as a "local MM4 link". As the home MMSC in this sense. By letting bearerbox decide on the routing, you can connect several mmsboxes to bearerbox which represent MMSC implementations of varios carriers/netwoks and let bearerbox connect using the same abtrasction API to MM4 implementations, like SMTP or SOAP/XML over HTTP in some cases (actually this would be MM7 in the MMS overall architecture, and the receiving MMSC would see you as a VASP application). > 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? +++1. It steamslessly integrates Kannels routing, queueing and storing architecture to the MM1, MM4, MM7 links defined in the overall MMS architecture. > *: 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? ok, first of all: mmsbox does exist. Exactly with the architecture I described above. It lives in cages at Wapme. And it _may_ be released to Kannel free land sometime. And about the convince: Simply tell him it puts your company in control of developing the software components you _really_ need and other people are contributing to this effort with no financial demands. Taking your reason as a compliment for the group. Summary: Now, as a lot of people are "thinking" of implementing MMS support to Kannel, and Kannel as itself is designed for messaging, it's really annoying me that I can't drop the code out of the door and let people work on it... I'll try to see how far I get from the management side here to get this done. Stipe mailto:[EMAIL PROTECTED] ------------------------------------------------------------------- Wapme Systems AG Vogelsanger Weg 80 40470 D�sseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ ------------------------------------------------------------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -----END PGP PUBLIC KEY BLOCK-----
