Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 1 day, 10 hrs ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 1 day, 11 hrs ago -
Maemo repository (3)
to Community by torsen - 2 days, 3 hrs ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 3 days ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 4 days, 7 hrs ago - more...
 |
|
2009-10-16
, 18:58
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#52
|
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?
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.
Originally Posted by Performer
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.
All that all of you talking about implementation MMS support is dirty hack.
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.
Thanks for your contribution.
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
| The Following User Says Thank You to allnameswereout For This Useful Post: | ||
|
|
2009-10-17
, 11:19
|
|
Posts: 18 |
Thanked: 18 times |
Joined on Oct 2009
@ Russia
|
#53
|
Originally Posted by allnameswereout
In IMS infrastructure MMS agent shoud request service thru SIP before applying MM1. Just check specs of MM1st3.
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.
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.
Originally Posted by allnameswereout
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.
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.
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.
Last edited by Performer; 2009-10-17 at 12:50.
| The Following 4 Users Say Thank You to Performer For This Useful Post: | ||
|
|
2009-10-17
, 20:39
|
|
Posts: 182 |
Thanked: 540 times |
Joined on Aug 2009
@ Finland
|
#54
|
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?
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?
| The Following 5 Users Say Thank You to abbra For This Useful Post: | ||
|
|
2009-10-18
, 07:57
|
|
Posts: 18 |
Thanked: 18 times |
Joined on Oct 2009
@ Russia
|
#55
|
Originally Posted by abbra
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.
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?
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.
Last edited by Performer; 2009-10-18 at 08:05.
| The Following 4 Users Say Thank You to Performer For This Useful Post: | ||
|
|
2009-10-18
, 08:54
|
|
Posts: 547 |
Thanked: 1,383 times |
Joined on Sep 2009
@ Stockholm, Sweden
|
#56
|
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).
Last edited by frals; 2009-10-18 at 08:56.
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).
__________________
Problem with fMMS? Run in x-terminal: cp /tmp/fmms.log /home/user/MyDocs/
After that you'll see fmms.log in filemanager or when you connect the device to your desktop as a mass storage device.
E-mail the log to me, if you don't have the email address, drop me a PM. Thanks!
fMMS - MMS for your N900
fAPN - GUI for adding a new GPRS APN
If you like this post, don't be shy to thank me -->
Problem with fMMS? Run in x-terminal: cp /tmp/fmms.log /home/user/MyDocs/
After that you'll see fmms.log in filemanager or when you connect the device to your desktop as a mass storage device.
E-mail the log to me, if you don't have the email address, drop me a PM. Thanks!
fMMS - MMS for your N900
fAPN - GUI for adding a new GPRS APN
If you like this post, don't be shy to thank me -->
Last edited by frals; 2009-10-18 at 08:56.
|
|
2009-10-18
, 09:39
|
|
Posts: 18 |
Thanked: 18 times |
Joined on Oct 2009
@ Russia
|
#57
|
Originally Posted by frals
Glad to help and some participate in the development process.
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).
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.
 |
|
2009-10-19
, 13:50
|
|
Posts: 72 |
Thanked: 51 times |
Joined on Jul 2008
@ Germany
|
#58
|
Originally Posted by frals
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.
The way I understood it, the first message asks the phone what capabilities it has, but I assume there is some kind of timeout for that response as well as you said tso.
Yes, I timeout for retrieval could be used, too.
Gruß...Tim
| The Following User Says Thank You to Framstag For This Useful Post: | ||
|
|
2009-10-19
, 14:08
|
|
Posts: 72 |
Thanked: 51 times |
Joined on Jul 2008
@ Germany
|
#59
|
Originally Posted by Performer
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.
In IMS infrastructure MMS agent shoud request service thru SIP before applying MM1. Just check specs of MM1st3.
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.
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
| The Following 3 Users Say Thank You to Framstag For This Useful Post: | ||
|
|
2009-10-19
, 14:32
|
|
Posts: 18 |
Thanked: 18 times |
Joined on Oct 2009
@ Russia
|
#60
|
Originally Posted by Framstag
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.
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
It's just for information.
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.