Active Topics
-
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 1 day, 19 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 2 days, 15 hrs ago - more...
| The Following User Says Thank You to Performer For This Useful Post: | ||
 |
|
2009-10-19
, 15:56
|
|
Posts: 72 |
Thanked: 51 times |
Joined on Jul 2008
@ Germany
|
#62
|
Originally Posted by Performer
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.
It we talking about feature development of the platform we should bear in mind. See requirements of 3GPPr6.
Originally Posted by Performer
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.
Just the opposite: SMS and HTTP for the reception, HTTP for the transfer. For IMS-solutions - SIP in both cases.
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.
Originally Posted by Performer
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.
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.
Originally Posted by Performer
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.
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:
[...]
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
| The Following 2 Users Say Thank You to Framstag For This Useful Post: | ||
|
|
2009-10-19
, 16:06
|
|
Posts: 303 |
Thanked: 175 times |
Joined on Oct 2009
@ London UK
|
#63
|
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.
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.
|
|
2009-10-19
, 16:43
|
|
Posts: 72 |
Thanked: 51 times |
Joined on Jul 2008
@ Germany
|
#64
|
Originally Posted by cpitchford
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...
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.
.
Gruß...Tim
|
|
2009-10-19
, 17:44
|
|
Posts: 18 |
Thanked: 18 times |
Joined on Oct 2009
@ Russia
|
#65
|
Originally Posted by Framstag
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.
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
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.
|
|
2009-10-19
, 18:58
|
|
Posts: 182 |
Thanked: 540 times |
Joined on Aug 2009
@ Finland
|
#66
|
Originally Posted by Performer
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).
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.
That's why we are talking about "hacks" which mostly directed towards overcoming this client-side limitation without kernel changes.
| The Following 2 Users Say Thank You to abbra For This Useful Post: | ||
 |
|
2009-10-19
, 19:11
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#67
|
Originally Posted by abbra
Perhaps the feature/patch can be backported to Linux kernel 2.6.28? Minimal changes, community can test, Nokia can roll out stable later.
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.
__________________
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!
|
|
2009-10-20
, 04:01
|
|
Posts: 18 |
Thanked: 18 times |
Joined on Oct 2009
@ Russia
|
#68
|
Originally Posted by abbra
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.
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.
Last edited by Performer; 2009-10-20 at 04:04.
|
|
2009-10-20
, 05:16
|
|
Posts: 182 |
Thanked: 540 times |
Joined on Aug 2009
@ Finland
|
#69
|
Originally Posted by Performer
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.
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.
| The Following User Says Thank You to abbra For This Useful Post: | ||
|
|
2009-10-20
, 05:32
|
|
Posts: 182 |
Thanked: 540 times |
Joined on Aug 2009
@ Finland
|
#70
|
Originally Posted by allnameswereout
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
Perhaps the feature/patch can be backported to Linux kernel 2.6.28? Minimal changes, community can test, Nokia can roll out stable later.
| The Following 2 Users Say Thank You to abbra For This Useful Post: | ||
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.
Last edited by Performer; 2009-10-19 at 15:12.