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:

—————————————————-

#!/usr/bin/ruby

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)

  response.value

  puts response.body

end

—————————————————-

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.

Thanks,

Mike

17 comments

  1. Sandeep Kumar says:

    Hi Mike,

    Nice Post.. Helped me a lot to understand Windows Phone Push architecture in a better way..

    Though I found out some issues regarding MPNS will debugging my Push Service.

    1) The response code of the first push say “push 1” after sending my phone to a disconnected state, i.e. via switching off the phone or after switching the phone to airplane mode, give a response 200 OK (Active, Received, Connected). But from second push say “push 2” onward the response are as expected i.e. 200 Ok (Active, Received, TempDisconnected).

    2) “push 1”, “push 2” , etc that where send to the MPNS when the device was in disconnected state are not delivered even after the mobile’s connectivity is resumed. The push send after the mobile connection resumption is delivered just fine..

    3) Documents says that “After a callback is registered, if the device transitions into an inactive state, the MPNS will send the message to the callback URI with the payload registered”. But on observation I saw that my callbackURI received a request after the mobile phone transition from “inactive to active state state”. Though I prefer it this way more 🙂 😀 .

    Correct me if I am wrong.

    Thanks

    • mjfusa says:

      Thanks Jeremy – I’ve corrected the link and updated the post. Thanks for the feedback!

  2. Frank says:

    Even though my Push Notification enabled phone app is running, sometimes my web service gets a ‘temporary disconnected’ status when sending notification to the device. Notification seems to arrive immediately when I exit my app. So exiting the app seems to notify MPNS that the device is ‘active’ and trigger it to send out the message. Any way to notify MPNS that the device is active when I start my app (besides opening a new channel)?

    • mjfusa says:

      Frank – the active state refers to the state of the connection of the device to MPNS. This is not impacted by the state of the app (running, dormant or terminated). As soon as MPNS is connected to your device again, it will transition to the ‘Connected’ state. You mention you get the notification when you exit the app. This is normal for toast and tile notifications. You can receive toast notifications while the app is running but you need the callback to receive these implemented. Raw notifications are only received when the app is running.
      I hope this helps.
      Mike

  3. Kunjan says:

    I am using an authenticated channel in my application. At times my device comes into a state where even on the first push I receive 404 from MPNS. There is hardly a delay of few minutes between channel procurement and sending the first push notification. Then after sometime ( usually couple of days) things again start to work normally although there is no change in the payload being sent..

    Any suggestions what might be causing the immediate expiry of procured push channel URl?

  4. Chris says:

    Hi Mike,

    nice overview!

    To the following question:

    “What is the limit of notifications I can send to the users of my app?”

    Do you have a source of Microsoft (MSDN) for me where I can read about it? I have found nothing about a possibility to open more than one channel per app. I guess I have read that Windows Phone is limited to 30 channels per device too.

  5. Stu says:

    What kind of certificate do I need to purchase for this? Is it called a Code Signing certificate or would a standard SSL certificate we use on our server for HTTPS traffic from one of the supported authorities by sufficient?

  6. Michele says:

    Hi there, thanks for this useful Faq!
    I would like to get some clarification on MPNS and Disconnected status:

    1.

    What is the proper way to handle ChannelErrorType.PayloadFormatError ?

    Is it something informative or we need to take action in some way?

    Do we need to close the channel or is it enough to call the Find method and then instantiating and opening a new HttpConnectionChannel ?

    2.

    What is the proper way to handleChannelConnectionStatus.Disconnected ?

    Again, is it something informative or we need to take action in some way?

    Once the status is Disconnected, can return to Connected without taking any action?

    Do we need to close the channel and try another open?

    3.

    Does the ChannelErrorType.PayloadFormatError trigger also aChannelConnectionStatus.Disconnected events?

    thanks

Comments are closed.