However, in order to make this work, you need to configure NowSMS with the appropriate MMS settings for the mobile operator whose SIM card is being used in the GSM modem.

To simplify this process, we include a list of settings for many mobile operators that can be selected from a drop down list within the NowSMS configuration.

However, it has been awhile since we last updated that list, so you might find that your mobile operator is not included in the list.

This post contains an updated list of mobile operator MMSC settings. You can also download this list in a NowSMS compatible format from http://www.nowsms.com/download/mmsop.ini. Save the “mmsop.ini” file to your NowSMS program directory (usually \Program Files\NowSMS or \Program Files (x86)\NowSMS, and NowSMS will automatically use the updated list.

In the following table, note that most versions of NowSMS refers to the “MMS Proxy” setting as the “WAP Gateway Address”.  If this address includes a port number (address:port), versions of NowSMS prior to 2013 releases require the address to be prefixed by http:// (for example http://10.1.2.3:8080).

For more information on configuring NowSMS to send MMS messages via a modem, please see: Using a GPRS Modem.

A NowSMS customer discovered a potential work-around by changing the TP-Protocol-ID (PID) value in the SMS message.

NowSMS has been updated to use configurable DCS and PID values when sending all types of WAP Push messages (including OMA OTA config). Previous versions of NowSMS only allowed the DCS value to be configured for WAP Push. These settings are available in NowSMS version 2013.04.01 and later.  (An update that supports these configurable values is available at http://www.nowsms.com/download/nowsms20130401.zip.)

By default, NowSMS uses a DCS value of F5 (binary, message class=2, ME specific) and a PID value of 0, which would be considered normal values.

It has been previously noticed that some providers will not accept DCS=F5 over a GSM modem connection and require a value of DCS=4 (generic binary).

One of our customers noticed in testing that by changing the PID value to 1 allowed WAP Push messages to be sent over a modem on the AT&T network. Technically speaking, PID=1 is an odd setting as it technically means the message originated as a Telex. We are suggesting that customers instead try using PID=41, which is a more normal setting, meaning replace short message type 1.

To set DCS or PID overrides for WAP Push messages generated by NowSMS, it is necessary to manually edit SMSGW.INI and under the [SMSGW] header, add:

PushDCS=F5
PushPID=41

(or try PushPID=1 if 41 does not work)

Please note that it is possible that AT&T may also decide to prevent this work-around. And note that cross operator WAP Push continues to be unavailable for messages submitted via a GSM modem in the USA.

Additional discussion of this issue can be found on our discussion forum at http://www.nowsms.com/discus/messages/1/71586.html.

In SMS hubbing configurations, NowSMS is connected to one or more service providers using the SMPP protocol. Service providers route selected SMS messages to NowSMS over an SMPP connection, and NowSMS is then used to route the SMS message to a different service provider over another SMPP connection.

The concept is simple, but the implementation can be challenging, due in part to issues of routing and mobile number portability (MNP), and due to the architecture of the SMPP protocol.

Message routing in NowSMS is controlled by either prefix routing or dynamic HTTP-based routing callbacks. Message routing is discussed in a separate article titled Dynamic SMS Message Routing with HTTP Callbacks.

When configuring an SMPP connection for hubbing, an important consideration is which party initiates the connection. This is important because the SMPP protocol assumes a client-server relationship. The party that initiates a connection is the client, or ESME. The party that accepts the connection is considered the server, or SMSC.

SMPP connections where NowSMS initiates the connection (NowSMS = ESME) are defined in the “SMSC” list.

SMPP connections where the other party initiates the connection (NowSMS = SMSC) are defined in the “SMS Users” list.

An ESME transmits SMS messages to an SMSC using an SMPP data packet called submit_sm.

An SMSC transmits SMS messages to an ESME using an SMPP data packet called deliver_sm.

Figure 1 illustrates the typical message flow in a simple ESME to SMSC configuration.

A hub connection is not a client-server relationship, instead logically it is a peer-to-peer connection. However, the SMPP protocol rules must still be followed and submit_sm or deliver_sm must be used depending on the direction of the connection.

Differences between submit_sm and deliver_sm create problems for message ID tracking, particularly with regard to delivery reports. This is because SMPP message IDs are not global, but exist only on a hop-by-hop basis.

When an ESME submits an SMS message to an SMSC using submit_sm, the SMSC assigns a new message ID when accepting the message, and returns the newly assigned message ID in the submit_sm response. The SMSC has no knowledge of any previously assigned message ID. From this point forward, any delivery reports that might be generated will reference the message by this new message ID. Any upstream SMSC will eventually route a deliver_sm packet containing this delivery report back to the ESME, and the ESME will need to have remembered/tracked the message ID assignment from the submit_sm response in order to know the message to which it refers.

In an SMS hubbing scenario, if an SMSC has a message to route to an ESME, it uses deliver_sm to transfer the message. The deliver_sm packet contains no message ID information, so the receiving ESME has no knowledge of message IDs that were previously assigned to the message. To further process the message, the ESME needs to assign a new message ID to the message. Unlike the submit_sm response, the deliver_sm response cannot report this newly assigned message ID back to the other side of the connection. Any delivery reports generated will reference this new message ID, however this message ID is not known to the original SMSC, and it cannot be tracked back to the original message to which it refers.

Figures 2 and 3 highlight the problems encountered when the SMS hub functions solely in the role of SMSC or ESME.

In a typical SMS aggregator scenario, an upstream SMSC functions as both an SMSC and ESME when routing messages, and is able to successfully route messages from ESME to the upstream SMSC and delivery reports from the upstream SMSC back to the ESME, as shown in Figure 4.

However, this scenario still expects a client-server relationship.

There are two ways to overcome these limitations for true peer-to-peer SMS hubbing.

1.) Each side of a hub connection connect to the other party as both ESME and SMSC. Regular SMS messages are always routed from ESME to SMSC, and delivery reports are always routed from SMSC to ESME. From a NowSMS perspective, the NowSMS initiated connection is defined in the “SMSC” list, and the other party initiated connection is defined in the “SMS Users” list.

This scenario is illustrated in Figure 5.

2.) Instead of using submit_sm and deliver_sm, the SMPP protocol defines an alternative packet format called data_sm. This data_sm packet can be used regardless of the direction of the connection, and when used in place of deliver_sm, can return message ID information. NowSMS 2013 provides configuration settings to enable the use of data_sm for either an ESME or SMSC connection.

This scenario is illustrated in Figure 6.

NowSMS always performs automatic SMPP message tracking, translation and routing for delivery reports. However, the expected flow of delivery reports is from SMSC to ESME. In order for NowSMS to be able to properly understand and route a delivery report received from an ESME (i.e., “SMS Users” connection), NowSMS must be configured to “Use data_sm PDU” when communicating with this account.

Similarly, If the connection is defined in the NowSMS “SMSC” list, it is also normal to enable the setting “Re-Route Received Messages for Outbound Delivery” under the Advanced Settings for the SMPP connection. Normally, messages received from an SMSC connection are routed to a 2-way command for processing. This setting changes the behaviour so that messages received from this SMSC connection are queued for outbound delivery.

Important Note: Do not confuse SMS hubbing and ESME/SMSC roles with the concept of whether or not to use a transceiver connection. The concept of one connection vs. two connections is similar, but different.

When an ESME initiates a connection to an SMSC, it specifies what type of connection it wants. Connection types are transmitter (send only), receiver (receive only) and transceiver (send and receive). When NowSMS connects to an SMSC, the default behaviour is to use separate transmitter and receiver connections. Transceiver mode can be enabled to use a single connection for both sending and receiving messages.

With a transceiver connection, the initiating side of the connection is still considered to be in the role of ESME. Therefore the hubbing considerations of which party is ESME and which is SMSC still apply.

This document outlines how MMS charging is implemented using Diameter and MM9 in the NowSMS MMSC. It also describes a test program that is used to validate proper Diameter configuration parameters and charging behaviour. MM9 Diameter charging is enabled in NowSMS MMSC versions 2013.04.01 and later.

The MMSC implements Diameter Credit Control for charging based upon the following specifications:

• [DIAMBASE] – RFC 3588 – Diameter Base Protocol
• [DIAMCCA] – RFC 4006 – Diameter Credit Control Application
• [3GPPDIAM] – 3GPP TS 32.299 – 3GPP Diameter Charging Applications
• [SCAPv2] – Ericsson CCN SCAPv2

[3GPPDIAM] defines a standard format for implementing MMS charging over Diameter, known as MM9 in the MMS protocol specifications. While the MMSC preference is to use MM9, it is also possible to configure the MMSC to use generic charging primitives defined in [DIAMCCA] in order to facilitate interoperability with a wider base of charging systems.

Optionally, Diameter extensions defined in Ericsson’s [SCAPv2] protocol can be enabled.

The MMSC Diameter MM9 implementation is highly configurable, with configuration settings that allow the Diameter requests to be tuned to meet the requirements of different charging systems. The core Diameter charging requests use Credit-Control-Request as defined in [DIAMCCA]. Several extension sets are defined that provide additional Diameter parameters to be include in the charging request.

For maximum flexibility, XML template files are used to define the underlying Diameter requests, allowing for custom parameters to be added or deleted as required.

The MMSC generates two different Diameter requests, which are described in detail in this document.

Capabilities-Exchange-Request is used to initiate the connection and identify that the connection is to be used for Diameter Credit-Control. In response, the MMSC expects to receive a Capabilities-Exchange-Answer that contains a Result-Code of 2001 to indicate success.

Credit-Control-Request is used to provide details for an MMS charging operation. In response, the MMSC expects to receive a Capabilities-Exchange-Answer that contains a Result-Code of 2001 to indicate success. The MMSC will reject the MMS submission if any other Result-Code is received.

MM9Test Program

The MM9Test program is used to test and validate proper configuration parameters and charging behaviour by initiating a Diameter connection and sending a charging request for a single MMS message. The latest version of this program can be downloaded at http://www.nowsms.com/download/mm9test.zip.

The MM9Test program generates the two Diameter requests detailed in this document: Capabilities-Exchange-Request and Credit-Control-Request.

MM9TEST.EXE is a command line program. When run, MM9TEST.EXE will prompt for the following Diameter related configuration parameters:

(Remote) Diameter Server Host Name or IP Address – The DNS host name or IP address of the Diameter charging server that will receive the connection.

(Remote) Diameter Server Port Number – The port number for the Diameter server that will receive the connection.

(Remote) Diameter Destination-Realm – The Destination-Realm parameter to be specified in the Diameter requests.

(Local/Origin) Diameter Host-IP-Address – The IP address of the local host. This is a required property for the Capabilities-Exchange-Reqeust.

(Local) Diameter Origin-Host – The Origin-Host parameter to be specified in the Diameter requests.

(Local) Diameter Origin-Realm – The Origin-Realm parameter to be specified in the Diameter requests.

Service-Context-Id (optional) – A Service-Context-Id may be required by the charging server. The default is 32270@3gpp.org as defined in [3GPPDIAM] to indicate MMS charging. Ericsson’s SCAPv2 requires a value of SCAP_V.2.0@ericsson.com.

Service-Identifier (optional) – Optional integer value to identify the service to the charging server.

Requested-Service-Unit CC-Service-Specific-Units (optional) – [DIAMCCA] allows for charging based upon either a fixed price or a service specific number of units associated with a particular service. In most configurations, a value of 1 will be used for CC-Service-Specific-Units to indicate 1 MMS message being sent. If this parameter is used, leave CC-Money and Currency-Code parameters blank.

Requested-Service-Unit CC-Money (optional, use decimal format 1.23) – If used, this indicates a fixed monetary charge to be applied for sending an MMS message. If this parameter is used, leave CC-Service-Specific-Units blank and specify a value for Currency-Code parameter.

Requested-Service-Unit Currency-Code (optional, use ISO 4217 currency code) – When using a fixed monetary charge, this indicates the currency being used (e.g., USD=840, EUR=978 ). If this parameter is used, leave CC-Service-Specific-Units blank and specify a value for CC-Money parameter.

MMS Sender Phone Number – MSISDN to be charged for sending MMS message. Used to build Subscription-Id and Originator-Address in Credit-Control-Request.

MMS Recipient Phone Number – MSISDN receiving MMS message. Used to build Recipient-Address in Credit-Control-Request.

3GPP-SGSN-MCC-MNC (optional) – If available to the MMSC, the SGSN MCC-MNC value can be used to detect roaming subscribers. If left blank, or not available, this parameter is not included.

SGSN-ADDRESS (optional) – If available to the MMSC, the SGSN-ADDRESS value can be used to detect roaming subscribers. If left blank, or not available, this parameter is not included.

Enable Ericsson SCAP Extension Set? (Y/N) – Answer Y to include the Credit-Control-Request parameters defined for the SCAP extension set. If selected, the program will prompt for additional optional parameters included in the SCAP extension set. SCAP parameter values prompted for include Service-Provider-Id, an integer value used to identify the service to the charging server, and Subscription-Id-Location. It is possible to use the 3GPP-SGSN-MCC-MNC value as the Subscription-Id-Location value by specifying a value of @@SGSNMCCMNC@@.

Enable 3GPPTIMEZONE Extension Set? (Y/N) – This setting will automatically default to Y if the Ericsson SCAP Extension Set is enabled. Answer Y to include the 3GPP-MS-TimeZone parameter in the Credit-Control-Request.

Enable 3GPP Extension Set? (Y/N) – Answer Y to include the Credit-Control-Request parameters defined for the 3GPP extension set (Service-Information/MMS-Information).

If successful, the last line of output from the test program will read Diameter Result Code 2001.

Raw Diameter packet information will be logged to MM9TEST.LOG. However, for easier troubleshooting, it is recommended that Wireshark be used to capture and log connection details. Wireshark will decode Diameter protocol information to more clearly report any protocol errors returned, as protocol errors typically relate to not having used the parameter values expected by the Diameter server.

Important Usage Note: The MM9 Test Program saves previous responses, so these previous responses will be used as a default setting for the next test. To delete a prior response for an optionally included parameter, press the Space key, then Enter.

For advanced requirements, the XML template files diameter-capabilities-exchange.xml and diameter-credit-control.xml can be edited to modify Diameter parameters included in charging requests.

After completing successful MM9 Diameter charging tests, the configuration settings used by the test program can be easily migrated to production MMSC settings.

MM9 test settings are saved in a file named MM9TEST.INI. Copying the entire [MM9Diameter] section of MM9TEST.INI to MMSC.INI will activate MM9 Diameter charging in NowSMS MMSC versions 2013.04.01 and later.

MM9 Diameter Charging in the MMSC

MM9 Diameter charging is enabled in NowSMS MMSC versions 2013.04.01 and later by configuring parameters under an [MM9Diameter] section header of MMSC.INI. It is recommended that the MM9TEST.EXE utility be used to initially define these settings. MM9 test settings are saved in a file named MM9TEST.INI. Copying the entire [MM9Diameter] section of MM9TEST.INI to MMSC.INI will activate MM9 Diameter charging.

The following settings are supported in this [MM9Diameter] section:

Destination-Host-Address – The DNS host name or IP address of the Diameter charging server that will receive the connection.

Destination-Host-Port-Number – The port number for the Diameter server that will receive the connection.

Host-IP-Address – The IP address of the local host. This is a required property for the Capabilities-Exchange-Requst.

Origin-Host – The Origin-Host parameter to be specified in the Diameter requests.

Origin-Realm – The Origin-Realm parameter to be specified in the Diameter requests.

Product-Name – The Product-Name parameter to be specified in the Capabilities-Exchange-Requst. The default value is MMSC.

Destination-Realm – The Destination-Realm parameter to be specified in the Diameter requests.

Service-Context-Id – A Service-Context-Id may be required by the charging server. The default is 32270@3gpp.org as defined in [3GPPDIAM] to indicate MMS charging. Ericsson’s SCAPv2 requires a value of SCAP_V.2.0@ericsson.com.

Service-Identifier – Optional integer value to identify the service to the charging server.

CC-Service-Specific-Units – [DIAMCCA] allows for charging based upon either a fixed price or a service specific number of units associated with a particular service. In most configurations, a value of 1 will be used for CC-Service-Specific-Units to indicate 1 MMS message being sent. If this parameter is used, leave CC-Money and Currency-Code parameters blank.

CC-Money – If used, this indicates a fixed monetary charge (e.g., 0.05) to be applied for sending an MMS message. If this parameter is used, leave CC-Service-Specific-Units blank and specify a value for Currency-Code parameter.

Currency-Code – When using a fixed monetary charge with CC-Money, this indicates the currency being used (e.g., USD=840, EUR=978). If this parameter is used, leave CC-Service-Specific-Units blank and specify a value for CC-Money parameter.

Service-Provider-Id – An integer value used to identify the service to the charging server when the SCAP extension set is enabled.

Subscription-Id-Location – A string value required by the SCAP extension set. It is possible to use the 3GPP-SGSN-MCC-MNC value as the Subscription-Id-Location value by specifying a value of @@SGSNMCCMNC@@.

EmailAddressNumber – Some charging environments may not be able to accept an e-mail address as a recipient. For those environments, specify a phone number to be substituted in Diameter charging requests for MMS messages to e-mail recipients.

MultipleRecipCharge – By default, the MMSC issues a separate charging request for each recipient when an MMS message is sent to multiple recipients. When this parameter is set to Yes, the MMSC issues a single charging request for multiple recipients, multiplying CC-Service-Specific-Units or CC-Money by the number of recipients automatically.

SupportedExtensionSets – A comma delimited list of extension sets enabled for the Diameter connection. Extension sets are detailed below:

• SCAP – Enables Diameter parameters defined by [SCAPv2], including Traffic-Case, Other-Party-Id, Service-Provider-Id and Subscription-Id-Location. Also enables 3GPP-MS-TimeZone.
• 3GPPTIMEZONE – Enables 3GPP-MS-TimeZone.
• 3GPPSGSN – Enables 3GPP-SGSN-MCC-MNC and SGSN-ADDRESS, if available to the MMSC.
• 3GPP – Enables Service-Information/MMS-Information grouped parameters providing MMS message detail.

Enabling MM9 Diameter for Only Select Subscribers

In some environments, it may be desirable to use MM9 Diameter charging for only some subscribers. For example, MM9 Diameter charging might only be used for prepaid subscribers.

In other environments, it may be desirable to use different Diameter charging servers for different groups of customers (for example, when the MMSC is hosting subscribers from multiple countries, or multiple MVNOs).

Both of these scenarios are facilitated through accounting callbacks, which are documented at http://www.nowsms.com/doc/advanced-configuration-settings/mms-accounting-callbacks.

The MMSSend PreAuth callback can return a response indicating that a Diameter charge should be attempted. In this scenario, CallbackTriggerOnly=Yes should be added to the [MM9Diameter] section of MMSC.INI to indicate that the MMSC should only generate Diameter charges if directed to do so by the response to the MMSSend PreAuth callback. The callback response should include the text MM9Diameter=Yes to indicate that a Diameter charge is required for the transaction.

Multiple Diameter servers can be configured by creating additional sections in MMSC.INI, similar to the [MM9Diameter] section documented here. Use a section name of [MM9Diameter-xxxxxxxx] where xxxxxxxx is a name to be associated with this Diameter server. The MMSSend PreAuth callback response can trigger a Diameter charge to this server by including MM9Diameter=xxxxxxxx in the text of the response. (MM9Diameter=Yes triggers a charge for the server defined in [MM9Diameter]. Values other than Yes trigger a charge for a different Diameter server.)

MM9 Diameter XML Templates

The XML template files used for Diameter charging in the MMSC are not fully documented at this time. It is recommended that any edits be made to these templates only after consulting with NowSMS MMSC Technical Support.

diameter-capabilities-exchange.xml:

<diameter>
<avp name="Origin-Host" code="264" mandatory="true" type="UTF8String" value="@@Config-Origin-Host@@" />
<avp name="Origin-Realm" code="296" mandatory="true" type="UTF8String" value="@@Config-Origin-Realm@@" />
<avp name="Host-IP-Address" code="257" mandatory="true" type="IPAddress" value="@@Config-Host-IP-Address@@" />
<avp name="Vendor-Id" code="266" mandatory="true" type="Unsigned32" value="0" />
<avp name="Product-Name" code="269" type="UTF8String" value="@@Config-Product-Name@@" />
<avp name="Supported-Vendor-Id" code="265" mandatory="true" type="Unsigned32" value="10415" />
<avp name="Supported-Vendor-Id" code="265" mandatory="true" type="Unsigned32" value="193" />
<avp name="Auth-Application-Id" code="258" mandatory="true" type="Unsigned32" value="4" />
<avp name="Acct-Application-Id" code="259" mandatory="true" type="Unsigned32" value="0" />
</diameter>

<diameter>
<avp name="Origin-Host" code="264" mandatory="true" type="UTF8String" value="@@Config-Origin-Host@@" />
<avp name="Origin-Realm" code="296" mandatory="true" type="UTF8String" value="@@Config-Origin-Realm@@" />
<avp name="Host-IP-Address" code="257" mandatory="true" type="IPAddress" value="@@Config-Host-IP-Address@@" />
<avp name="Vendor-Id" code="266" mandatory="true" type="Unsigned32" value="0" />
<avp name="Product-Name" code="269" type="UTF8String" value="@@Config-Product-Name@@" />
<avp name="Supported-Vendor-Id" code="265" mandatory="true" type="Unsigned32" value="10415" />
<avp name="Auth-Application-Id" code="258" mandatory="true" type="Unsigned32" value="4" />
<avp name="Acct-Application-Id" code="259" mandatory="true" type="Unsigned32" value="0" />
</diameter>

<diameter>
<avp name="Origin-Host" code="264" mandatory="true" type="UTF8String" value="@@Config-Origin-Host@@" />
<avp name="Origin-Realm" code="296" mandatory="true" type="UTF8String" value="@@Config-Origin-Realm@@" />
<avp name="Host-IP-Address" code="257" mandatory="true" type="IPAddress" value="@@Config-Host-IP-Address@@" />
<avp name="Vendor-Id" code="266" mandatory="true" type="Unsigned32" value="0" />
<avp name="Product-Name" code="269" type="UTF8String" value="@@Config-Product-Name@@" />
<avp name="Auth-Application-Id" code="258" mandatory="true" type="Unsigned32" value="4" />
<avp name="Acct-Application-Id" code="259" mandatory="true" type="Unsigned32" value="0" />
</diameter>

<diameter>
<avp name="Origin-Host" code="264" mandatory="true" type="UTF8String" value="@@Config-Origin-Host@@" />
<avp name="Origin-Realm" code="296" mandatory="true" type="UTF8String" value="@@Config-Origin-Realm@@" />
<avp name="Host-IP-Address" code="257" mandatory="true" type="IPAddress" value="@@Config-Host-IP-Address@@" />
<avp name="Vendor-Id" code="266" mandatory="true" type="Unsigned32" value="0" />
<avp name="Product-Name" code="269" type="UTF8String" value="@@Config-Product-Name@@" />
</diameter>

(Repeated sections show multiple attempts to be made if the previous attempt did not succeed.

diameter-credit-control.xml:

<diameter>
<avp name="Session-Id" code="263" mandatory="true" type="UTF8String" value="@@Session-Id@@" />
<avp name="Origin-Host" code="264" mandatory="true" type="UTF8String" value="@@Config-Origin-Host@@" />
<avp name="Origin-Realm" code="296" mandatory="true" type="UTF8String" value="@@Config-Origin-Realm@@" />
<avp name="Destination-Realm" code="283" mandatory="true" type="UTF8String" value="@@Config-Destination-Realm@@" />
<avp name="Auth-Application-Id" code="258" mandatory="true" type="Unsigned32" value="4" />
<avp name="Service-Context-Id" code="461" mandatory="true" type="UTF8String" value="@@Config-Service-Context-Id@@" />
<avp name="CC-Request-Type" code="416" mandatory="true" type="Unsigned32" value="4" />
<avp name="CC-Request-Number" code="415" mandatory="true" type="Unsigned32" value="0" />
<avp name="Event-Timestamp" code="55" mandatory="true" type="Unsigned32" value="@@TimeStamp@@" />
<avp name="Subscription-Id" code="443" mandatory="true" type="Grouped">
  <avp name="Subscription-Id-Type" code="450" mandatory="true" type="Unsigned32" value="0" />
  <avp name="Subscription-Id-Data" code="444" mandatory="true" type="UTF8String" value="@@Sender@@" />
</avp>
<avp name="Requested-Action" code="436" mandatory="true" type="Unsigned32" value="0" />
<avp name="3GPP-MS-TimeZone" code="23" vendor="10415" mandatory="true" type="OctetString" value="@@TimeZone@@" extensionset="3GPPTIMEZONE,SCAP" />
<avp name="3GPP-SGSN-MCC-MNC" code="18" vendor="10415" mandatory="true" type="UTF8String" value="@@SGSNMCCMNC@@" omitifblank="true" extensionset="3GPPSGSN" />
<avp name="SGSN-Address" code="1228" vendor="10415" mandatory="true" type="IPAddress" value="@@SGSNADDRESS@@" omitifblank="true" extensionset="3GPPSGSN" />
<avp name="Service-Identifier" code="439" mandatory="true" type="Unsigned32" value="@@Config-Service-Identifier@@" omitifblank="true" />
<avp name="Requested-Service-Unit" code="437" mandatory="true" type="Grouped" value="@@Config-CC-Service-Specific-Units@@@@Config-CC-Money@@" omitifblank="true" >
  <avp name="CC-Service-Specific-Units" code="417" mandatory="true" type="Unsigned64" value="@@Config-CC-Service-Specific-Units@@" multiplerecipmultiply="true" omitifblank="true" />
  <avp name="CC-Money" code="413" mandatory="true" type="grouped" value="@@Config-CC-Money@@" omitifblank="true" >
    <avp name="Unit-Value" code="445" mandatory="true" type="grouped" value="@@Config-CC-Money@@" omitifblank="true" >
      <avp name="Value-Digits" code="447" mandatory="true" type="Unsigned64" value="@@Config-CC-Money-Value-Digits@@" multiplerecipmultiply="true" />
      <avp name="Exponent" code="429" mandatory="true" type="Integer32" value="@@Config-CC-Money-Exponent@@" />
    </avp>
    <avp name="Currency-Code" code="425" mandatory="true" type="Unsigned32" value="@@Config-Currency-Code@@" omitifblank="true" />
  </avp>
</avp>
<avp name="Traffic-Case" code="1082" vendor="193" mandatory="true" type="Unsigned32" value="20" extensionset="SCAP" />
<avp name="Other-Party-Id" code="1075" vendor="193" mandatory="true" type="Grouped" multiplereciprepeat="true" extensionset="SCAP" >
  <avp name="Other-Party-Id-Nature" code="1076" vendor="193" mandatory="true" type="Unsigned32" value="1" />
  <avp name="Other-Party-Id-Data" code="1077" vendor="193" mandatory="true" type="UTF8String" value="@@Recip@@" />
  <avp name="Other-Party-Id-Type" code="1078" vendor="193" mandatory="true" type="Unsigned32" value="0" />
</avp>
<avp name="Service-Provider-Id" code="1081" vendor="193" mandatory="true" type="UTF8String" value="@@Config-Service-Provider-Id@@" omitifblank="true" extensionset="SCAP" />
<avp name="Subscription-Id-Location" code="1074" vendor="193" mandatory="true" type="UTF8String" value="@@Config-Subscription-Id-Location@@" omitifblank="true" extensionset="SCAP" />
<avp name="Service-Information" code="873" vendor="10415" mandatory="true" type="Grouped" extensionset="3GPP" >
  <avp name="MMS-Information" code="877" vendor="10415" mandatory="true" type="Grouped">
  <avp name="Originator-Address" code="886" vendor="10415" mandatory="true" type="Grouped">
    <avp name="Address-Type" code="899" vendor="10415" mandatory="true" type="Unsigned32" value="@@Sender-Address-Type@@" />
    <avp name="Address-Data" code="897" vendor="10415" mandatory="true" type="UTF8String" value="@@Sender@@" />
  </avp>
  <avp name="Recipient-Address" code="1201" vendor="10415" mandatory="true" type="Grouped" multiplereciprepeat="true">
    <avp name="Address-Type" code="899" vendor="10415" mandatory="true" type="Unsigned32" value="@@Recip-Address-Type@@" />
    <avp name="Address-Data" code="897" vendor="10415" mandatory="true" type="UTF8String" value="@@Recip@@" />
  </avp>
  <avp name="Submission-Time" code="1202" vendor="10415" mandatory="true" type="Unsigned32" value="@@TimeStamp@@" />
    <avp name="MM-Content-Type" code="1203" vendor="10415" mandatory="true" type="Grouped">
      <avp name="Type-Number" code="1204" vendor="10415" mandatory="true" type="Unsigned32" value="51" />
      <avp name="Content-Size" code="1206" vendor="10415" mandatory="true" type="Unsigned32" value="@@MsgSize@@" />
    </avp>
    <avp name="Message-ID" code="1210" vendor="10415" mandatory="true" type="UTF8String" value="@@Session-Id@@" />
    <avp name="Message-Type" code="1211" vendor="10415" mandatory="true" type="Unsigned32" value="1" />
    <avp name="Message-Size" code="1212" vendor="10415" mandatory="true" type="Unsigned32" value="@@MsgSize@@" />
    <avp name="Message-Class" code="1213" vendor="10415" mandatory="true" type="Grouped">
      <avp name="Class-Identifier" code="1214" vendor="10415" mandatory="true" type="Unsigned32" value="0" />
    </avp>
  </avp>
</avp>
</diameter>

A customer reported that they were no longer able to process received MMS messages using a GSM modem on the Orange  network in the UK.

There are a variety of potential causes, such as a SIM not being enabled for MMS support, or incorrectly provisioned Operator MMS settings.  However, this case was unusual.

Generally when there is a problem receiving MMS messages via a modem, the first thing we check is whether or not the modem can be used to send MMS messages.  Assuming that is OK, we look to see if NowSMS is reporting receiving any SMS messages when an MMS is expected.  As described in the How MMS Works article, the initial trigger for MMS message delivery is a specially formatted SMS message known as an MMS Notification.

The MMS Notification message was being received via SMS, and looking at the SMSDEBUG.LOG, it was determined that NowSMS was attempting to retrieve the MMS message using valid settings, but the operator MMSC was returning an error code 412 (Precondition Failed).

Needless to say, a web search for more information on HTTP error 412 Precondition Failed does not offer any good suggestions for what the problem might be.

However, in the discussion thread, Des correctly diagnosed that the MMSC was expecting something in the request that was not being provided, and suggested that the MMSC might be complaining that no user agent profile information is present in the request to retrieve the MMS message.

The solution to the problem was to locate and manually edit the MMSC.INI configuration file, adding the following settings under the [MMSC] section header:

HeaderUserAgent=iPhoneOS/4.2.1 (8C148) 
HeaderProfile=http://www.apple.com/mms/uaprof.rdf

For additional details, please refer to the original discussion thread:  Unable to retrieve mms using nowsms and orange.

Follow this link to browse all technical bulletins, or select a topic from the list below.

It is also possible to subscribe to receive new technical bulletins automatically via e-mail.

There are other articles that explain how NowSMS handles retry situations for outbound message delivery.  A good overview can be found in the article SMPP Error Code Handling in NowSMS.  While that article focuses primarily on SMPP connections, the general parameters do also apply to modems.  Additional issues specific to CIMD2 and UCP/EMI SMSC connections can be found in the article SMS Retry Error Handling with UCP/EMI and CIMD2.

There are two types of error conditions to consider.   One condition is that the 2-way command is unable to process a message and returns an error response, such as “500 Internal Error”.  This could happen because of a web server configuration problem, or it could also happen because of a logic error in the 2-way command … for example, it is not uncommon to find programming errors in a 2-way command where unexpected message content causes unexpected problems.  The other type of condition, is a connectivity problem where it is not possible to connect to the web server hosting the 2-way command.

If a web server returns a valid HTTP error response, such as “500 Internal Error”, NowSMS policy is to mark the message as bad and never retry the message.  Over 5 years ago, older versions of NowSMS used to retry messages in these situations, but customers who encountered script problems complained about duplicate messages when their scripts returned unexpected errors.   When a message in the 2-way SMS queue fails in this manner, a file with a .BAD file extension is created inside the NowSMS\SMS-IN directory structure.  It is  possible to rename the file with a .IN file extension to trigger NowSMS to reprocess the message.

The remainder of this document explains retry procedures for messages where it is not possible to connect to the web server hosting the 2-way command, or the web server does not return a valid HTTP response (timeout).

By default, NowSMS will retry 20 times with a staggered delay based upon the number of previous failures.

The default behaviour for the delayed retry schedule works like this:

After the first error, a retry can be attempted immediately (but first NowSMS will try other pending messages).

After the second error, NowSMS will wait 30 seconds before allowing the message to be retried.

After the third error, NowSMS will wait 60 seconds before allowing the message to be retried.

For each successive error, NowSMS waits an additional 30 seconds before allowing a retry.

After 20 errors, the message will be considered as failed.

The following parameters can be applied to the [2Way] section of the SMSGW.INI file to provide additional control for this retry schedule (this section of the file will not exist until you create it):

RetryDelay=
RetryDelayMultiplier=
RetryDelayAfterAttempts=
RetryDelayMax=
RetryMaxAttempts=

RetryDelay=#### specifies a number of seconds to wait to retry sending after an error condition, the default value is 30.

RetryDelayMultiplier=### specifies a multiplier to be applied for successive send failures, the default value is 1. For each failed attempt, the retry delay will be the product of RetryDelay*RetryDelayMultiplier*#FailedAttempts. To use a fixed retry delay of RetryDelay, specify RetryDelayMultiplier=0.

RetryDelayAfterAttempts=### specifies that the retry delay should only be applied after ### failed attempts, the default value is 2. NowSMS will immediately retry a failed message send until it has made RetryDelayAfterAttempts, after which it will apply a retry delay.

RetryDelayMax=### specifies the maximum number of seconds that NowSMS will allow to elapse between retries, putting a limit on the multiplier.

RetryMaxAttempts=### specifies the maximum number of retries that NowSMS will attempt before a message is rejected, the default value is 20.

Note: If memory serves me correctly, the default values will result in about 90 minutes worth of retries before erroring out. (And the message file being renamed with a .BAD extension.)

Note that if these same settings names are also used to control retry behaviour for outbound messages.

Retry settings set under the [SMSGW] section header will apply to both inbound (2-way) and outbound messages.  If retry settings exist under both [2Way] and [SMSGW], [2Way] settings are used for inbound (2-way) messages and [SMSGW] settings are used for outbound messages.

Retry settings can also be placed under connection specific headers (e.g., [Modem - xxx] or [SMPP - server:port]) so that different rules can apply to different outbound connections.

These accounting callbacks are HTTP-based. When accounting callbacks are enabled, NowSMS will issue HTTP requests to a customer supplied URL in order to interface with the customer billing and charging systems.

To enable SMS accounting callbacks, it is necessary to manually edit the SMSGW.INI configuration file, and define the callback URL under the [SMSGW] section header, using the following configuration parameter:

SMSAccountingURL=http://server/path

Whenever the SMS Gateway processes an SMS message, it issues an accounting callback by issuing an HTTP transaction to the callback URL. Variables describing the SMS message transaction are appended to the SMSAccoutingURL as HTTP GET CGI-style variables, with standard URL escaping applied for encoding reserved characters.

For example:

http://server.name/path?PreAuth=Yes&Type=SMSSend&From=UserAccount&To=%2B447777777777
&MsgCount=1&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

(These variables and transaction types will be described later in this section.)

Accounting callbacks exist primarily to record billing and charging information, however they also can offer the ability to maintain credit control external to NowSMS.

The following accounting callbacks exist for SMS Messaging:

• SMSSend PreAuth Callback – This callback occurs when a client user account is attempting to submit an SMS message to NowSMS.  The callback can choose to accept or reject the message, and can optionally control message routing and some other message attributes.
• SMSSend Accounting Callback – This callback occurs when a client user account has submitted an SMS message to NowSMS, and NowSMS has accepted this message for processing.  The callback can choose to accept or reject the message, and can optionally control message routing and some other message attributes.
• SMSOut Accounting Callback – This callback records that a message has been submitted to an upstream SMSC connection, or has an encountered an error condition or rejection when attempting to be sent to an upstream SMSC connection.
• SMSIn Accounting Callback – This callback records that an inbound message has been received from an upstream SMSC connection.

The remainder of this section provides additional details on the parameters supported by these callbacks.

SMSSend PreAuth Callback

This callback is executed when an SMS (web, SMPP, SMTP) user is requesting to send a message.

This is a “pre-authorisation” request, and does not mean that the message will actually be accepted by NowSMS for delivery. If NowSMS cannot successfully connect to the accounting URL, or the URL returns a response other than a standard “HTTP 200 OK” response, the user request to send a message will be blocked.  To separate error conditions from active blocking of a message, we recommend that the response include the text “PreAuth=Deny” if the message should be blocked from acceptance.

HTTP clients can submit a single message to multiple recipients.  In this case, normal behaviour for NowSMS is to use a single PreAuth callback specifying the  number of messages that will be sent in the “MsgCount” parameter.  It is possible to override this behaviour and generate a separate PreAuth callback per recipient by setting SMSAccountingPreAuthPerRecip=Yes under the [SMSGW] section header of SMSGW.INI.  (The setting SMSAccountingMustSetRoute=Yes also forces this per recipient callback behaviour.)  If a PreAuth callback rejects one recipient of a multiple recipient message, the entire message will be rejected.  For this reason, it is important to understand that a successful PreAuth callback does not mean that NowSMS has accepted a message for processing.  NowSMS will generate a separate SMSSend Accounting Callback (always one per recipient) when it accepts the message for further processing.

The following variables will be set for a pre-authorisation request:

PreAuth=Yes (indicates that the message is a Pre-Authorisation Request)
Type=SMSSend
From=Defined “SMS Users” Account
To=Comma delimited list of message recipients (will not be present if message is addressed to more than 100 recipients)
MsgCount=#### (number of recipients user is requesting to send the message to)
SubmitIP=a.b.c.d
SMSCRoute=xxxxxx (optional, will be present only if an explicit route was requested in message submission)
Sender=xxxxxx (optional, will be present only if a sender address was specified in message submission)
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
ReceiptRequested=Yes (optional, will be present only if message is requesting a delivery receipt … only available in v2009.01.26 and later)

Any defined SMPPOption parameters will also be included.

(Note: For SMTP message submissions, only PreAuth, Type, From, To and MsgCount variables will be present.)

Example:

http://server.name/path?PreAuth=Yes&Type=SMSSend&From=UserAccount&To=%2B447777777777&MsgCount=1&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

Note that URL escaping is performed when building the URL string. Most HTTP scripting languages will automatically unescape these parameters for you (e.g., %2B is translated back to “+” and %20 is translated back to a space character).

The HTTP response can include additional text responses to further control message processing.  These additional responses are expected to appear in the text of the HTTP response, as Name=Value entries appearing with one Name=Value per line of text (e.g., separated by new line characters).

The following Name=Value responses are supported for the SMSSend PreAuth Callback:

PreAuth=Deny

This causes NowSMS to reject the message, and the submitting client will receive a submission error.

SMPPErrorCode=0x#### or ####

Specifies a numeric error code to be returned to the submitting client if the message was submitted via SMPP.  The default error code for a rejected message is 0×0058 (ESME_RTHROTTLED).

RejectMessage=text string

This parameter specifies error text to be returned to the user if the submission interface supports returning such text (e.g., HTTP).

The following Name=Value responses are supported only if SMSAccountingPreAuthPerRecip=Yes or SMSAccountingMustSetRoute=Yes is set under the [SMSGW] section header of SMSGW.INI:

SMSCRoute=routename

If this setting is present in the response, NowSMS will use the specified outbound route name for delivering the message.   (For more information on SMS message routing, see http://www.nowsms.com/routing-sms-messages-to-a-specifc-smsc-route.)  In NowSMS versions 2011.08.11 and later, the SMSCRoute can also take the format localuser:username (the text localuser: followed by a user account name) to indicate that the message should be routed to a local user account instead of an outbound SMSC connection.

Note:  If you are relying on accounting callbacks to set route information, we recommend setting SMSAccountingMustSetRoute=Yes under the [SMSGW] section header of SMSGW.INI.  If this setting is not present, and an accounting callback returns invalid or missing routing information, NowSMS will use its internal routing logic to route the message.   If this setting is present, NowSMS will reject or fail messages if the accounting callback returns invalid or missing routing information.

Further Note:  Routing information can be returned in response to either the SMSSend PreAuth or SMSSend Accounting Callbacks.  If set by the SMSSend PreAuth Callback, any routing response by the SMSSend Accounting Callback will  be ignored and the PreAuth routing information will be used.

RouteCharge=####

If NowSMS credit balances are being used for user accounts, this specifies a charge to be used for the message.  By default, NowSMS assumes 1 credit per message.  This value can support a variable number of credits, including decimal values valid to thousandths of a credit (e.g., .001).

UserData=text

If this value is returned, it will be passed as a parameter to any future SMSSend Accounting Callback referencing this same transaction.  NowSMS versions 2012.02.09 and later will also pass this parameter to any future SMSOut Accounting Callback referencing this same transaction.

Accounting callbacks also have the ability to modify some message attributes (v2011.05.23+), including sender/source address, recipient/destination address and SMPP TLV parameters.  The following Name=Value responses are supported only if SMSAccountingAllowChanges=Yes is set under the [SMSGW] section header of SMSGW.INI: “To=”, “Sender=”, “ServiceType=”, “Validity=”, and “SMPPOption_xxxx=” (SMPPOption_xxxx refers to any optional SMPP TLV parameters that have been configured in NowSMS).  If any of these Name=Value parameters are present, the value specified will replace the existing value in the message being processed.  (In the case of SMPPOption_xxxx= parameters, a blank value will remove the parameter.)  It is recommended that the HTTP response terminate each value with a new line to signal the end of the value string.

SMSSend Accounting Callback

This callback is executed after an SMS message that has been submitted by a client user account has been accepted by NowSMS for further processing.

In NowSMS 2009 and later, NowSMS will check the response to the HTTP request. If this response includes the text “SMSCRoute=xxxxx”, then NowSMS will apply this SMSC route for the message. The specified route “xxxxx” can either be the name of a particular SMSC connection (e.g., “SMPP – host:port”), or it can be the value of the “RouteName=” attribute defined for one or more connections. (For more information on the “RouteName=” attribute, see http://www.nowsms.com/routing-sms-messages-to-a-specifc-smsc-route.)

In NowSMS versions 2011.08.11 and later, the SMSCRoute can also take the format localuser:username (the text localuser: followed by a user account name) to indicate that the message should be routed to a local user account instead of an outbound SMSC connection.

Note:  If you are relying on accounting callbacks to set route information, we recommend setting SMSAccountingMustSetRoute=Yes under the [SMSGW] section header of SMSGW.INI.  If this setting is not present, and an accounting callback returns invalid or missing routing information, NowSMS will use its internal routing logic to route the message.   If this setting is present, NowSMS will reject or fail messages if the accounting callback returns invalid or missing routing information.

The following variables will be set for the accounting callback:

Type=SMSSend
From=Defined “SMS Users” Account
To=Message Recipient Phone Number (if the message is sent to multiple recipients, this callback is repeated for each recipient)
MessageID=Message ID assigned to the message by NowSMS
SubmitIP=a.b.c.d
SMSCRoute=xxxxxx (optional, will be present only if an explicit route was requested in message submission)
Sender=xxxxxx (optional, will be present only if a sender address was specified in message submission)
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
ReceiptRequested=Yes (optional, will be present only if message is requesting a delivery receipt … only available in v2009.01.26 and later)

Any defined SMPPOption parameters will also be included.

(Note: For SMTP message submissions, only Type, From, and To variables will be present.)

Example:

http://server.name/path?Type=SMSSend&From=UserAccount&To=%2B447777777777&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

Note that URL escaping is performed when building the URL string. Most HTTP scripting languages will automatically unescape these parameters for you (e.g., %2B is translated back to “+” and %20 is translated back to a space character).

The HTTP response can include additional text responses to further control message processing.  These additional responses are expected to appear in the text of the HTTP response, as Name=Value entries appearing with one Name=Value per line of text (e.g., separated by new line characters).

The following Name=Value responses are supported for the SMSSend Accounting callback:

SMSCRoute=routename

If this setting is present in the response, NowSMS will use the specified outbound route name for delivering the message.   (For more information on SMS message routing, see http://www.nowsms.com/routing-sms-messages-to-a-specifc-smsc-route.)  In NowSMS versions 2011.08.11 and later, the SMSCRoute can also take the format localuser:username (the text localuser: followed by a user account name) to indicate that the message should be routed to a local user account instead of an outbound SMSC connection.

Note:  If you are relying on accounting callbacks to set route information, we recommend setting SMSAccountingMustSetRoute=Yes under the [SMSGW] section header of SMSGW.INI.  If this setting is not present, and an accounting callback returns invalid or missing routing information, NowSMS will use its internal routing logic to route the message.   If this setting is present, NowSMS will reject or fail messages if the accounting callback returns invalid or missing routing information.

Further Note:  Routing information can be returned in response to either the SMSSend PreAuth or SMSSend Accounting Callbacks.  If set by the SMSSend PreAuth Callback, any routing response by the SMSSend Accounting Callback will  be ignored and the PreAuth routing information will be used.

UserData=text

If this value is returned, NowSMS versions 2012.02.09 and later will also pass this parameter to any future SMSOut Accounting Callback referencing this same transaction.

Accounting callbacks also have the ability to modify some message attributes (v2011.05.23+), including sender/source address, recipient/destination address and SMPP TLV parameters.  The following Name=Value responses are supported only if SMSAccountingAllowChanges=Yes is set under the [SMSGW] section header of SMSGW.INI: “To=”, “Sender=”, “ServiceType=”, “Validity=”, and “SMPPOption_xxxx=” (SMPPOption_xxxx refers to any optional SMPP TLV parameters that have been configured in NowSMS).  If any of these Name=Value parameters are present, the value specified will replace the existing value in the message being processed.  (In the case of SMPPOption_xxxx= parameters, a blank value will remove the parameter.)  It is recommended that the HTTP response terminate each value with a new line to signal the end of the value string.

SMSOut Accounting Callback

This callback is executed when a submitted SMS message is dispatched to an upstream SMSC connection, or queued for a local SMPP user account.

The response to this HTTP callback is currently ignored. A standard HTTP 200 OK response is encouraged for future compatibility.

The following variables can be set for the accounting callback:

Type=SMSOut
From=String (local user account name, or upstream SMSC connection name)
To=Message Recipient Phone Number
MessageID=Message ID assigned to the message by NowSMS
SubmitIP=a.b.c.d (not present for messages received from upstream SMSC connection)
Sender=xxxxxx
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
MessageID=String (NowSMS assigned message ID)
SMSCMsgId=String (upstream SMSC assigned message ID, if available)
SMSCName=String (the SMSC connection to which this message was routed in the format that it appears in the NowSMS SMSC list, e.g., “SMPP – servername:port”)
Status=String (Starts with “OK”, “Retry Pending” or “ERROR” to indicate message disposition)

Any defined SMPPOption parameters will also be included.

SMSIn Accounting Callback

This callback is executed when an SMS message is received from an upstream SMSC connection.

The response to this HTTP callback is currently ignored. A standard HTTP 200 OK response is encouraged for future compatibility.

The following variables can be set for the accounting callback:

Type=SMSIN
To=Message Recipient Phone Number
Sender=xxxxxx
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
SMSCReceiptMsgID=String (optional, NowSMS assigned message ID will be present if this is a delivery receipt)
SMSCReceiptMsgIDOrig=String (optional, upstream SMSC assigned message ID will be present if this is a delivery receipt)
SMSCName=String (the SMSC connection from which this message was received in the format that it appears in the NowSMS SMSC list, e.g., “SMPP – servername:port”)

Any defined SMPPOption parameters will also be included.

The purpose of this article is to document additional parameters supported in more recent versions of NowSMS.

This provisioning interface is enabled whenever one or more user accounts is defined in NowSMS under “SMS Users” with the “Enable Admin Access” checked.

This interface is accessed via the NowSMS web interface port, with a URI of “/provision” followed by a series of “HTTP GET” parameters. (The admin username and password must be supplied in the HTTP GET request within an “Authorization:” header using HTTP Basic Authentication, or they can be be appended to the URL as parameters such as /provision?user=username&password=password.  Using URL parameters for provisioning authentication is supported only in NowSMS 2012.01.10 and later.)

Two different provisioning request formats are defined, one for defining ”SMS Users” accounts, and a second for defining “MMSC Users” accounts.

If a parameter of ”Type=SMS“ is specified, the following parameters are supported:

AdminAction=Add, Modify, Delete, or CreditCheck

Name=Account Name

Password=password

Fullname=Full Name

EnableWebLogin=Yes/No

EnableSmppLogin=Yes/No

EnableSmtpLogin=Yes/No

ForcedSenderAddress=Sender Address

RestrictIPAddress=list of IP addresses

EnableCreditBalance=Yes/No

CreditsToAdd=####

MessageLimitDefault=Yes/No

MessageLimitPerDay=####

MessageLimitPerMonth=####

RecipientAddresses=list of recipient phone numbers that should be routed to this account

WebOptions=All/Advanced/TextOnly/Text/SMSMMS/SMSWAPMM/SMSMMSWAPMM

AdminEnabled=Yes/No (version 2011.10.18 and later)

ReceiveEnabled=Yes/No (version 2011.10.18 and later)

As an example, to add credits to an existing account, issue the following URL request:

http://server:port/provision?Type=SMS&AdminAction=Modify&Name=accountname&CreditsToAdd=100

Assuming that the user is authorized to issue a provisioning command (valid username/password, and supported IP address for originating the request), the server will return a normal HTTP response code of 200 with a MIME content type of “text/plain”. The response will start with “OK” if the request was successful, or “ERROR” if the request failed. If a”CreditsToAdd” parameter was specified, or ”AdminAction=CreditCheck”, the HTTP response will include the text ”Credits=####”, where “####” is the current balance for the account.

If a parameter of ”Type=MMS“ is specified, the following parameters are supported:

AdminAction=Add, Modify, Delete, or CreditCheck

PhoneNumber=phonenumber

Name=Alias

Password=password

Fullname=Full Name

MessageLimitDefault=Yes/No

MessageLimitPerDay=####

MessageLimitPerMonth=####

This bug only effects configurations where NowSMS is being used as an SMPP server.  In other words, an SMPP client is being used to submit messages to NowSMS, and messages are being segmented by the SMPP client before they are submitted to NowSMS.  (If the client uses message_payload submission and allows NowSMS to segment messages, the problem does not occur.)

This bug could cause up 1 to 3 extra @ characters to be appended to message text for long messages that require 3 or more segmented messages.  Specifically effected were messages where the final segment contained less than 4 characters of text, where extra @ characters might be added to cause the segment to have at least four characters.  For example, messages with between 207 and 209 characters inclusive would be padded to 210 characters with extra @ characters at the end.  Messages with between 460 and 462 characters inclusive were similarly effected, and padded to 463 characters in length.

(Effected messages had character lengths between (x * 153) + 1 and (x * 153) + 3 inclusive, where x is larger than 2.)

An updated release of NowSMS, which corrects this problem, is available at http://www.nowsms.com/download/nowsms20120209.zip.

An updated release of NowSMS Lite which includes this fix is available at http://www.nowsms.com/download/lite20120209.zip.

Please note that there are numerous other issues that can cause @ characters to appear unexpectedly in SMS messages, which are not specifically related to this bug.  This bug only effects messages of the specified lengths in the listed versions of NowSMS.

Other unexpected problems related to the  @ character can occur because in the GSM character set, the @ character is represented by a NULL (value of 0).

If  you experience a problem where your text messages are truncated at an @ character, or @ characters are missing from text messages, this is indicative that you are using a different character set than the SMSC.  If you experience this problem with an SMPP connection, we recommend changing the “SMSC Character Setting” for the SMPP connection to use iso-8859-1, as this problem suggests that the SMPP provider is expected use of the iso-8859-1 character set.  By default, NowSMS uses the GSM character set for SMPP connections.

If you are experiencing problems sending particular characters via SMS, please post a query in our discussion forums at http://www.nowsms.com/messages.

The problem occurs because the MMS client cannot process an MMS notification message where the MMS Content URL contains a URL escaped parameter.  When the MMS client encounters a URL escaped parameter in a URL, it re-encodes the URL with another level of URL escaping.  As an example, if the MMS client receives an MMS notification which includes a URL with a parameter ?id=%2b, the MMS client converts this to ?id=%252b.  This errant conversion causes the MMSC to be unable to determine the message that the client is asking to retrieve.

As a work-around for this issue, the following configuration setting can be applied in the [MMSC] section of the MMSC.INI file:

CompactMMSURL=Yes

This setting changes the format of the MMS content URL so that it will not include any URL escaped parameters, and will avoid the bug in the Nokia N9 MMS client.

The original intended effect of this setting was to reduce the length of the MMS Content URL by 14 bytes.  This setting should have no other effect on operation.

An updated release of the NowSMS MMSC is also available at http://www.nowsms.com/download/nowsms20120209.zip, which implements a work-around for this problem without requiring any special configuration settings.

For a VB.NET version of this example, please see the related article Send MMS from VB.NET.

MMS examples for other environments (PHP, Java, command line) can be found at http://www.nowsms.com/sending-mms-messages-with-nowsms.

As discussed in Sending MMS Messages with NowSMS, one of the easiest ways to interface with NowSMS for sending MMS messages is to use what we refer to as the Proprietary URL Submission interface.  This interface is the one used for sending messages via the forms in the built-in NowSMS web interface.  Sending an MMS message via this interface is a matter of using an HTTP POST to submit MMS content in the form using the MIME type “multipart/form-data”.  This technique is often referred to as “HTTP File Upload” and is associated with web pages that have a “Browse” button that allows files to be uploaded.

There’s a great C#.NET HTTP File Upload library at: http://aspnetupload.com/Upload-File-POST-HttpWebRequest-WebClient-RFC-1867.aspx

A direct link to download the library is here (only the UploadHelper component is needed): http://aspnetupload.com/AspNetUploadSamples.zip

In the event that this link does not work in the future, we have archived a copy of the library at the following link:

AspNetUploadSamples.zip AspNetUploadSamples.zip(388.7 k)

The following code example uses code from that library to send an MMS message:

(Note: This example can be downloaded at http://www.nowsms.com/download/sendmms.c#.txt.)

// Set the following variables as appropriate for your system. 

// URL that points to NowSMS web interface 
Uri url = new Uri("http://127.0.0.1:8800/"); 

// Valid username/password for account defined in NowSMS under "SMS Users". 
String username = "testuser"; 
String password = "testpass"; 

// Images & Files to be included in the message. 
// First parameter is filename and path. 
// Second parameter must be MMSFILE 
// Third parameter should be MIME type 

UploadFile[] files = new UploadFile[] 
{ 
new UploadFile("f:\\temp\\image1.png", "MMSFILE", "image/png"), 
new UploadFile("f:\\temp\\image2.jpg", "MMSFILE", "image/jpeg"), 
}; 

// Create additional form parameters for sending MMS 
NameValueCollection form = new NameValueCollection(); 

// "PhoneNumber" variable contains recipient phone number 
form["PhoneNumber"] = "9999999999"; 
// "MMSFROM" variable contains sender phone number or address
//  (Note: Ignored when sending via modem) 
form["MMSFROM"] = "9999999999"; 
// "MMSSUBJECT" variable contains subject line for message 
form["MMSSUBJECT"] = "test subject"; 
// "MMSTEXT" variable contains test to appear in message (optional) 
form["MMSTEXT"] = "This is a test message"; 

// Send the request to NowSMS, creating an HttpWebRequest and 
// then use HttpUploadHelper to send files in multipart/form-data format 
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url); 

var credCache = new CredentialCache(); 
credCache.Add(url, "Basic", new NetworkCredential(username, password)); 
req.Credentials = credCache; 

HttpWebResponse resp = HttpUploadHelper.Upload(req, files, form); 

// Read the HTTP response and echo to console 
using (Stream s = resp.GetResponseStream()) 
using (StreamReader sr = new StreamReader(s)) 
{ 
string response = sr.ReadToEnd(); 
System.Console.WriteLine(response); 
}

Additional MMS options can be included using the form["variablename"] = “value” syntax shown in the above example. The other options/variables are described in more detail in http://www.nowsms.com/sending-mms-messages-with-nowsms.

For a C# .NET version of this example, please see the related article Send MMS from C# .NET.

MMS examples for other environments (PHP, Java, command line) can be found at http://www.nowsms.com/sending-mms-messages-with-nowsms.

As discussed in Sending MMS Messages with NowSMS, one of the easiest ways to interface with NowSMS for sending MMS messages is to use what we refer to as the Proprietary URL Submission interface.  This interface is the one used for sending messages via the forms in the built-in NowSMS web interface.  Sending an MMS message via this interface is a matter of using an HTTP POST to submit MMS content in the form using the MIME type “multipart/form-data”.  This technique is often referred to as “HTTP File Upload” and is associated with web pages that have a “Browse” button that allows files to be uploaded.

There’s a great C#.NET HTTP File Upload library at: http://aspnetupload.com/Upload-File-POST-HttpWebRequest-WebClient-RFC-1867.aspx

A direct link to download the library is here (only the UploadHelper component is needed): http://aspnetupload.com/AspNetUploadSamples.zip

In the event that this link does not work in the future, we have archived a copy of the library at the following link:

AspNetUploadSamples.zip AspNetUploadSamples.zip(388.7 k)

The following VB.NET code example uses code from that library to send an MMS message:

(Note: This example can be downloaded at http://www.nowsms.com/download/sendmms.vb.txt.)

Imports System.Text
Imports System.IO
Imports System.Net
Imports System.Web
Imports System.Web.Services
Imports ClassLibrary1
Imports ClassLibrary1.Krystalware
Imports ClassLibrary1.Krystalware.UploadHelper
Imports ClassLibrary1.Krystalware.UploadHelper.HttpUploadHelper
Imports ClassLibrary1.Krystalware.UploadHelper.MimePart
Imports ClassLibrary1.Krystalware.UploadHelper.StreamMimePart
Imports ClassLibrary1.Krystalware.UploadHelper.StringMimePart
Imports ClassLibrary1.Krystalware.UploadHelper.UploadFile
Imports System.Collections.Specialized

Public Class Form1
    Public Sub SendMMS()
        ' Set the following variables as appropriate for your system. 
        ' URL that points to NowSMS web interface 
        Dim url As New Uri(" http://127.0.0.1:8800/ ")

        ' Valid username/password for account defined in NowSMS under "SMS Users". 
        Dim username As [String] = "testuser"
        Dim password As [String] = "testpass"

        ' Images & Files to be included in the message. 
        ' First parameter is filename and path. 
        ' Second parameter must be MMSFILE 
        ' Third parameter should be MIME type 

        Dim files As UploadFile() = New UploadFile() {
         New UploadFile("c:\mms\tts.mp3", "MMSFILE", "audio/mpeg"),
         New UploadFile("c:\mms\image.png", "MMSFILE", "image/png")}

        ' Create additional form parameters for sending MMS 
        Dim form As New NameValueCollection()

        ' "PhoneNumber" variable contains recipient phone number 
        form("PhoneNumber") = "09059999999"
        ' "MMSFROM" variable contains sender phone number or address
        '  (Note: Ignored when sending via modem) 
        form("MMSFROM") = "09058888888"
        ' "MMSSUBJECT" variable contains subject line for message 
        form("MMSSUBJECT") = "test subject"
        ' "MMSTEXT" variable contains test to appear in message (optional) 
        form("MMSTEXT") = "this is a test message"

        ' Send the request to NowSMS, creating an HttpWebRequest and 
        ' then use HttpUploadHelper to send files in multipart/form-data format 
        Dim req As HttpWebRequest = DirectCast(WebRequest.Create(url), HttpWebRequest)

        Dim credCache = New CredentialCache()
        credCache.Add(url, "Basic", New NetworkCredential(username, password))
        req.Credentials = credCache

        Dim resp As HttpWebResponse = HttpUploadHelper.Upload(req, files, form)

        ' Read the HTTP response and echo to console 
        Using s As Stream = resp.GetResponseStream()
            Using sr As New StreamReader(s)
                Dim response As String = sr.ReadToEnd()
                MsgBox(response)
                System.Console.WriteLine(response)
            End Using
        End Using
    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        SendMMS()
    End Sub
End Class

Additional MMS options can be included using the form(“variablename”) = “value” syntax shown in the above example. The other options/variables are described in more detail in http://www.nowsms.com/sending-mms-messages-with-nowsms.

In addition to the HHE issues discussed in that article, we frequently receive questions about using HTTP Cookie headers for identifying the MSISDN.

These questions are usually asked for the following reasons:

• Customers migrating from or augmenting an Ericsson MIEP may have applications that expect to receive the MSISDN via HTTP Cookie headers.
• The Opera Mini browser has a tendency to remove the X-MSISDN header that NowWAP would usually generate.

For these reasons, recent versions of NowWAP (2011 and later), support a built-in option that can be used to automatically add an HTTP Cookie header for the MSISDN.

To enable this option, edit WAPGW.INI, and under the [WAPGW] header, add MsisdnCookieHeaders=Yes

When this option is set, NowWAP will generate an HTTP Cookie header for the MSISDN, in addition to the standard X-MSISDN header, when communicating with any content domains that are enabled for Basic HHE.

For compatibility purposes, NowWAP generates an HTTP Cookie Header using a format similar to those generated by the Ericsson MIEP:

Cookie: User-Identity-Forward-MSISDN=1234567890

If IMSI information is available via RADIUS, the IMSI will also be included in a User-Identity-Forward-IMSI cookie.

This interface is described in more detail in the following article:

http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics

An XML Schema Definition can be found in the following article:

http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics-2

As we frequently receive questions asking how this status information can be accessed via a PHP script, this article will provide some simple examples.

The PHP SimpleXML functions are the easiest way to access and process this information.

In a discussion board posting (http://www.nowsms.com/discus/messages/1/60149.html), we previously provided a simple example of a PHP script that queries the number of messages waiting in the NowSMS outbound SMS message queue.

The first step to access the data is to load the status URL into a SimpleXML object:

<?php

$xmldata = file_get_contents
             ("http://127.0.0.1:8800/admin/xmlstatus?user=adminuser&password=adminpass");

$xml = simplexml_load_string($xmldata);

?>

Substitute in your appropriate IP address and port, and the appropriate “adminuser” and “adminpass” values for your NowSMS installation.

To report the number of messages in the outbound SMS message queue, simply access the following variable:

$xml->SMSOUTQ

To report the number of messages sent out today, or in the last 7 or last 30 days, use the following variables:

$xml->SMSSent->MessagesToday
$xml->SMSSent->MessagesLast7Days
$xml->SMSSent->MessagesLast30Days

To report the number of active SMPP client connections, use the following variable:

$xml->SMPPClientList->ActiveConnectionCount

Refer to the XML examples and schema referenced in the earlier links to see other status information that is available via this XML-based interface.

As an additional example, here is code that queries SMSC connection status and reports any connections that are experiencing connectivity problems:

<?php

$xmldata = file_get_contents
            ("https://127.0.0.1:8801/admin/xmlstatus?user=adminuser&password=adminpass");

$xml = simplexml_load_string($xmldata);

$allConnectionsOK = true;

foreach ($xml->SMSCStatus as $smscStatus) {

   if (strcasecmp ($smscStatus->Status, "OK")) {

      $allConnectionsOK = false;

      echo "Connection Error: " . $smscStatus->Name . " -- " . $smscStatus->StatusDetail . "\n";

   }

}

if ($allConnectionsOK) {

   echo "OK\n";

}

?>

For more information on using the SimpleXML functions, please refer to the PHP documentation at:   http://us.php.net/manual/en/book.simplexml.php

For more information on the NowSMS Status Query XML interface, please refer to the following articles:

• http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics
• http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics-2

The MMSC user database had become corrupt, preventing new users from being able to be automatically provisioned.  While it is not known why this corruption occurred, the most common potential cause is an abnormal system shutdown, such as power failure.

Future versions of the MMSC will include start-up logic to detect and repair corrupt MMSC user databases automatically.  However, the following instructions for manual repair may be helpful if someone else encounters this problem.

Copy the MMSCUSERS.DB file (normally located in \ProgramData\NowSMS) to another location. Also copy SQLITE3.EXE from the NowSMS program directory.

From a command line prompt, issue the following command:

sqlite3 mmscusers.db

This command  should bring you to an sqlite> prompt.

Issue the following command:

select name from sqlite_master where type='table';

The system should respond back with:

Users
sqlite>

Issue the following command:

select count (*) from users;

The system should report how many users are in the database.

Issue the following command:

pragma integrity_check;

If the database is corrupt, this command should return an error.  If there is no corruption problem, this command will return OK.

Use the .quit command to exit the sqlite3 utility.

To attempt to recover the database, issue the following command:

sqlite3 mmscusers.db .dump > mmscusers.txt

mmscusers.txt will be a text file of SQL commands containing a database dump.

Inspect this text file to confirm that it has close to the number of users expected. If it does not, please contact NowSMS support for further analysis.

To create a new repaired database, issue the following command:

sqlite3 mmscusersnew.db < mmscusers.txt

The repaired database will be named mmscusersnew.db. Rename to mmscusers.db and replace the original database in the NowSMS data directory. It is necessary to stop the NowSMS services in order to do this.

For example, an end user in the UK might want to send an SMS message to 0777777777 using the local number format, but the upstream SMSC connection requires a country code to be specified, such as +44777777777.

An end user in the US might sometimes prefix a number with 1, and other times not.

Starting with the 2011.10.18 release of NowSMS, there are configuration settings that can be used to perform these types of phone number prefix conversions globally or only for specific SMSC connections a per SMSC basis.

To configure a global option for prefix number conversion to apply to all SMS messages, edit the SMSGW.INI file and under the [SMSGW] section add one or both of the following settings:

GlobalRecipPrefixConvert=???:???
GlobalSenderPrefixConvert=???:???

These settings provide a global option for prefix number conversion to apply to all SMS messages (for SMSC specific options search PrefixConvert in the SMSC specific section of SMSGW.INI). These settings apply to sender (source) and recipient (destination) addresses, as denoted in the settings name. Prefix conversions can be a comma delimited list, such as 00:+,0:+44 In this case, 0044777777777 is converted to +44777777777, and 0777777777 would be converted to +44777777777. This conversion is applied as messages are submitted.

To apply these conversions only for a specific SMSC connection, in the SMSC specific section of SMSGW.INI (e.g., [Modem - modem driver name] or [SMPP - server:port]) the following settings are now supported to apply number prefix conversions for inbound or outbound messages:

OutRecipPrefixConvert=???:???
OutSenderPrefixConvert=???:???
InRecipPrefixConvert=???:???
InSenderPrefixConvert=???:???

These settings provide support for prefix number conversion when submitting SMS messages to an SMSC connection, in order to deal with situations where a particular provider requires national or international number format. These settings apply to sender (source) and recipient (destination) addresses, as denoted in the settings name. Prefix conversions can be a comma delimited list, such as 00:+,0:+44 In this case, 0044777777777 is converted to +44777777777, and 0777777777 would be converted to +44777777777. For outbound messages, the conversion occurs before the message is submitted via this SMSC connection. For inbound messages, it is applied as the message is received from the SMSC connection.

In most cases, you would be applying conversions for the recipient phone number.

For example, a conversion that assumes UK local numbers being converted to international format would use one of the following examples (the first example is applied globally, the second only for a specific SMSC connection):

[SMSGW]
GlobalRecipPrefixConvert=00:+,0:+44

[SMPP - server:port]
OutRecipPrefixConvert=00:+,0:+44

With the above setting, 0044777777777 would be converted to +44777777777, and 0777777777 would be converted to +44777777777.

If the connection is an SMPP connection, the “+” is not actually included in the recipient address, but instead NowSMS uses this as a signal to indicate that the recipient TON (dest_addr_ton) value should be set to 1 to indicate an international number.

A similar conversion for USA local numbers would look like this (the first example is applied globally, the second only for a specific SMSC connection):

[SMSGW]
GlobalRecipPrefixConvert=011:+,1:+1,2:+12,3:+13,4:+14,5:+15,6:+16,7:+17,8:+18,9:+19

[SMPP - server:port]
OutRecipPrefixConvert=011:+,1:+1,2:+12,3:+13,4:+14,5:+15,6:+16,7:+17,8:+18,9:+19

With the above setting, 01144777777777 (011 being an old style prefix for an international phone number) would be converted to +44777777777.

15555551212 would be converted to +15555551212.

5555551212 would be converted to +15555551212.

For more complex and custom conversions of source/sender and destination/recipient addresses, it is also possible to apply dynamic conversions via accounting callbacks. Every time NowSMS routes a message, it can be configured to pass message details to an HTTP-based callback. This callback can be configured to have the ability to dynamically make changes to source and destination addresses. For more information on this capability, see Dynamic SMS Message Routing with HTTP Callbacks.

It may also be necessary to specify more than one SMPP connection to the same SMSC in order to process messages for more than one short code.  In this latter case, you may need to specify different credentials for each SMPP connection.  In this case, simply add a second (or third, or fourth…) SMPP connection, specifying the same server address.  When NowSMS adds the connection to the SMSC list, it will automatically append “#2″ (or #3, or “#4″) to the SMSC address in order to maintain separate settings for each connection.

However, if you are connecting to the same SMSC multiple times using the same account credentials, it can be inconvenient to define the same connection multiple times.  For this reason, NowSMS 2011.07.05 and later releases (see http://www.nowsms.com/category/updates) provide a configuration interface to define the number of transmitter, receiver and/or transceiver connections to be allocated for a single SMPP connection, without requiring multiple duplicate connections to be defined.

To configure these settings, edit the “Properties” of an SMPP connection, and in the “Advanced Settings” menu, the following settings are available:

If “Send and Receive Messages over the same Connection (SMPP Transceiver)” is enabled, specify the number of concurrent SMPP Transceiver sessions that NowSMS should establish.  (Transceiver sessions support both sending and receiving messages over the same connection/session.)

If this transceiver mode is not enabled, the number of Transmitter and Reciever Sessions can be configured independently.

These settings can also be manually configured by editing SMSGW.INI.

In the [SMPP - server:port] section of SMSGW.INI, the following settings are used:

TransmitterCount=##
ReceiverCount=##

TransmitterCount=## defines the number of transmitter connections to be established. If transceiver mode is configured, TransmitterCount specifies the number of transceiver connections to be established. If transceiver mode is not configured, ReceiverCount specifies the number of receiver connections to be established.

This document details the update release history since the previous official release, version 2010.11.04.  Release history for the changes prior to the current official release can be found at  http://www.nowsms.com/category/updates.

Customers running any earlier 2011 interim release of NowSMS are strongly encouraged to update to this release due to a number of problems that exist in earlier 2011 interim releases. (If upgrading is not possible, as a  precaution delete the file NLS.INI if it exists in the Program Files\NowSMS directory, which will disable SMS shift table support that was introduced earlier this year.  Note that this recommendation applies only to NowSMS 2011 releases prior to 2011.07.05.  Do not delete this file if running NowSMS 2011.07.05 or later.)

Highlights of this update:

1.) Configuration changes no longer require a NowSMS service restart.  The NowSMS service will activate configuration changes without requiring a full service restart.

2.) Updated web interface templates (we know … the old ones were perfectly functional, but yes, they were a throwback to web 1.0, or possibly web 0.5).

3.) Increased administrative capabilities from the web browser.  In addition to statistics and log files, it is possible to view alerts, recent activity, inbound and outbound messages.  It is also possible to add and update user accounts.

4.) Easier configuration of logical SMSC Route Names (as compared to server addresses in earlier releases).

5.) SMS Shift Table Support (of interest primarily for those working with Turkish and Portuguese languages, as well as for handset developers/testers working to add support for SMS shift tables in languages of the Indian subcontinent).  For more information, see http://www.nowsms.com/tag/sms-shift-table.

6.) SMPP connections can define multiple transmitter and/or receiver sessions.

7.) SMPP relay improvements – Support for absolute format validity_period settings, support for additional values in message_state TLV parameters.  Also accounting callbacks can now have the capability to modify TLV parameters, as well as source and destination addresses.

8.) MM4 – Addressed an issue with missing originator/From fields for messages from a particular operator.

9.) E-mail alert improvements (can use SMTP authentication and SSL/TLS to send out via an account).

10.) Numerous accounting callback enhancements (more detailed information can be found in the release notes).

11.) Local PHP script support.  NowSMS can now host PHP scripts directly, so that you do not need to configure an external web server for hosting 2-way commands or accounting callbacks.  For more information, see http://www.nowsms.com/now-sms-native-php-scripts.

12.) SMPP – Improved handling of throttling errors especially as an effort to keep multiple parts of a segmented message from being separated.

There are numerous other minor updates that are detailed in the release history information below.  The release history information provides additional information on configuration settings that have been added to address unusual configuration requirements.

2011-07-05:

• SMS Gateway: SMS accounting callbacks can now be used to route messages to an external SMSC account, or to a local user account. When the “SMSSend” accounting callback is issued, it is possible for the callback to return SMSCRoute=routename in the HTTP response to specify an external route via which the message should be routed, or SMSCRoute=localuser:username to route the message to a local user account.
• SMPP: message_state TLV parameter is now set according to the text of the delivery receipt. Previously a value of 5 (undeliverable) was used for all undeliverable status conditions. Most notable, a value of 3 is now correctly used for messages that were marked expired.
• Web Interface: Update “Send Text Message” HTML form to address issue where Chrome and Firefox count a line break as one character, but when posting the message, post two characters instead. (Counter now counts two characters for a line break, assuming the browser will post two characters.) IE counts two characters and posts two characters.
• SMS Gateway: Add support for prefix number conversion when submitting SMS messages to an SMSC connection in order to deal with situations where a particular provider requires national or international number format. In the SMSC specific section of SMSGW.INI (e.g., [Modem - modem driver name] or [SMPP - server:port]) the following settings are now supported to apply number prefix conversions for inbound or outbound messages: OutRecipPrefixConvert, OutSenderPrefixConvert, InRecipPrefixConvert, InSenderPrefixConvert. These settings apply to sender (source) and recipient (destination) addresses, as denoted in the settings name. Prefix conversions can be a comma delimited list, such as 00:+,0:+44 In this case, 0044777777777 is converted to +44777777777, and 0777777777 would be converted to +44777777777. For outbound messages, the conversion occurs before the message is submitted via this SMSC connection. For inbound messages, it is applied as the message is received from the SMSC connection.
• 2-way SMS: Add support for @@SMSCROUTEID@@ replaceable parameter to contain the unique route name identifier (e.g., “Modem – Driver Name” or “SMPP – host:port”). If the same route name is assigned to multiple connections, the route name is used for @@SMSCROUTE@@. @@SMSCROUTEID@@ allows distinction of which connection the message was received form.
• SMS Gateway: Add SMSGW.INI [SMSGW] setting, UserOutboundQueueLimitInterval=## to specify the delay interval between user queue size scans when the UserOutboundQueueLimit=## setting is used.
• SMS Gateway: Fix for exception errors related to improper decoding of some messages that make use of a single shift table.

2011-06-20:

• SMPP: Absolute format validity_period setting is now supported from SMPP clients. HTTP clients can also use the “&Validity=” parameter to submit a validity_period setting in SMPP format. (SMPP format validity period will only be forwarded to upstream SMPP connections.
• MMSC: MmsMessageSizeLimit=#### (value in KB) setting in MMSC.INI now also applies to MM7 and MM4 submissions.
• MMSC: Handle situation where the HTTP POST from an MM7 client includes a host name in the POST URL. Normally the POST URL in the HTTP request only includes a host name in the URL if the submission is being routed via an HTTP Proxy. MMSC already handles this case for MM1 submissions, but not for MM7 submissions until this release. (According to HTTP 1.1 specification, servers must accept this format, but client should not generate this format unless posting via an HTTP proxy.)

2011-06-15:

• 2-way SMS: Additional fix for restarts associated with a bug introduced in 2011.05.23 version for 2-way SMS messages that include SMPPOptions parameters.

2011-06-09:

• SMS Gateway: Fix for a resource leak that can be caused by inbound SSL connnections (HTTP or SMPP) that do not complete the SSL handshake.

2011-06-08:

• 2-way SMS: Fix for restarts associated with a bug introduced in 2011.05.23 version for 2-way SMS messages that include SMPPOptions parameters.

2011-06-06:

• MM4: Fix for a problem where messages received from a particular operator had a missing originator/From field. This was caused by unexpected horizontal tab characters being included in the SMTP “From:” header. According to the SMTP specification, these horizontal tab characters are legal, and NowSMS needs to ignore them.

2011-06-03:

• SMS Gateway Startup: Move most database integrity checks to a background thread so as to not delay startup.
• 2-way SMS commands with mailto: links: Support routing e-mail non-delivery messages back to sender if message undeliverable.

2011-06-02:

• SMS Gateway: Fix for 2011-05-23 interface reporting errors with the SMPP server if an SSL port number for SMPP is not defined.
• SMS Gateway: Route names are now supported in the configuration interface to make it easier to work with SMSC connections. “SMSOUT” and “SMSIN” accounting callbacks now include “&SMSCRouteName=” parameter.
• SMS Gateway: Fix for problem where server would not take extra time to shutdown if HTTP SSL connections are supported.

2011-05-23:

• SMS Gateway Web interface:  Update NowSMS web user interface templates.
• SMS Gateway:  Web Administration Access is now associated as an attribute to an “SMS Users” account, instead of being a separate login identity.
• SMS Gateway:  E-Mail alerts can now specify to be sent via a mail server that requires with SMTP Authentication & SSL/TLS.
• SMPP: Configuration program supports defining the number of simultaneous transmitter and/or receiver sessions to be associated with an SMPP SMSC connection.
• HTTP SMSC: Configuration program supports defining the number of simultaneous HTTP transmitter sessions to be associated with an HTTP SMSC connection.
• SMPP: Seldom used configuration parameters for specifying the local TCP port that the SMPP client should bind to have been removed from the configuration program interface. These parameters continue to be supported by manual configuration file entries under the [SMPP - server:port] section header of SMSGW.INI: SenderPort=#### specifies the local TCP port to be used for the transmitter or transceiver session, and ReceiverPort=#### specifies the local TCP port to be used for the receiver session.
• SMPP:  Fix for [SMPP] / DeliveryReceiptFlag=Yes not working properly. (Only worked properly if set as [SMPP] / DeliveryReceiptFlag=1)
• SMS Gateway:  Fix for SMS service restarts/exception errors that could be triggered by updating the SMSGW.INI file. (Problem was introduced in 2011.03.15 update.)
• SMS Gateway: Fix for service restarts that could occur when using the web administrative interface.
• SMS Gateway & MMSC:  Various configuration restarts no longer require a service restart. (SMSC connections can be added/deleted/modified without requiring a restart. Configuration changes will take effect within within approximately 60 seconds.)
• Accounting callbacks now have the ability to change sender/recipient values (useful for source address translation when routing messages), and the ability to modify service type, validity and defined SMPP TLV parameters. This capability is enabled in the “SMSSend” and “SMSIN” accounting callbacks when SMSAccountingAllowChanges=Yes is defined in the [SMSGW] section of SMSGW.INI. When this setting is present, NowSMS will parse the HTTP response for “SMSSend” and “SMSIN” accounting callbacks looking for “To=”, “Sender=”, “ServiceType=”, “Validity=” and “SMPPOption_xxxx=” settings. If any of these text strings are present, the value that follows will be used to replace the existing value. (In the case of SMPPOption_xxxx=, a blank value will completely remove the parameter.) It is recommended that the HTTP response terminate the value with a new line to act as an end of value string delimiter.
• SMPP: TLV parameters defined in GSM Assocation IR.75 are automatically supported by default using the HexString encoding: SMPPOption_source_subaddress (0×202) and SMPPOption_dest_subaddress (0×203). For more information, refer to http://www.nowsms.com/smpp-tlv-parameters-for-advanced-message-routing
• Retrieving SMS messages via POP3: Fix for carriage return/line feed in an SMS message appearing as \r\n when converted to e-mail format. Also add sender phone number to subject line of message.
• SMPP Client: Previously NowSMS tracked upstream SMPP message IDs only if the client asked for a delivery report (or non-delivery report). However, many SMPP servers always return delivery reports, which can cause confusion, because if NowSMS did not track the upstream message ID, it will not know how to route it or resolve the message ID. NowSMS now always tracks the upstream SMPP message ID, unless TrackSMPPReceiptsAlways=No is set under the [SMSGW] header of SMSGW.INI.
• MMSC: Include “MMSStatus=” in “MMSDeliveryReport” callbacks. Status values are extracted from the MMS specifications. Possible values include “Retrieved” (success), “Expired”, “Rejected”, “Deferred”, Unrecognised”, “Indeterminated”, “Forwarded”, “Unreachable” and “Unknown”.
• MMS Proprietary URL Submission: Include “MMSMessageID=” parameter in accounting callback for MMS message submissions via this interface.
• MMSC: Reduce DNS query timeouts that can backlog the processing of MM4 acknowledgments, especially when the “MM4 Ack Route” has not been set for a connection.
• MMSC: Fix for bug receiving MMS messages via MM4 which included filenames that have a “?” character in the filename.
• E-Mail to SMS: When routing e-mail to SMS, a new configuration option supports tracking the e-mail sender address, so that an SMS reply can be routed back to the original e-mail sender. Note that when this tracking option is enabled, if multiple e-mail senders send to the same SMS phone recipient, NowSMS cannot distinguish which e-mail address should receive the reply, and the reply will be directed to the most recent e-mail sender. To enable this tracking, add SMSEMailTrackSender=Yes to the [MMSC] section of MMSC.INI. If it is possible for NowSMS to send/receive SMS using multiple SMS numbers, NowSMS can use the multiple SMS numbers to improve tracking if multiple e-mail addresses send to the same SMS recipient. To define the SMS sender numbers to be used for e-mail to SMS, add SMSEMailSender= to the [MMSC] section of MMSC.INI. SMSEMailSender supports a comma delimited list of sender numbers, and also supports ranges of sender numbers such as 800001-800100 to allocate a sequential range of numbers.
• SMS Gateway: Additional subdirectories created to prevent situations where a large SMS-IN queue makes the system unstable.
• SMS Gateway: NowSMS can now host PHP scripts locally (accounting callbacks, 2-way commands) without requiring an external web server. Further information and details are avaialble at http://www.nowsms.com/now-sms-native-php-scripts

2011-04-19:

• SMS Gateway: Add configuration parameter to allow customisation of the maximum message length for automatic message segmentation to allow for smaller segments that may be necessary in some environments. These settings can be configured under the [SMSGW] section header of SMSGW.INI, using the following parameters: MaxSMSSegmentLengthText=160 and MaxSMSSegmentLengthBinary=140
• 2-Way SMS: Previously NowSMS would only retry a 2-way SMS command if the connection to the web server failed or a timeout error occurred. It would not retry the command if the web server returned an HTTP error (such as 500 Internal Error), and would simply rename the message file to have a .BAD extension. This version changes the behaviour to perform retries with progressive delays, similar to the processing of outbound SMS messages. By default, NowSMS uses the same retry parameters as described at http://www.nowsms.com/sms-retry-error-handling-with-ucpemi-and-cimd. To define retry parameters specific to 2-way SMS processing, place them under a [2Way] section header in SMSGW.INI, instead of under the [SMSGW] section. If a server hosting a 2-way command is down and is not accepting connections or not returning a valid HTTP response, NowSMS continues to retry the 2-way command indefinitely, but it does introduce a progressive delay for these retries.
• MMSC: Performance optimisation for configuration front end open and displaying statistics, particularly on a multiple server installation, where if the configuration program were open simultaneously on multiple servers, it would become sluggish or unresponsive until other copies were closed.
• 2-Way MMS: Add configuration option to simplify processing received MMS messages so that they can be posted to a PHP script via HTTP. Previously, it was necessary to create an “MMSC Routing” definition to point to a PHP script. That mechanism is still supported, but it is also possible to now define a 2-way MMS POST URL on the “2-way” page of the configuration. The URL defined on this page will process any received MMS messages that get posted to the MMS-IN directory. The format of the POST uses the PHP format described at http://www.nowsms.com/doc/2-way-mms-support/receiving-mms-messages-with-a-php-script

2011-04-11:

• Configuration Program: Update font selection for configuration program to address issues where some installations were seeing text that was too large to display in the window.
• SMS Gateway: Fix for problem that could occur if an automated program submitting messages via HTTP uses multiple user accounts over a single HTTP connection. If some user accounts have “forced sender address” configured, and some do not, the “forced sender address” from a previously accessed account would be applied to submissions from an account with no “forced sender address” setting. Note that this could only occur if a program was submitting over a single HTTP connection using multiple user accounts for different message submissions.

2011-03-21:

• SMS Gateway: Fix for web interface not working properly with Firefox. (Problem introduced with late 2010 update to enable keep alive sockets.)

2011-03-18:

• MMSC: Fix for problem in a multiple server installation (SHAREDVOLUME.INI) where only one front-end would actively listen for connections for MMS messages converted to SMS. (Fix was attempted in 2011-03-15 version, but did not completely fix the problem.)

2011-03-15:

• SMS Gateway: Add configuration setting to limit individual user accounts from flooding the outbound message queue. This setting enforces a maximum number of queued messages that any individual user account can have pending in the outbound message queue. If a user attempts to submit additional messages when over the limit, a throttling error will be returned. To enable this throttling, the setting UserOutboundQueueLimit=##### must be added to the [SMSGW] section of SMSGW.INI. The ##### value sets a default maximum outbound message queue size to be applied to all user accounts. (A special value of 0 means no limit, but enables non-default settings to be applied to individual user accounts.) To override the default setting for individual user accounts, create an [UserOutboundQueueLimit] section, and add username=##### to this section to enable a limit for a specific user account. (A value of 0 will disable limits for that user account.) Note that queue size monitoring experiences a 30 to 60 second delay, so it is possible that users may slightly exceed configured limits. Also note that for SMPP accounts, care is taken to ensure that a throttling error does not occur in the middle of a multipart message transmission.
• SMS Gateway: Improved handling of “User Queue Size Threshold” to prevent problems where SMPP user accounts could be allocated multiple queue directories, giving extra priority to that account.
• SMS Gateway: The SMSGW.INI SMSCSendLimit=x/y setting, which can limit the speed at which messages are sent via a specific SMSC connection, was not functioning accurately at higher speeds. The setting has been reworked to support throttling at higher speeds.
• SMS Gateway: Fix for changes to the [Inbound SMS Routing] table (used for routing received messages to local user accounts based upon recipient address matching) not automatically being reloaded by the server without a restart.
• 2-Way SMS Command Processor: Fix for a problem where a message with invalid UDH could be posted repeatedly to a 2-way command. The problem could occur if the user data header indicated a multipart message where the current part number was larger than the number of indicated message parts.

2011-02-16:

• SMS Gateway: Add configuration option to duplicate SMPP receipts being routed to a local SMPP user account, so that they are also routed to 2-way command processing. This setting would be used when an installation needs to process all delivery receipts via a 2-way command. To enable this option, edit SMSGW.INI, and under the [SMSGW] header, add DuplicateUserReceiptsFor2Way=Yes.

2011-01-14:

• SMPP Server: Fix for a change first introduced in 2010-05-20 version which could cause extra null messages to be delivered to connected SMPP clients. This problem could only potentially occur if a client had multiple receive (or transceive) connections open to the NowSMS SMPP server.
• MMSC: Change MM7 transaction ID format to not include @ character, due to suspcion that this was causing a problem for a particular provider.

2010-12-21:

• MM7: When AllowAlphaRecip=Yes is enabled, use <Number> instead of <ShortCode> for the recipient address type, even if it is not a number.
• Configuration program opens LOG files using the default program for the .LOG extension instead of always using Notepad.

2010-12-14:

• MMS via GPRS Modem: Fix for problem introduced in 2010.11.04 version where MMS messages would not be retrieved from some operator MMSCs, particularly T-Mobile USA.

2010-12-07:

• Web Interface: Fix for problem sending pre-compiled MMS messages via the “Send MMS Message” web interface that could cause these messages to become corrupted.
• SMS Gateway/SMPP Client: When a throttling error occurs, additional logic requeues the message that triggered the error so that several retries will be attempted without requiring a pass through the entire message queue before the message is retried. This is necessary for proper handling of multipart segmented messages, so that if one part of the message encounters a throttling error, it can still be transmitted within the same window as other parts of the message when the outbound message queue is very full.
• MM7: Don’t add extra CRLF before closing MIME boundary as this might be confusing some Java libraries.

2010-11-26:

• MMSC: Fix for problem where the message ID in a delivery receipt was not formatted correctly (“/” characters changed to “.”) for delivery receipts that arrived via an MM4 connection. This prevented sending clients from being able to correctly resolve delivery receipts.
• SMS Gateway: Fix for web admin interface only sending the first 16KB when attempting to remotely download log files.

This post provides some example PHP functions that can be used to simplify this process.  Now that NowSMS can support PHP scripts natively without a separate web server, it is even easier to prototype SMS applications with NowSMS.

In this example, we’ll use these example PHP functions to allow users to send an SMS message to the NowSMS server to add or remove themselves from a distribution list, and allow any member of a distribution list to send a message that is broadcast to all distribution list members.

This is intended as an example only, and a starting point for adding further logic.

nowsmsdlist.php is a PHP include file that contains functions for working with NowSMS distribution lists.  This file can be downloaded at the following link:  http://www.nowsms.com/examples/nowsmsdlist-php.txt.

The following function are defined in nowsmsdlist.php:

<?php
// NowSMSDListExists - Returns true if distribution list exists, otherwise false.
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name

function NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListAction=List&DListName=" . urlencode($dlistName);
   $response = file_get_contents($urlString);
   if (!strncasecmp ($response, "OK", 2)) return true;
   else return false;

}

// NowSMSDListCheckMember - Returns true if member of distribution list, otherwise false.
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name
//  $dlistMember - Distribution list member phone number

function NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListAction=List&DListName=" . urlencode($dlistName);
   $response = file_get_contents($urlString);

   $memberArray = explode("\r\n",$response); 

   for ($i = 1; $i < count($memberArray); $i++) {
      $idxDash = strpos ($memberArray[$i], " -");
      if ($idxDash !== false) {
         $memberArray[$i] = substr ($memberArray[$i], 0, $idxDash);
      }
      if (!strcasecmp ($memberArray[$i], $dlistMember)) return true;
   }

   return false;

}

// NowSMSDListAddMember - Add member to distribution list
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name
//  $dlistMember - Distribution list member phone number

function NowSMSDListAddMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListMemberAction=Add&DListName=" . urlencode($dlistName) . "&DListMember=" . urlencode($dlistMember);
   $response = file_get_contents($urlString);

}

// NowSMSDListDeleteMember - Delete member from distribution list
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name
//  $dlistMember - Distribution list member phone number

function NowSMSDListDeleteMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListMemberAction=Delete&DListName=" . urlencode($dlistName) . "&DListMember=" . urlencode($dlistMember);
   $response = file_get_contents($urlString);

}

// NowSMSDListDeleteMemberAllLists - Scan all distribution lists and remove member
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistMember - Distribution list member phone number

function NowSMSDListDeleteMemberAllLists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListAction=List";
   $response = file_get_contents($urlString);

   $dlistArray = explode("\r\n",$response); 

   // Loop through all distribution lists and remove member
   for ($i = 0; $i < count($dlistArray); $i++) {
      if ($dlistArray[$i] != "") {
         if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistArray[$i], $dlistMember)) {
            NowSMSDListDeleteMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistArray[$i], $dlistMember);
         }
      }
   }

}

// NowSMSDListSendSMS - Send an SMS text message to a distribution list
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name

function NowSMSDListSendSMS ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $smsText) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "PhoneNumber=" . urlencode($dlistName) . "&Text=" . urlencode($smsText);
   $response = file_get_contents($urlString);
   if (strpos ($response, "MessageID=") === false) return false;
   else return true;

}
?>

<?php

header ("Content-Type: text/plain"); 

// dlist-example.php - This is an example to describe PHP functions for adding and deleting members from an SMS distribution list.
//
// Expected 2-way command format:  http://server/dlist-example.php?sender=@@SENDER@@&text=@@FULLSMS@@
//
// This example supports receiving the following commands via SMS:
//   "JOIN dlistname" or "START dlistname" to join a distribution list
//   "STOP dlistname" or "LEAVE dlistname" to be removed from a distribution list.
//   "STOP" by itself will remove the user from all distribution lists.
//   "SEND dlistname " allows any member of the distribution list to broadcast a message to the entire list.

$nowsmsIP = "127.0.0.1";
$nowsmsPort = "8800";
$nowsmsUser = "test";
$nowsmsPassword = "test";

require_once "nowsmsdlist.php";   // PHP function file that contains functions for working with NowSMS distribution lists

/* Performs explode() on a string with the given delimiter and trims all whitespace for the elements */
function explode_trim($str, $delimiter = ',') {
    if ( is_string($delimiter) ) {
        $str = trim(preg_replace('|\\s*(?:' . preg_quote($delimiter) . ')\\s*|', $delimiter, $str));
        return explode($delimiter, $str);
    }
    return $str;
} 

// Check for required URL parameters, sender and text
// Expected 2-way command format:  http://server/dlist.php?sender=@@SENDER@@&text=@@FULLSMS@@

if (!isset($_REQUEST['sender'])) {
echo "ERROR : 'sender' parameter missing!\r\n";
exit();
}

if (!isset($_REQUEST['text'])) {
echo "ERROR : 'text' parameter missing\r\n";
exit();
} 

$array = explode_trim($_REQUEST['text'],' '); 

// If a list name was not specified, set array with blank value
if (count($array) < 2) $array[1] = "";

if (!strcasecmp($array[0],"JOIN") || !strcasecmp($array[0],"START")) {
   // Check if distribution list exists
   if (NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1])) {
      // Distribution list exists, check if sender is already a member
      if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
         echo "You have already joined list " . $array[1] . ".  Reply STOP " . $array[1] . " to leave.";
      }
      else {
         // Add member to distribution list
         NowSMSDListAddMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender']);
         // Verify that member was added to distribution list
         if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
            echo "You have joined list " . $array[1] . ".  Reply STOP " . $array[1] . " to leave.";
         }
         else {
            echo "An error occurred attempting to join list " . $array[1];
         }
      }
   }
   else {
      echo "List " . $array[1] . " does not exist.";
   }
}
else if (!strcasecmp($array[0],"LEAVE") || !strcasecmp($array[0],"STOP")) {
   // If a list name was not specified, remove from all lists.
   if ($array[1] == "") {
      NowSMSDListDeleteMemberAllLists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $_REQUEST['sender']);
      echo "You have been removed from all lists";
   }
   // Check if distribution list exists
   else if (NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1])) {
      // Distribution list exists, check if sender is a member
      if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
         // Remove member from distribution list
         NowSMSDListDeleteMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender']);
         // Verify that member was removed
         if (!NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
            echo "You are no longer subscribed to list " . $array[1] . ".";
         }
         else {
            echo "An error occurred attempting to leave list " . $array[1];
         }
      }
      else {
         echo "You are not subscribed to list " . $array[1] . ".";
      }
   }
   else {
      echo "List " . $array[1] . " does not exist.";
   }
}
else if (!strcasecmp($array[0],"SEND")) {
   // Check if distribution list exists
   if (NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1])) {
      // Distribution list exists, check if sender is already a member
      if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
         $smsText = $array[1] . ":" . $_REQUEST['sender'];
         for ($i = 2; $i < count($array); $i++) {
            $smsText = $smsText . " " . $array[$i];
         }
         if (NowSMSDListSendSMS ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $smsText)) {
            echo "Message sent";
         }
         else echo "Error sending message";
      }
      else echo "You are not subscribed to list " . $array[i] . ".";
   }
   else echo "Unknown list " . $array[i] . ".";

}
else {
   echo "Unknown request " . $array[0];
}

?>

These log files are stored on the NowWAP server, with one log file created for each day, using a file naming convention of WAPGW-yyyymmdd.LOG, where yyyymmdd is the 4-digit year, 2-digit month and 2-digit day.

NowWAP 2011 has optional functionality which can convert these log files into a database format for further analysis. This functionality is enabled by checking “Generate Usage Reports” on the “Reports” page of the configuration dialog.

When usage reports are enabled, NowWAP will automatically generate daily and monthly usage reports.

These reports are located in the REPORTS subdirectory of the NowSMS installation.

REPORTS\LOGDB contains SQLite format databases with one database per month.

REPORTS\TEXT contains text format summary reports of NowWAP usage. Daily reports have file names of YYYYMMDD.TXT and monthly reports have file names of YYYYMM.TXT. Every night at midnight, a new daily report and updated monthly report for the current month will be generated.

The format of the text report will be similar to the following:

NowWAP Usage Report: YYYYMMDD
#### - Max Active Users
#### - Max Active Requests
#### - Total Unique MSISDN
#### - Total Sessions
#### - Total Requests

Top Active Users
#### - Phone Number 1
#### - Phone Number 2
etc...

Top Content Domains
#### - Domain 1
#### - Domain 2
etc...

Top Content Servers
#### - Server 1
#### - Server 2
etc...

REPORTS\XML contains XML formatted summary reports of NowWAP usage. Daily reports have file names of YYYYMMDD.XML and monthly reports have file names of YYYYMM.XML. Every night at midnight, a new daily report and updated monthly report for the current month will be generated.

The format of the XML report will be similar to the following. Note that some XML elements may not be present, depending on NowWAP configuration issues. Also note that additional XML elements may be added in future releases.

<NowWAPUsageReport>
<ReportDate>YYYYMMDD</ReportDate>
<MaxActiveUsers>####</MaxActiveUsers>
<MaxActiveRequests>####</MaxActiveRequests>
<TotalUniqueMsisdn>####</TotalUniqueMsidn>
<TotalSessions>####</TotalSessions>
<TotalRequests>####</TotalRequests>
<TopActiveMsisdn>
<Name>Phone Number 1</Name><Requests>####</Requests>
<Name>Phone Number 2</Name><Requests>####</Requests>
</TopActiveMsisdn>
<TopContentDomains>
<Name>Domain 1</Name><Requests>####</Requests>
<Name>Domain 2</Name><Requests>####</Requests>
</TopContentDomains>
<TopContentServers>
<Name>Server 1</Name><Requests>####</Requests>
<Name>Server 2</Name><Requests>####</Requests>
</TopContentServers>
</NowWAPUsageReport>

ReportDate – YYYYMMDD for a daily report or YYYYMM for a monthly report.

MaxActiveUsers – The maximum number of active (concurrent) users recorded during the report period. (Note: This information cannot be obtained from log files created by earlier versions of NowWAP.)

MaxActiveRequests – The maximum number of simultaneous requests recorded during the report period. (Note: This information cannot be obtained from log files created by earlier versions of NowWAP.)

TotalUniqueMsisdn – The number of unique MSISDN (phone numbers) that made requests of the proxy. (Note: Requires MSISDN/RADIUS integration.)

TotalSessions – The number of user sessions during the report period.

TotalRequests – The number of user requests serviced during the report period.

TopActiveMsisdn – A list of the most active mobile terminals and the number of requests generated by that mobile terminal during the report period. (Note: Requires MSISDN/RADIUS integration.)

TopContentDomains – A list of the content domains which recorded the most requests (hits) during the report period.

TopContentServers – A list of the content servers which recorded the most requests (hits) during the report period.

Additional Reports

It may be possible to create additional reports by developing your own queries of the reports database.

Every day the log files from the previous day get merged into a monthly SQLite database format that is stored in the REPORTS\LOGDB directory.

It is possible to download SQLite from www.sqlite.org, and use sqlite3.exe to run queries against the database.

To better understand the database structure, here are the commands that are used to create the monthly database:

CREATE TABLE WAPGWLOG (AUTOID INTEGER PRIMARY KEY AUTOINCREMENT, RequestID text, RequestIP text, MSISDN text, RequestDate text, RequestTime text, RequestType text, RequestServer text, RequestDomain text, RequestURL text, HTTPStatus text, BytesOut integer, BytesIn integer, UserAgent text);
create index RequestID on WAPGWLOG (RequestID);
create index RequestDate on WAPGWLOG (RequestDate);
create index MSISDN on WAPGWLOG (MSISDN);
create index RequestDomain on WAPGWLOG (RequestDomain);
create index RequestServer on WAPGWLOG (RequestServer);
create index RequestType on WAPGWLOG (RequestType);
create index MSISDNByDate on WAPGWLOG (RequestDate,MSISDN);
create index RequestDomainByDate on WAPGWLOG (RequestDate,RequestDomain);
create index RequestServerByDate on WAPGWLOG (RequestDate,RequestServer);
create index RequestTypeByDate on WAPGWLOG (RequestDate,RequestType);

More information about database fields:

RequestID = auto generated ID for request
RequestIP = IP address of device
MSISDN = MSISDN of device
RequestDate format = YYYYMMDD
RequestTime format = HHMMSS
RequestType – GET, POST, CONNECT, DISCONNECT, STARTSERVICE, STOPSERVICE
RequestServer – Host name part of URL
RequestDomain – Host name parsed to higher level domain name
HTTPStatus – HTTP Status code of request (e.g, 200=OK, 301=Redirect, 304=Not Modified, 404=Not Found, etc.)
BytesOut, BytesIn – Number of bytes transferred to/from device
UserAgent – User-agent header from device making request

SQL Commands used to generate information in summary report:

Total Unique MSISDN

select count(*) from (select MSISDN from WAPGWLOG where (RequestDate = ‘%s’) and (MSISDN != ”) group by MSISDN);

Total Sessions

select count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestType = ‘CONNECT’) and (RequestURL = ”);

Total Requests

select count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestType != ‘STARTSERVICE’) and (RequestType != ‘STOPSERVICE’);

Top Active Users

select MSISDN,count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (MSISDN != ”) group by MSISDN order by count(*) DESC limit 100;

Top Content Domains

select RequestDomain,count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestDomain != ”) group by RequestDomain order by count(*) DESC limit 100;

Top Content Servers

select RequestServer,count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestServer != ”) group by RequestServer order by count(*) DESC limit 100;

Some of this discussion can be found at the following message thread on the NowSMS discussion forum: http://www.nowsms.com/discus/messages/1/70053.html

This article attempts to summarise this information. Those interested in further information are encouraged to join the discussion thread.

Most NowSMS users will have no reason to be concerned with these parameters. This article is presented primarily for the interest of those using NowSMS as part of an SMS hub application.

Part of the inspiration for this discussion is the GSM Association document “Open Connectivity SMS Hubbing Architecture IR.75″, which can be found at the following link: http://www.gsmworld.com/documents/IR7520_unrest.pdf

That document suggests using the SMPP TLV parameters source_subaddress (0×202) and dest_subaddress (0×203) for encoding routing information for the MCC (mobile country code) and MNC (mobile network code) of the source (sender) and destination (recipient) addresses.

This is done to help simplify the routing of messages by intermediary hubs.

Historically, SMS service providers have defined their own proprietary SMPP TLV to encode this information (if it is made available at all). For example, mBlox defines an mblox_operator parameter using TLV parameter number 0×1402.

Hopefully more providers will use the GSM Association Recommendation in IR.75 in place of proprietary parameters.

Future versions of NowSMS (releases after 2011.05.05) will include automatically include support for forwarding these parameters.

Support can be enabled in prior versions of NowSMS by creating or editing an [SMPPOptions] section in SMSGW.INI and adding the following entries to this section:

[SMPPOptions]
source_subaddress=202,HexString
dest_subaddress=203,HexString

(Note: Support for the HexString parameter format was added in 2007.04.)

It is necessary to use the HexString encoding format for this parameter, because the SMPP specification defines first byte of the value as being a binary code value for the type of subaddress. In the case of the GSM Association values, this first byte is always A0 (hex), indicating user specified.

The next 3 bytes are the MCC, followed by 3 bytes for the MNC.

ASCII character values are used for the MCC and MNC, and then converted to a hex string.

The IR.75 document provides an example using the MCC and MNC for AT&T USA, where MCC=310 and MNC=380.

Converting the MCC value from ASCII to its hex string encoding would produce the following sequence of bytes: 33 31 30, and MNC would result in the following: 33 38 30.

The resulting parameter value in hex string format would be A0333130333830.

To specify this value as a source subaddress in NowSMS via HTTP, the following parameter value would be used:

SMPPOption_source_subaddress=A0333130333830

This thread discusses the use of NowSMS accounting callbacks, which can be used to query and/or update these parameters. (Update support was added in the 2011.04.17 release.)

Most NowSMS users will have no reason to be concerned with these parameters.

However, here are a few of the scenarios where it may be necessary to use these parameters.

1.) 2-way (interactive) SMS applications may receive the SMPPOption_source_subaddress parameter to indicate the mobile network from which the request originated, and be required to supply this value as the SMPPOption_dest_subaddress when generating a reply.

Future versions of NowSMS (releases after 2011.05.05) will apply this logic automatically when processing a 2-way command that returns its text response directly. Other 2-way commands would need to look for the “&SMPPOption_source_subaddress=” URL parameter and generate an appropriate “&SMPPOption_dest_subaddress=” URL parameter when submitting a message reply back to NowSMS.

2.) When NowSMS is being used to route messages between providers, it may be desirable to route messages based upon the MCC/MNC value.

This can be done via SMS accounting callbacks. This concept is described in the following article:

http://www.nowsms.com/dynamic-sms-message-routing-with-http-callbacks

What is not mentioned in that article is that beginning with release 2010.05.17, NowSMS also includes SMPP TLV parameters in the accounting callbacks.

This allows the callback processor to inspect the “&SMPPOption_source_subaddress=” and “&SMPPOption_dest_subaddress=” parameters, using those values to determine which route to use for sending the message. (The callback returns a response of SMSCRoute=xxxxx to specify the route to be used, as described in the link referenced above.)

3.) As an extension to the previous scenario, it may be necessary for a system providing SMS hubbing services to apply or insert the above values.

For example, it may be desirable to apply a source_subaddress automatically to all messages received from a particular connection.

Or it may be desirable to perform HLR lookups and apply dest_subaddress parameters before routing.

NowSMS 2011.04.17 and later allow these TLV parameters to be updated by an accounting callback.

In addition to passing these parameters to accounting callbacks via HTTP URL parameters, NowSMS checks the response from the accounting callback to allow these parameters to be set or updated.

The accounting callback should return a “text/plain” response with any parameters to be updated separated by line breaks.

For example:

SMSCRoute=connectionA
SMPPOption_source_subaddress=A0333130333830
SMPPOption_dest_subaddress=A0323334303135

Note: To enable the ability to override SMPPOption parameter values in the accounting callback response, it is necessary at this time to add SMSAccountingAllowChanges=Yes to the [SMSGW] section of SMSGW.INI.

One other note for those not familiar with the NowSMS concept of accounting callbacks. These are HTTP callbacks where NowSMS send an HTTP request to a URL that you define.

These callbacks would normally reside on a separate web server. However, newer versions of NowSMS also support the ability to host PHP scripts locally, as described in the following article: http://www.nowsms.com/now-sms-native-php-scripts

PHP scripts are often used for 2-way SMS or MMS processing, providing a convenient mechanism for processing the received message content in an application, and optionally replying back to the received message, updating or querying a database, or taking other action upon the message which could involve sending one or more messages to other parties.

PHP scripts are also frequently used to implement accounting or routing callbacks. Accounting callbacks can be used to record messaging activity, and to integrate with external billing or accounting systems. These accounting callbacks also support the ability to block messaging activity when external billing criteria indicates that a message operation should be be allowed. Routing callbacks can be used to provide additional control for selecting the outbound route to be used for message delivery, such as interfacing into mobile number portability databases or HLR lookups.

NowSMS interfaces with PHP scripts via an HTTP interface, which has historically required a separate HTTP web server with PHP installed. By using an HTTP interface, NowSMS can integrate with other web based scripting languages and environments, including ASP, ASP.Net, Java and Perl.

The separate web server requirement can make it more difficult to develop 2-way command scripts or accounting callbacks, especially when prototyping an application.

Beginning with the 2011.04.19 version of NowSMS (currently in test release at http://www.nowsms.com/download/nowsms20110419.zip), NowSMS supports the ability to interface with a locally installed copy of PHP, without requiring a separate web server to manage PHP callbacks.

To enable this support, it is necessary to first install PHP on the PC that is running NowSMS by following these steps:

1.) Download and run the Windows installer for PHP at http://windows.php.net/download/.  We recommend using a thread safe version of the current build (5.3.6 at the time this article was written).

2.) When the PHP installer displays its “Web Server Setup” selection screen, be sure to select “Other CGI”.

3.) The default PHP installation does not include many popular PHP libraries and extensions.  You may want to consider installing other “Extensions” and “Extras”.  At a minimum, we recommend installing PEAR, which is listed under “Extras”.   (In particular, the mail functions built into PHP are extremely limited, and the PEAR Mail Package is frequently used for sending e-mails from PHP scripts.)



4.) After PHP has been installed, let’s continue and install PEAR and the PEAR Mail package.  Open a Command Prompt window by right clicking on “Command Prompt” (usually under Programs/Accessories) and selecting “Run as Administrator”.  Once the Command Prompt window is open, change to the directory in which PHP was installed.

5.) To install PEAR, type go-pear and press Enter.  Unless you are an expert at installing and configuring PEAR, accept all of the defaults presented by the installation routine by pressing Enter each time prompted.

6.) To install the PEAR Mail Package, from that same command prompt window, type:

 pear install Mail

7.) Mail requires an additional PEAR package to function properly: Net_SMTP.  To install the PEAR Net_SMTP Package, from that same command prompt window, type:

 pear install Net_SMTP

8.) PHP installation is complete.  Now it is necessary to configure NowSMS to use the locally installed copy of PHP.  In the NowSMS configuration, go to the “2-Way” page, and select “Enable Local PHP Processing”.

NowSMS interfaces with php-cgi.exe, which should have been installed by the PHP installation program.  When “Enable Local PHP Processing” is first checked, NowSMS will verify that it can locate php-cgi.exe.  If it cannot locate this file, an error message will be displayed.

You are now ready to create your first PHP script.

What You Need To Know About NowSMS and Local PHP Scripts

The “2-Way” command page displays the directory location of the directory that should contain any local PHP scripts, as shown above, where it displays “http://nowsmslocal/php resolves to C:\ProgramData\NowSMS\PHP\”.

This indicates that PHP scripts need to be placed in the C:\ProgramData\NowSMS\PHP directory.  It is possible to change this directory by editing SMSGW.INI, and under the [SMSGW] header, adding PHPDir=c:\path

If, after adding a PHPDir= configuration parameter, the “2-Way” page does not update to the new location, uncheck “Enable Local PHP Process”, and then recheck this setting.

When defining a 2-way command (or accounting callback) that points to a local PHP script, the script URL should start with http://nowsmslocal/php (example for a script named echo.php: http://nowsmslocal/php/echo.php&sender=@@SENDER@@&text=@@FULLSMS@@).

It is also possible to access these PHP scripts from a web browser installed on the same machine by referencing the script via the local loopback address, http://localhost:8800/php or http://127.0.0.1:8800/php (assuming that the NowSMS web interface is running on port 8800, otherwise change this port number).  By default, PHP scripts can only be accessed locally.  If access required from other systems, check “Allow External Web Access to PHP Scripts”.  When “Allow External Web Access to PHP Scripts” is enabled, the scripts will be accessible to any system that can access the NowSMS web interface (i.e., the “Allowed/Blocked” list on the “Web” configuration dialog).

Let’s start with a simple 2-way command example.

echo.php is a simple PHP script that parses the text of a received message, and replies back with the same text:

<?php
header ("Content-Type: text/plain");
if (isset($_REQUEST['text'])) {
   $text = $_REQUEST['text'];
   echo $text;
}
else {
   echo "Invalid request, text= parameter expected.";
}
?>

This simple example provides a good starting point for building more complex 2-way commands.

Cut and paste the above script into a file named echo.php in your NowSMS PHP directory.

From a web browser on the same machine, access http://127.0.0.1:8800/php/echo.php.  A text page should be returned that says “Invalid request, text= parameter expected.”  This indicates that local PHP support is fully configured and operational.

Now let’s configure NowSMS to execute this command every time it receives an SMS message, sending an echo response back to the sender.

Before continuing, ensure that “Process received SMS Messages” is checked.

In the “SMS Command Prefix” field, enter a single asterisk character: *  This character is a wildcard, indicating that the command will match all received messages.  If you want to use this test script for a particular keyword match only (such as “echo”), then enter that keyword instead of *.

The “Receive Phone Number” field can be left blank for the purposes of this test.

“Command to Execute” should be http://nowsmslocal/php/echo.php?text=@@TEXT&sender=@@SENDER@@

This particular command returns its response directly in the script, so “Command returns response text” should also be checked.

Press “Add” to add the command to the table, and “Apply” to save changes.  Restart the NowSMS service.

The simple version of the echo.php script only checks the “text=” parameter, which is accessible in the script as $_REQUEST['text'].

Try sending an SMS message in to the script. If the “SMS Received” counter on the “Service” page of the NowSMS configuration dialog is not showing an increase in received messages, your messages are not making it as far as NowSMS.  There are some helpful troubleshooting tips for this situation in a post on the NowSMS discussion board at http://www.nowsms.com/discus/messages/1/4520.html.

Note that it is very dangerous to implement a script that blindly replies back to all received messages, as it is possible to get stuck in an infinite reply loop with other SMS robots.  It is advisable that you include logic in your script to limit replies, especially error replies.  Also, beware of loops where you accidentally send an SMS message from your modem to itself.  You can include a check at the beginning of a PHP script to guard against sending to yourself by checking the number from which the message was received, and make sure it does not match the sending number:

if (!strcmp($_REQUEST['sender'],”+447777777777″)) { return; }

This is a real simple example intended to help you get started.

Instead of replying back to the SMS message, your script can issue new requests back to NowSMS to send messages (see Send SMS from PHP Script and Send MMS Message from PHP Script for these examples).  Or your PHP script could query and/or update a database.  There are many possibilities.

Additional NowSMS PHP examples and information are available at the following links:

http://www.nowsms.com/faq/api

http://www.nowsms.com/tag/php

Additional resources for general PHP API information include:

http://www.php.net/

http://pear.php.net/

This document details the update release history since the previous interim update, version 2010.11.04. Release history for the changes prior to the current official release can be found at http://www.nowsms.com/category/updates.

The following issues are addressed by this update:

SMS Gateway Updates:

• SMS Gateway Web Admin Interface: Fix for web admin interface only sending the first 16KB when attempting to remotely download log files. (For additional information, see http://www.nowsms.com/discus/messages/1/60254.html.)
• SMS Gateway: Add configuration setting to limit individual user accounts from flooding the outbound message queue. This setting enforces a maximum number of queued messages that any individual user account can have pending in the outbound message queue. If a user attempts to submit additional messages when over the limit, a throttling error will be returned. To enable this throttling, the setting UserOutboundQueueLimit=##### must be added to the [SMSGW] section of SMSGW.INI. The ##### value sets a default maximum outbound message queue size to be applied to all user accounts. (A special value of 0 means no limit, but enables non-default settings to be applied to individual user accounts.) To override the default setting for individual user accounts, create an [UserOutboundQueueLimit] section, and add username=##### to this section to enable a limit for a specific user account. (A value of 0 will disable limits for that user account.) Note that queue size monitoring experiences a 30 to 60 second delay, so it is possible that users may slightly exceed configured limits. Also note that for SMPP accounts, care is taken to ensure that a throttling error does not occur in the middle of a multipart message transmission.
• SMS Gateway: Improved handling of “User Queue Size Threshold” to prevent problems where SMPP user accounts could be allocated multiple queue directories, giving extra priority to that account.
• SMS Gateway: The SMSGW.INI SMSCSendLimit=x/y setting, which can limit the speed at which messages are sent via a specific SMSC connection, was not functioning accurately at higher speeds. The setting has been reworked to support throttling at higher speeds.
• SMS Gateway/SMPP Client: When a throttling error occurs, additional logic requeues the message that triggered the error so that several retries will be attempted without requiring a pass through the entire message queue before the message is retried. This is necessary for proper handling of multipart segmented messages, so that if one part of the message encounters a throttling error, it can still be transmitted within the same window as other parts of the message when the outbound message queue is very full.
• SMS Gateway: Fix for changes to the [Inbound SMS Routing] table (used for routing received messages to local user accounts based upon recipient address matching) not automatically being reloaded by the server without a restart.
• 2-Way SMS Command Processor: Fix for a problem where a message with invalid UDH could be posted repeatedly to a 2-way command. The problem could occur if the user data header indicated a multipart message where the current part number was larger than the number of indicated message parts.
• SMS Gateway: Add configuration option to duplicate SMPP receipts being routed to a local SMPP user account, so that they are also routed to 2-way command processing. This setting would be used when an installation needs to process all delivery receipts via a 2-way command. To enable this option, edit SMSGW.INI, and under the [SMSGW] header, add DuplicateUserReceiptsFor2Way=Yes.
• SMPP Server: Fix for a change first introduced in 2010-05-20 version which could cause extra null messages to be delivered to connected SMPP clients. This problem could only potentially occur if a client had multiple receive (or transceive) connections open to the NowSMS SMPP server.
• Web Interface: Fix for problem introduced in 2010.11.04 version where the web interface was not working properly with Firefox.

MMSC Updates:

• MMSC: Fix for problem where the message ID in a delivery receipt was not formatted correctly (“/” characters changed to “.”) for delivery receipts that arrived via an MM4 connection. This prevented sending clients from being able to correctly resolve delivery receipts. (For additional information, see http://www.nowsms.com/discus/messages/485/60287.html.)
• MMSC: Change MM7 transaction ID format to not include @ character, due to suspcion that this was causing a problem for a particular provider.

MMS Gateway Updates:

• MMSC: Fix for problem in a multiple server installation (SHAREDVOLUME.INI) where only one front-end would actively listen for connections for MMS messages converted to SMS.
• MM7: When AllowAlphaRecip=Yes is enabled, use <Number> instead of <ShortCode> for the recipient address type, even if it is not a number.
• MMS via GPRS Modem: Fix for problem introduced in 2010.11.04 version where MMS messages would not be retrieved from some operator MMSCs, particularly T-Mobile USA.
• MM7: Don’t add extra CRLF before closing MIME boundary as this might be confusing some Java libraries.
• Web Interface: Fix for problem sending pre-compiled MMS messages via the “Send MMS Message” web interface that could cause these messages to become corrupted.

Other Updates:

• Configuration program opens LOG files using the default program for the .LOG extension instead of always using Notepad.

It started off simple enough.

If you send an MMS message using the simple web form in NowSMS, and you include some text and an image, the resulting message displays the text first and then the image.

What if you want the image displayed first and then the text?

Or what if you want the text to be displayed as a caption under the image, on the same page, instead of on a separate page?

The first scenario is simple to address. The second scenario is where you may require an aspirin.

Des did an excellent job of addressing the scenario of displaying the image first, and then the text:

NowSMS inserts objects in the order that they are presented.

Instead of using the text object, put the text in a file and attach that file after the image.

If you want more full control, you need to create your own SMIL and include it as one of the objects (use a .smil file extension).

If no SMIL is included, NowSMS auto generates some simple SMIL that presents one object per page in the order in which the objects were attached.

If only Des didn’t mention SMIL. He could have left the answer simple and moved on to another question.

But that is not our way.

So what exactly is SMIL?

SMIL is a presentation language that is used to configure how an MMS message is displayed, similar to how HTML is a presentation language that is used to configure how information on a web page is to be displayed.

However, while HTML is a very powerful and flexible presentation markup language, SMIL is a very simplistic and limited presentation markup language. And MMS SMIL, which is a subset of Basic SMIL, which is a subset of SMIL, is even more limited still.

I like to think of SMIL as a simple presentation language for slide show presentations. SMIL organizes the slides, or pages, of an MMS message presentation. Sort of like PowerPoint, but again, much more limited.

Have I emphasized enough that SMIL, especially MMS SMIL, is very limited? So don’t expect to wow your audience with complex charts and graphics.

Before we dive further into SMIL, let’s backup and look at what an MMS message is.

An MMS message is very similar to an e-mail message, in many ways you can think of MMS as an e-mail system designed for mobile phone networks. (Looking for more information on the transport level implementation? If so, see our article How MMS Works).

Like an e-mail message, an MMS message has a header that contains information such as who the message is “From” and who it is “To”, along with a “Subject”.

The content of an MMS message is a collection of one or more multimedia objects, such as text, image, video and audio. MMS messages can also contain other objects such as address cards (vCards), calendar appointments (vCal), Java applications, and more, if supported by the MMS client on the mobile phone. But for the most part you are dealing with one or more text, image, video and/or audio objects.

If you think of an e-mail message, you think of a text object, along with zero or more attachments.

Or, a more modern e-mail message might be HTML formatted, so that the multimedia objects are automatically displayed when the e-mail message is opened.

Similar to HTML being used in an e-mail message, an MMS message should always have a SMIL presentation part which determines how the MMS message is displayed. (If a SMIL presentation is not included in an MMS message, many operator MMS systems will automatically generate SMIL and add it to the message before it is received by the recipient.)

When included in an MMS message, a SMIL presentation becomes one of the objects within an MMS message. A typical MMS message that contains text and an image would have three objects contained in the MMS message, a SMIL object, a text object and an image object.

Let’s stop using the word object. When building an MMS message, an object is a file. So our typical MMS message with text and an image has three separate files that are the content of the MMS message, a SMIL file, a text file and an image file (e.g., PNG, JPEG, GIF).

One important conceptual difference between SMIL and HTML is that there is no in-line text within a SMIL presentation. If you want to include text in a SMIL presentation, you include a reference to a separate text object/file.

Another important conceptual difference is that you have to consider the relatively small screen of most devices that will be receiving MMS messages.

For all practical purposes, you should not include more than one of the same type of object in a single page (slide) of the SMIL presentation. This means more than one image on a page is generally not recommended because of the limitations of most devices. More than one text object on a page is also not recommended.

The MMS Conformance Document from the Open Mobile Alliance goes into more detail. Basically each page of a SMIL presentation can have no more than two regions, an image region and a text region. The image region can have a single image or a video. The text region can have a single text object. An audio object can play while the page is being displayed.

That’s really all there is to it. Full SMIL has capabilities like setting text and background colors, however the subset that is MMS SMIL, as defined in the MMS Conformance Document, does not include those attributes.

Let’s go back to our original scenario, sending an MMS message that includes text and an image.

The Send MMS Message web form (and the NowSMS Proprietary URL API) include a single text field and zero or more files to include in the message.

When NowSMS processes the web form, if a text field is present, NowSMS automatically converts the text field into a text file to be included as the first object in the MMS message.

If a SMIL file is not included among the files to be included in the message, NowSMS automatically generates one.

For the widest compatibility with different devices, the default SMIL that NowSMS generates has one object per page. If the text field was used in the submission, it becomes the first page. Other pages are generated based upon the order in which objects were included in the submission.

The default NowSMS SMIL will typically look like this:

<smil>
<head>
<layout>
<region id="Image" height="100%" width="100%" fit="meet"/>
<region id="Text" height="100%" width="100%" fit="scroll"/>
</layout>
</head>
<body>
<par dur="3s">
<text src="filename.txt" region="Text"/>
</par>
<par dur="5s">
<img src="image.jpg" region="Image"/>
</par>
</body>
</smil>

The start of the SMIL is a header and opening for the body section:

<smil>
<head>
<layout>
<region id="Image" height="100%" width="100%" fit="meet"/>
<region id="Text" height="100%" width="100%" fit="scroll"/>
</layout>
</head>
<body>

The layout section defines two regions, as instructed by the MMS Conformance Document. For simplicity, NowSMS automatically generated SMIL says that either section can take up the entire height and width of the page. Images are scaled to “meet” the size of the screen, while text is allowed to “scroll” if it is too large.

More complex region layouts can be designed, but the MMS Conformance Document states that an MMS Client may choose to replace the layout section with its own terminal specific layout, so we have yet to see the point of such an effort.

Each page of the SMIL presentation is represented by a <par> section:

<par dur="3s">
<text src="filename.txt" region="Text"/>
</par>

<par dur="5s">
<img src="image.jpg" region="Image"/>
</par>

text, img, video and audio tags with a src parameter define objects that appear in the MMS message. You’ll see text and img tags in the above example. The src parameter of one of these object tags refers to another content object/filename that is included in the message. Unlike HTML format e-mails, you cannot reference content by an external HTTP link. Any content referenced by your SMIL must be a file that is included in the MMS message content.

The “dur” parameter for the <par> element specfies how long a particular slide is displayed.

In this example, the text that was submitted as part of this MMS message was included in a text file named filename.txt. The image was an image file named image.jpg.

When submitting files to be included in an MMS message with NowSMS it is important to use common filename extensions such as .txt and .jpg. This is because when NowSMS packages the files into an MMS message, NowSMS needs to specify the MIME content type of the files. NowSMS uses the filename extension to MIME content type mappings defined in the MMSCTYPE.INI file that is in the NowSMS program directory.

Finally, the SMIL is concluded with tags to close the presentation:

</body>
</smil>

It is easy to override the automatically generated SMIL by creating your own SMIL. You then include this SMIL as one of the content objects in your MMS message. (Again filename extensions are important …. be sure to give the file a “.smil” file extension, so that NowSMS will recognise it as such.) All “src=” references within your SMIL should be for filenames of other files that are being included in the MMS message.

For example, to have the image and text display on a single page, you could do make this change:

<smil>
<head>
<layout>
<region id="Image" height="100%" width="100%" fit="meet"/>
<region id="Text" height="100%" width="100%" fit="scroll"/>
</layout>
</head>
<body>
<par dur="5s">
<text src="filename.txt" region="Text"/>
<img src="image.jpg" region="Image"/>
</par>
</body>
</smil>

When submitting the MMS message, you would need to include the SMIL file, along with filename.txt and image.jpg.

You could also change the “%” of height for the text and image regions for best results, but be aware that a lot of MMS clients will ignore it.

Also note that when you generate your own SMIL, you should include any text objects as separate files, not using the “MMS Text” parameter of the NowSMS web interface. This is because NowSMS automatically converts the “MMS Text” into a file, but it generates a temporary name for the text file, so it is not possible to reference this text in your SMIL

There is more discussion back on the discussion board thread MMS: first shows a picture and then the text, but hopefully this discussion is more digestable as a simple tutorial for creating your own SMIL in an MMS message.

For more information, I highly recommend referring to the MMS Conformance Document from the Open Mobile Alliance, which can be found at the following location: http://openmobilealliance.org/Technical/release_program/mms_v1_2.aspx.

The full SMIL 2.0 specification can be found at http://www.w3.org/TR/2005/REC-SMIL2-20050107/.

When a certificate is issued by a certificate authority by an intermediate certificate, it is necessary to install not just your certificate on the server, but additionally it is necessary to install the certificate chain for the CA’s intermediate certificate.  This certificate chain will be provided by the certificate authority along with your signed certificate.

At this time, an updated version of SMSSSL.DLL is required to support an SSL certificate chain.  An update can be downloaded at http://www.nowsms.com/download/smssslchain.zip.  To install the update, stop the NowSMS services and exit the NowSMS program.  Next, update the SMSSSL.DLL file in Program Files (or Program Files (x86)) \ NowSMS with the version in this ZIP file.

Locate the directory that contains your SSL certificate request (SSL.CSR).  This is either the ProgramData\NowSMS directory (Windows 7/Vista/2008) or Program Files\NowSMS (XP/2003) directory.

Using a text editor, such as NOTEPAD.EXE, create or edit a file named SSL.CA, which is the filename designated to contain your signed SSL certificate.  Your signed certificate should be placed at the start of this file, including the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– markers.  Following  your signed certificate, you should include any intermediate certificates in this same text file.  If there are multiple intermediate certificates, they should be ordered in the path from your server certificate toward the root CA certificate.

The NowSMS service must be restarted after updating an SSL certificate file in order for the new certificate to take effect.

In most cases, this is possible.  The NowSMS MMSC is designed with minimal administration requirements and automatic subscriber provisioning.  For a typical mobile operator configuration, subscribers are automatically provisioned to the NowSMS MMSC the first time a user sends an MMS message.   The following article explains how to configure this:  http://www.nowsms.com/nowsms-operator-mmsc-considerations

Automatic subscriber provisioning works great for a new MMSC installation, but what if you are replacing an existing MMSC that already has provisioned subscribers?

In some cases, it is not required that subscribers be provisioned on the NowSMS MMSC at all.  If the “Default Route” for MMS message delivery, or an explicit route defined just for your subscribers, is configured as “Direct Delivery“, then the MMSC will deliver MMS messages to subscribers whether or not they have been provisioned.

The above approach is used by some smaller mobile operators, but most operators prefer to only deliver MMS messages to subscribers that have been provisioned.  In this case, non-provisioned subscribers receive MMS messages that have been converted into an SMS format with a web link for accessing the multimedia content.  Configuring this option is described in the following article:  http://www.nowsms.com/mms-conversion-to-sms-with-web-link

In this case, you will want pre-provision your MMS subscribers in the NowSMS MMSC, so that they will receive MMS messages in normal MMS format, without the SMS conversion … and without requiring the subscribers to first send an MMS message to provision their account on the NowSMS MMSC.  There is an HTTP interface available for provisioning MMS subscribers which is described in the following article: http://www.nowsms.com/provisioning-sms-and-mmsc-user-accounts-via-http.

There is an additional alternative that is useful for bulk MMS subscriber provisioning, which is the MMSUSER.EXE command line utility.  MMSUSER accepts a text file that has a list of subscriber phone numbers.  The format of this file should contain one subscriber phone number per line, prefixed by “A,” which indicates that the subscriber should be added (conversely “D,” means the subscriber should be deleted).  For example:

A,+441111111111
A,+441111111112
A,+441111111113
A,+441111111114

Assuming that the file containing the list of subscribers in this format is called subimport.txt, run the following command from a command line prompt in the Program Files\NowSMS directory:

mmsuser -import subimport.txt

Additional information of interest to customers planning or considering an MMSC migration/replacement:

• MMSC Accounting Callbacks for Billing and Charging
• MM4 Interconnection Basics for exchanging MMS with other mobile operators
• Mobile Number Portability (MNP) and the NowSMS MMSC
• Detecting Roaming Subscribers

And for operators using CDMA based technologies, also see:

• MMSC in CDMA and CDMA2000 Environments

Another frequently asked question regards the role of the WAP Push Proxy Gateway (PPG).  The NowSMSC MMSC includes an integrated PPG that sends WAP Push messages using an SMS bearer, and there is not a requirement for a separate PPG.  However, for specialised configurations, it is possible to configure the NowSMS MMSC to use an external PPG, which is described in the following article:  http://www.nowsms.com/routing-mms-notifications-via-a-wap-push-proxy-gateway

It is also possible to use NowSMS as a PPG for other applications, as described in the following article:  http://www.nowsms.com/using-nowsms-as-a-wap-push-proxy-gateway-ppg

Basic HHE allows the subscriber to be identified by their MSISDN.

Aliased HHE allows the subscriber to be identified without divulging the subscriber’s MSISDN.

A standard feature of the NowWAP Proxy is to provide Basic HTTP Header Enrichment to facilitate operator billing for HTTP based services, including Multimedia Messaging Services (MMS).

Basic HHE is enabled for all subscriber HTTP transactions that are forwarded to a configurable list of content provider hosts and/or domains (most frequently these are hosts within the operator domain, such as the operator MMSC). Depending on the information available from the RADIUS accounting feed, this basic information can include the subscriber MSISDN, SGSN IP Address, SGSN MCC & MNC (useful for determining if the client is currently roaming), client IP address (useful for identifying which operator APN was accessed), IMSI, and radio access type (4G, 3G or 2.5G) .

Basic HHE can result in the following HTTP headers being inserted:

X-MSISDN: xxxxxxxxxxxxxxxxx
X-WAP-3GPP-SGSN-MCC-MNC: xxxxx
X-WAP-3GPP-SGSN-ADDRESS: 1.2.3.4
X-WAP-3GPP-IMSI: xxxxxxxxxxxxxx
X-WAP-3GPP-RAT-TYPE: 1 or 2 (1 = 3G, 2 = EDGE/GPRS) X-WAP-Client-IP: 7.8.9.0

The list of content provider hosts and/or domains that receive this basic HHE is configurable. Host names can be listed here explicitly, such as mmsc.operator.com, or all hosts within a particular domain can be included by adding the domain name to the list prefaced with a “.”, for example .operator.com means that all hosts within the operator.com domain would receive basic HHE (for example, both www.operator.com and mmsc.operator.com).

In many instances, it is useful to provide similar identifying information to content provider partners, but without divulging the subscriber MSISDN. A new feature of the NowWAP Proxy 2011 release is to provide Aliased HTTP Header Enrichment to meet this need.

Content provider hosts and domains that are to receive Aliased HHE are configured with a list that is similar, but separate from, the existing Basic HHE content provider domain/host list that is configured on the “MSISDN” page of the NowWAP configuration program.

NowWAP does not directly generate the Aliased HHE. Instead, it provides an HTTP callback interface to allow the customer to generate customized Aliased HHE that is appropriate for the target operator environment.

A customer-defined Aliased HHE callback interface is defined to NowWAP by adding the following configuration setting to the [WAPGW] header of WAPGW.INI: HHECallbackURL=http://server/path

When the HHE callback is configured in NowWAP, each time NowWAP receives a RADIUS notification of a new user connecting, NowWAP will make an HTTP GET request to the HHE callback to request HHE/alias information for the user account.

The HHE callback request will include MSISDN, and other RADIUS information, if available.

Example:

http://server/path?PhoneNumber=xxxx
&UserName=xxxxx
&AssignedIP=a.b.c.d
&3GPP-SGSN-MCC-MNC=xxxxx
&3GPP-SGSN-ADDRESS=xx
&3GPP-IMSI=xxxxxxxxxxxxxxx
&3GPP-RAT-TYPE=x

(Line breaks have been inserted in the URL above for readability only. There are no line breaks in the actual HHE callback URL.)

The “PhoneNumber” (MSISDN) and “AssignedIP” (X-WAP-Client-IP) parameters will always be present.  The 3GPP parameters would be present only if they were presented to NowWAP by the RADIUS feed.

The HHE callback response should be a text response containing enriched HTTP headers to be included in all requests that are processed on behalf of this device.  Example:

HTTP/1.1 200 OK
Content-Type: text/plain

X-MSISDN-Alias: xxxxxxxxxxxxxxxxxxxxx
X-HHE-Extra-Info: xxxxxxxxxxxxxxxxxxxxx

As NowWAP processes subsequent requests, if the request is directed to a content domain that receives Aliased HHE, these headers would be included in the HTTP request that is forwarded to the content provider. (Basic HHE would not be forwarded to these content providers.)

The list of content domains to receive Aliased HHE is defined in the WAPGW.INI file, under the [WAPGW] header, using keyword value pairs of the following format:

IncludeHHEForDomain1=.domain1.name
IncludeHHEForDomain2=host.domain2.name
IncludeHHEForDomain3=host.domain3.name

Host names can be listed explicitly, such as www.contentprovider.com, or all hosts within a particular domain can be included by adding the domain name to the list prefaced with a “.”, for example .contentprovider.com means that all hosts within the contentprovider.com domain would receive aliased HHE (for example, both www.contentprovider.com and www2.contentprovider.com).

Over the years, we’ve added a few comments to clarify how the script is to be used.  However, one of the most limiting things about the script is that it doesn’t support any of the additional SMS URL parameters supported by NowSMS.

Among other uses, these parameters might be needed in order to specify the SMSC Route to be used for sending the message, or specifying a sender address.

An updated SendSMS.php script, which supports additional URL parameters is available at http://www.nowsms.com/download/sendsms2-php.txt.

In the original script, we provided the following example for calling the SendSMS PHP function:

$x   = SendSMS("127.0.0.1", 8800, "username", "password", "+44999999999", "Test Message");

The new script supports the above format, but can also support additional optional parameters, specified in “parameter=value” format.  For example, the following example specifies an explicit outbound SMSC route and a sender address to be used.

$x   = SendSMS("127.0.0.1", 8800, "username", "password", "+44999999999", "Test Message",
 "SMSCRoute=Test", "Sender=1234");

For additional usage information regarding this PHP script, please refer to the original discussion of sendsms.php at http://www.nowsms.com/nowsms-php-example-send-sms-text-message.

For more information about NowSMS URL parameters, see http://www.nowsms.com/doc/submitting-sms-messages/url-parameters.

The updated SendSMS.php script is available at http://www.nowsms.com/download/sendsms2-php.txt.

Our investigation suggests that this problem is related to a software issue in the iPhone MMS client, when operating outside of 3G coverage.  There is no problem in the operation of either the NowWAP Gateway or the NowSMS MMSC.

(Note:  Problems with accounting callbacks and routing callbacks in the NowSMS MMSC can cause similar sporadic problems if the web server hosting the callbacks has problems with HTTP Keep-Alive sockets.  To rule out this being a problem, we recommend editing MMSC.INI, and under the [MMSC] header, add RoutingKeepAlive=No and AccountingKeepAlive=No.)

The iPhone appears to have an overall maximum timeout for sending an MMS message.  If it cannot send the entire content of the MMS message within this timeout period, it aborts the attempt and returns an error indication to the sender.   It is unclear exactly how the iPhone determinates this timeout value, as our tests suggest that it is somewhat variable and ranges between 2-1/2 and 3-1/2 minutes.

If an MMS message cannot be transmitted within this timeout period, the iPhone gives up, and automatically initiates a second attempt, and if that attempt fails with a similar timeout error, it returns the dreaded red “!” to indicate that the message sending failed.  If this type of timeout error has occurred, the red “!” will be returned after 5 to 7 minutes.
This problem is not likely to occur in 3G or HSPA coverage areas, but is more likely to happen in 2.5G coverage areas, especially areas that only have GPRS, but not EDGE, or areas with weaker signal strength, because the data upload speeds are slower, and it takes longer to transmit a message.

It appears that iOS 4.x will generally try to send larger image sizes in MMS messages than previous releases.  During testing, we found that one of the test images that we were sending, taken with the iPhone 4 camera, was 950KB in size.   In order to send a 950KB message in 2 minutes or less, the network must be able to provide an average upload speed of 80 Kbps, which is possible with a strong EDGE class 10 connection (max possible upload speed is 118Kbps), but not with GPRS (max possible upload speed is 40Kbps).

Note:  When the iPhone is connected with EDGE, it should “E” next to the operator name, instead of “3G”.   If the phone is connected with GPRS only, a dot is shown instead.

Depending on operator configuration, the iPhone advertises itself to the MMSC as supporting a maximum message size of 1MB (UAProf = http://www.apple.com/mms/uaprof.rdf) or 2MB (UAProf = http://iphonemms.apple.com/iphone/uaprof-2MB.rdf)

To rule out any issues potentially related to either NowWAP or the NowSMS MMSC, these same timeout values were observed testing standard issue operator locked iPhones on O2 in the UK and AT&T in the USA with 3G mode disabled on the phone.

Note that in jailbroken iPhones, it is possible to configure a “MMS Max Message Size” in the “Cellular Data Network” settings.  We experimented with lowering this value, however it appeared that when this value was lowered, if a message was going to exceed this size value, the iPhone would quickly fail the message with a red “!”, without actually attempting to send the message.  (Based upon these brief tests, it is not clear what algorithm the iPhone uses to scale down a picture before sending, as the 950KB picture that we referenced above actually has a native size of 2.7MB, and was taken with HDR enabled.)

The bottom line appears to be that sending pictures via MMS will frequently fail if the iPhone 4 is operating in a 2.5G (“E” for EDGE or a dot for GPRS) environments.  The problem is due to a sending timeout implemented in the MMS client software in the device.  This problem can only be resolved by changing this timeout in the MMS client software implementation, or changing the MMS client to have an option to send lower resolution pictures when operating in 2.5G environments.  There does not appear to be any solution that can be implemented on the mobile operator side.

To avoid frustration, it is recommended that users avoid sending picture or video messages when operating outside of a 3G coverage area.

Messages longer than 70 characters can, of course, be sent, but they are sent as multipart (segmented) messages, and reassembled by the receiving client.  If a message that contains Unicode characters is longer than 70 characters, it is broken into segments of 67 characters for sending.  To send a 160 character message requires 3 SMS messages if the message contains characters that are not part of the GSM character set.

The original GSM protocol was developed in Western Europe, so it includes most Western European characters, plus capital letters in the Greek alphabet in order to facilitate Greek SMS support.  You can view a table of characters in the GSM character set at the following link:  http://www.nowsms.com/long-sms-text-messages-and-the-160-character-limit

A recent posting on the NowSMS Technical Forums discusses recent developments in the 3GPP specifications to add additional national language support to the SMS standard, and eventually overcome these limitations.  For additional discussion of this topic, we recommend joining the discussion at http://www.nowsms.com/discus/messages/1/69650.html.   The start of this discussion is highlighted below.

Question:

I have a question about sending SMS messages using Turkish national characters. Specifically, these characters are a problem:

Ğ, ğ, Ş, ş, İ, ı, ç (upper case Ç is ok?)

I can send messages that contain these characters ok, but NowSMS encodes the messages with Unicode. This means if I send a message longer than 70 characters, it costs me to send two or more messages … instead of normal 160 character limit.

But in Turkey I have heard that there is a way to send these national characters without forcing the whole message to use Unicode encoding. I do not know how it works, but I have heard that this feature is called a locking shift table. Instead of the standard GSM 7-bit character table, mobile phones in Turkey must support a locking shift table that replaces the GSM characters with national characters for Turkey.

Can NowSMS support this SMS locking shift table?

Response:

The fact that messages that contain characters outside of the GSM character set require Unicode encoding and are limited to 70 characters per message instead of the expected 160 character limit, is indeed frustrating for many languages.

The shift tables that you mention are a relatively new development. There is a concept of a locking shift table that replaces the GSM 7-bit character set, and a single shift table which provides additional characters.

You are correct that these shift tables can replace and extend the default GSM 7-bit character set table so that more national characters can fit into a single SMS.

We’ve received a number of inquiries from handset testing labs about them, but I’m not sure that they are used in production systems. (Perhaps they are in active use in Turkey as I can see that there was national legislation there that prompted the 3GPP to develop a solution.)

In addition to Turkey, there are shift tables defined for the Spanish and Portuguese languages. These were all added in 3GPP release 8 (3GPP TS 23.038 and 23.040), which only started being released in 2008.

The Spanish shift table adds ç, Á, Í, Ó, Ú, á, í, ó, and ú.

The Portuguese shift tables add support for the following national language characters: Á À Â Ã ª á à â ã É Ê é ê Í í Ó Ô Õ º ó ô õ Ú Ü ú ü ` ç ∞

3GPP Release 9 adds 10 shift tables for languages of the Indian subcontinent: Bengali, Gujarati, Hindi, Kannada, Malayalam, Oriya, Punjabi, Tamil , Telugu, and Urdu.

Update:  Shift table support is now available in NowSMS.  Additional information and discussion is available at the following link:  http://www.nowsms.com/discus/messages/1/70000.html.

This release contains fixes for specific problems encountered by customers.  If you are not experiencing one of the following issues, version 2010.11.04 is recommended as the current update release (see http://www.nowsms.com/category/updates).

The following issues are addressed by this update:

* MMSC:  Fix for problem where the message ID in a delivery receipt was not formatted correctly (“/” characters changed to “.”) for delivery receipts that arrived via an MM4 connection.  This prevented sending clients from being able to correctly resolve delivery receipts.  (For additional information, see http://www.nowsms.com/discus/messages/485/60287.html.)

* SMS Gateway Web Admin Interface: Fix for web admin interface only sending the first 16KB when attempting to remotely download log files.  (For additional information, see http://www.nowsms.com/discus/messages/1/60254.html.)

The reason for this seems to be some unusual communication patterns between the handset and the App World server. The handset attempts to created a tunneled connection to the HTTP port (80) of the BlackBerry App World server.

Symptoms of the problem include numerous 403 errors for connections to appworld.blackberry.com:80, similar to the WAPGW-yyyymmdd.log entry below:

10.3.4.63 50373060234 [26/Oct/2010:15:39:45 -0600] "CONNECT appworld.blackberry.com:80" 403 0 "" ""

The default configuration of NowWAP only allows tunneled connections to the HTTP SSL/TLS port (443).

It is possible to override this default configuration, and allow the connection by applying the following setting on the “HTTP” page of the NowWAP configuration: “Allow SSL/TLS Tunnel to non-standard ports”.

Enabling this setting will resolve the problem and allow users to connect to BlackBerry App World.

There are no security concerns involved with enabling this setting. If there are any concerns, they are commercial concerns. Most mobile operators have different APNs that provide different levels of connectivity. The default setting for NowWAP allows only standard web browsing to pass through the proxy. Enabling this setting could allow other applications to function through the proxy by allowing tunnels for other port numbers.

Future versions of NowWAP will include port 80 as an allowed tunneling port to avoid conflicts with the BlackBerry App World service.

In simplistic terms, an SMSC manages SMS messages for a mobile operator network, delivering SMS messages to mobile phones.

An ESME is any other type of entity that wants to exchange SMS messages with these mobile subscribers.  In other words, it is any type of application or service that wants to be able to send and/or receive SMS messages. These applications or services are also often referred to as Value Added Services (VAS) or Value Added Service Providers (VASP).

The SMPP protocol is designed to facilitate the exchange of these SMS messages over the standard TCP/IP protocol.

SMPP is designed to be fast and efficient to facilitate high volume reliable message exchange.

This page is designed to be a quick resource for more information on SMPP.  The following links provide more detailed information on specific issues or considerations regarding SMPP (especially for users of NowSMS):

• SMPP Version 3.4 Protocol Specification – This is the version of the SMPP specification that is in widespread use.  There is a later version 5.0 specification that was defined, but it did not have significant market acceptance, and the group that defined the later version specification has been disbanded.
• SMPP Version 3.3 Protocol Specification – A few mobile operators still use old SMSCs that implement the version 3.3 specification.  They can be challenging to work with as some areas of the version 3.3 specification are even more vague than version 3.4.
• Connecting to an SMPP SMSC – Connecting to an SMSC using SMPP can be confusing because of unusual terminology like TON, NPI, and service type.  It can also be confusing because there are many key areas of the SMPP specification that are vague, and different providers have decided to implement things different ways, especially with regard to character set encoding.  This link explains how to configure an SMSC connection in NowSMS, and includes a discussion of some of the terminology and configuration options.
• SMPP Character Set Issues: Long Text Messages and Unicode – Some SMPP implementations want you to submit a long message in a single submission, others require you to perform message segmentation based upon the message type (sometimes using TLV parameters, sometimes using GSM UDH).  Some SMPP implementations use the GSM character set, others use iso-8859-1.
• What are TON and NPI Settings? – TON (Type of Number) and NPI (Numbering Plan Indicator) are two of the settings that can easily give you a headache.  This link provides more information on these settings.
• Optional TLV Parameters – The SMPP Protocol is extensible in that it allows providers to add their own additional parameters, which are known as TLV parameters, so named because of the format of these parameters … Tag, Length, then Value.   Some TLV parameters are defined in the specification, but are optional and are sometimes used and sometimes not used.  Other parameters are provider specific.  This link helps you learn more about TLV parameters by explaining how to configure NowSMS to support custom TLV parameters for a provider.
• SMPP Error Code Reference – What do the error numbers or obscure terms like ESME_RTHROTTLED mean?  Use this link as a quick reference.
• SMPP Error Handling in NowSMS – This link explains how NowSMS handles different SMPP errors, and how can this behaviour be modified.
• Limiting the Speed of an SMPP Connection – SMS providers limit the speeds at which they will accept messages in order to optimise their resource allocation.  If you try to send faster than your provider allows, you may encounter unexpected errors and delays.
• Understanding SMPP Connection Types – Are you both sending and receiving messages?  Does your provider expect you to establish separate sender and receiver connections, or do they expect you to connect as a single connection transceiver?
• Using NowSMS as an SMPP Server for Other Applications – One of the more common uses of NowSMS is to use NowSMS as an SMPP server.  Other clients or applications connect to NowSMS as their SMPP Server, and NowSMS chains to one or more other SMSCs for sending and receiving SMS messages, possibly using SMPP, or possibly using other protocols.
• SMPP Asynchronous Mode – If you’re sending faster than 10 SMS messages per second, you  need to understand SMPP asynchronous mode.
• NowSMS Tech Support Blog – This link will display SMPP related posts on the NowSMS Tech Support Blog.
• NowSMS Technical Forum / Discussion Board – Additional discussions of SMPP related topics and issues take place on the NowSMS Technical Forum / Discussion Board.  Feel free to search these discussions and/or post questions.

One more thing …

As I wrote this post, I recalled one other bit of SMPP terminology that can drive new users crazy … MO and MT messages.  Some people like to throw these terms around just to pretend they know what they are talking about.

MO – Mobile Originated message … in other words, a message that has been sent by a mobile phone subscriber.

MT – Mobile Terminated message … in other words, a message that is destined to be delivered to a mobile phone subscriber.

When you are an application provider that is connecting to an SMS service provider, you receive MO messages, and you send MT messages.

If you would like more information on interfacing your application to NowSMS for SMS message processing, please refer to our API guide at:  http://www.nowsms.com/faq/apis-apis-apis-more-apis

This document details the update release history since the current official release, version 2010.02.09.  Release history for the changes prior to the current official release can be found at  http://www.nowsms.com/category/updates.

Highlights of this update:

1.) SMS Gateway: Performance enhancements for processing large message queues, especially when there are 4 or more outbound SMSC connections.

2.) SMS Gateway: Improved performance for accepting HTTP message submissions, HTTP keep-alive sockets now supported.

3.) SMS Gateway/SMPP Client: Added the capability to define the number of transmitter, receiver and/or transceiver connections to be allocated for a single SMPP connection, without requiring multiple duplicate connections to be defined.

4.) SMPP Server: Support for using SMPP Asynchronous mode to speed the delivery of messages to SMPP Clients when NowSMS is acting as an SMPP Server.  Also an improvement message ID generation logic to prevent duplicate message IDs (SAR-phonenumber-x-x-x format) from being generated.

5.) MMSC: Fix for corrupt message problems that could trigger internal restarts of the MMSC service when processing such a message.

6.) MMSC/MM4: Tolerance improved in decoding received messages where the Content-Location header does not conform to the relevant SMTP specifications, which previously resulted in some users receiving occasional corrupt messages over some MM4 interconnections.  Forwarding of these corrupt messages is suspected in the corrupt message problems that triggered internal restarts of the MMSC service.  Also, fix foran  interoperability problem that was causing some customers problems interconnecting with NTT DoCoMo Japan.  Received messages from this interconnect were not strictly following the 3GPP TS 23.140 Message-ID and Transaction-ID formats.  NowSMS used to correct the encoding problem when sending acknowledgments, but now returns acknowledgments with these ID values in the same format in which they were received, even if the values are invalid per the 3GPP TS 23.140 specification.

There are numerous other minor updates that are detailed in the release history information below.  The release history information provides additional information on configuration settings that have been added to address unusual configuration requirements.

* E-Mail to SMS: Translate Greek capital letters to visually equivalent 7-bit characters in attempts to send SMS messages out using 7-bit encoding. (The NowSMS web interface already does this.)

* MM7 Client: Change Content-Type: text/xml; charset=”utf-8″ to Content-Type: text/xml; charset=utf-8 to address a compatibility problem with a particular operator MMSC. (Whether or not this parameter is quoted should not matter. Removing the quotes should not cause a problem with other MMSCs.)

2010-10-28:

* SMPP Client: Fix for some BinaryDCS= values not working properly, especially BinaryDCS=2. If BinaryDCS=2 was set for a connection, NowSMS would garble the data.

2010-10-22:

* SMPP Client: Fix for a problem introduced in mid-2010 where message receipt IDs were not properly evaluated if the receipt was received two or more days after the message was originally sent.

* SMPP Server: Add preliminary support for NowSMS acting as an SMPP server to use async mode to deliver messages to SMPP clients (NowSMS has previously supported async mode in the other direction, where NowSMS is the SMPP client). This can provide increased performance in delivering messages to connected SMPP clients, provided that the client can support SMPP async mode. To enable SMPP async mode for all clients, add SMPPServerAsyncWindowSize=## to the [SMSGW] section of SMSGW.INI. Alternatively to enable or disable for selected clients, add an [SMPPServerAsyncWindowSize] section to SMSGW.INI, and specify AccountName=## to set the async window size for a specific SMS User account. (A window size of 0 disables async mode.)

2010-10-18:

* SMS Gateway: E-mail alerts now support multiple recipients, separated by a comma.

2010-10-13:

* MMSC: When NowSMS generates an MM7 error response, it was not encoding the error in an a SOAP envelope <fault> element, as required by Section 8.7.8.3 of 3GPP TS 23.140. (Note: The issue is not as cut and dried as it may seem, as the MM7 element defintions for the error response are in conflict with this Section 8.7.8.3. We are choosing to follow Section 8.7.8.3 and assume that the definitions that conflict with it are mistakes in the specification. Further discussion of this issue is at http://www.nowsms.com/discus/messages/485/60182.html.)

2010-10-04:

* SMPP – Fix for a problem where recent versions have not properly passed the “Bind TON”, “Bind NPI” or “Address Range” parameter in SMPP connection tests from the configuration dialog when initially defining a new SMSC connection.

* SMS Gateway: Initial HTTP Keep-Alive socket support in the SMS gateway in the last release caused a problem for “/provision” requests. This problem has been resolved.

* MMSC: Add configuration option to block routing callback for short codes (many routing callbacks expect standard phone numbers). If ForceRoutingCallback=Yes is set in the MMSC.INI, then ForceRoutingCallbackShortCodes=No can be set to exclude short codes from the routing callback. Note: The default maximum short code length is 6 digits, this can be adjusted with the ShortCodeMaxLength=## setting. (All settings referenced in this description are in the [MMSC] section of MMSC.INI.)

2010-09-30:

* SMS Gateway: HTTP Keep-Alive sockets are now supported for HTTP submissions to offer improved performance. If this causes a problem for some applications, keep-alive sockets can be disabled by editing SMSGW.INI and under the [SMSGW] header, adding EnableKeepAlive=No.

2010-09-21:

* SMS Gateway: The SMPPRejectErrorCodes setting described in http://www.nowsms.com/smpp-error-code-handling-in-nowsms can now be set on an individual connection basis. SMPPRejectErrorCodes= is now supported under individual [SMPP - server:port] section headers to allow settings that apply to only that connection.

* SMS Gateway: Improve performance of accepting new HTTP connections for message submissions.

* SMPP Server: Fix message id generation logic to avoid duplicate message IDs when accepting long messages from SMPP clients.

2010-09-14:

* SMPP: When receiving a delivery report from an upstream SMPP connection, if the TLV parameter message_state is not set, NowSMS would previously assume that the delivery report signals successful delivery and would generate TLV parameter message_state=2 if the delivery report is relayed to an SMPP client. Effective with this update, NowSMS now parses the text of the delivery report to determine the status. If the status cannot be determined, NowSMS will not generate a message_state parameter.

2010-08-23:

* MMSC: Add configuration setting to allow the SMTP host name to be set independently of the MMSC “Local Host Name”. To set the SMTP Host name, edit MMSC.INI, and under the [MMSC] header, add SMTPHostName=xxxx. If this parameter is not present, the “Local Host Name or IP Address” field will be used as the SMTP host name. (This setting was added on 2010-06-17, but the original implementation was for SMTP only, not MM4. It now also applies to MM4.)

* SMPP: Fix for a problem with delivery receipt handling for a delivery receipt that was received in Unicode text format.

2010-08-17:

* MMSC: Fix for an exception error that could trigger MMSC restarts when processing MMS to “SMS web link with code” conversions.

2010-08-13:

* MMSC/MM7: Fix for “MMSBCC=Yes” parameter not properly encoding recipients as “BCC” if routing externally via an MM7 or MM4 connection.

* SMPP: Add support for iso-8859-15 character set. This character set may be required if you are experiencing problems sending the Euro € character. When using the GSM character set, the Euro is encoded as an escape character followed by e. However, the Euro character is not actually defined in the iso-8859-1 character set. When NowSMS is configured to use the iso-8859-1 character set, it encodes the Euro with hexadecimal value 0×80, which is the standard encoding from the Microsoft Windows extension of iso-8859-1. However, some SMPP servers expect the Euro to be encoded as 0xA4, which is defined in the iso-8859-15 character set, a character set which was originally intended to be a replacement for iso-8859-1, but that did not see widespread implementation. When an SMPP connection is configured to use the iso-8859-15 (or iso-8859-1) character set, the default behaviour of NowSMS is to submit messages using a data_coding value of 3 to indicate iso-8859-1 encoding. Additional SMPP character set notes: 1.) Some SMSCs expect iso-8859-1 (or -15) encoding to be used, but do not understand the data_coding = 3 setting. For those environments, it is possible to manually edit SMSGW.INI, and under the [SMPP - server:port] section header for the SMPP connection, add SMSCCharsetDefault=Yes, which will tell NowSMS to use a data_coding value of 0 with the character set that is configured for the connection. 2.) If there are character set encoding problems receiving a message from a connection, note that NowSMS uses the configured character set for the connection for interpreting text messages only if the data_coding value is 0. If the data_coding value is 3, NowSMS will decode the text as iso-8859-1 (or iso-8859-15), regardless of the character set configured for the connection. If the data_coding value is 1, or a text encoding value other than 3, NowSMS will decode the text as using the GSM character set. To override this decoding behaviour for received messages, and force NowSMS to always use the character set configured for the connection, edit SMSGW.INI and under the [SMPP - server:port] section header for the SMPP connection, add SMSCCharsetReceiveTextOverride=Yes.

* SMPP Server: Support for SMPP clients connecting to the NowSMS server via SMPP using the iso-8859-15 character set has been added, similar to the settings described for outbound SMPP connections from NowSMS. Default settings for the NowSMS SMPP server character set can be configured under the [SMPP] header of SMSGW.INI. If there is a need to support SMPP clients that use different default character sets, it is possible to add additional user-specific section headers to SMSGW.INI. Under a header of [SMPP - username], the following parameters can be applied to a specific SMPP client account: SMSCCharset=IA5 (for GSM), iso-8859-1 or iso-8859-15; SMSCCharsetDefault=Yes (tells NowSMS to use a data_coding value of 0 with the configured character set), SMSCCharsetReceiveTextOverride=Yes (tells NowSMS to always use the character set configured for the user for text messages, even if the data_coding value implies a different character set is being used).

2010-08-03:

* SMS Accounting Callbacks: Add additional parameters to accounting callbacks, including SMPP “ServiceType” and “Validity” parameters.

2010-07-27:

* MMSC: Fix for a problem sending a message to a large number of MMS recipients, where a problem occurred because initial message recipients would receive the message notification before the MMS message file was closed on the MMSC. This caused message download failures unless MSISDNMatchRequiredForReceive=No was set under the [MMSC] header of MMSC.INI. (Most MMS clients would re-attempt download later and the message would be successfully delivered.)

* Web Interface/Send MMS Message: Fix for an exception error that could occur in the SMS gateway when sending an MMS message to a large number of recipients that include a “+” character.

2010-06-30:

* SMPP & MM7: Add configuration option to support alphanumeric recipients for SMS messages sent over SMPP and MMS messages sent over MM7. This is to support a provider that maintains server side distribution lists which are addressed as alphanumeric recipients. Alphanumeric recipients are only supported if AllowAlphaRecip=Yes is added to the [SMSGW] section of SMSGW.INI. (Fix problem sending to SMS recipients that include a “:” character.)

2010-06-28:

* MMSC/inbound MMS Messages: A new “MMSC Routing” option has been added for “MMSC VASP” definitions. “Local MMS Recipients Only” means that the connection will only accept messages that the MMSC can handle directly without routing to an external MMSC Routing (MM4, MM7) definition. “Local MMS Recipients Only” includes both local MMS users, as well as recipients that are automatically converted to WAP Push or SMS with web link (code). The purpose of the setting is to disallow selected MM4 or MM7 connections from being able to route externally via another MM4 or MM7 connection.

* MMSC: The MSISDNHeaderConvertToLocalNumber=Yes setting now affects both MMS headers and MMS messages that have been converted to SMS with web link (with code) for delivery, so that the message sender phone number is displayed in local number format instead of international number format.

* MMSC: Some temporary files (TEMPxxxxxxxx.TMP) were being created in the NowSMS program directory, and would fail to be deleted. These files are now properly created in the TEMP subdirectory and automatically cleaned up.

* SMS Gateway: When an HTTP message submission is rejected, it could be because the user is out of credits, has exceeded daily/monthly allowances, been denied by a response from an accounting callback, or an error has occurred processing an accounting callback. To aid in troubleshooting, the HTTP 403 error response now includes text that explains the reason for the message rejection. Additionally, it is easier to search for rejection information in the SMSDEBUG.LOG, as the error information in the log will be preceded by “MessageAccountingReject:”.

2010-06-17:

* SMPP Configuration: Add a scroll bar to the “SMSC Character Set” options list to allow easier selection of different character sets.

* SMS Gateway Accounting Callbacks: Fix “SMSOut” accounting callback to start with the text “Retry Pending” for “Status” when a message delivery attempt fails, but a retry is still pending, allowing temporary errors to be properly distinguished from final error conditions.

* SMS Gateway: Optional fix for segmentation logic to avoid repeating UDH headers when NowSMS is automatically segmenting a long message submitted via SMPP “message_payload” or via HTTP. Repeating UDH headers in all segments can cause problems for some uses, particularly SIM data download. To enable this logic, add RepeatUDHAllSegments=No under the [SMSGW] header of SMSGW.INI.

* SMS Gateway/SMPP Client: When operating in sync mode, if ESME_RTHROTTLED is returned, after waiting for the throttle delay, the same message will be re-attempted up to 5 times.

* SMS Gateway/SMPP Client: The SMPP Throttle error delay is now configurable on a per connection basis. The default throttle error delay is 5 seconds. To set a global throttle error delay that applies to all connections, add SMPPThrottleErrorDelay=## (where ## is a number of seconds) under the [SMSGW] header of SMSGW.INI. To specify a delay that should be used only for a specific connection, add SMPPThrottleErrorDelay=## to the [SMPP - server:port] section for the connection.

* SMS Gateway/SMPP Client: Add configuration option to treat the ESME_RMSGQFUL (receive message queue full) error the same way as a throttling error, subjecting it to the SMPPThrottleErrorDelay pause. This option can be activated for inidividual SMPP connections if desired by adding ThrottleForQFull=Yes under the [SMPP - server:port] section header for a connection.

* SMS Gateway: Additional performance optimisations for user credit balance and quota tracking.

* SMS Gateway: Fix for a message encoding problem when sending long text messages via an outbound SMPP connection with WDP Adaptation enabled if the message contains source and/or destination port addressing.

2010-06-04:

* SMS Gateway/GSM Modem Receive Message: Fix for a problem where the sender phone number was not being interpreted correctly for some messages. For some reason, the problem messages were being received with the sender address type being set to a reserved/unknown value, which was causing NowSMS to mistakenly interpret the sender address as being alphanumeric.

2010-06-02:

* SMS Gateway: Performance optimisations for user credit balance tracking.

2010-06-01:

* MMSC/MM4: When generating MM4_forward.RES acknowledgments include the “X-Mms-Message-ID:” and “X-Mms-Transaction-ID:” headers exactly as they were received. Previously, quote characters were added to these values if they were not present in the received message, because the MM4 specification (3GPP 23.140) defines these headers as requiring quoted-string values. This was causing a problem with an MM4 interconnect to NTT DoCoMo Japan, which is not properly formatting these headers with quoted-string values. In the unlikely event that this change causes a problem with other MM4 interconnects, a configuration setting has been added to force the old behaviour which would always format these values as quoted-string. To enable this old behaviour, edit MMSC.INI and under the [MMSC] header, add ForceMM4QuotedMessageID=Yes.

2010-05-25:

* MMSC: Fix for a corrupt message problem that triggered repeated MMSC restarts and denial of service.

2010-05-24:

* SMS Gateway: Fix for bug effecting the “ReRouteReceived” setting, which allows messages received via an SMSC connection to be redirected for delivery via another SMSC connection. Recent changes to allow accounting callbacks to specify message routing was causing invalid routing information to be recorded for these messages, causing them to be stuck in the queue.

2010-05-20:

* GSM Modem Handling: When routing messages received via a GSM modem to an SMPP client account, if the modem phone number is not available, insert a value of “1″ as the destination address instead of blocking the message from being received by the SMPP client.

2010-05-17:

* SMS Gateway: 2010-05-07 version had a problem with “Stuck messages” if messages were submitted with explicit queue routing (&SMSCRoute=routename), and the setting UseRouteQueues=Yes was not applied.

2010-05-13:

* GSM Modem Handling: Additional checks to stop polling memory locations that don’t exist on unusual modems like the Multitech CDMA modem. (Was not an operational problem, but resulted in a lot of error information in debug logs.)

2010-05-12:

* GSM Modem Handling: Add an additional modem test (AT+CREG?) to check if the modem reports loss of signal. If the loss of signal condition persists, trigger a soft reset of the modem to try to get the modem to reconnect with the operator.

* GSM Modem Handling: Fix for a “CMS ERROR: 340″ issue that could occur with some CDMA modems that emulate GSM modems, where NowSMS would try to use support for GSM Phase 2+, even if it was not enabled in the configuration.

2010-05-07:

* SMS Gateway: Add the capability to define the number of transmitter, receiver and/or transceiver connections to be allocated for a single SMPP connection, without requiring multiple duplicate connections to be defined. In the [SMPP - server:port] section of SMSGW.INI, the following settings are supported: TransmitterCount=## and ReceiverCount=##. TransmitterCount=## defines the number of transmitter connections to be established. If transceiver mode is configured, TransmitterCount specifies the number of transceiver connections to be established. If transceiver mode is not configured, ReceiverCount specifies the number of receiver connections to be established. Note that the number of receiver connections cannot be greater than TransmitterCount.

* SMS Gateway: Performance optimisations for large message queues, especially when there are a large number of outbound SMSC connections. Previously documented UseRouteCache=Yes parameter setting is now enabled by default. In the event of unexpected problems, the new routing logic can be disabled with a setting of UseRouteCache=No under the [SMSGW] header of SMSGW.INI.

* SMS Accounting Callbacks: Add SMPPOptions TLV parameters to the accounting callbacks.

* SMS Accounting Callbacks: Fix for a problem with accounting callbacks if text included “@@”.

* MMSC: Fix problem with automatic MMS version detection that was preventing some MMS clients from recognising that the MMSC supports read receipts, causing clients to send read receipts as standard messages (bug was introduced in early 2009 versions).

* MMSC: Add pre-auth callback for “MMSReadReport” when an MM1 client is submitting a message read receipt. (A pre-auth callback is not necessarily required for this event, however it is being added for consistency, since a pre-auth callback does exist for delivery reports.) Pre-auth delivery report callback also modified to include AccountingExtraHeaders if configured.

* MMSC: Fix for MMSC routing callback not including the “From=” parameter for messages submitted via the web interface.

2010-04-20:

* SMS Gateway: Fix for a routing issue where multiple SMSC connections have the same sender address, where one route has one or more preferred routes, and another route with the same sender address has “Support any outbound message traffic” checked. Messages with a matching sender address should only be routed to the first route if the recipient matches a preferred route, however it was being routed to either route. Note: This only applies to sender based routing.

2010-04-15:

* Accounting Callbacks: Add additional parameter “AcctInfo=” that can be included when submitting a message via HTTP. If included on submission, this parameter will be passed to subsequent accounting callbacks regarding the message.

* MMSC: Fix for MM4 message decoding problem when “Content-Location:” header contains a space character. According to RFC2557, White space characters do not appear to be valid as part of a location name in this header. A change to allow them is being implemented to address a problem where customers are receiving corrupt messages from some Verizon phones.

* SMS Gateway: New performance optimisations for performance problems with large message queues, especially when combined with a large number of outbound SMSC connections. These performance optimisations are only enabled in this version when UseRouteCache=Yes is specfied under the [SMSGW] header of SMSGW.INI.

* Internal: Include additional error checking to detect and automatically repair SQLite databases that are used for receipt tracking.

* Internal: Update SQLite databased (used for message id receipt tracking) to v3.6.23.

2010-03-18:

* SMS Gateway: Fix for 2-way SMS problem on Windows XP systems, where early 2010 versions would have problems sending replies to 2-way SMS messages because of corrupt “SMSCRoute=” information being added to the SMS message.

* SMS Gateway: Add configuration settings to disable user logging and quota management features to add performance for systems that do not need user logs and/or quota tracking. Under the [SMSGW] header of SMSGW.INI, the following settings have been added: DisableUserLog=Yes – This setting disables the creation of user specific log files in the USERS\username directory structure. DisableUserQuota=Yes – This setting disables the tracking of how many messages each user account sends in a day.

2010-03-10:

* SMS Gateway: Fix for delivery receipts message IDs not being tracked if the sender address is alphanumeric containing a ‘ (single quote/apostrphe) character.

* SMS Gateway: Minor performance optimisation for large message queues (could be major for some installations, minor for others).

* WAP Push testing parameters added to meet a particular conformance test which required support for WAP Push SI, SL and CO messages using WBXML version 1.1 and the iso-8859-1 character set. NowSMS defaults to using WBXML version 1.2 and the UTF-8 character set. To set the WBXML version, edit SMSGW.INI and under the [SMSGW] section header, add WAPPushWBXMLVersion=1.1. To specify iso-8859-1 as the WAP Push character set, use WAPPushUseUTF8=No in the [SMSGW] section of SMSGW.INI.

2010-02-10:

* Fix for error message confusion where NowSMS would report an error about the SMPP port already being in use when the port conflict actually involved the SMTP port.

The primary API for sending and receiving SMS and MMS messages with NowSMS is HTTP-based. Because the API is HTTP based, applications that wish to send or receive messages via NowSMS do not have to run on the same physical server, they can interface with NowSMS over a network.

This page contains links to additional information that describes the raw HTTP interface, as well as links to example scripts for PHP, Java and command-line interfacing with NowSMS.

Note that in addition to these APIs, NowSMS also supports the SMPP protocol, allowing SMS clients to connect to NowSMS as an SMPP server for both sending and receiving SMS messages. For MMS clients, NowSMS also supports the MM1, EAIF, MM3 (SMTP), MM4 and MM7 protocols for both sending and receiving MMS messages.

HTTP Protocol Information

• Sending SMS Text Messages over HTTP

• Sending WAP Push Messages over HTTP

• Sending WAP Push Messages using PAP over HTTP

• NowSMS HTTP URL Parameter Reference

• Sending MMS Messages over HTTP

• 2-Way: Receiving SMS Messages over HTTP

• 2-Way: Receiving MMS Messages over HTTP

• Search the NowSMS Web Site for 2-Way SMS

• Search the NowSMS Web Site for 2-Way MMS

PHP Scripts for Sending SMS & MMS

• Sending SMS Text Messages with PHP

• Sending MMS Messages with PHP

• Sending OMA Client Provisioning Messages with PHP

• 2-Way: PHP Examples for Receiving SMS

• 2-Way: Receiving MMS with a PHP Script

• PHP Related Postings on the Technical Blog

• Search the NowSMS Web Site for PHP

Java Examples for Sending SMS & MMS

• Sending SMS Messages from Java

• Sending WAP Push Messages from Java

• Sending MMS Messages from Java

• Java Related Postings on the Technical Blog

• Search the NowSMS Web Site for Java

.NET Examples for Sending SMS & MMS

• Sending MMS Messages from VB .NET

• Sending MMS Messages from C# .NET

• .NET Related Postings on the Technical Blog

• Search the NowSMS Web Site for .NET

Command Line Interface for Sending SMS & MMS

Note: The Command Line Interface is particularly useful because you can easily spawn a command line script to interface with NowSMS.

• Sending SMS Messages

• Sending WAP Push and Binary SMS Messages

• Sending MMS Messages

• Sending OMA Client Provisioning Messages

• Command Line Interface Related Postings on the Technical Blog

• Search the NowSMS Web Site for Command Line Interface

Before the MMSC can pass this information to the accounting callbacks, the MMSC must receive this additional information from the operator network. The MMSC expects to receive this information via HTTP headers that are inserted into the MMS client request by a WAP gateway or proxy. This is the same process that the MMSC uses for identifying subscribers, as detailed in the article at http://www.nowsms.com/support/bulletins/tb-nowsms-002.htm.

NowWAP 2010 and later include additional RADIUS support for the 3GPP SGSN-MCC-MNC and SGSN-ADDRESS attributes. If they are present, NowWAP generates additional HTTP headers for these attributes in any requests where it also includes the MSISDN header. There are no special configuration parameters required in NowWAP to include these parameters, they are always included when present in the Radius Accounting packet. The HTTP request that is forwarded by NowWAP will include “X-WAP-3GPP-SGSN-MMC-MNC:” and “X-WAP-3GPP-SGSN-ADDRESS:” headers with the associated values.

The SGSN information identifies the network node to which the subscriber is connected, making it possible to identify whether or not the subscriber is roaming.

It is then possible to configure the MMSC to include these headers in MMS accounting callbacks, when using NowSMS 2009 or later. To enable this, edit MMSC.INI, and add the following under the [MMSC] header:

AccountingExtraHeaders=X-WAP-3GPP-SGSN-MCC-MNC,X-WAP-3GPP-SGSN-ADDRESS

When this parameter is present, the MMSC looks for any of the HTTP headers in this comma delimited list and includes them in the MMS accounting callback if they are present. They are appended to the accounting callback URL like this:

&X-WAP-3GPP-SGSN-MCC-MNC=xxxxx&X-WAP-3GPP-SGSN-ADDRESS=1.2.3.4

(An additional parameter that may be of interest in some environments is X-WAP-IMSI.)

For additional information on MMSC accounting callbacks, please see http://www.nowsms.com/mmsc-accounting-callbacks-for-billing-and-charging.

The interface to support this is defined in the following article:

Mobile Number Portability (MNP) and the NowSMS MMSC

However, there is an additional issue that is not discussed in that article.

By default, the routing callback is only called for recipients that are not defined to the MMSC on the “MMSC Users” page.

In a typical operator MMSC configuration, new MMSC user accounts are automatically provisioned the first time a user sends an MMS message. This configuration is detailed in the article titled NowSMS MMSC Operator Considerations.

A problem scenario develops if a subscriber moves their number from this operator to another operator, after they have already been provisioned on the MMSC. The MMSC will see the user account and attempt to deliver the MMS message directly, without performing a routing lookup.

To address this scenario, an additional MMSC configuration parameter exists. Under the [MMSC] header or MMSC.INI, add the parameter ForceRoutingCallback=Yes. This setting will cause the routing lookup to always occur.

Prior to the 2009-06-30 release, to address this issue, we recommended instead using the setting DisableMMSDirectDelivery=Yes, a setting name which sounds contrary to the intended purpose. This other setting was originally added to NowSMS for a different purpose, but it does have the side effect of always forcing the routing callback.

We no longer recommend the use of DisableMMSDirectDelivery=Yes for this purpose, and instead recommend the ForceRoutingCallback=Yes setting. This is because DisableMMSDirectDelivery=Yes has an extra side effect of disabling the automatic version tracking of MMS clients. Because the MMS read receipt format was not introduced until OMA MMS v1.2, this can cause some clients to generate read receipts as regular MMS messages instead of using the read receipt format.

This document covers changes between the last major 2009 release and version 2010.02.09.  An interim update may be available at the following link:   http://www.nowsms.com/nowsms-update.

The release history information provides additional information on configuration settings that have been added to address unusual configuration requirements.

2010-02-03:

* Fixes for UseRouteQueues=Yes setting when “SMSCRoute=” is set by a PreAuth SMS Accounting callback.

2010-01-27:

* 2-way SMS: Fix for problem where SMPPOptions settings and service type were not preserved when recombining a received multipart SMS for passing to a 2-way command.

* MMS Gateway/MM1: Fix for problems routing MMS delivery reports back to an MM7 connection if the MMSC host name is not configured (which is always the case in NowSMS Lite). Also fix a problem where MMS delivery reports were not automatically routed to the default route configured for the modem’s MMS receive settings.

* SMS Gateway/SMPP Client: Update configuration parameter that allows the “users” directory to be moved to another location other than beneath the NowSMS program directory. This directory contains queues of received messages waiting for SMPP or POP3 clients, as well as user specific log files. Under the [SMSGW] header in SMSGW.INI, use UsersDir=d:\path\ or UsersDir=\\Server\Volume\path\ to specify the location of the SMS “users” directory. When this parameter is set, the “SMS Users” database files (SMSUSERS.D2A and SMSUSERS.D2I) will also be located in this directory (by default, when this parameter is not set, these files are in the NowSMS program directory). With this release, it is now possible to separate the queued messages and log files from other user related data. Under the [SMSGW] header, use UsersQDir=d:\path\ or UsersQDir=\\Server\Volume\path\ to specify the location of the user directories that will hold queued messages only. Under the [SMSGW] header, use UsersLogDir=d:\path\ or UsersLogDir=\\Server\Volume\path\ to specify the location of the user directories that will hold log files. Other user directories and files will be stored relative to the “UsersDir=” setting, or in their default location if “UsersDir=” is not present.

* SMPP: Add SMSC specific configuration option to suppress TLV receipt parameters when delivery receipts are routed to an outbound SMSC connection (this would generally only happen when the ReRouteReceived option is used). Under the [SMPP - server:port] header of SMSGW.INI, if you want to suppress the receipt TLV parameters for messages routed to this server, add IgnoreReceiptTLV=Yes.

2010-01-19:

* SMS Gateway: Add a configuration option to add separate queues for explicitly routed messages. In SMSGW.INI, under the [SMSGW] header, add UseRouteQueues=Yes.

* SMS Gateway: Add a configuration option to possibly speed up receiving of SMS messages when accounting callbacks are enabled and SMPP async mode is enabled for a connection. When this configuration option is enabled, inbound SMS message processing and accounting callbacks are moved to a separate thread. To enable this setting, edit SMSGW.INI, and under the [SMSGW] header add AsyncReceiveMessages=Yes. (Note: This setting is still considered experimental.)

2010-01-06:

* MMSC: Fix for problem with MSISDN header parsing where the MMSC was looking for both the X-MSISDN header and a value configured for the “MSISDNHeader=” setting, when it should only be looking for the “MSISDNHeader=” setting.

2009-12-24:

* SMS Gateway: Fix for problem where if “Separate outbound message queues” for each user is not enabled, NowSMS would not send out any SMS messages that originated via SMTP.

2009-12-22:

* SMS Gateway: Fix for problem where NowSMS would keep re-initialising a modem if the user had never edited and saved properties for the modem after the initial add.

2009-12-21:

* SMPP: If routing a delivery receipt via an outbind SMSC connection, use esm_class of 8 in submit_sm. (Previously, a value of 4 was being used, which is not valid in submit_sm.) Also add a configuration option to suppress TLV paramters (message_state and receipted_message_id) for delivery receipts routed via an outbind SMSC connection. To suppress these TLV parameters, edit SMSGW.INI, and under the appropriate [SMPP - server:port] section header, add IgnoreReceiptTLV=Yes.

* SMPP: Add message_id to data_sm_resp if we receive a data_sm from an outbind SMSC connection, and the message is rerouted to another outbind SMSC connection because of a “ReRouteReceived” configuration setting.

* SMS Gateway: Update preferred service_type handling for routing particular service_type values to specific SMSC connections to support pattern matching and “best match”. See http://www.nowsms.com/discus/messages/1/42107.htm and http://www.nowsms.com/discus/messages/1/24460.html.

* Add option to disable writing anything to the Windows Event Log. Add DisableEventLog=Yes under [SMSGW] header in SMSGW.INI.

* SMS Gateway: Allow retry parameters to be specified on a per-SMSC connection basis, so that different connections can have different retry settings. If any of the following retry parameters is found in the SMSC specific section of SMSGW.INI, it will override the default setting under the [SMSGW] header: RetryDelay, RetryDelayMultiplier, RetryDelayAfterAttempts, RetryDelayMax, RetryMaxAttempts, InitRetryDelay, InitRetryDelayMultiplier, InitRetryDelayAfterAttempts, InitRetryDelayMax.

2009-12-08:

* MMSC/MM4: Implement checks to prevent circular routing for MM4 interconnects. If a message is received via an MM4 connection, and the MMSC determines that its delivery path to the recipient is via that same MM4 connection, the message will be rejected with a negative response in the MM4_forward.RES. For compatibility with previous releases, this check can be disabled with the setting DisableCircularRoutingCheck=Yes in MMSC.INI.

2009-12-01:

* MMSC: Fix for MMSUSER.EXE -quotareport listing up to 1000 blank user entries after the last user.

2009-11-25:

* SMS Gateway: Fix for a problem where individual parts of a multipart message were not routed out via the same SMSC connection if NowSMS was able to fully route one part before the next part was received.

* SMPP: Add a configuration option to override the character set for received SMS messages. A customer encountered a situation where the SMSC was encoding text using the iso-8859-1 character set. However, the SMSC was setting the character set flag in the message to indicate that text was using the GSM character set. NowSMS was configured to use the iso-8859-1 character set with this SMSC, however, since the character set was explicitly set as GSM in the received message, NowSMS could not decode the text properly. To address this issue, it is possible to add SMSCCharsetReceiveTextOverride=Yes under the [SMPP - server:port] section of SMSGW.INI. When this parameter is present, NowSMS will always interpret received text messages as being encoded in the character set configured for the connection.

* SMPP: Add a configuration setting to allow a default PID value to be used for all messages routed to a specific SMSC connection. Under the [SMPP - server:port] section of SMSGW.INI, add DefaultPID=XX, where XX is the PID value in hex.

2009-11-04:

* MMSC: When the sender of an MMS message is an e-mail address (instead of a short code or phone number), and the message arrives via a VASP connection, requesting a delivery receipt, the MMSC would always try to send the delivery receipt back via e-mail. This was only an issue if the MMSC was delivering the message directly, if it was routing to an upstream MMSC connection, delivery receipts back to an e-mail recipient would be routed correctly.

* SMS Gateway: Add a configuration option to use 16-bit reference numbers when generating concatenated multipart messages. By default, NowSMS uses 8-bit reference numbers, which allows the most characters to be fit in a single SMS. However, a customer observed that when sending binary messages to a Java application on many Motorola phones, one byte of data per message segment would be lost when using 8-bit reference numbers due to a bug in the phone software. When 16-bit reference numbers are used, message length per segment rules change. For long text messages, instead of 153 characters per segment, only 152 characters per segment can be achieved. For Unicode messages, instead of 67 characters per segment, only 66 characters per segment can be achieved. For binary messages, 133 bytes of binary data can be included per segment, instead of 134 bytes. To enable 16-bit reference numbers, edit SMSGW.INI, and under the [SMSGW] section header, add ConcatRef16Bit=Yes. Note that when this setting is applied, 16-bit reference numbers are only used when NowSMS performs the segmentation (message submitted either via HTTP, or via SMPP using a single message_payload submission) … NowSMS does not resegment messages that have already been segmented by the submitting client.

2009-10-28:

* SMPP: Add SMPP character support for an unusual “Roman-8″ character set needed for a specific SMSC.

2009-10-23:

* GSM Modem: Add code to detect a system waking up from sleep or hibernation where we may need to reset the modem.

* SMPP: Add configuration setting to prevent NowSMS from remapping GSM message class DCS values which are invalid in SMPP to valid SMPP values. To apply this setting for a specific SMSC, edit SMSGW.INI, and under the SMSC specific section (e.g., [SMPP - server:port]), add emapMessageClassDCS=No.

2009-10-21:

* SMS/GSM Modem: For messages received via GSM modem, if a phone number property is not set for the modem, read the phone number from the modem and apply it as the received phone number.

* SMSLite: Configuration program was not allowing the “Route SMS to local user” setting to select users.

2009-10-19:

* SMS/GSM Modem: Fix for problem initialising Telit HSPA Modem. Previously, attempts to initialise modem were returning error: “Error initializing modem – 0″

2009-10-12:

* MMSC: EnableReadReceipt=No was disabling read receipts from being generated by local recipients, but it was not disabling the read receipt request from being routed to external recipients. It now blocks both.

2009-10-07:

* SMPP Server: Fix for change in 2009.10.01 version which caused server to accept messages from an SMPP client even if a user was over quota.

2009-10-01:

* GSM Modem: More GSM modem handling updates.  Added code to reset the modem after persistent errors sending SMS or MMS messages to try to recover “hung” modems. MMS sending updated to address an issue where if a modem was removed/reinserted, the MMS part of NowSMS could not recognize the modem again until the service restarted. (This could also happen with buggy modems that restart themselves periodically.) An additional option was added to the GSM modem configuration to trigger NowSMS to restart the server if a modem becomes unresponsive and NowSMS is unable to access the modem. (Note: NowSMS retries for about 15 minutes before triggering a reboot when this option is enabled.)

* SMPP/WDP Adaptation: Fix for 2009.06.30 change. If BinaryDCS override is not specified for the SMPP connection, and WDP Adaptation is being used, continue to remap DCS value 0xF5 to 4, as was done in earlier releases.

* SMPP Server: When accepting messages from an SMPP client, if the client specifies TON=1 (international), but the address starts with “0″, assume that the number is in local format, not international.

2009-09-16:

* MMSC/MM4: Work-around for situation where MM4 delivery reports were not being accepted because the recipient address (original sender) for the delivery report was not being specified in the “RCPT TO:” command. Instead, the other MMSC was specifying the MMSC system address in the “RCPT TO:” command and only included the original recipient in the “To:” header of the message.

2009-09-15:

* SMS Gateway: Fix for an exception error that could occur with segmented SMS messages submitted to recipient phone numbers longer than 70 characters. Problem most frequently occurred with multiple outbound SMSC connections.

* Receiving MMS via GPRS Modem: Fix for problem where when received SMS messages are being routed to a local user, NowSMS would also route MMS notifications to that local user account instead of processing them as received MMS messages.

2009-09-08:

* MM7: Add configuration option to allow selected MM7 status codes to be classified as success or retry status codes. By default, NowSMS accepts only StatusCode 1000 as an inidication of successful message submission. To add additional status codes, edit VASPOUT\accountname\VASP.INI, and under the [VASP] header, define SuccessStatusCodes=1000,1001,1002 (comma delimited list of status codes). Similarly, NowSMS considers all errors except 2001, 3003, 4000, 4006 and 4007 to be permanent status errors. If NowSMS receives a StatusCode response with any other value, the message submission will not be reattempted (3003 is a special status code case indicating that the MMSC only accepts one recipient at a time). To add additional StatusCode responses that should be treated as temporary errors, edit VASPOUT\accountname\VASP.INI, and under the [VASP] header, add RetryStatusCodes=2001,4000,4006,4007 (comma delimited list of status codes, include the default StatusCodes that should be retried).

2009-08-31:

* SMPP: Add SMPP character support for the unusual “ASCII 437″ code page that is used by Telstra.

* SMPP: Add configuration setting to set the initial SMPP sequence_number value to be used by a connection as a random value. To enable this setting, edit SMSGW.INI, and under the [SMSGW] header add SMPPSeqRandom=Yes.

2009-08-26:

* GSM Modem Handling: If errors occurred when sending MMS messages via a modem route, the MMSC would not timely release the modem to allow SMS sending to continue.

* SMPP: Fix for improper sequence_number generation issues.

* Add “BCC” option for sending an MMS message via the web interface. If using NowSMS proprietary URL submission, include “MMSBCC=Yes” to force recipients to be BCC.

* SMS Gateway/SMPP Client: Update configuration parameter that allows the “users” directory to be moved to another location other than beneath the NowSMS program directory. This directory contains queues of received messages waiting for SMPP or POP3 clients, as well as user specific log files. Under the [SMSGW] header in SMSGW.INI, use UsersDir=d:\path\ or UsersDir=\\Server\Volume\path\ to specify the location of the SMS “users” directory. When this parameter is set, the “SMS Users” database files (SMSUSERS.D2A and SMSUSERS.D2I) will also be located in this directory (by default, when this parameter is not set, these files are in the NowSMS program directory). With this release, it is now possible to separate the queued messages from other user related data and logs. Under the [SMSGW] header, use UsersQDir=d:\path\ or UsersQDir=\\Server\Volume\path\ to specify the location of the user directories that will hold queued messages only. Other user directories and files will be stored relative to the “UsersDir=” setting, or in their default location if “UsersDir=” is not present.

* MMSC/MM4: Add the ability to use different source/sender domain names for different groups of users. This may be useful when multiple mobile operator networks are serviced by a single MMSC. To specify the outbound domain name, edit VASPOUT\accountname\VASP.INI for the outbound MM4 connection … creating a [DomainMapping] section. Within this section, specify address pattern to domain name mappings using the following format addresspattern=domain.name (e.g., +111*=domain1.com). Note: To support these additional domain names when receiving messages, add domain name alias settings under the [MMSC] section of MMSC.INI using the format DomainNameAlias1=domain1.com … DomainNameAlias2=domain2.com … etc.

2009-08-20:

* GSM Modem Handling: Internal updates for improved performance and compatiblity. Change the default receive polling interval to 3 seconds when “Direct to Modem” is the “SMS Message Storage” type. The polling interval is set to 2 seconds for other “SMS Message Storage” types (prior to NowSMS 2009, it was always 1 second). To change the default add ReceivePoll=##, where ## is the number of seconds, under the appropriate [Modem - driver name] section header of SMSGW.INI. Modem polling logic also optimised to be less resource intensive on the modem. If this change causes problems receiving messages with older phone modem implementations that worked with previous version of NowSMS, add OldPollingLogic=Yes under the appropriate [Modem - driver name] section header of SMSGW.INI.

* MMSC: When routing MM7 to MM1, do not encode “Content-Disposition:” headers in the MM1 message, as this seems to confuse some operator MMSCs.

2009-08-15:

* 2-way SMS processing: Non-delivery receipts generated by NowSMS when an SMSC connection rejected a message were being marked with a “.IN” extension instead of a “.REC” extension. While not necessarily a problem, this could cause delays for other “.IN” messages being processed. These receipts are now marked with a “.REC” extension so that they will be processed in the 2-way SMS receipt queue instead of the normal inbound message queue.

2009-08-14:

* Multimedia Content Push: WML format is used by default. HTML format is only used if the receiving client does not support WML.

* Internal changes (updated debug log information) for 2-way SMS processing in the SMS-IN directory.

* GSM Modem Handler: Improved compatibility with SonyEricsson USB modems (especially MD300).

2009-08-05:

* Multimedia Content Push: Fix XHTML generated for multimedia content push. Update install to include missing CSS file for XHTML version of multimedia content push.

* SMS Gateway: Modem handling – Change “Default” and “Direct to Modem” handling to prefer SIM message storage.

2009-07-29:

* Fix for 2009 changes to multimedia WAP push causing problems displaying content that includes Unicode text.

2009-07-23:

* SMS Gateway: When NowSMS generates a non-delivery receipt because an upstream SMSC connection has rejected a message, the non-delivery receipt was not being logged. It is now logged to the SMSIN log file.

* SMS Gateway: Add configuration option to suppress the creation of “.ERR” files when an SMSC connection rejects a message. To suppress these files, edit SMSGW.INI, and under the [SMSGW] header, add ErrorQRetainDays=0.

2009-07-21:

* MMSC: Fix for AccountingKeepAlive=No and RoutingKeepAlive=No settings not working for MMS accounting and routing callbacks. Use of these settings would cause a handle leak and after a period of time, the MMSC would no longer be able to accept or initiate connections.