There are some ios sip applications who are able to communicate with a UDP only SIP Server.
As I know iOS allows only TCP connection to remain open in the background but most of the SIP providers are supporting only UDP.
I have noticed that iOS application 3CXPhone has a "NAT helper mode" and it is able to keep the communication in background with a 3CX Phone system who is UDP only. Dose anyone know what trick do they use? I am developing an SIP app and I have to make it work for the UDP only SIP providers.
I know there are multiple questions regarding UDP socket in background on SO but none of them has a useful answer or the solution proposed there dose not work anymore (starting from iOS 6).
Until now I am aware of 2 possible solutions:
1. Use some GPS events and during that events maintain the socket communication too. After that try to trick apple and get your app in the store.
2. Use a SIP proxy in the middle (B2BUA). But in the 3CXPhone "NAT helper mode" I am not seeing any sip proxy configuration.
If you really need a UDP socket you will need a few things:
UIRequiresPersistentWiFi: to ensure that iOS connects to Wi-Fi and doesn't turn it off after some time (I'm assuming you want Wi-Fi as well, if not just ignore this one)
Play an empty audio in the background in a loop to keep your application active.
Have a timer that pops every ten seconds or so and sends a small (e.g. crlf) message to the server.
The last step is needed to keep the UDP connection open in the network. If you don't send anything often, someone in the network (e.g. a router) will close it.
The empty audio file is the only way to ensure you can do something in the background in short intervals (the ten second timer).
After writing all that: this will consume a lot of battery. Users will not leave your app running for long.
Most modern SIP servers support TCP. You should really spend your time on a TCP solution. The UDP one won't be accepted by your users.
Related
Can anyone tell me, is it possible to create an iPhone chat app without using a server. I just need only two connections.
I guess it would be possible by the two devices have to be directly connected (i.e. bluetooth, wifi, etc.). They may therefore discover each other (at an application layers i.e periodically broadcasted UDP packets on a give port?), create a tcp connection (or UDP but in this case you should ensure at application level all the sent messages are actually received..) on the top of which the actual chat protocol can be realized
I have an idea of an application that involves a "chat feature", basically an ability for people to chat with each other. Since sending messages through a server would be slow (plus it would be pretty bad having to check the server every second if you have new messages) I want to use sockets to have peer to peer chat ability instead of going through a server.
My 2 questions:
1) Is socket programming the most optimal way to develop a chat program? I know there is push notification service, but I don't think it can be used for a chat program too well. Going through a server seems kind of bad if you imagine 5,000 people chatting and having to poll the server every second.
2) Will Apple have issues approving an app that has peer to peer chat program that uses sockets?
Thank you.
Sockets are indeed appropriate. But you are better off with a client/server approach rather than a P2P approach.
Having worked on a very well known instant messaging service for many years, I can tell you absolutely that going through a server is not slow - as long as your server is not slow.
Client/server has lots of advantages. Namely, it's not as difficult as any sort of P2P connectivity where such issues as NATs and Firewalls make direct socket connections difficult and unreliable. Besides, you would need a messaging service anyway for clients to exchange IP addresses.
Your stated assumption that a client or server would have to "poll" is not how scalable systems work. You should use a persistent TCP socket and look at scaling a socket service up though any of the available async methods that exist today. select(), poll(), epoll on Linux, and IO Completion Ports on Windows are all techniques for having thousands of sockets simultaneously connected without periodic polling.
My suggestion - just deploy an XMPP/Jabber server. Most implementations scale up nicely to the thousands of clients. Then your chat program is just an XMPP client socket. Some of the Jabber servers even support HTTP connectivity for situations where a user's only access is via an http or http proxy server. I played around with Openfire a while back and was reasonably impresseed.
I'm fairly certain that iOS has sockets, and that it's allowed by Apple. I only know via second hand from folks that have worked on iOS products. You probably shouldn't use the push notification service for anything more than notifications to wake up your app that there is something it needs to do.
Hope this helps.
From my understanding you cannot socket a connection between two iPhones (correct me if I'm wrong). So what I would like to do is have one server sitting between the client application that accepts messages and redistributes them to the appropriate person(s). Essentially the application is going to allow people to have a shared map that has their locations and everyone can annotate it.
1) I have been reading and researching into the CFStream class, but I'm curious to know if it might be better to just use the C send() and recv() functions. They almost seem much easier to use. What does CFStream offer over the native C socket functions that make it a better option?
2) Since I need the phone to actively listen for updated shared user locations/new annotations from other users, my plan was to periodically have the phone poll the server for any "news" from other users (say every minute or two). Is there anyway the phone could spin off a new thread in the application that is constantly waiting for incoming traffic? It would make life easier to be able to have a user annotate the map, push that to the server which then immediately updates the appropriate users maps.
I have been using example socket code from Jonathan Zdziarski's iPhone SDK book from O'Rielly Media to just try sending messages between a server and iPhone emulator (the classic knock knock joke server/client). However, after sending 1 or 2 messages the server gets stuck "receiving." The code runs perfectly when not sent from an emulator, as I can seemly spam the client send function and get a response from the server each time. Could the server be hanging because I use send() and recv() instead of the CFRead and Write stream?
You can socket iPhone applications using bonjour, or even GameKit (which is what I use because it manages all data for you).
I have an iPhone on a 3G cellular network and a server on the internet and I want them to be able to exchange messages bidirectionally. Sometimes the iPhone makes a request to the Server some other times the Server makes a request to the iPhone. Problem is that the iPhone is behind the NAT of the cellular network and it doesn't have a fixed ip:port , on every new connection the port changes.
I think I have to make a bidirectional socket SO_REUSEADDR/SO_REUSEPORT and make the connection persistent.
The other two solutions are Apple's Push notification and long polling, for now I need an answer for the P2P solution between the iPhone and the Server.
Can you advise me on what I have to do or provide me a working example code where an iPhone can receive messages from a host that is on the internet?
It is a pity that Java is not supported on the iPhone, because the JXTA framework would have solved your issue easily.
What you are looking for is a TURN like implementation of P2P. The Iphone has to initiate the connection to the server to punch the hole in the NAT and yes, it has to be kept alive (even if you investigate more sophisticated implementations like STUNT for NAT traversal).
With TURN, the server has to transmit messages between IPhones, with STUNT, messages are transferred directly between devices, but it is quite complicated to implement properly.
i've been doing a lot of reading up on these things and my understanding is that XMPP is the solution for you. use an open source XMPP server (like openfire) and XMPPframework (an ios module).
I would like to be able to develop an iPhone application that can communicate with Modbus devices, but I'm not sure how to proceed. Has anyone had experience with this or are there existing libraries out there for this purpose?
You will need first to know how to make a simple TCP client on your iPhone, and a simple TCP server on your computer that your iPhone client will talk to via WiFi. Make sure PING command works and firewall does not block your server port before any client/server experiments, and make sure that server port for experimenting is greater then 1024 and not already used. Then take a look at MODBUS TCP specification from official site, get familiar with function codes you are interested in, and study C code found here. Then make a simple MODBUS TCP client that can send a request to MODBUS TCP server and interprete an answer. The best way is to start reading single register value, then progress in time and add more functions.
I do exactly all above points, my iOS Modbus lib works fine, application is now up on AppStore, PLCLink read and set any modBus data into my Wago home automation.
Installation guide : http://pautex.fr/plclink