Re: Brainstorm: MMS Support
 

All that all of you talking about implementation MMS support is dirty hack.
Just look the truth. In real situation to implement it we should consider next requirements:
1. MMS is not unique service that requires separate interface. Just see the OMA and 3GPP's R5 requirements. All operator's services should be provided thru IMS. MMS is one of. So, the MMS feature is SIP.
2. IP-address spaces of Internet's connection (Inernet's PDP or Wi-Fi) and operator's PDP could be the same. There is collision.
3. MMS PDP usualy have separare DNS (if used to resolve HTTP Proxy / WAP 1.2 Gateway address).
4. 3G network and GSM supports up to 2 separate PDP-conexts at the same time.
5. WAP-Push indicators has specific message type and i'm not sure that messages of that type will be stored at the event database.
So the best idea is to implement multi-instanced TCP-stack like it's implemented at Symbian and qualified support of WAP-Pushes. After that we could speak about MMS frond-end and rendering.
I know nothing about implementation of multi-PDP at Android but the Windows Mobile implementation is too dirty. As i understood the iPhone implementation has second TCP stack for MMS.

Re: Brainstorm: MMS Support
 

At least for some folks an additional PPP connection isn't necessary. But I don't understand something. Its been long possible to have multiple PPP interfaces. What is exactly the issue of it not working?

Yes, my primary goal would be to be able to read a received MMS in some way. In my case, this may involve some command line work. That is OK with me because I won't receive many MMS anyway. This way, you at least are compatible receiving the content instead of not being able to read it at all.

SIP? Some comments in this thread point out that in some cases a seperate connection is required. I'm not sure on the statistics though, thats quite foggy.

In my case MMSC has public IPv4. If you'd sent the MMS and then give target device the link to the content you'd need to give a public IPv4. So the MMSC must have at least one public IPv4. If operators use a private IPv4 for their MMSC that is their stupidity because there is no need for that.

Thanks for your contribution.

Re: Brainstorm: MMS Support
 

In IMS infrastructure MMS agent shoud request service thru SIP before applying MM1. Just check specs of MM1st3.

I found an simple presentaion about MMS feature - http://www.cdg.org/news/events/cdmas...m/Qualcomm.pdf
Current specs also supports BCAST.
You can find all specs here.

Sorry, but my experience shows that most of operators uses private IP-networks for their services. I'm employee of one of them who has about 70 million of subscribers. Most parts of data-interchange between operators performs thru private networks like GRX by reasons of security and stability.
So if you are not part of them you can't discuss what is stupid because you know nothing about operator's infrastructure.
If we are talking seriously MMS support requires separate TCP-stack and HTTP Proxy support because most operators supports WAP 2.0 devices and WAP 2.0 Gateway is a classical HTTP proxy with some extensions.

Re: Brainstorm: MMS Support
 

Performer, the things you are describing are same we have been discussing internally already. Dirty hacks could help right now but probably will not work for all cases. Separate TCP-stack is something you can get with Linux 2.6.30+ (separate networking namespaces). Maemo 5 is on 2.6.28 baseline where networking namespaces are not available, thus all this discussing with hacks.

As you are representing an operator business, would you be able to reflect on how important MMS is to operators? I know from statistics that generally users utilize MMS at a rate about 2-4% of SMS use, which is definitely very low and being replaced by alternative options -- email, direct social services communications, etc -- over time. But how important whole MMS business to operators?

Re: Brainstorm: MMS Support
 

MMS has little part in VAS share of operations. Primary parts are GPRS Internet and SMS. By Nokia's public plans the market of Maemo 5 enabled devices is small and the target of launch series is market research. So I am not sure that operators are ready to invest in technology and changes in the modification of infrastructure.
The process of sending MMS is specific and has a number of features. In my last post, I talked about that WAP 2.0 Gateway is the HTTP Proxy with some extensions. The main extension - a recognition of the subscriber, it does not make it impossible to use public addresses.
With a large number of online subscribers, the operator uses a private address on the Internet PDP given the extremely scarce resources networks IPv4. These networks are isolated through NAT and Firewall.
Unfortunately, there is only one way to identify the subscriber in the IP-based network is to get a bunch of IP-address + MSISDN via RADIUS Accounting-Start message from the GGSN to the WAP Gateway. In turn, WAP Gateway provides MSISDN in the HTTP Header request. Thus MMSC recognizes subscriber.
Such insecure channel necessitates placement MM1 of MMSC in an isolated network. At the same time it makes no sense to install WAP Proxy on the Internet PDP because this decision will reduce the availability of Internet services for the entire subscriber base.
In other words, the operators does not make sense to change their infrastructure for one device with low sales.
For the discussed work-around I have no confidence that the solution will work fully with Vodafone NL, or any other network.
Just look at Apple. they did a full-fledged support for MMS when it is really needed and exactly when it became possible. I think we should wait Maemo 6 or new kernel with a full support of Network Namespaces.

Re: Brainstorm: MMS Support
 

Thanks for the great input, glad to see we got someone working for an operator in here to tell us how they look at it :)

While I do realise fullfledged MMS support is impossible with the current kernel, I do still have a question.
Is it possible to implement it and get it working to such a degree you would be able to receive MMS only when there is no other connection active (and then open a connection to the MMS APN)? Assuming of course we can somehow read the WAP Push messages (if they don't show up in the el.db).

Re: Brainstorm: MMS Support
 

Glad to help and some participate in the development process.
Course possible to rise the connection to the MMS PDP and work fully with it, when other connections are inactive. This solution gives assurance of no collisions. Far as I know this is exactly the path that runs Windows Mobile. But that will have to make application, expected for continuous on-line Internet connection? Telepathy in particular. I think that it is single possible way for current situation.
Now the main effort in my opinion should be given to the study receiving WAP-Push. Without this, nothing will work.

Re: Brainstorm: MMS Support
 

The MMSC of my former employer marked an user/device as MMS capable as soon as the device send an MMS on its own. Part of the MMS submit request also can be a device id (string) and a profile URL (XML file), which in turn can be used for getting device capabilities and content conversion when sending an MMS to a device.

Yes, I timeout for retrieval could be used, too.

Gruß...Tim

Re: Brainstorm: MMS Support
 

It's about 1 1/2 ago I looked at MMS/IMS integration. But I'm sure that the provider will want all the old devices out their to still work - and their definitely do not SIP. So if we assume that legacy device support will continue for 5-10 years we should not care about SIP now.

MMS for the device is TCP/IP for retrieval and PUSH (IP, SMS but possibly also SIP in future) for sending.

GRX is something that is not relevant for the device. GRX is used (as above mentioned) for inter-operator communication between providers, in the MMSC case communication between MMSC.

From the view of the device it does use SMS and IP roaming.

AFAIK there is no device lock-out. Every device that can handle the procotol should be able to do MMS.

I personally based on my work for my former employer only know the communication after WAP gateway and similar network elements and thus cannot tell you anything about APs and kernel requirements. But I can help if it comes to MMS protocol/messsage/PDU handling.

Feel free to ask.

Gruß...Tim

Re: Brainstorm: MMS Support
 

The MMS capability mark as resoult of sending initial SMS is most popular case but it's still work-around. The right way is to provision MMS subscription from CCBS. In fact this method minimizes invocations from CCBS.
It's just for information.