Well I have the socket sample working now. This is what I have learned.
The first PDP context is used.
The sample app takes care of ‘cgatt’
In my case, the app needs to be started a few times at times. It is somewhat intermitten, however; once it is running it seems solid. The problem looks to come from the way the app waits for the cgatt response, which needs to be “OK”. When that response is recieved, the device is not always copletelly attched. I put a small delay aftre calling the cgatt, and it seems to improve the execution.
In my case, which should be the norm, the ISP uses a NAT server on for thier public APN. Now it is possible to use a socket like a UDP stream as long as the packets are comming or qoing every 40 seconds. That is how long the NAT server will keep your IP in it’s table. After that the entry is droped. So once must make sure the socket on the ME is initiating communications very reguarly.
To establish a routable IP, you have to get an additional APN (in my case) designed for that purpose. This APN has dynamically assigned static IPs from a pool of static IPs. So the IP is static but only for the duration of PDP context activation, which is indefinate or limited by the quality of service.
The ping functionality is not allowed, as it is a security hole and this should be the case for most ISPs.
Public or static IPs are available, but very uncomen and if used, it is at a request where it has to be proven that is needed. So no matter how one goes about it, the ME app should not be the server. If it has to be, then some sort of DNS with a wired server somewheres should be implemented. This provides a lookup for ME(s) that periodically report to the server.
Any commets are appritiated