Q: What is the WAP Push Library? A: The WAP Push Library (WPL) is a collection of run-time libraries, development tools and sample code that makes it easy to develop services that utilizes the features of the Openwave WAP push implementation.
Q: How does WAP Push work? A: WAP Push allows a content server to push content to a WAP 1.2 enabled handset proactively. This is done by sending a specially formatted (Push Application Protocol, PAP) XML document to the Push Proxy Gateway (PPG), that in turn forwards it to the handset.
Q: How exactly does the run-time library work? A: The run-time library is a collection of Java classes that abstracts the complexities of the PAP protocol. That is, when using the Openwave WAP Push Libraries the developer will not have to bother about constructing XML documents according to the PAP protocol. All that needs to be done, is to fill out data-fields in the Java objects.
Note that you will need access to a Push Proxy Gateway in order to use the run-time library.
Q: How can I test my push applications? A: Testing push applications is easily done with the PushIT tool included in the Openwave WAP Push library package; PushIT has a graphical user interface for building PAP messages and sending those to handsets. Together with the Openwave SDK, WAP edition 5.0, a total end-to-end push environment can be simulated.
Note that you will need access to a Push Proxy Gateway in order to use the PushIT tool.
Q: How can I use the Openwave SDK to test push? A: You need to configure the SDK to access a real Push Proxy Gateway. The Openwave Mobile Access Gateway (MAG) version 5 implements such a PPG. Under the settings in the SDK, You can configure the gateway to access, as well as the client ID by which the SDK will be identified when targeting it for push messages. Please refer to Chapter 4 WAP Push Library Developer's Guide for details.
Q: How can I get access to an Openwave Mobile Access Gateway? A: The Openwave developer site hosts a MAG with PPG that can be freely accessed and on which you can create a subscriber.
To receive pushed content, you need to create a subscriber account. Test subscribers provisioned on the Openwave Developer MAG receive pushed content via the same version of Openwave Push Proxy Gateway (PPG) deployed by network operators.
Visit the Mobile Access Gateway Provisioning section of the Openwave Developer web site for instructions on how to sign-up for a developer provisioning account. When you sign-up, a test subscriber is automatically created for you. After you sign up, view your WAP subscriber and copy the Client ID (IP Address) and Subscriber ID values for future reference. You need the client ID to configure your phone simulator device settings
see step 5 of the WAP Push Quick start Guide .You need the subscriber ID to specify the recipient of your pushed content see step 8 of the WAP Push Quick start Guide .
Q: Will the applications I write using the Openwave WAP Push Library work on all WAP phones? A: The Openwave WAP Push Library (WPL) is implemented according to the WAP 1.2.1 specifications. All gateways (PPG's) and handsets that are implemented according to this standard can be addressed using the WPL.
Q: Will the Openwave WAP Push Library ship on other platforms than Java? A: Yes, there are future plans for the WAP Push Libraries to be supporting platforms other than Java. Refer to the Openwave developer site for updated information on the WAP Push Libraries.
Q: How do I give comment or feedback on the WAP Push Library? A: Comment and feedback are very welcomed. You can post them in the Question and Answer section of this discussion area
Q: Are all the features specified in the WAP Push Specifications implemented by the WAP Push Library ? A: Yes, all the features are implemented in the "pushlib" run-time library, and are also supported by the Openwave PPG. However, some special tags and attributes are currently not supported by the Push-IT demo application (refer to the release note), and "Push-IT" doesn't currently support HTTPS. These features are all in the roadmap for next release of the WAP Push Library.
Q: I can't send push message to the S45 via SMS with URL that is longer than 50 characters. A: The original wappushlib.jar file includes some standard HTTP headers in the Push request. These headers are also sent to the handset. In the case of Push messages sent via SMS, these headers will also be included in the SMS message and hence limited the number of characters available for the URL. You can download a modified version of the wappushlib.jar from here. All you have to do is to replace the original wappushlib.jar with this new version in the \lib directory.
Q: I'm using PushIT to deliver push messages to a handset via SMS, but the push message never reaches the handset. What could be wrong? A: Push messages needs to be sent as "unconfirmed" for using SMS as bearer. Please make sure you specify unconfirmed as deliver method in quality of service.
Q: I have a dynamic IP address...what happens? A: If your IP address is dynamically assigned to you by your Internet Service Provider, you can provision your simulator to the gateway based on a dummy IP address. Then, all you need to do is launch the simulator, select "simulator","device settings", select "proxy 3" and enter "devgate2.openwave.com", enter IP Address(IPv4 Packet/Circuit) as the Client ID format and the dummy IP address as the client ID, also enter 9203 as the server port.
Q: How is WAP Push different from SMS and Openwave's previous implementation of Push? A: In addition to the benefits described above, WAP Push allows delivery of more content (1400bytes) as compared to the limit of 160 characters with SMS. That content is also not limited to text, but can include images, sounds, and WML. Therefore, the end user can receive much richer content and can immediately take action on the content (e.g., click to get more information, download an image, make a transaction).
Other differences between WAP Push and SMS:
Rich feature set
The WAP Push system offers a rich feature set including application level control of intrusion, application level confirmation of receipt of push message, delivery notification to the content provider, multi-recipient addressing and device capability discovery and utilization.
Active content
Content which is active and can be used to stimulate user access and which is compatible across different terminal vendors. Additional enhanced features such as the ability to include WML and content replacement using HREF or unique identifiers offers the ability to create an enhanced user experience. In this case if the push is un-read by the user it may be silently replaced by subsequent push messages under the control of the push application.
Cache control
Offering the ability to affect the dynamic storage of data on the terminal
Over The Air
In terms of the air interface the Push Proxy offers access to a number of bearers and the ability for the initiator to specify in terms of Quality of Service which is the preferred mechanism. Additionally authentication and secure push can be services are available.
PPG Control
The Push Proxy Gateway offers the service provider a number of sophisticated mechanisms to tailor service for particular content providers and to offer differing degrees of access to a wide user community of WAP capable and pre-existing Openwave Browsers.
Open Standard
Unlike Openwave's previous push implementation, WAP Push is an industry standard. Therefore, developers writing to WAP Push can be assured that their application can support any WAP 1.2.1 handset. Openwave has also ensured backward compatibility so that WAP Push messages can also be sent to the millions of Openwave's browsers already in the market. WAP Push also provides developers with enhanced application development features listed above (under "Rich feature set") that were not available with Openwave's previous implementation. WAP Push also supports MSISDN addressing.
Q: How many handsets can support WAP Push? A: As an open standard, WAP Push supports all WAP 1.2.1 handsets. Openwave Browser version 5 and above provide full support of WAP Push. Openwave has also ensured backward compatibility with our previous implementation of push, called UPNotify or Web Alerts, providing access to millions of existing handsets that have Openwave browser 2.x and above. For a list of devices with the Openwave Browser version 5.x and higher can be found at here. In addition, many non-Openwave Devices currently shipping support WAP Push, including (but not limited to) the Ecrisson T68, T68i, T39, etc? the Mitsubishi Trium XL, the Nokia 8390, 8310, 9290, and 9210
Q: What are the different ways of delivering Push requests? A: Pushes can be confirmed or unconfirmed, connection-oriented or connection-less.
Confirmed pushes are push messages with a receipt confirmation sent to the content provider or application that originated the push message. Unconfirmed push messages do not require a receipt confirmation to be sent back to the content provider or application. The content provider or application can specify when sending a push whether the push is unconfirmed or confirmed.
Secure pushes are push messages that are encrypted using WTLS when the message is sent. This ensures that the message cannot be intercepted and read by an unauthorized party during transmission. Non-secure messages are not encrypted during transmission. Secure pushes depend on whether the device supports secure pushes.
Whether a push is connection orientated or connectionless is normally a reference to the mechanism used for delivery. Connection oriented, which may be confirmed or unconfirmed, push requires that there is an active session between the subscriber and the push proxy. Note that an unconfirmed push may be sent over the user's active session. Connection-less, which are unconfirmed only, push are pushes sent to the user without an active session between the user and the content provider or application. Examples of the bearer for connectionless are SMS or UDP.
If a confirmed push is required, but the user is not in a session, the Push Proxy Gateway can establish a session with the handset by sending a request in the connection-less route (e.g., SMS). The choice of whether the session is secure or unsecure is based on the capabilities of the handset. Once the user is in a session, then the push message can be sent in a connection-oriented way.
browsers as well as the older Openwave browser versions 3 and 4. Openwave's PPG will also support handsets that have neither WAP Push or UPNotify (Openwave' previous push technology).
Q: What will be new in WAP 2.0 Push? A: WAP Push 2.0 will add support for:
· HTTP from the Push Initiator (content provider) to the handset, a capability of the next generation mobile data networks.
· More flexible user and client addressing, such as email addresses (Network Access Identifier addressing specification)
· XHTML push content. XHTML will become the new mark-up language standard for the Internet. XHTML redefines HTML as an XML application. XHTML provides a painless transition to advanced technology that improves HTML with uniformity of document structure and increased interoperability (e.g., wireless, desktop).
· Other features that will improve the end-user experience and simplify push application development.
Q: What is a Push Initiator? A: The entity (e.g., application such as a news site) that originates push content and submits it to the push framework for delivery to the handset.
Q: In what scenario would a content provider or developer send large content (e.g., image) using the SMS bearer (vs. WSP)? A: The SMS bearer may be used if a WAP session is not available. Message size for this bearer is dependent on the individual type of network involved, for example in GSM SMS it is 160 Bytes. Messages greater than 160 bytes are segmented and reassembled automatically, using the WAP WDP specification. In terms of the maximum SDU (Service Data Unit) allowed by the session, the current WAP default limit is 1400 bytes, but is dependent on the handset negotiation. Even then you are talking about segmenting over 9 SMS messages, which can be done, but it just takes time in the handset. For larger messages try for 1-2 SMS Messages = about 300 Bytes. Also, remember that these are encoded bytes for over the air transport. For example if this was a Service Indication you would be looking at the overhead on the text label and URL of about 30-50 bytes for encoding, giving you 80-120 chars to play with in a single GSM SMS message.
Q: Is the experience from the subscriber perspective the same regardless of bearer? A: Yes, unless the user receives an SI and initiates a pull to download large content, in which case the user would experience a long delay before the content is delivered completely when sending over SMS. The user would not see a delay if the entire message is pushed, since they would know that they have a message until the entire message has arrived. WAP Push uses the user data header to indicate that the SMS message is a WAP Push message. The WAP default is used if the handset does not negotiate. WTP SAR will allow 256x1400 bytes, and Extended WTP SAR will allow even larger content as part of WAP 2.0.
Q: How does the PPG process know the capabilities of the handset before sending a push? A: If the user has pulled content, the PPG process looks at the WSP session header to get browser version information. It can also look at the provisioned data in the MAG 5 DB. The PPG process looks up the handset profile in the MAG DB before sending a message. Some content providers require users to identify their handsets before receiving push services. This information can be passed to the PPG by the Push Initiator. Otherwise, the PPG can send whatever is the default push format setting in MAG for an anonymous user.
Q: What is an anonymous user and how would an application know their subscriber ID in order to Push to an anonymous user? A: An anonymous user is an unregistered user. So there is no profile data, and hence no subscriber id. Therefore, the phone number must be known in order to push a message. It is possible for the carrier to disable anonymous push to prevent all push initiators from being able to send push messages to subscribers who are not provisioned or have not opted-in to a particular developer's push service. Refer to the question on access controls for more information.
Q: Can the WAP Push system send pushes to handsets that are not provisioned and have never connected to the web site (Push Initiator)? These are called "anonymous" pushes? A: WAP Push Phones: Push Initiators can send a WAP Push to any WAP Push-compliant phone simply by addressing the push with the MSISDN number (assuming the carrier has allowed the PI using the access control white list or the carrier has enabled all PIs to push). WAP Push phone do not have to be provisioned to receive push messages. Message delivery is dependent on inter-carrier relationships in this case because the push message is delivered using the connection-less mode via SMS. Also, a WAP Push message via SMS is sent to a phone that does not support WAP Push, the message is simply ignored, and there is no harm to the phone.
UPNotify Phones: Phones with Openwave's previous push technology must be provisioned and the subscriber must have visited the web site (Push Initiator) before a push can be sent to the subscriber. Addressing via the Subscriber ID available in MAG after provisioning and available to the PI after the user has visited the web site. It is possible to bypass the provisioning and connection requirements. Please contact the Push team for information.
SMS Phones: Any SMS phone can be pushed a message via the PAP protocol or the standard SMS protocol (dependent on the carrier's inter-carrier relationships if sending between carriers). No provisioning is required.
Q: What is SIR/SIA? A: The Session Initiation Application (SIA) resides in the handset and can automatically initiate a WAP data session. The Session Initiation Request (SIR) is an instruction sent to the SIA in the handset by the PPG to request that the handset initiate a data session. Both the SIA and SIR are part of the WAP standard. Together, they are a way for a Push Initiator to automatically start a data session without subscriber input or with a prompt for the subscriber to initiate a session. For example, an application can be developed that automatically launches a browser in the handset.
Q: Is the way an SIR/SIA works essentially a way to force a handset to establish a WAP session without subscriber intervention? A: A session will only be established if the user has enabled this in the browser; for example in the Siemens S45 this parameter is called "autosia" in the browser and even then only if the handset configuration also allows it. The gateway can be disabled from letting the "Service Load" content type through and application developers would never be able to send an "SIA".
Q: If a developer writes to WAP Push, will PPG take care of the backward conversion for UPNotify and anonymous users? To which standard should developers write their push-enabled applications? A: The PPG takes care of backward compatibility, including formatting for SMS if the handset does not handle UPNotify or WAP Push. Developers should write to WAP Push. No additional developer work is required.
Q: If a developer is using MSISDN (for WAP Push) addressing, but if the handset is not WAP 1.2.1 compliant, how does the message get to the user? A: The MSISDN is converted to Subscriber ID. WAP Push supports both MSISDN or Subscriber ID addressing. Subscriber ID is a unique identifier assigned to each provisioned subscriber within the Mobile Access Gateway. A content developer can be provided the Subscriber ID by the carrier or through the request headers when the subscriber visits their site. If the user is not provisioned and is not visiting the provider's site, a push can be sent by using the subscriber's phone number. In this case, the subscriber must provide the phone number or the content provider must obtain it in some other way.
Q: What is the "Application ID" in a push message? A: The application ID tells the handset which application the push content is for. The application can therefore receive and process the content. Existing client applications include the WAP browser, instant messaging, provisioning, MMS, and WTA (Wireless Telephony Application).
Q: What about non-Openwave handsets. Will the push process automatically format to text and forward? A: WAP Push will work with any WAP 1.2.1 compliant handset, including non-Openwave. For handsets that are not 1.2.1 compliant or those that are older and non-Openwave, WAP Push will format the message to text and send it over SMS. These handsets include Openwave browser versions 3.x and 4.x, and non-Openwave handsets that support SMS, but not WAP Push. Refer to the "WAP Push, UPNotify, and SMS" document for differences between the three types of push messages.
Q: Does Openwave's WAP Push API work with non-Openwave gateways? A: Openwave's WAP Push API has not been tested with other WAP 1.2.1 compliant gateways.
Q: Can you use OPWV's SDK to develop Apps for non-OPWV Gateways and Browsers? A: Yes. Openwave's SDK will work with any WAP 1.2.1 compliant gateway. The minimum level of service, as defined by the WAP Forum is the ability to push Service Indication content type over a connectionless bearer (e.g. SMS).
Q: If developers write to UP.Notify, do they have to re-write the applications when the carriers upgrade to MAG 5+? A: No. Applications written to UPNotify will work without modification when the carrier upgrades their Mobile Access Gateway. However, in order to take full advantage of WAP Push capabilities, developers would need to write to WAP Push using the Push Access Protocol (PAP). Refer to the "WAP Push, UPNotify, and SMS" document for differences between the three types of push messages.
Q: What has changed between the Beta and the GA release of the Openwave WAP Push library ? A: There have been many enhancements/adjustments to both the library as well as the tools that ship as part of the package. The most significant changes are as follows:
Delivering a Push is now accomplished with the Pusher or SimplePush classes. In the Beta version of the library, pushes were delivered by instantiating the plPushMessage. In fact, all of the pl* classes have been deprecated in the 1.0 GA release of the library.
The XPIP application is no longer part of the package. It will be available as a separate download from the Openwave Developer site in the near future
The PushIT application has been completely re-written/re-designed to allow developers to accomplish a much broader set of Push actions,
The TravelDemo application has been simplified, removing many of the cards and decks that were not essential to the push portion of the application
Q: Do I have to upgrade to the new library now? A: As of the release of the Openwave WAP Push library 1.0 GA, Openwave will no longer support the beta release of the library.
Q: Do I have to migrate my existing applications built on the Openwave WAP Push library 1.0 Beta to the new classes in 1.0 GA? A: No, your existing applications should work as-is with the new library. However, all of the pl* classes in the beta release of the library have been deprecated in 1.0 GA, so we do recommend migration as soon as feasible.
Q: How to configure Tomcat 4 to run Wap Push applications with Openwave wap push library java edition 1.0 ? A: You need to store log4j.jar, jsse.jar, jnet.jar and jcert.jar in $Tomcat_Home/common/lib directory. These jar files are shipped with Openwave wap push library. You also need to set your class-path to them.
Q: Push messages are not arriving to my Nokia 3410? A: Currently there are known issues which prevent WAP Push messages sent by the Openwave PPG from being processed by the Nokia 3410 handset. At this time, there is no known workaround.
Q: Push messages do not arrive to my Nokia 7650 when going through the Openwave PPG? A: To ensure that push messages arrive properly through the Openwave PPG to the Nokia 7650 v3.12, the value of the application ID should be set to ' * ' in your message."To do this using the Openwave Push Library do the following...You can set the Application ID to '*' within the Openwave Push Initiator tool when selecting Content Type within the tool. Within each content type there is the option to add additional Internet headers. Select the add button within this option and give the HTTP header X-WAP-Application-ID the value of '*'
