WAP and SIP

 

This document provides a summary of the ongoing investigation into the potential interworkings of the Session Initiation Protocol (SIP) and the Wireless Application Protocol (WAP). At present, there are no definite conclusions to the investigation; there are still technical questions, mainly in the WAP arena, that need to be answered.

SIP Session Initiation Protocol (SIP) is used to establish sessions between multiple parties in a location-independent manner. The sessions are typically voice sessions, however they could be chat sessions (text based), instant messaging sessions, an online gaming session, etc. 

Figure 1

Wireless Application Protocol (WAP) is designed to tackle the limitations of the mobile (cellular) network, in order to allow mobile devices to access internet-based services. Typical services might be email, simple web access, stock alerts, etc.

 

 

 

 

 

 

Figure 2

The WAP protocol is outside of the scope of call signalling and audio transport. Therefore there is no direct mapping between the WAP protocol and SIP. WAP does not contain an equivalent of the SIP INVITE message. For SIP to interact with a WAP enabled mobile phone in call setup and manipulation there has to be a mapping between SIP and the cellular signalling protocols, and that occurs in the gateway in Figure 1.

WAP is predominantly about content delivery to the WAP mobile over the wireless network.

Delivering CLI From SIP Client to a WAP Client

If WAP is about content delivery to mobile clients then perhaps WAP can be used to deliver caller information to a WAP device.

The WAP model allows content to be "pushed" to a mobile client.

Figure 3

In the example shown opposite:

  • The SIP Client inititates the call targeted at the WAP mobile by sending an INVITE to sip: +1-212-691-8215@wapit.com.
  • The INVITE arrives at the SIP Proxy Server in the WAPit.com domain. The Proxy Server consults with the Application Server Broker and determines that the mobile client associated with the sip URL has registered for the CLI delivery service.
  • The CLI Delivery Service is then able to push WAP content to the WAP Push Proxy Gateway asscoiated with the callee. The Push Proxy Gateway then delivers the WAP content over the Wireless Network.
  • In parallel to this activity, the Proxy Server, converts the sip URL into a tel URL of the format tel: +1-212-691-8215. The Application Service Broker is consulted again in order to identify a SIP/PSTN gateway that can act as an intermediary between the IP and PSTN networks.
  • A Location Server is used to identify a suitable gateway using the TRIP (Telephone Routing over IP) protocol. The WAP client will receive the pushed content containing the callee CLI, and a corresponding incoming call.
  • The WAP user is then free to accept or decline the call using the standard phone interface or via WAP content, stored on the mobile client, which is associated with mobile network events, e.g. incoming call.

SIP / CLI Alternatives

Could the caller details (SIP URL) be passed using the CLIP details in the cellular network protocol? If so, this does away with the WAP element for this operation.

Could a SIP client be embedded into the mobile phone, giving the ability to just talk SIP from endpoint to endpoint?

This relies on an IP-based mobile network with high bandwidth. Maybe GPRS will help us with that, but it's more likely that UTMS will be needed. Again this does away with the need for WAP for this application.

SIP > WAP

This scenario shows a SIP client sending an Instant Message to a WAP mobile phone:

  • The WAP mobile client subscribes to an Instant Messaging Service provided by WAPit.com. This SIP client sends the MESSAGE to the SIP proxy server with the URL sip: +1-212-691-8215@wapit.com.
  • The MESSAGE is sent to the Application Service Broker which is configured to instruct the Proxy Server to forward the MESSAGE onto the Messaging Server/Gateway.
  • The Messaging Server/Gateway converts the text associated with the Instant Message into WAP content format and sends it to the WAP Push Proxy Gateway.
  • The Push Proxy Gateway then delivers the Instant Message over the wireless network to the WAP client. The messaging gateway is able to interrogate the Push Proxy Gateway to ascertain if the instant message was delivered succesfully.
  • Using the result of the interrogation, a SIP response is formulated and returned to the SIP Client via the SIP proxy server.

Figure 4

 SIP > WAP Alternatives

Use SMS instead of WAP to push message to mobile client - SMS content is not as rich as WML. For example, a WAP instant message could contain a hyperlink, that could be activated from the WAP client. WAP content could also contain an image.

WAP > SIP

This scenario shows a WAP mobile client sending an Instant Message to a SIP client:

  • The WAP client accesses an Instant Message WAP service (WML) via the WAP Gateway.
  • The Instant message service is WAP content, which allows a WAP client to enter a message, and specify a destination.
  • The WAP client then submits the WML page to the Messaging Server, which extracts the salient information.
  • The Messaging server then goes on to form a SIP Instant Message request which is sent via proxy (and ASB) the client acknowledges receipt of message.

 Figure 5

SIP / CLI Questions

Can a WAP mobile phone have a WAP session and a telephone call active at the same time?

  • It seems that the answer is NO. This is a function of the wireless bearer and the number of transmitters / receivers in the mobile handset. GPRS may alleviate this problem, however I haven't got a definitive answer yet.


Has WAP Push model been implemented in any Push Proxy Gateways?

  • Openwave has a fully compliant WAP push gateway which interworks with a number of vendors. I also believe that Ericsson, Nokia and CMG have WAP Push gateways.


Is it possible to receive a Push onto the WAP browser without the mobile user having to confirm the receipt?

  • With the current proprietary Phone.com implementation of Push, the client has to acknowledge receipt of the Push; the content of the Push is then retrieved from a WAP content server. There are two aspects of this which are tedious for the user in our example:
     - When the phone rings, the user has to click a button to acknowledge Push.
     - Caller content has to be retrieved from the WAP server, and the phone is still ringing. The current bandwidth of the wireless network is 9.6K, i.e. slow. Then again, the content should be very small.
  • It would be nice if content is delivered with the Push, and if the content is just displayed to the user. Obviously, there are potential spamming problems here, so 'pushers' must be authorized.


How will the timing of the content delivery and incoming call be handled?

  • It's not clear at present; it could be difficult to synchronise the delivery. Also there is the possibility of a race condition between two incoming calls. The mobile user could be presented with incorrect user details in this scenario. 

Does SIP client dial a telephone number or does the WAP client have a SIP URL that is mapped to a phone number at the SIP/PSTN Gateway?

Two alternatives:

  • WAP client could have a SIP URL that maps to a tel. URL. User would have to register with WAPit.com registrar, maybe via a WAP site interface?
  • Use sip:telno@wapit.com

 
Does ASB talk SIP to "Other services"?

  • This is not clear, at present. 

SIP > WAP Questions

Does SIP client identify the WAP client with a telephone number or a SIP URL?

  • SIP Client idetifies the WAP client


Two alternatives:

  • WAP client could have a SIP URL that maps to a tel URL. User would have to register with WAPit.com registrar, maybe via a WAP site interface?
  • Use sip: telno@wapit.com

 
What about mapping from other Instant Messaging Protocols?

  • At present there are many proprietary Instant Messaging Protocols e.g. AOL, Yahoo, ICQ, IRC, etc. The solution proposed only allows Instant Messaging between SIP & WAP. What about SIP & AOL, WAP & AOL, SIP & IRC?


Will SIP become the IETF approved mechanism for IM?

  • Currently SIP Instant Messaging is just a draft. SIP IM is the subject of a massive, potentially long-winded, argument within the IETF IMPP Working Group. There is no guarantee that SIP IM will be the approved IM standard.
  • If SIP does become the IETF approved mechanism for Instant Messaging then SIP URL's will spread rapidly throughout the internet community, if the big players in IM (AOL, et al) adopt the new standard. This becomes interesting, as at the same time, mobile networks should have greater bandwidth and IP support, allowing the widespread adoption of SIP in mobile phones. Maybe then everybody will have a SIP URL. No more phone numbers and no more mapping between different identifiers in different IM protocols, as everybody is identified by a SIP URL.
  • However, at this current point in time, the debate continues at the IETF IMPP Working Group.

 
WAP Push Availability?

  • In development at present.


Message Security?

  • The weakness in the security model is in the Messaging Server/Gateway, as the message is converted from SIP to WAP format

WAP > SIP Questions

How does WAP client know if message is delivered successfully?

  • Perhaps a success or failure page could be returned to WAP client after successful/failed delivery of message.


How does the WAP user specify a recipient?

  • For SIP, the SIP URL could be used, but what about for WAP to WAP messaging, or WAP to AOL? Perhaps, if the IETF accept SIP as the Instant Messaging standard then these issues will dissipate and SIP URL's will be the accepted identifier.