SMS message processing

PortaSwitch allows the ITSP to offer SMS services (such as instant messaging to mobile users, premium number SMS, SMS campaigns and wholesale SMS) while using an all-IP infrastructure:

• PortaBilling performs the authorization and billing for outgoing SMS messages.
• PortaSIP accepts incoming SMS messages from mobile operators and delivers them to end users within the network.
• PortaSIP routes SMS messages to one of the vendors for delivery to a mobile network using the industry standard SMPP protocol according to the routing results provided by PortaBilling.

When sending messages within your network, the SIP protocol is always used.

Together with instant messaging and voice calls, this feature offers your customers a complete, real-time communication experience.

Step-by-step instructions on how to configure the messaging service can be found in the Unified PortaSwitch Handbook Collection.

Prior to sending a message, PortaSIP determines how to handle it:

• When the message’s recipient is one of the accounts within the network that is capable of receiving on-net instant messages, PortaSIP delivers the message via the SIP protocol.
• When the recipient of the message is a mobile subscriber, PortaSIP asks PortaBilling to compute the routing for delivering the message and sends it via the SMPP protocol.

The determination is made based upon domain service policies, wherein each of them has its priority and match pattern. PortaSIP extracts the domain name from the To: header of the MESSAGE request and matches it against all available service policies. To ensure proper domain service policy selection, the instant messenger must send the correct contact information to PortaSIP.

The parameters defined within the selected domain service policy (e.g., transport protocol, routing, and billing parameters) are used for message processing and delivery.

Thus, when a user sends a message and the MESSAGE request arrives at PortaSIP, PortaSIP may:

• Perform on-net routing and deliver the message to the recipient within the network using the SIP protocol.
• Receive the routing list computed based on the LCR from PortaBilling and send the message to the SMS aggregator for further transmission.
• Route the SMS traffic received from customers to the SMS aggregator using the SMPP protocol. If specifically defined, PortaSIP also performs real-time HLR lookup prior to sending the message.

For further details about SMS routing with real-time HLR lookup, please refer to the PortaBilling Administrator Guide.

More and more people use mobile applications in their daily life. To gain these users as customers, service providers can now introduce a two-way SMS service that allows them to enjoy exchanging messages with their friends and family.

PortaSwitch accepts incoming SMS messages from mobile operators and delivers them to end users within the network.

All incoming SMS messages for recipients are free of charge, while the sender of the SMS message is the one charged per message.

Incoming SMS handling is determined by the domain service policy configuration. Thus, when PortaSIP receives SMS messages via the SMPP protocol, the delivery flow looks like this:

• PortaSIP matches the corresponding domain service policy (using a domain pattern) that defines how the SMS message must be processed.
• PortaSIP authorizes the message in PortaBilling and receives instructions to deliver the message to the end user within the network.
• PortaSIP converts the SMPP message to the SIP protocol and routes it to the account within the network.
• If the recipient is online, they immediately receive the message. If not, PortaSIP stores the message until the recipient comes online (their application registers them within the network) and then delivers the message.

Together with outgoing messaging, this full-scale solution allows service providers to benefit from this two-way SMS service, as it adds additional profit.

For more detailed information regarding message processing conditions please refer to APPENDIX F.

The standard SMS message size may contain up to 160 Latin characters or 70 non-Latin characters. To send longer messages (e.g., 250 Latin characters each), mobile operators send multipart SMS messages. This means that SMS messages may be comprised of several SMS parts.

PortaSwitch accepts multipart SMS messages and delivers them as a single message, either to end users within the network or to your SMPP vendor.

Note that the sender is charged for each SMS sent as part of a multipart SMS message. Delivery reports are sent for each SMS part as well.

When PortaSIP receives a multipart SMS message via the SMPP protocol, the delivery flow looks like this:

1. PortaSIP collects all the SMS parts of the multiple SMS message.
2. PortaSIP authorizes the multiple SMS message in PortaBilling (sends one request to authorize all the SMS parts).
3. PortaBilling locks the funds required to cover all the SMS parts of the multiple SMS message.
4. PortaSIP assembles the SMS parts and sends them as one message.
5. The sender is charged per SMS part for the following cases:
   • The user within the network receives the message (softphone sends a 200 OK response).
   • The SMPP vendor receives the message and sends an ESME_ROK (no error) response.

Consider the following example:

A mobile user, John Doe, sends a multipart SMS message to Mary Smith, your network user. Since the SMS message contains 190 Latin characters (2 SMS parts), John is charged for 2 SMS messages although Mary receives a single message from John.

Incoming multipart SMS message processing conditions:

1. For incoming multipart SMS message delivery, the User Data Header (UDH) cannot be used in conjunction with the concatenation related optional parameters (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum).
2. Since UDH information is part of the message itself, the size for each incoming SMS part is limited to 153 (Latin) characters or 63 (non-Latin) characters.
3. PortaSIP must receive all the SMS parts within 60 seconds, otherwise, PortaSIP sends the ESME_RINVNUMMSGS error code (invalid number of messages) and then all the SMS parts that have been received are deleted.
4. If authorization fails or there are no routes, PortaSIP sends the ESME_RSYSERR error code (SMSC system error) and drops all the received SMS parts.
5. If PortaSIP stops (e.g., connection is broken), PortaSIP drops all the received SMS parts.

The capability for delivering a multipart SMS message as a single message improves the user experience.

Some enterprises that organize SMS marketing campaigns require that delivery reports track the outcome of SMS message delivery. PortaSIP can send delivery reports that indicate whether or not an SMS message was successfully delivered.

PortaSIP only provides the delivery reports by request. Thus, the enterprises must send the SMS messages with the registered_delivery parameter in the SUBMIT_SM PDU.

To receive delivery reports from your vendors (to whom you send SMS traffic), configure the service policy for an SMPP vendor connection (registered_delivery = 1). Make sure that the vendors support the delivery reports beforehand. In case your vendor cannot provide delivery reports, PortaSIP generates them on its own, based on the vendor’s SMPP response message (e.g., ESME_ROK – no error, ESME_RINVDSTADR – invalid destination address).

Consider the following example:

Your customer, EasySMS, sends a bulk of SMS messages that you transfer to your wholesale provider, Lleida Networks. Once Lleida Networks provides the delivery reports, PortaSIP transfers them to EasySMS.

The sender of the SMS messages is only charged for successfully delivered SMS messages. PortaSwitch locks the funds required to cover the amount of the SMS messages. Once the delivery reports are received, the funds for undelivered SMS messages are unlocked.

This functionality helps service providers track delivery information about SMS messages sent. In addition, this enables them to gain new enterprises as customers, since some enterprises consider delivery reports of crucial importance.

When an SMS message cannot be delivered for some reason, a vendor includes an error code in the response. When a code indicates a temporary error, PortaSIP automatically resends the SMS message.

The first attempt to resend an SMS message occurs within 30 seconds after the error code is received and the second attempt occurs within 60 seconds. For each successive attempt, 30 seconds are added. The maximum number of attempts is 20 though you can set your own parameters in the IMGate configuration file.

By default, PortaSIP does not try to resend SMS messages if a vendor sends the following error codes: ESME_RINVSRCADR (invalid source address), ESME_RINVDSTADR (invalid destination address), ESME_RX_R_APPN (ESME Receiver reject message error). The other codes are considered temporary. To add more error codes that prevent SMS messages from being resent, specify these codes in the service policy for the SMPP vendor connection.

Consider the following example:

Lleida Networks sends an error code to indicate that their message queue is full (ESME_RMSSQFUL). Since this error code is not mentioned in their service policy, PortaSIP attempts to resend the SMS message.

This new enhancement helps increase the number of SMS messages delivered. Thus, service providers improve the profitability of their SMS service offerings while providing a better subscriber experience.

In today’s world, instant messages are a powerful and popular tool for marketing and for customer support. For example, call centers that advertise goods often need to broadcast promotional information about sales or reach individual subscribers about special offers. Instant messages are an easy and convenient way to do this.

In the wholesale scenario, messages are sent via the SMPP protocol. Upon receiving a message, PortaSIP authorizes the customer by their IP address and checks whether the customer’s product and balance allow messaging. Then the message is forwarded to a vendor. When there are several vendors configured in the system, LCR (least-cost routing) is used allowing a service provider to build an optimal pricing strategy.