Tag: push

Windows Phone Push Notifications: Frequently Asked Questions

Updated March 3, 2013 – added clarifications around the use of certificates.
The following is a collection of FAQs regarding Windows Phone Push Notifications.

Q: How can I get started with Push Notifications?
A: A good way to approach Push Notifications is using a known working sample. Entire sample including client and server code here. Once you get the sample working, you can transfer that to an actual application. This way you can be sure you are composing the push notifications correctly. I would they suggest they get the sample working and then compare that to how they are doing the same notification type.

Q: Do we have to get a new URI if the original URI was received more than 30 days ago?
A: No. As long as the URI has not changed, you can continue to use the URI.

Q: How do we know if the URI has changed?
A: When the app starts, do an HttpNotificationChannel.Find and compare to the previously received channelURI stored in isolated storage. If different, update the web service registration with the new channelUri. If empty, recreate the Channel. See the file MainPage.xaml.cs in the sample here where this logic has been implemented. Note that it is a best practice to send along with the URI information that uniquely identifies the device (DeviceExtendedProperties.GetValue("DeviceUniqueId"). You can use this information when re-registering channel URIs with your web service to replace the existing (invalid) URI with the new one.

Q: How can we tell at the web service if the URI we are sending to the MPNS is still valid?

A: The MPNS will return a 404 response code with one the following notification statuses if the URI is not valid:

Response Code NotificationStatus DeviceConnectionStatus SubscriptionStatus
404 Not Found Dropped Connected Expired
404 Not Found Dropped Temporarily Disconnected Expired
404 Not Found Dropped Disconnected Expired

Note that your web service should stop sending notifications to this URI and un-register it, if the MPNS returns 404 (Dropped).

Q: What causes the MPNS to return the 404 (expired) response code?
A: The following conditions will cause a channel URI to become expired:
1) No activity for 30 days (the channel uri is not used).
2) The device is unable to connect with the MPN server for 30 days. In this case, MPN will return the 412 (inactive) response code, if it cannot connect within 30 days, it will return 404 (dropped).
3) If the xml payload of the notification request is not valid, MPNS will invalidate the channel uri and return 404.

When the application restarts it will receive a new channel URI, which should replace the current (expired) channel URI registered with the web service.

Q: What causes the MPNS to return the 412 (inactive) response code?
A: If the device has been off or otherwise cannot connect with the MPNS it is considered ‘temporarily disconnected’. When the device is in this state, the MPNS will return:

Response Code NotificationStatus DeviceConnectionStatus SubscriptionStatus
200 OK Received Temporarily Disconnected Active

If the web service sends another notification to this URI and at least 90 minutes have passed since the last ‘temporarily disconnected’ notification, MPNS flags the URI ‘inactive’ and will return the 412 response code. In this state, MPNS stops attempting to connect to the device. Note that temp disconnected and inactive are both natural states for a mobile device and shouldn’t be viewed negatively. Commonly 30-40% of devices show temp disconnected at any one time and 10-20% show inactive because mobile devices transition between network conditions and situations frequently.

Q: Besides sending a notification request to MPNS, is there any other way to know if a channel uri (device) has transitioned to the ‘inactive’ state?
A: No. Previous documented was a callback mechanism where authentication notifications could receive a callback if the device transitioned from active to inactive. This has been deprecated and removed from the documentation.

Q: If the PNS is no longer attempting to connect to the device, when does it start communicating again?
A: The PNS will attempt to connect to the device when the Web Service sends the next notification request. The response code returned reflects the devices state (200 – URI OK, 404, URI invalid, 412, URI OK, Device out of communication)

Q: What does the PNS response code 200 suppressed mean?
A: You can receive the suppressed status when for a:

  • Tile notification if the user hasn’t pinned the tile
  • Raw when the app is not in the foreground
  • Toast and Tile when the device is in low battery state

Q) What is the limit of notifications I can send to the users of my app?
A) By default, the limit is 500 notifications per channel URI per day. So if you have multiple notifications (say Toast and Tile) in your application, you can send 500 of each type. That is 500 of each type of notification per device / user. For example, if you have 100 users of your application and 1 type of notification, you can send up to 50,000 (1 * 500 * 100) notifications per day. Authenticated notifications are unlimited.

Q) How do I setup authenticated notifications?
A) Follow the guidance here: Setting Up an Authenticated Web Service to Send Push Notifications. Pay particular attention to the set up of the certificate. For more information on setting up the certificate, see here: No-quota push notifications using a root Certificate Authority.

Q) What can cause a 401 (Unauthorized) status returned when attempting to send an authenticated notification?
A) Can can get a 401 if the Service Name in the certificate does not match the service name parameter in the HttpNotificationChannel constructor. Also, the client will receive a URI with an ‘http’ prefix. If functioning properly HttpNotificationChannel  will return a Uri with an ‘https’ prefix.

Q) I am setting up authenticated notifications and am getting back a 403 status code in my web service code. What is going wrong?
A) Generally, a 403 (forbidden) status is what you would get if either you are not including a certificate in the POST request or it is not a valid/trusted cert. Note that the certificates need to be deployed onto the web servers sending the requests. These certificates should include the private key. (The certificate uploaded to Microsoft should NOT include the private key.) If using an intermediate certificate, ALL of the certificates in the chain should be added prior to the POST request (see below).  When submitting your application to Marketplace, you will also need to associate your application with the appropriate certificate. This is done in the ‘describe’ step.

Q) How do I include a certificate(s) in the POST request?
A) If you are using .NET in your server code, you can add the certificate to the HttpWebRequest as follows:

Request.ClientCertificates.Add(new X509Certificate2("[PathToCertificate]", "[Password]"));

If you are using Ruby, you can add the certificate as follows:



SERVER_CERT_FILE = "certs/freshCA.crt"

CERT_FILE = "certs/s2 at magnesium.crt"

CERT_FILE_KEY = "certs/s2 at magnesium.key"

require ‘net/https’

https = Net::HTTP.new(‘fresh’, 443)

https.use_ssl = true

#client certificates

https.cert = OpenSSL::X509::Certificate.new( File.read(CERT_FILE) )

https.key = OpenSSL::PKey::RSA.new( File.read(CERT_FILE_KEY), ‘panza’)

#server certificate

https.ca_file = SERVER_CERT_FILE

https.verify_mode = OpenSSL::SSL::VERIFY_PEER     #VERIFY_NONE

https.read_timeout = 120

https.start do |https|

  request = Net::HTTP::Get.new(‘/notes/test_auth’)

#  request.basic_auth ‘s’, ‘x’

  response = https.request(request)


  puts response.body



Q) In the code above, does this mean the private certificate (definition below) is sent as part of the request?
A) No. The private certificate is used to sign the request. The server then uses the included public cert to decrypt the request.

Q) When do I use a private certificate and when do I a public certificate?
A) First some definitions: a private certificate is one that includes the private key or is used along with a separate key (.key) file. A public certificate is one that does not include the private key. Note that with push notifications, you will use both private and public versions of your certificate.

Q) When do I use the public certificate? When do I use the private?
A) Upload certificate to Dev Center: Public
Install certificate on my web server certificate store: Private
Certificate included with POST request to MPNS: Private

Q) What can cause a 409 to be returned from the MPNS?
A) A 409 is returned when using authenticated notifications and the certificate has expired. You will need to submit a new certificate.