I had an issue today where a client was getting a busy signal when dialing in or out. They have a Cisco phone system and their provider is Cox who uses an edgewater devices to convert the internet traffic to SIP traffic.
I accessed the BE6000 router/gateway and pinged the HP switch that has the phone system connected. I had one timeout and then it's like the connection between the router and the switch woke up. Is it possible that the connection on the uplink from the switch to the router wasn't communicating until I sent that ping request? As soon as I did that and it started communicating I was able to call in and they could call out.
Just seeing if that was a coincidence or had any significant impact.
Based on the information provided, there is no way to determine the cause why the Phone system was down. However, I can confirm that the switch would not be sleeping and come up after you ping it. It is not how switches work. The reason why your first ping timedout and received response on second one is most likely due to arp request and response, which is normal between hosts that haven't communicated directly with each other for sometime (arp timeout).
Related
We are developing an application where an iPhone should connect to an cc2564 device (Specifically cc2564+msp430f5438), the application should make quick and short connections to send some data. We need reliability in the connection so we need to know if the connection was really successfully or not, and we need a way to connect to the device with assurance.
The iPhone connects correctly to de device most times, it discovers services and works as expected, but sometimes the iphone makes the connection but the callback of discovered services is never called.
We used a sniffer to look at the communication packages and we saw that in those cases the connection package was send but there wasn't any response from the device, the phone tries to retry some version request messages and then stops, as you can see in the image:
The problem seems to be on the device, we are using the SPPLEDemo sample provided by Texas, and the first function that is called when the connection is established is GAP_LE_Evenet_Callback, and when the problem occurs it's never called. We don't know if somewhere inside the GAP API the device receive the connection message.
Is there some way to debug it or to know if the connection message is received by the device when the error occurs?
Is it a problem on the iPhone (unlikely), or is a problem on the device?
You quoted that
..the first function that is called when the connection is established is GAP_LE_Evenet_Callback, and when the problem occurs it's never called..
I'd recommend tweaking (playing) a bit with connection timeouts and Link Supervision Timeouts before consulting the experts who have developed the BLE Device firmware if that is possible for you.
Be assured that whenever a connection is made, the BLE device gets an event (callback) from the BLE stack that the connection has been established.
If that event is not handled the way it should be, then you can conclude that BLE device has some implementation issue.
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.
I develop IOS app, which needs to make standard TCP connection from one iPhone(or iPod) to another. Connection works well between apps on simulator and device, as well as between two simulators.
Application uses posix connect() and I have to stick to this method, because other modules are pure C.
When invoking connect() application blocks, and after timeout error is returned.
The communication is via wifi in LAN
I've sniffed the traffic and encountered, that after connecting to simulator, device sends ARP and after answer, standard TCP handshake proceeds and session is made.
Same case with iPhone<>iPhone stops after ARP request, because another iPhone doesn't respond to it. Moreover iOS sends only gratuitous ARP (announces it's mac ip pair). My MAC seems like proceeding this request, because its ARP table has iPhone record, it doesn't work for another iPhone.
I've tried bonjour service, but it also works only with simulator <> device.
My question:
Is there any way to allow such communication? Is it possible it is problem with my iPhones only? Is there any explicit way to tell OS to send response for arps, or is it somehow blocked for traffic ios<>ios communication.
Not sure if this will help, but I am working on a project that is doing something similar with devices announcing themselves on a network. We are using SSDP to send out an alive request from one device and other devices are listening on the multicast address and port. Once each device receives the alive, it sends out a response with all if its pertinent information, including IP Address and port. Unfortunately, SSDP is a send and forget type of protocol, so there are issues there. We use the IP Address and port information to send messages directly to each device.
Again, not sure if this helps in your situation, but I've seen this work very well so far.
Sometimes I am experiecing a delay while receiving APN , while at other times its working absolutely fine.
I am also connecting to the feedback server at ssl://feedback.sandbox.push.apple.com , but its not showing any data.
What are the possible reasons for the delay?
Thanks
Delay can happen if you've got a bad connection on 3G or Edge (iPhones use those, not wifi, for push unless they're totally unavailable). If the connection is dropped but the device doesn't know it, it'll wait until it does a heartbeat and realizes the connection is closed.
Also, if you're using an iPod Touch, the connection to the push servers will only be maintained while the backlight is on or you're plugged in via USB; otherwise the wifi connection will be dropped when the backlight goes off to save power, and it'll poll for new notifications every half an hour.
I have client/server application. Client on iPhone, the server on the Windows-based machine. First, I establish a connection to my server and that works fine. When I go away from WiFi area - client disconnects (is's expected).
But, when I enter into WiFi area again and tried to connect to the server, the connection is established but the client doesn't receive any data. I need restart my client application to connect to the server.
Why did it happen? This happens always when I'm sending data in both directions with about 1 Mbit/s.
I'll be thankful for any idea =)
Thanks
When you leave the Wifi area, Tcp detects that you have no connection, so the server will drop the Tcp connection. You have to reestablish it when you get back in Wifi range.
I am not an expert in this area, but maybe there is a time limit, within which, if you reenter the Wifi, the existing Tcp connection is reused?
However, to be robust, you should always code your app to retry, if operating in Wifi is one of your main scenarios.
Your TCP has gone into a long timeout trying to get the data through on a link that doesn't exist for a while. You need to detect this happening, close the socket, and reconnect.
Or, switch to using UDP if you don't actually need TCP's reliability (although this isn't its proper name, think of UDP as the 'Unreliable Datagram Protocol', in other words there's no guarantee of delivery, nor of delivery in the correct order).