Re: Brainstorm: MMS Support
 

It we talking about feature development of the platform we should bear in mind. See requirements of 3GPPr6.
Just the opposite: SMS and HTTP for the reception, HTTP for the transfer. For IMS-solutions - SIP in both cases.
Course GRX and the device does not interact directly. Subject GRX mentioned in the explanation of the need to use private IP-based networks. Please read carefully.
Realy? But what you will say about MMS notification by WAP-Push indicators and MMS transmission in roaming?

For example the typical high-level use-case of MMS delivery in roaming:
1. MMSC has MMS for subscrier B. MMSC sends WAP-Push indicator by SMS to UA.
2. UA receives WAP-Push and asks subscriber to retreive MMS.
3. Subscriber accepts UA-request.
4. UA initiates PDP-context to MMS APN.
5. SGSN of guest network opens Gn tunnel thru GRX to GGSN of home network responsible for MMS APN
Now UA has IP from IP-space of home MMS pool.
6. GGSN sends the pair of MSISDN and IP to WAPGW by RADIUS Accounting-Start message.
7. UA sends HTTP-request for MMSC using message URL from WAP-Push indicator. UA uses WAPGW as proxy and open PDP-context as interface.
8. WAPGW transmits request to MMSC. WAPGW puts additional HTTP-header with MSISDN to request.
9. MMSC receives request and sends message content as response. If MMSC has content adaptation feature MMSC adapts content of the message to UA capable format using HTTP-header User-Agent form HTTP-request to determinate parameters of adaptation/transcoding.

Re: Brainstorm: MMS Support
 

Yes. OK. Why not. But put it somehwere down the roadmap, since currently it is technically not required to support this. How many MMS capable devices are out that cannot handle SIP in any way and stlll work and will work in future. For "getting MMS somehow to work" we can just do as they do. SIP based communication in an IMS network is still (mostly) future. Most important things first.

The device receives notification in the form of SMS and/or IP pushes (or other means). It sends messages and other PDU by doing HTTP POST (and not PUSH, you are right). And it retrieves message content by doing HTTP GET.

For writing an MMS client it is therefor necessary to get access to binary SMS and do not make them appear in the normal SMS inbox (useability requirement). And we must be able to get IP access to the MMSC. This was found out by other participants before.

Sorry, this was possibly lax quoting. As *you* told GRX is for inter MMSC operation. I just stated that *you* were right. But I also stated that while you are right, mentioning GRX in "MMS device support" adds no technical requiremnts for the MMS client.

What I meant is, that if we get a MMS client working that behaviour likes the specification requires we can assume that providers will not block out devices with our client installed. They may block users/SIM cards because of user belonging to foreign provicers and other reasons, but that are different stories.

Please let us not discuss about thinks that do not directly help for the next step (even if they are correct and true). The next step is above cited problems:

Getting access to the SMS and getting IP access to the MMSC.

If that is not solved everything else is not important anymore :-/ Sadly I cannot help with that. I can help writing the actual client though if it ever comes to that.

Gruß...Tim

Re: Brainstorm: MMS Support
 

Out of interest, I was wondering about the URI used to reach the MMSC
if the host component is a name, it would need to be resolved.

if multiple connections are made to different APN (or even wifi + MMS APN) split DNS would need to be taken into account. To me it would seem reasonable that the host name of the MMSC may only be resolvable when using the DNS server presented when connecting to the MMS APN.

I guess that rules out using the system resolver. I guess but it it complicates the idea of using NAT or some other IP translation and routing manipulation since multiple DNS server entries may also need to be taken into account. And the HTTP client would need to rely on custom DNS code.

Re: Brainstorm: MMS Support
 

Wouldn't it be a possible work around to just use the (before somehow found out :-/) IP adress of the MMSC instead of the hostname? This is of course not a end-user solution but could help to get past this barrier to analyse further problems and get to a proof of concept...

Gruß...Tim

Re: Brainstorm: MMS Support
 

May be you mean IP-address of WAPGW?? The resolving IP of MMSC fully implemented at WAPGW side. Most operators declares to end-users the IP address of WAPGW instead of hostname to make setting capable with old terminals which supports WAP 1.2.
In this case DNS resolving is not a problem. The main problem in my opinion is possible address-spaces collisions between MMS PDP and fo example subscriber's WLAN.

Re: Brainstorm: MMS Support
 

Thanks. When talking about kernel changes and need for networking namespaces I was talking about the device side, not an operator's side. All other comments from you still apply but it is purely an issue on the client side (Linux kernel without networking namespaces).

That's why we are talking about "hacks" which mostly directed towards overcoming this client-side limitation without kernel changes.

Re: Brainstorm: MMS Support
 

Perhaps the feature/patch can be backported to Linux kernel 2.6.28? Minimal changes, community can test, Nokia can roll out stable later.

Re: Brainstorm: MMS Support
 

Are you sure? You want to use operator's service but you want to know nothing about it. Just for your information: If Maemo would have significant market share, there would not be necessary to develop this "hack", the operators would have changed the infrastructure. Any service should be perceived as a mutually beneficial agreement.

Re: Brainstorm: MMS Support
 

I'm not sure where did you get "want to know nothing about it". I never stated it and all I was saying about "hacks" is that they are discussed for the device side to cope with insufficient support in kernel side of the N900 to handle simultaneous TCP connections to both operator's PDP and public PDP in case those networks have overlapping TCP spaces. If operators would change their infrastructure, that is fine, but reallistically any MMS implementation on client side would need to support any server-side configuration.

Re: Brainstorm: MMS Support
 

Not so easy. Even though basic network namespaces are support in Linux kernel since 2.6.24, up until 2.6.30 or so it was not stable enough and required additional patches. You can read more about networking namespaces at http://lxc.sourceforge.net/network.php