On fre, 2004-07-16 at 16:40 +0200, SÃren Hansen wrote: > Ok, I've given it a bit more thought, and this is what I'm thinking: > mmsbox receives the MMS submission from phone > mmsbox does magic to figure out MSISDN of submitter. (TODO) > binary encoded MMS is sent along with msisdn to bearerbox. > bearerbox relays MMS to... > [snip] > ...sends decoded MMS to smtp server.
Alright, here's what I'm thinking now (I think I'm getting there now): 1. mmsbox receives the MMS submission from phone 2. mmsbox figures out MSISDN of submitter (TODO) 3. mmsbox figures out destination addresses and whether they're MSISDN or e-mail. 4. mmsbox sends binary messages (one of each recipient) to bearerbox along with source and destination address and the type of destination. 5.1.1. If destination type is e-mail, the message is sent back to an mmsbox that accepts e-mails to the particular domain. 5.1.2. The mmsbox decodes the MMS to RFC822-format and relays it to an SMTP-server. 5.2.1. If destination type is MSISDN, bearerbox determines if there's an mmsbox configured to handle that particular MSISDN (ie. is it local?) 5.2.1.1.1. If it's local, it's sent to the mmsbox configured to the MSISDN. 5.2.1.1.2. The mmsbox stores the mms in a database of some sort. 5.2.1.1.3. A notification is sent via the PPG. 5.2.1.1.4. The client fetches the message. 5.2.1.2.1. If it's non-local, the recipient domain should somehow be determined. (I don't know how this is done in the real world?) 5.2.1.2.2. The mms will be sent to the mmsbox configured for that domain. As an enhancement, the mmsbox at 5.2.1.1.2 could have an extra SMTP- server defined to which it could send a decoded version of the MMS. That way you could easily get access to it via imap, pop3, webmail etc.. How does this look? -- SÃren Hansen <[EMAIL PROTECTED]>
