I am developing an application with push notification.
When the receiver is not connected to WIFI/internet while the sender is sending messages, does the receiver receive all of the sent messages when the receiver reconnects to the internet?
There is a queue that will be sent to the user once he/she gets an internet access. However if the user is without internet for a "long time" there is no guarantee that the notification will be sent/recveived.
The Apple documentation is very vague on what amount of time that is considered long time. (See documentation)
Apple Push Notification service includes a default Quality of Service (QoS) component that performs a store-and-forward function.
If APNs attempts to deliver a notification but the device is offline, the notification is stored for a limited period of time, and delivered to the device when it becomes available.
Only one recent notification for a particular application is stored. If multiple notifications are sent while the device is offline, each new notification causes the prior notification to be discarded. This behavior of keeping only the newest notification is referred to as coalescing notifications.
If the device remains offline for a long time, any notifications that were being stored for it are discarded.
However I've heard that the APNS will try to resend the notification for approximately 25-30 days. However there is no official documentation supporting this!
No by APNS and other fire base its not possible to get all notification.
we can take only the last notification send by the application .
another possible solution is to save in database and write one scheduler to fire notification after period of time limit.
When the device is connecting to APNs over WiFi ensure that no firewalls are blocking inbound and outbound TCP packets over port 5223.
5223 port communicate with APNS . and see following are other solution for it.
TCP port 5223 to communicate with APNs.
TCP port 2195 to send notifications to APNs.
TCP port 2196 for the APNs feedback service.
TCP port 443 is required during device activation, and afterwards for fallback (on Wi-Fi only) if devices can't reach APNs on port 5223.
Check with your network administrator to make sure that the ports are accessible.
Related
Working on a SIP application that requires monitoring call activity/state on a phone. My app (UA) is registered with a proxy server, as is the phone being monitored. I am making use of SUBSCRIBE/NOTIFY messages to tell the phone that I want to know about its "dialog" events, and once subscribed, this works fine. I am running into two problems:
I am requesting a subscription length of 900 seconds and consistently getting some absurd amount of 4000+ seconds returned from the phone.
There is the possibility that the phone may be unplugged while the subscription is active (don't ask, but, yes, this is a possibility). When this happens, I am not getting any type of notification as to the phone no longer being available. Consequently, I have to wait for my subscription to time out, try and renew it, handle the failure, and create a new subscription.
I realize that I can renew my subscription sooner than its expiration time, but is there a better way to go about it? For example, would I be able to get "presence" events and use them to know when the phone is there or not? Are those events always guaranteed to happen on phone start-up, and even so, since there is a proxy in the middle, would I even get the notifications, or would I still not know that the phone restarted and no longer recognizes my subscription(s)? Are these "presence" updates something that I can request from the proxy?
Any insight would be great; for the moment, I'm going to simply try and refresh my subscription on a much smaller interval, but I would love to know if there is a better way to go about it. Thanks in advance.
I don't know about a SIP agnostic way other than perhaps somehow pinging the phone but there is definitely a SIP way to do presence and that's using the same subscribe/notify model you are using for dialogs but in this case for presence. The relevant standard is RFC 3856 A Presence Event Package for the Session Initiation Protocol (SIP).
Typically the presence notifications would be generated by a SIP registrar, and since you say your phone is registering with your proxy it must also have a registrar built in. The registrar would notify your UA when the other phone's registration status changes such as when it first came online or when it failed to re-register. As far as the delay between a phone "disappearing" and the registrar server detecting it there's no prescribed way to do it. You can either wait for the registration period to expire and mark the phone as offline when it fails to register or alternatively the server could actively send a packet or even a SIP request such as an OPTIONS request to the phone and mark it as offline if it got a failure response, Asterisk uses te latter approach.
When a SIP UAC client registers with a SIP UAS Registrar, the SIP client provides a Expiry Header, which indicates that maximum amount of time after which a SIP client needs to re-register itself. If the SIP client does not re-register itself in this time period, then Sip UAS proxy/registrar server will mark the client as disconnected.
Proprietary SIP packages like FreePBX and Asterisk, proactively, send SIP OPTIONS to the client, continuously, at some interval, wherein the client responds with OK. This is a more proactive way of validating if SIP clients are online; however, this technique is proprietary and not part of the actual SIP specification.
I am implementing a VOIP application in which I work with SIP protocol. As per SIP I need to refresh my registration with SIP server at certain interval. But when my app goes in background, my keepalive handler is invoked only after 600 seconds as per documents os Apple. But this is not desired with SIP protocol. To be able to keep my connection alive with server and receive incoming call, I need to send registration message before 600 seconds even when app is in background. According to Apple documentation this is not possible but stilll I have seen apps on AppStore which runs in background and keeps their registration on with SIP server even when registration interval is 60 seconds. They keep app running in background throughout. So how is this possible? I know that playing silent audio in background will survive but then AppReview process will reject it. But if its so, how Apple allowed other such apps on AppStore? Is there some standard way to achieve what I have described above? Any help is appreciated.
You don't have to send the registration more often. You can do something like this: configure your server to send keep alive packages to your sip client in order to keep the TCP connection open. Your server should support TCP connection and your client should communicate over TCP since apple is very restrictive in background mode and only the TCP connection is allowed to remain open in the background (if your TCP socket is wrapped with CFReadStreamRef).
The problem is no the registration message, this can be configured by the client by specifying the time between the connection attempts, and the sip sever will be fine with an interval of one hour between 2 registration messages. The real problem is how will the server contact the sip client in case of an incoming call or IM. Most of the sip clients will not have a public IP adress but most probably they will be behind a NAT. So there is no way the sip server can open a direct connection to the sip client, for this reason you have to keep a socket open between your client and the server.
None of the app in the appstore is sending registration message more often than 600s.
Do you use your own library for sip or you use pjsip? If you use pjsip i can give you more hints. What SIP server do you plan to use?
Some hints:
make sure you set in your app-info.plist the required background modes to "App provides Voice over IP services" and "App plays audio"
in case your app will not be tied to your own sip server then provide a way for the user to disable the allow_contact_rewrite pjsip param (usually u want this to be enable for bypassing the nat problem) since some session border controllers are not happy about this feature
make sure, in case you capture the messages send form the sip thread in your main thread, you are using a method to post them in the main thread
here are described some other interesting issues
have a lot of coffee prepared :))
This application support send a scheduled sms in background mode! How to they do that?
What do you think about this their info:
In order to send out the scheduled message:
This app must be running on your iPhone, either in the background or in the foreground;
Your iPhone must not be in the airplane mode;
Your iPhone must have carrier's signal at the scheduled time;
NOTES:
If you schedule a message with a large number of recipients, please check with your carrier for the maximum number of recipients allowed per message. If you exceed the maximum number allowed, your message may be blocked by your carrier.
Your iPhone must be powered on at the scheduled time so that the message can be sent out;
If you reboot your iPhone, or turn it off/on, remember to restart this app as soon as possible so that the timer can still be active.
Some results from testing...confirms this app is sending normal SMS WITHOUT user interaction!
WLAN ON + GSM OFF (no reception) => the app does NOT send SMS, even after reception is back no SMS gets send. In the phone's messages log it tells "failed sending SMS"
WLAN OFF + GSM ON => the app sends SMS without user interaction (I checked my bill, and in fact a SMS got sent through the provider! - no data traffic to a server!)
Also, by the way when the SMS is received the sender's SMS number is displayed correctly. I know one could do this through a SMS server - but in fact a REAL SMS got sent through the provider! There was no data traffic, no other cost than my providers SMS charge, and on the past activities it explicitly showed this SMS!
So somehow this app sends a real SMS without user confirmation.
Probably there is a way to use the direct SMS library without Apple's review team finding out? Anyway I know for sure, that Apple rejects apps that use this library (if they find out!)
Your best bet is to setup an intermediate server on the internet that uses an online SMS sending service, and send the SMSs via that route if you need complete automation. (ie, your program on the iPhone sends a UDP packet to your server, which sends the real SMS)
I know how to make a TCP connection from a phone to a URL (server)
I know how to make an HTTP connection from a phone to a URL (server)
I do not know how to make a connection from a server to a phone
Is there a way to use the phone number of a phone to bridge from voice network to data network of the same provider (VERIZON or AT&T or ROGERS in Canada)?
In essence I wish to find a way to make a "phone call" from a server, over the Internet and over the local data network or WiFi, to a phone, without using any intermediaries
We are willing to pay for this info (optionally)
You can use Push Notification Systems for connecting to the phone. Ideally, you'd want to initiate a pull of data from the device when it receives a push notification from your server. This is because push notifications can handle only small amounts of data.
Another option for you, would be to open a socket on the client device and broadcast this address to your server during startup. Later, your server can directly connect to the listening port on your device, provided the app is still running.
You could send a push message to the phone and let the phone establish the connection.
Just a rough short sketch, maybe this will help you. If I'd had to solve that problem
i would use androids Cloud2Device messaging to tell the phone to connect to a certain
server which you specify in the message from the cloud. Then the phone connects to your command server and you can tell over the connection what the phone should do.
This way you dont have to execute a server on the phone.
Look here
My Ideas
1.Have a look at http://developer.android.com/reference/android/net/sip/package-summary.html
2.Use C2DM(cloud to device message),It will send the message to your app
3.Use XMPP chat client from the server you can send the message to android app after receiving message your app can call(it depends on your logic)
There is no universal one-to-one mapping between cellular phone numbers and IP addresses (e.g. the user could have driven out of cell tower range to a coffee shop with wifi). So this is impossible to do directly.
The services that do seem to do this require a running app on the mobile device to cooperate by periodically connecting to some centralized database using its current IP address, which some server can record in its database for you to do a lookup when want to try to connect to that mobile device. Google "SIP service providers".
How the server know whether the push notification received by iPhone(and also the action that user performed (tapping "Cancel" or "View")). Do i need to send separate message from client to server that "Notification received" or Is There any mechanism to get status from APNS by server so that I can avoid sending a message from client side.
I have checked enter and Push notification guide, but I didn't find any information.
As per the documents there is no guarantee for a notification to be received successfully. Also APNS won't inform the server about a successful delivery of push notification. So better
on the method
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
{
//you can send a message to the server so that server can make sure that notification is delivered successfully.
}
FYI : If notifications to a particular device token is getting failed continously the APNS will inform about that.
From apple docs
"Apple Push Notification Service includes a feedback service that APNs continually updates with a per-application list of devices for which there were failed-delivery attempts. The devices are identified by device tokens encoded in binary format. Providers should periodically query the feedback service to get the list of device tokens for their applications, each of which is identified by its topic. Then, after verifying that the application hasn’t recently been re-registered on the identified devices, a provider should stop sending notifications to these devices. "