Task:MMS
Contents |
Introduction
The aim of this page is to list potential obstacles and solutions in regards to implementing MMS in Maemo 5 ”Fremantle” on the N900.
Use case
While this has been discussed much back and forth both on Talk and on #maemo, here are some points why MMS should be implemeneted:
- Quickly sending private pictures to someone.
- While most users tend to be able to receive MMS, there's a lot few with push e-mail on their phones atm (need citation, but this is what's come up in discussion; see Mms_implemention_conversation)
- Another use case is to send your location from nokia maps over mms to quickly allow another person using nokia maps and gps find a location or service (e.g. bar, restaurant , etc).
The advantage MMS have over e-mail on the phone as well is it's generally less spammy; e.g. no Facebook notification mails etc.
Implementation
To successfully implement MMS sending and receiving on the N900 the following has to be done:
Hook in to SMS receving.
According to this post by danielwilms the final SDK for Maemo5 should let us do this through Telepathy. Docs on this should be coming *soon*.
What's needed here is basically to extract the WAP PUSH message and then reply with the correct messages.
Fetch the MMS from the provider.
Multiple issues with this.
- Fremantle UI currently only allows configuring one APN. gconf MIGHT allow you to add multiple.
"[...] you can only define one APN in Maemo5, at least in the release I've got." [1]
- Most operators only allow fetching of MMS when accessing via a specific APN. To access this you would have to temporarily suspend your current 3G connection and switch over to this (is this correct? need someone with knowledge on this). On S60 you won't get dropped as long as you are on a 3G connection.
- If the user only got access to GPRS the current connection (if in-use) have to to be temporarily suspended while fetching the MMS. This should be doable by doing a "Deffered Retrieval". [2]
- Accessing the MMS "server" through a specific connection: iptables tweaking? Discussion at [Mms_implemention_conversation#Technical] The following is based on that conversation:
- The problem here is routing specific data to the specific connection. While this is possible with some clever routes, this does raise the problem with operators having the same gateway for both GPRS and MMS connections, which might lead to a collision (if both they are indeed the same gateway, it should be no problem just getting the MMS over the current connection?).
- One possibility is to tag the appropiate packets with iptables and then sent to a different routing table.
- To overcome the problem with different gateways on the same subnet one could add a hard dumb route to the specific gateway via route, then set the Internet gateway to a higher priority. e.g. rename 123.123.123.0 -> MMS route via iproute2 NAT. Something like http://lartc.org/howto/lartc.rpdb.multiple-links.html maybe?
- Another solution would be a mms-fetcher-daemon running as a specific user (e.g. mmsd) and use iptables to route all these packages to the correct interface. This works around when both the GPRS and the MMSC specified is on the same IP but requires different connections. i.e. "route add 1.2.3.4 ppp:mmc - fails if there is also a server on 1.2.3.4 on ppp:normal"
- At the core of it - whats needed is a separate interface (e.g. ppp0, ppp1 etc) for each APN the user sets up.
- Applications should be able to request a certain IAP to be activated; thus should the MMS app be able to request the correct APN. Source
- The functionality to handle the above problem is in linux-2.6.30+ (Fremantle runs 2.6.28) so if there is a future kernel upgrade, it should be possible to implement full MMS support. See this talk-post. Alternative would be to backport the networking namespace to 2.6.28.
Format the MMS and display it correctly.
- How open is the Messaging client?
Plenty of open source libs to do this in other languages:
- PHP1
- PHP2
- Java JavaSE/JavaME
- C
- Gammu+ with C++ implementation (compilable in Linux and Windows)
- Python
Rough roadmap
Before MMS implementation is written a roadmap must be chosen, and various factors must be taken into account before choosing a roadmap.
Potential roadmaps based on e.g. practical situations could use a quick community hack whereas official certification is much more work, and theoretical/technical.
Please note following information is much easier understood by using a flowchart.
Quick hack, r/o
- Make sure a technical inclined Nokia N900 user is able
- Receive MMS
- Read MMS
- Community support; not official Nokia support
- CLI, GUI, HIG not important
Quick hack, r/w
- Make sure a technical inclined Nokia N90 user is able to
- Receive & sent MMS
- Read MMS
- Write MMS
- Community support; not official Nokia support
- CLI, GUI, HIG not important
Quick hack, r/o, user-friendly
- Make sure a non-technical inclined Nokia N900 user is able
- Receive MMS
- Read MMS
- Community support; not official Nokia support
- Finger/touch GUI, HIG recommended
Quick hack, non-r/w user-friendly
- Make sure a technical inclined Nokia N90 user is able to
- Receive & sent MMS
- Read MMS
- Write MMS
- Community support; not official Nokia support
- Finger/touch GUI, HIG recommended
Full specs, r/w
- Make sure a non-technical inclined Nokia N900 user is able to
- Receive & sent MMS
- Read MMS
- Write MMS
- Official support by Nokia, official MMS certification.
- Must support all the specifications such as WAP 2.1.
- Finger/touch GUI, HIG mandatory