• Intro
• Downloads
• Community
• Development
• News
• TALK

Task:MMS/Conversation

Revision as of 09:24, 28 September 2009

this is a conversation which occured on #maemo Monday 28th September 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.

<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
* hannesw__ has quit (Read error: 110 (Connection timed out))
<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 :)
* swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) has joined #maemo
<lcuk> putting pictures on public accounts is not always wanted
<kirma> sounds like they rob the money from consumers and actively avoid proper capacity planning and upgrades, because that would give the customers better service than what keeps them on the network
<lcuk> i want to sometimes send a picture to a specific user with the expectation of privacy and "for your eyes only"
<kirma> and of course when most customers are on several-year plan, it's not very hard to keep them
<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
<johnx> kirma, better than that: carriers aren't compatible with each other :D
<lcuk> cmug, only a few people have email on their phones
<lcuk> even if capable, most dont configure it
<johnx> you can't take the iphone (unlocked or not) to a different US carrier and use the 3G
<RST38h> kirma: No need to disconnect people, sue them, firewall them, etc
<cmug> lcuk, when they buy the n900 (or two) they will
<RST38h> kirma: Then, as your network grows, lower the price
<lcuk> why would they
<cmug> because the will create a ovi email account
<lcuk> i dont see the point in email on my mobile device
<RST38h> cmug: Sure about it?
<lcuk> its something i leave for big pc still
<cmug> RST38h, lets see :)
<johnx> conversely, in the US, the N900 will be t-mobile only (in terms of 3G access)
<cmug> s/will/should/
* 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
<cmug> so do mine
<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"
* guardian (n=guardian@mar44-1-87-90-32-28.dsl.club-internet.fr) has joined #maemo
* L0cutus_ (n=kki@84.222.93.184) has joined #maemo
<lcuk> difference johnx
<Myrtti> johnx: most of us aren't
<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
<johnx> lcuk, crap, I knew I was doing something wrong...
<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
* fnordianslip (n=fnoridan@94-30-69-47.xdsl.murphx.net) has joined #maemo
* fab (n=bellet@monkey.creatis.insa-lyon.fr) has joined #maemo
* 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
<johnx> lcuk, I'm working on making them define when I'm "on call" at least
<johnx> one step at a time
<RST38h> lcuk: Now, if somebody insists on giving me a second device, there is a big chance it will be left at the desk
<lcuk> RST38h, your personal preference is not the same thing
<lcuk> i understand you can use the same device
* pvanhoof (n=pvanhoof@d54C0C0BA.access.telenet.be) has joined #maemo
<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> ok i give up
<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!
* ouilsen (n=ouilsen@linuxc54.rz.RWTH-Aachen.DE) has joined #maemo
* shdb has quit (Read error: 104 (Connection reset by peer))
* shdb (n=shdb@217-162-129-64.dclient.hispeed.ch) has joined #maemo
<cmug> sure if it can be implemented it should be
* fnordianslipeee (n=darren@94-30-69-47.xdsl.murphx.net) has joined #maemo
<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
* trickie (n=trickie@94.100.112.225) has joined #maemo
<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...
* sergio (n=sergio@155.99.117.91.static.mundo-r.com) has joined #maemo
<lcuk> kirma, thats because it has a phone keypad too
* AStorm (n=astralst@unaffiliated/astralstorm) has joined #maemo
* sphenxes has quit (Remote closed the connection)
<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
* ab[out] is now known as ab
<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
* hannesw__ (n=hannes@91-114-231-139.adsl.highway.telekom.at) has joined #maemo
<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

<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"
* jauaor has quit (Remote closed the connection)
<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
* andre__ (n=andre@g1.blanicka25.net) has joined #maemo
<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
* milos_ (n=milos@92.36.186.81) has joined #maemo
<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?
* dneary (n=dneary@ALyon-152-1-41-74.w83-205.abo.wanadoo.fr) has joined #maemo
<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
* fnordianslip has quit ()
<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
* fnordianslipeee has quit (Read error: 60 (Operation timed out))
<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
* bergie has quit ()
<AStorm> no, you were suggesting an owner match in iptables
<AStorm> which is... ugh.
<ab> no
* Vulcanis has quit ("This, my lords and gentlemen, is the message which we send forth today to all states and nations, bound or free, to all the m)
<AStorm> ab: or l7 match, even more ugly
<ab> this is one of approaches, another was exactly what you have said
* calvaris has quit ("Ex-Chat")
<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
* zap (n=zap@213.59.86.89) has joined #maemo
<AStorm> since any tagging done there will be either on owner (one process? please...)
<AStorm> or content (slow and... meh)
* calvaris (n=calvaris@91.117.99.155) has joined #maemo
<AStorm> others will infringe on internet access
<AStorm> although you could do a NAT in iptables
* bilboed-pi (n=bilboed@74.Red-80-24-4.staticIP.rima-tde.net) has joined #maemo
<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)
* tomdavidson (n=quassel@uwyo-129-72-152-201.uwyo.edu) has joined #maemo
* florian_kc (n=fuchs@port-217-146-132-69.static.qsc.de) has joined #maemo
<ab> and we re-write routing based on a packet that comes from that interface
<ab> pure NAT
* herzi (n=herzi@tmo-109-101.customers.d1-online.com) has joined #maemo
<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
* chx is now known as chx_sleeping
<AStorm> (since ip rule will catch it)
* florian_kc is now known as florian
* AD-N770 (n=jep@o.bcn.fluendo.net) has joined #maemo
<ab> yes, it is more or less clear
* JamieBennett (n=JamieBen@5ac884e9.bb.sky.com) has left #maemo
<ab> would be good to have a write up so that I can further point internal guys to this proposal