View source for Task:MMS/Conversation

__FORCETOC__
this is a conversation which occured on #maemo Monday 28th September 2009
It principally involves users ab and astorm discussing implementation specifics for MMS on the n900.

it is not a proposal of any sort now, and requires cleanup and extrapolating into a formal proposal/way forward so others can get involved.

the conversation consists of 2 principle sections
firstly, the problem definition itself and issues with the proposed "send an email" approach.
then ab and astorm get into the swing of thing and start talking shop :)


Please help by cleaning up this conversation into the specifics and possibly attempt to writeup a proposal based on some of the points discussed here.

Attempt of write up is at [[MMS implementation]]

==Problem Definition==

<pre>

<johnx> really. I didn't know they had a specific MMS meltdown
<johnx> I just thought they were just in a state of partial meltdown all the time
<kirma> I wonder how much network congestion there is in .fi networks in practice. I suspect considerably less...
<cmug> mavhc, johnx, thats why you have the Ovi share account and you put the picture there
<johnx> people pay attention to their data usage instead of hitting youtube on the bus, so yes, probably :)
<lcuk> putting pictures on public accounts is not always wanted
<lcuk> i want to sometimes send a picture to a specific user with the expectation of privacy and "for your eyes only"
<cmug> lcuk, or you can send it to them on email
<RST38h> kirma: Well, set the MB price so that 1GB of data costs the user $50, and you have solved most of the network problems while keeping users happy
<lcuk> cmug, only a few people have email on their phones
<lcuk> even if capable, most dont configure it
<lcuk> i dont see the point in email on my mobile device
<lcuk> its something i leave for big pc still
* lcuk has never configured an email account on any mobile device
* RST38h used Modest today. What is this world coming to?
<kirma> the problem with email on the phone is that I get way too much of if to funnel it all to the phone, and a more dedicated filter for the stuff is going to drop lots of stuff that I want to read eventually anyway
<lcuk> cmug, my email account gets so much traffic
<RST38h> kirma: Headers-Only save the day
<RST38h> kirma: And IMAP too
<Myrtti> why the bloody hell would I want my work email on my phone?
<lcuk> cos your collegue might want to send you a picture!
<Myrtti> or get "You've been invited to an event" emails from facebook?
<johnx> Myrtti, spoken like someone who isn't permanently "on call"
<kirma> rst38h: well, still, hundreds of emails per day are unbearable to even look at on a phone
<lcuk> if you are oncall
<lcuk> you get your work people to setup your work device
<RST38h> kirma: it is fine if they are threaded
<Myrtti> if I'm not by my computer, I'm not working
<Myrtti> if I am, I most likely am
<lcuk> johnx, why are you using your personal device as a work tool - i hope you are compensated accordingly
* kirma is in many ways stuck into early nineties unix world technology-wise, and doesn't want to change very easily... although many things would get simplified if he did
<RST38h> lcuk: I prefer to use a single device for everything, so no need for compensation
<cmug> filtering is the key to success
<lcuk> is the filtering documented clearly currently
<lcuk> and could [random_person] set it up easily
<lcuk> so they dont miss their work mails
<cmug> i don't filter on the phones, i filter on thunderbird or server directly
<cmug> erm
<cmug> i am a technically oriented person, so i find it difficult to think that somebody who would use filtering would need help setting it up
<cmug> i understand that my mother in law would not be able to setup filtering rules, but she receives one email per week
<lcuk> i am a technical person also - i think and write in c at a very low level
<johnx> lots of people at my office receive huge amounts of email but are some of the least "technical" in the company
<lcuk> email filtering is something i have rarely stepped into and is outside my field of knowledge
<johnx> think: customer service, marketing, etc
<lcuk> why should i spend a week setting up something like that
<cmug> you win, lets moan about lack of mms together
<lcuk> lets find a solution rather
<lcuk> i see there are people digging and seeign libraries and mechanisms
<lcuk> and of course, someone at nokia itself has to know!
<cmug> sure if it can be implemented it should be
<lcuk> nod, im sure some of the maemo guys have beers with some other guys from different departments.  we might be a different OS but get the right people together and they might be able to find a solution
<kirma> I wonder if MMS implementations might have patent mines on trivial issues
<kirma> like, there's a bunch of patents related to text input methods (like T9, even if it's not exactly T9), and SMS
<lcuk> sms is there
<kirma> patentability of those "inventions" is questionable at the best, but what can you do now
<lcuk> and i have to say, works better than any other implementation ive ever used :$
<kirma> I suppose N900 specifically chooses not to implement T9?
<lcuk> it has a qwerty keyboard
<kirma> yep
<kirma> but so has E90...
<lcuk> kirma, thats because it has a phone keypad too
<X-Fade> kirma: But you get T9 for free with Nokia's Symbian ;)
<AStorm> s/free/included in price/
<AStorm> you don't get it in the free version
<AStorm> T9 is propietary
<X-Fade> AStorm: Sure, but for Nokia it is no work to add it for E90 as they have it in every other phone.
<AStorm> (while I could make a better, more accurate system w/o infringing on that fairly broad patent, it wouldn't be easy)
<AStorm> true
<kirma> of course, it's licensed. but even trying to implement reasonably equivalent functionality would, stupidly enough, be a patent breach
<X-Fade> And those firmwares are just the basic components added together ;)
<AStorm> kirma: that's why you have to read the patent and circumvent it
<AStorm> :>
<AStorm> should be possible
<X-Fade> I really see no use for T9 on N900 or N810.
<AStorm> yes, there is none
<AStorm> we have a full keyboard there
<johnx> AStorm, though if you read the pattent and they find you infringing you might suffer a larger fine then someone who claims they never heard of it ;)
<AStorm> no.
<kirma> X-Fade: I can understand, but the patent issue spaghetti is probably one more reason pushing it away from the device...
<AStorm> johnx: that doesn't work that way
<AStorm> I just get a cease and desist
<AStorm> and then I do that.
<X-Fade> kirma: Nah, how about not spending time on useless components ;)
<AStorm> or I can take it to the court
</pre>

==Technical==

<pre>
<ab> MMS is not so easy. I've been told there are technical requirements to have two separate IPv4 namespaces when dealing with MMS and GPRS/EDGE/3G at the same time, as gateways might have same IP networks provided and then you'd have collisions
<AStorm> hehe
<AStorm> simple - fix the gateway
<kirma> on every operator separately...
<ab> the gateway is something that belongs to an operator
<RST38h> ab: No way???
<AStorm> MMS gateway doesn't have to provide any networks
<AStorm> only MMS.
<RST38h> So THAT may be the reason for "kernel MMS support"
<AStorm> the real fix is: add a correct route
<X-Fade> So it needs some kind of tunnel?
<ab> RST38h, there are ways, of course, but someone needs to investigate them. My current metaphor is that an issue similar to have correct implementation of something like VLAN tagging over the same ethernet port
<AStorm> so MMS gateway only gets one route
<AStorm> exactly to its IP
<AStorm> and nothing else
<AStorm> hmm, although...
<AStorm> the dumb ISP might be using a subnet to provide MMS
<ab> AStorm, fun is in the case when both IPs are the same from both gateways
<kirma> I suppose MMS is run over separate ATM/ISDN virtual connection or whatever it should be called, which itself isn't bad, but overlapping routes sure make it more problematic
<ab> so at least from my ISP-related past I know it is possible to solve on a stock 2.4/2.6 kernel but for what price and control over networking setup?
<kirma> I can imagine how it can be implemented without kernel modifications, but it's certainly more complicated than the benefit of having MMS for average N900 users would warrant straight away
<AStorm> ab: then you add a multipath route?
<AStorm> hmmh
<AStorm> or rather, why then the other ASN won't accept MMS?
<johnx> kinda seems like the thing you put in, say a 5.1 release :)
<ab> AStorm, I was thinking along the line of having packets tagged with iptables and then routed to a separate routing table within ip rule
<AStorm> ab: yes yes, nice idea
<AStorm> or instead, just routed via a device
<AStorm> so you have ppp0 and ppp1
<AStorm> one for MMS, the other for internet
<AStorm> both via different ASNs
<AStorm> but that needs some kernel support, yes
<ab> sure, but you need to have the packets tagged first because those interfaces might still have same IP subnets and you would need to help a routing a bit with proper tagging
<AStorm> naah
<ab> with such approach no kernel changes are needed but some user space work on tunnel setup and rules for firewall/ip rule
<AStorm> you could rename the routes
<AStorm> e.g. 123.123.123.0 -> MMS route
<AStorm> via a hard iproute2 NAT
<AStorm> ab: you still need kernel support
<AStorm> note different ASNs
<AStorm> so you need 2 ppp devices
<AStorm> otherwise it will go through the wrong ASN
<AStorm> and might get rejected
<ab> if you have two interfaces, say ppp0, ppp1, both span the same IP subnet (GPRS gateway and MMS gateway gave you overlapping networks), you need to set routes quite carefully for that
<AStorm> not carefully
<AStorm> it's very simple really
<AStorm> different metric (= priority)
<AStorm> internet route gets higher priority
<ab> yep, and then you'd need to tag packets based on a content, not only destination
<AStorm> and then you add a hard dumb NAT (using some local IPs) to access that other route
<AStorm> no.
<AStorm> you do a trick
<AStorm> ip renaming.
<AStorm> far easier
<ab> yep, that is what I was suggesting as well
<AStorm> no, you were suggesting an owner match in iptables
<AStorm> which is... ugh.
<ab> no
<AStorm> ab: or l7 match, even more ugly
<ab> this is one of approaches, another was exactly what you have said
<AStorm>  ab | AStorm, I was thinking along the line of having packets tagged with iptables and then routed to a separate routing table within ip rule
<AStorm> no.
<ab> AStorm, care to write it up on wiki.maemo.org?
<AStorm> ip rule would need some protocol match
<AStorm> while NAT would need only a tiny bit of knowledge in the MMS app
<ab> ip rule needs a mark from firewall, it is enough there
<AStorm> (it must know about IP rename)
<AStorm> mark from firewall based on what?
<AStorm> ;p
<AStorm> owner? protocol? both are ugly
<AStorm> instead, I'd rather have MMS mapped to some constant ip subnet
<ab> make sure you also cover a case when hosts A and B which belong to MMS and GPRS networks have the same IP and you need to send to A for MMS and access B on a GPRS network for everything else
<AStorm> maybe even ipv6 to not clobber anything
<AStorm> ;p
<ab> this is something that guys internally were showing as evidence from some of operators
<AStorm> sure it does, metric takes care of this case
<AStorm> while the nat rule takes care of the rename and routes to the correct ppp device
<ab> AStorm, please write your proposal on wiki.maemo.org
<AStorm> and the routing table *doesn't* look at the metric then.
<AStorm> (since the device is specified)
<AStorm> ab: hmmh, I don't even have an account
<AStorm> but I will write it down
<ab> time to create :)
<AStorm> after I implement a test setup here
<ab> good
<AStorm> or, you can add the routing info for MMS to another routing table
<AStorm> but that may require a patch for ppp
<ab> again, as I was saying :) <ab> AStorm, I was thinking along the line of having packets tagged with iptables and then routed to a separate routing table within ip rule
<AStorm> tagged with iptables = fallible
<AStorm> since any tagging done there will be either on owner (one process? please...)
<AStorm> or content (slow and... meh)
<AStorm> others will infringe on internet access
<AStorm> although you could do a NAT in iptables
<ab> ip rule can work with nat (it has nat option)
<ab> it also has incoming interface to match, that would be an easiest thing if we could make it a sort of a tunnel where applications always send to a locally maintained address (on some tun/tap interface)
<ab> and we re-write routing based on a packet that comes from that interface
<ab> pure NAT
<AStorm> incoming interface? ugh.
<AStorm> worse than having some constant local ip range
<AStorm> which is far easier to adapt apps to.
<AStorm> e.g. you could have MMS on 127.0.127.x
<AStorm> or such.
<ab> just as what I was going to right
<ab> write
<AStorm> incoming on MMS is routed fine already
<AStorm> (since ip rule will catch it)
<ab> yes, it is more or less clear
<ab> would be good to have a write up so that I can further point internal guys to this proposal
</pre>

== Higher level technical ==

<pre>
[22:17:15] <frals> hmm, when ur on 3G, you got one voice and one data connection right? couldnt you get that to be dual data?
[22:17:24] <frals> <- 3g/gsm noob ;)
[22:18:08] <lcuk> frals, i dunno
[22:18:14] <lcuk> its just automatic mumbo jumbo
[22:19:00] <lcuk> qwerty12_N810 to placate some might be an idea to actually indicate in the initial posting of your that it was later sorted ;)
[22:20:14] <javispedro> frals: I dunno about 3G, but I read somewhere that MMS requires an extra inet connection.
[22:20:29] <lcuk> ahhh well
[22:20:31] <frals> yeah it requires you to connect to a specific APN to get the MMS
[22:20:34] <javispedro> s/inet/net
[22:20:44] <frals> or rather, most operator requires that afaik
[22:20:54] <javispedro> frals: well, icd2 is supposed to be able to handle that :S
[22:21:31] <javispedro> (the nit internet connectivity daemon, in case you're wondering)
[22:22:15] <frals> yeah was looking at that yesterday, from what i gathered it required user confirmation when starting a new connection, which would be annoying when auto fetching an mms
[22:22:33] <frals> on the other hand im sure i dont have the whole picture and it can be circumvented somehow ;)
[22:22:46] <ShadowJK> i'd think you'd be able to set it no-confirm
[22:22:54] <javispedro> frals: not sure. apps can open wi-fi without any dialog if an existing AP is found
[22:23:17] <javispedro> considering we could have control of the plugin and thus be able to decide that, I'd guess we'd be able to bypass confirmation.
[22:23:29] <frals> ye - but does that setting apply to just the one connection or systemwide..
[22:23:37] <frals> ah good point javispedro
[22:24:54] <javispedro> (either way, the mms not necessarily has to be managed by icd2, and you may have worse kernel problems to resolve)
[22:25:30] <lcuk> frals, javispedro make sure the important bits of your dialog goes onto the wiki page
[22:25:59] <javispedro> don't consider my word authoritave, it am not a icd2 dev ;)
[22:26:45] <lcuk> javispedro, your word is good as a counterpoint to a conversation, even if you dont know it exactly it helps to make the right sounds
[22:29:16] <javispedro> frals: and apps can request for a certain IAP to be activated, thus mms apps could request the mms iap to be activated.
http://maemo.org/api_refs/5.0/beta/icd2/group__dbus__api.html#g2d518bd08002c0a8a92c8ba00546360f
</pre>