Task:MMS/Conversation - Revision history

amigadave: categorize

amigadave — Tue, 11 May 2010 08:22:57 GMT

categorize

← Older revision		Revision as of 08:22, 11 May 2010
Line 246:		Line 246:
	http://maemo.org/api_refs/5.0/beta/icd2/group__dbus__api.html#g2d518bd08002c0a8a92c8ba00546360f		http://maemo.org/api_refs/5.0/beta/icd2/group__dbus__api.html#g2d518bd08002c0a8a92c8ba00546360f
	</pre>		</pre>
		+
		+	[[Category:Tasks]]

guaka: 2009

guaka — Tue, 05 Jan 2010 00:59:25 GMT

2009

← Older revision		Revision as of 00:59, 5 January 2010
Line 1:		Line 1:
	__FORCETOC__		__FORCETOC__
-	this is a conversation which occured on #maemo Monday 28th September	+	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 principally involves users ab and astorm discussing implementation specifics for MMS on the n900.

allnameswereout: Mms implemention conversation moved to Task:MMS/Conversation

allnameswereout — Thu, 29 Oct 2009 15:08:36 GMT

Mms implemention conversation moved to Task:MMS/Conversation

← Older revision

Revision as of 15:08, 29 October 2009

javispedro: /* Higher level technical */

javispedro — Mon, 28 Sep 2009 21:04:57 GMT

Higher level technical

← Older revision		Revision as of 21:04, 28 September 2009
Line 235:		Line 235:
	[22:22:33] <frals> on the other hand im sure i dont have the whole picture and it can be circumvented somehow ;)		[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: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 if ~~a default if set~~	+	[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 ~~if "default is set"~~, I'd guess we'd be able to bypass confirmation.	+	[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:29] <frals> ye - but does that setting apply to just the one connection or systemwide..
	[22:23:37] <frals> ah good point javispedro		[22:23:37] <frals> ah good point javispedro
Line 244:		Line 244:
	[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: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.		[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>		</pre>

frals: linking to mms implementation

frals — Mon, 28 Sep 2009 20:50:02 GMT

linking to mms implementation

← Older revision		Revision as of 20:50, 28 September 2009
Line 11:		Line 11:

	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.		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==		==Problem Definition==

frals: Added one more conversation from IRC

frals — Mon, 28 Sep 2009 20:34:32 GMT

Added one more conversation from IRC

← Older revision		Revision as of 20:34, 28 September 2009
Line 1:		Line 1:
		+	__FORCETOC__
	this is a conversation which occured on #maemo Monday 28th September		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 principally involves users ab and astorm discussing implementation specifics for MMS on the n900.
Line 212:		Line 213:
	<ab> yes, it is more or less clear		<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		<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 if a default if set
		+	[22:23:17] <javispedro> considering we could have control of the plugin and thus be able to decide if "default is set", 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.
	</pre>		</pre>

frals: Made technical/problem defition headers to allow direct linking to each part

frals — Mon, 28 Sep 2009 20:25:08 GMT

Made technical/problem defition headers to allow direct linking to each part

← Older revision		Revision as of 20:25, 28 September 2009
Line 11:		Line 11:
	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.		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.

-		+	==Problem Definition==

	<pre>		<pre>
Line 101:		Line 101:
	</pre>		</pre>

-	Technical:	+	==Technical==

	<pre>		<pre>

frals: Cleaned up the chatlog, removed some junk and join/parts etc

frals — Mon, 28 Sep 2009 15:48:42 GMT

Cleaned up the chatlog, removed some junk and join/parts etc

Show changes

lcuk: New page: 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 propo...

lcuk — Mon, 28 Sep 2009 09:24:56 GMT

New page: 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 propo...

New page

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.

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

</pre>

<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"
* 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

</pre>