9 Developing a Short Message Application

This chapter describes how to develop a SIP application that sends short messages to, and receives short messages from, mobile subscribers.

About Solution Architecture

Service Broker provides interfaces that allow you to develop a SIP application that sends short messages to, and receives messages from, mobile subscribers through a Short Message System Center (SMSC).

The application-facing side of Service Broker provides a SIP application with a standard SIP interface. The network-facing side of Service Broker provides an SMPP interface that enables Service Broker to communicate with SMSCs. Service Broker acts as a mediator by providing translation capabilities between SMPP and SIP.

A solution based on Service Broker consists of the following components:

• SIP application

• Service Broker

• Short Message System Center (SMSC)

Figure 9-1 shows a SIP application that interacts with an SMSC.

Figure 9-1 Architecture for Interacting with an SMSC

Sending a Short Message from an Application to an SMSC

When an application sends a message to an SMSC, the flow works as follows:

1. A SIP application sends a SIP MESSAGE to Service Broker.

2. Service Broker responds to the application with a 202 Accepted message.

3. Based on the SIP MESSAGE, Service Broker generates a submit_sm message and sends it to the SMSC.

4. The SMSC responds to Service Broker with a submit_sm_resp.

5. Based on the submit_sm_resp message, Service Broker generates a SIP MESSAGE and sends it to the application.

6. The application responds to Service Broker with a 200 OK message.

7. If Service Broker is configured to request a delivery receipt or acknowledgement from the SMSC, an SMSC sends a deliver_sm message to Service Broker. This message can carry one of the following:

   • SMSC Delivery receipt, which confirms that the SMSC received the message from the application.

   • SME Manual/User Acknowledgement, which is sent by a mobile device in response to the application's message. For example, this acknowledgement might contain a selected menu item from a menu list that the application sent to the mobile subscriber.

   • SME Delivery Acknowledgement, which confirms that the mobile subscriber has read the short message.

8. Service Broker responds to the SMSC with a deliver_sm_resp message.

9. Based on the deliver_sm, Service Broker sends a SIP MESSAGE to the application.

10. The application responds to Service Broker with a 200 OK message.

Figure 9-2 shows an example flow when an application sends a short message to an SMSC.

Figure 9-2 Call Flow for Sending a Short Message to an SMSC

About Methods of Specifying Short Message Parameters

To translate a SIP MESSAGE to an appropriate SMPP message, Service Broker uses an IM-UIX-SMS interworking module. You can configure this module using the Service Broker Administration Console.

When the application encapsulates a short message into the Content header, IM-UIX-SMS generates an SMPP message using the information that you defined in headers of the SIP MESSAGE as well as in configuration settings of the IM-UIX-SMS itself.

Most of the parameters can be defined in both SIP MESSAGE headers and IM-UIX-SMS settings. If you do not provide parameters in the headers, Service Broker uses the settings defined in the configuration of the IM-UIX-SMS. When the settings are defined both in the headers and in the IM-UIX-SMS configuration, Service Broker uses the settings defined by the headers.

The following sections explain how to specify various parameters. In addition, each section explicitly specifies whether you can use headers or IM-UIX-SMS configuration settings to specify a parameter.

Specifying the Identity of an Application

You specify the identity of the application that sends a short message by using the user part of the From header. In addition, you might specify the optional tokens Numbering Plan Indicator (NPI) and Nature of Address (NOA).

Specifying the Identity of a Mobile Subscriber

You specify the identity of a mobile subscriber by specifying the MDN of the subscriber in the user part of the RequestURI header.

In addition, you can specify subscriber's NOA or NPI using one of the following methods:

• Specifying the NOA or NPI tokens of the RequestURI header

• Using the Service Broker Administration Console. You can define the following parameters on the IM-UIX-SMS configuration screen:

  • Submit Destination Address Type of Number

  • Submit Destination Address Numbering Plan Identification

  See the "Configuring SMPP Operations" section of the "Configuring IM-UIX-SMS" chapter in Oracle Communications Service Broker Processing Domain Configuration Guide for more information.

Specifying the Message Content Type

You can specify the content type using one of the following methods:

• Specifying the Content-Type header of a SIP MESSAGE. You must set Content-Type to "plain/text". Optionally, you can also set the charset parameter of the Content-Type header.

• Using the Service Broker Administration Console. You need to define the Data Coding parameter on the IM-UIX-SMS configuration screen.

  See the "Configuring SMPP Operations" section of the "Configuring IM-UIX-SMS" chapter in Oracle Communications Service Broker Processing Domain Configuration Guide for more information.

Setting the Validity Period of a Message

The validity period of a message is the time period after which the message is discarded if it cannot be delivered to the destination.

Service Broker applies the validity period only when the Submit Validity Period Format is set to either VP_RELATIVE_FORMAT or VP_ABSOLUTE_FORMAT. You specify Submit Validity Period Format on the IM-UIX-SMS configuration screen.

You can specify the validity period using one of the following methods:

• Setting the Expires and Date headers. To make Service Broker to use the values set in these headers, on the IM-UIX-SMS configuration screen, you need to set the Submit Validity Period Source parameter to SAL_MESSAGE.

• Using the Service Broker Administration Console. Service Broker uses the values set in the IM-UIX-SMS configuration if the configuration parameters are set as follows:

  • In Submit Validity Period Value, specify the time after which the message is discarded.

  • Set Submit Validity Period Source to STATIC_CONFIGURATION.

  • Set Submit Validity Period Format to VP_RELATIVE_FORMAT.

  See the "Configuring SMPP Operations" section of the "Configuring IM-UIX-SMS" chapter in Oracle Communications Service Broker Processing Domain Configuration Guide for more information.

Triggering an SMSC to Send a Predefined Short Message to a Mobile Subscriber

If an SMSC stores a collection of pre-defined short messages, you can trigger the SMSC to send one of these messages to a subscriber by using the Play header. In this header, you specify the ID of the message that you want the SMSC to send.

Specifying the Message Mode, Type, and Privacy Indicator

You can specify the message mode, type, and privacy indicator using one of the following methods:

• Setting the Mode, Type, and Privacy tokens of the Subject header

• Using the Service Broker Administration Console. You can define the following parameters on the IM-UIX-SMS configuration screen:

  • Submit Message Mode

  • Submit Message Type

  • Privacy Indicator

  See the "Configuring SMPP Operations" section of the "Configuring IM-UIX-SMS" chapter in Oracle Communications Service Broker Processing Domain Configuration Guide for more information.

Specifying the Message Priority

You can specify the message priority using one of the following methods:

• Setting the Priority header

• Using the Service Broker Administration Console. You can define the Submit SM Priority Level parameter on the IM-UIX-SMS configuration screen.

  See the "Configuring SMPP Operations" section of the "Configuring IM-UIX-SMS" chapter in Oracle Communications Service Broker Processing Domain Configuration Guide for more information.

Requesting a Delivery Receipt or Acknowledgement

You can configure Service Broker to request the SMSC to send a delivery receipt or acknowledgement. You can set these settings only by using the Service Broker Administration Console. You can define whether or not Service Broker should send a receipt or acknowledgement by specifying the following parameters on the IM-UIX-SMS configuration screen:

• Delivery receipt request

• SME Acknowledgement Request

See the "Configuring SMPP Operations" section of the "Configuring IM-UIX-SMS" chapter in Oracle Communications Service Broker Processing Domain Configuration Guide for more information.

Tunneling an SMPP Message using the XER or BER Format

An application can send a ready SMPP message to Service Broker. You need to encapsulate the message in the XER or BER format. In this case, Service Broker forwards the message to the SMSC.

You must set the Content-Type header to one of the following:

• application/smpp-phase3.4+xml, when you want to encapsulate a message in the XER format.

• application/vnd.3gpp.sms, when you want to encapsulate a message in the BER format.

Processing Headers of a Delivery Receipt or Acknowledgement

You can configure Service Broker to request the SMSC to send a delivery receipt or acknowledgement. After Service Broker received a receipt or acknowledgement from the SMSC, Service Broker generates a SIP MESSAGE and sends it to the application.

Table 9-1 describes headers and tokens that a SIP application needs to process in this message.

Table 9-1 Headers of a Delivery Receipt or Acknowledgement Received from an SMSC

Header	Description
In-Reply-To	Specifies the Call-ID of the original message. The application can use the In-Reply-To header to associate the response message with the original one.
Content	Contains the state of the message for which Service Broker requested a delivery receipt. Possible values: 2 The message is delivered to the destination. 3 Validity period of the message expired. 4 Message was deleted. 5 Message is undeliverable. 6 The message has been manually read on behalf of the subscriber by a customer service. 7 The message is in an invalid state. 8 The message is in the rejected state.

Receiving a Short Message Sent by a Mobile Subscriber

An SMSC initiates sending of a short message to an application when the SMSC needs to forwards a message sent by a mobile subscriber.

The flow of sending of a short message from an SMSC to an application works as follows:

1. An SMSC sends a deliver_sm message to Service Broker.

2. Based on the deliver_sm, Service Broker sends a SIP MESSAGE to the application.

3. The application responds to Service Broker with a 200 OK message.

Figure 9-3 shows an example flow when an SMSC sends a short message to an application.

Figure 9-3 Call Flow for Sending a Short Message to an Application

Processing Headings of a Short Message Sent by a Mobile Subscriber

Table 9-1 describes headers and tokens that a SIP application needs to process in a SIP MESSAGE if the message is sent by a mobile subscriber.

Table 9-2 Headers of a Message Sent by a Mobile Subscriber

Header	Description
RequestURI, To	User part token: Specifies the address of the application to which the subscriber sends the message. Domain part token: Specifies the domain part of the application to which the subscriber sends the message. In addition, the RequestURI and To headers might contain the NOA and NPI tokens.
From	User part token: Specifies the MDN of the subscriber who sends the message. Domain part token: Specifies the domain part of the address of the subscriber who sends the message. NOA token: Specifies the Nature of Address of the address of the subscriber who sends the message. NPI token: Specifies the Numbering Plan Indicator of the address of the subscriber who sends the message.
Content-Type	Specifies the content type of the message.
Content-Language	Specifies the language of the response.
Content	If the Content-Type header is set to "plain/text", the Content header contains the contents of the short message.

Handling Errors

Service Broker sends a SIP MESSAGE to the application with the Reason header containing the cause of the error in the following cases:

• If sending of the original message failed, Service Broker sends a SIP MESSAGE to the application and adds the Reason header to this message. The header contains the error code. The Content header contains the description of the error.

• If Service Broker does not receive a delivery receipt or acknowledgement from the SMSC within the specified time period.