Editing Task:MMS

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

The aim of this page is to list potential obstacles and solutions in regards to implementing MMS in Maemo 5 ”[[Open development/Maemo roadmap/Fremantle|Fremantle]]” on the [[Nokia N900|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 receiving.===
According to [http://talk.maemo.org/showpost.php?p=319365&postcount=15 this] post by danielwilms the final SDK for Maemo5 should let us do this through Telepathy.

To handle WAP Push messages one will be required to register a handler via the D-BUS API (final docs on this pending, for alpha version please contact [http://talk.maemo.org/member.php?u=24057 frals]).

=== Fetch the MMS from the provider.===
Multiple issues with this.

* Fremantle UI currently only allows configuring one (GPRS) APN. Add one manually with gconftool and it will show up in the UI afterwards

Example:
 gconftool-2 --set /system/osso/connectivity/IAP/Tele2@32@MMS/type --type string "GPRS"
 gconftool-2 --set /system/osso/connectivity/IAP/Tele2@32@MMS/name --type string "Tele2 MMS"
 gconftool-2 --set /system/osso/connectivity/IAP/Tele2@32@MMS/gprs_accesspointname --type string "internet.tele2.se"
 gconftool-2 --set /system/osso/connectivity/IAP/Tele2@32@MMS/ipv4_type --type string AUTO
 gconftool-2 --set /system/osso/connectivity/IAP/Tele2@32@MMS/sim_imsi --type string YOURSIMIMSI

To get the SIM IMSI to use:
 gconftool -R /system/osso/connectivity/IAP |grep sim_imsi

* Most operators only allow fetching of MMS when accessing via a specific [http://en.wikipedia.org/wiki/Access_Point_Name 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". <ref>[http://www.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=MMS&file=V1_3-20080128-C/OMA-TS-MMS-CTR-V1_3-20080128-C.pdf Figure 7. Page 16]</ref>

* 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. [[Mms_implemention_conversation#Higher_level_technical|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. [http://talk.maemo.org/showthread.php?p=349859#post349859 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:

# [http://www.hellkvist.org/software/ PHP1]
# [http://heyman.info/mmsdecoder.php PHP2]
# [http://sourceforge.net/projects/mmslib/ Java] [http://sourceforge.net/projects/freshmeat_messaging-midp/ JavaSE/JavaME]
# [http://projects.xplico.org/mmsdec.html C]
# [http://www.gammu.org/wiki/index.php?title=GPlus:Main_Page Gammu+ with C++ implementation (compilable in Linux and Windows)]
# [http://python-mms.sourceforge.net/ 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

Implemented, see: http://talk.maemo.org/showthread.php?p=450237#post450237

=== Quick hack, r/w ===

* Make sure a technical inclined Nokia N900 user is able to
** Receive & sent MMS
** Read MMS
** Write MMS
* Community support; not official Nokia support
* CLI, GUI, HIG not important

Implemented, see: http://talk.maemo.org/showthread.php?p=450981#post450981

=== 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

Implemented, see http://talk.maemo.org/showthread.php?p=459426#post459426

=== Full specs, r/w, user-friendly ===

* 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

== References ==
[[Task:MMS/Conversation]]
<references />

[[Category:Brainstorm]]
[[Category:Cellular]]
[[Category:N900]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Task:MMS"

Personal tools

Navigation

Views

Editing Task:MMS

@@ Line 40: / Line 40: @@
 ** 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". However, using the ipt_route module (experimental for years, netfilter patch-o-matic-ng) would allow traffic to be directed out of a specific interface (ppp:mmc) and since this interface is point2point it would not need a specific route. infact the mmc ip address could be access via ppp:normal or ppp:mmc depending on the match criteria of iptables (pid, uid?).
+** 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'''.