mBlox and NowSMS: Premium Rate SMS and OPPC

Posted by on Oct 8, 2008 in Support Blog

Topic Keywords: , , ,

Here at NowSMS, we make it a point not to endorse any particular SMS service provider. The fact of that matter is that bulk SMS services are a volatile business, and we like our customers to have flexibility to choose and change SMS service providers that best fit their needs.

That said, some SMS service providers have unique configuration attributes, and you need to apply special configuration parameters in NowSMS in order to take advantage of features and flexibility offered by the SMS service provider. This is especially the case with premium rate SMS services, including AT&T’s OPPC (Off Portal Purchase Control).

mBlox uses a number of special parameters, some of which are specific to their service only. So for customers who are looking to use NowSMS with mBlox, I want to highlight some of these settings and parameters.

This should not be construed as an endorsement of mBlox by NowSMS, or vice versa. This is just information that is provided to help simplify the process of integrating NowSMS with the mBlox service.

There are a series of special SMPP parameters that mBlox defines for their service. SMPP is flexible in that it allows service providers to define additional parameters in the optional TLV (tag, length, value) section of the SMPP message packet.

To enable the additional mBlox parameters in NowSMS, it is necessary to manually edit the SMSGW.INI file and and add the following section:


The above text should be added to the SMSGW.INI file “as is”. “String” and “Integer” are not place holders for you to replace when adding this information to the SMSGW.INI file, so please avoid that common mistake.

These parameters are provider specific, and you are telling NowSMS that there are additional parameters supported by your provider, and these settings tell NowSMS the parameter type (e.g., “String”), length restrictions, and the SMPP parameter value.

When these settings are present, additional parameters are supported when submitting a message to NowSMS via an HTTP URL request.

“&SMPPOption_mblox_operator=” can specify a value for the destination operator.

“&SMPPOption_mblox_tariff=” can specify a value for the premium rate tariff associated with the message.

“&SMPPOption_mblox_sessionid=” may be required for some premium rate SMS operator implemtnations.

“&SMPPOption_user_message_reference=” is a generic option that allows you to set/retrieve the value of the SMPP “user_message_reference” variable. An mBlox FAQ suggests that it is possible to use this option to specify a billing reference.

For additional information on any of these parameters, please refer to the mBlox SMPP Gateway Manual.

Please note that mBlox support will often suggest that you use a value of “0” for the mblox_tariff initially. However, customers have reported to us that mBlox appears to require a 5 digit code for this field, and that “00000” should be used instead of “0”.

When these SMSGW.INI file settings are present, NowSMS will also route these parameters to HTTP-based 2-way commands. If a message is received which contains values for either of these settings, NowSMS will automatically append “&SMPPOption_mblox_operator=value” and/or “&SMPPOption_mblox_tariff=” to the 2-way URL. It is not necessary to add any variables to the 2-way command template, as these values will be appended automatically if present in a received message.

In addition to supporting these options via HTTP URL request, it is possible to configure default settings for any of these options for each outbound SMPP connection.

In many cases, it may be desirable to define default values for these parameters, instead of having to specify them in each HTTP URL submission. To define default values for these parameters, manually edit the SMSGW.INI, and in the section header for an SMPP connection (e.g., [SMPP – ip.address:port]), add a “DefaultSMPPOptions=” setting, where the value of this setting can contain any of the “SMPPOptions” settings. For example, “DefaultSMPPOptions=mblox_tariff=00000”. To include multiple options, separate the entries with a “;”, for example, “DefaultSMPPOptions=mblox_tariff=00000;user_message_reference=1”.

In addition to the above parameters, mBlox uses some additional parameters and terminology which differs slightly from NowSMS terminology.

The “originator” is the “Sender Address”, or “short code” associated with your serivce. You will want to configure this value as the “Default Sender Address” for the mBlox SMPP SMSC connection that you define to NowSMS.

“ProfileID” equates to the “Serivce Type” parameter in SMPP. Do not confuse “Service Type” with “System Type”. “System Type” is an SMPP parameter that is sent at initial login (bind). “Service Type” is a parameter that is set for each message that is sent. While “System Type” can be easily defined via the NowSMS user interface, in order to define a default “Serivce Type” value, it is necessary to edit the SMSGW.INI file, and under the [SMPP – server:port] header (server:port will be replaced with the address of your SMSC), specify: ServiceType=value (value is the value that you want to be specified as the service type). It is also possible to override the default Service type value when submitting a message to NowSMS via SMPP by including “&ServiceType=value” in the HTTP URL string.

When we work with customers who are interfacing NowSMS with mBlox, the issues that we typically see are this:

1. ) Make sure that you have the [SMPPOptions] section defined in SMSGW.INI exactly “as is” … do not replace “String” with some other value.

2.) Define your short code as the “Sender Address” for the SMPP SMSC connection.

3.) Make sure that you have your DefaultSMPPOptions= settings under the [SMPP – server:port] section of SMSGW.INI for the SMSC connection that you have defined (e.g., under [SMPP – smpp.psms.us.mblox.com:3209]). mBlox documentation will tell you what settings you need to specify, but generally you will need to specify an mblox_tariff value (e.g., “DefaultSMPPOptions=mblox_tariff=00000”).

4.) If you require a specific profile id, include ServiceType=value under the [SMPP – server:port] section of SMSGW.INI.

5.) If you need to use parameters other than the defaults for specific messages, then when you submit the message to NowSMS include URL parameters to override the defaults (e.g., “&SMPPOption_mblox_tariff=00000&ServiceType=123”).

For comments and further discussion, please click here to visit the NowSMS Technical Forums (Discussion Board)...

7 Responses to “mBlox and NowSMS: Premium Rate SMS and OPPC”

  1. Anonymous says:

    where should i put the SMPPoptions section?? in the smsgw.ini file. at the beginning or in any selected section.

    also while receiing an MO message should i change anything in my http application?
    should i add the mbolx parameters to this http??

  2. Bryce Norwood says:


    The [SMPPOptions] section can go anywhere in the SMSGW.INI file.

    Any text that is surrounded by “[” and “]” characters is considered to be a section header.

    So [SMPPOptions] becomes its own section.


  3. Dear Bryce,

    i applied all the Mblox paramters to the SMSGW.ini file.
    but i’m still facing one problem, whatever i set the value of the parameter user_message_reference it is received from their side as special character: user_message_reference=^@^@

    do you have any idea about this issue??

  4. Dear Bryce,

    i still have one problem with the MBLOX paramters. when i’m sending an MT from my side, MBLOX is receiving the following value:
    user_message_reference=^@^@ although the value is set to 0 in the SMSGW.ini.
    do you have any idea about this issue?

  5. Bryce Norwood says:

    For follow-up comments, I would suggest posting on our discussion board @ https://nowsms.com/messages.

    user_message_reference is defined in the SMPP specification as a 2 byte binary integer. So a value of 0 would be encoded as 00 00 in hex.

    00 is considered to be the “@” character in the GSM character set.

    It sounds like they might be expecting the user_message_reference value to be in text instead of as a binary integer.

    It’s also possible that the person you are speaking to at the provider doesn’t know what they are talking about when they are interpreting the logs on their end.

    (We once had a tech representative from that company arguing with one of our customers that the reason they were having problems sending binary messages was because they were submitting the binary data in upper case, but they should be using lower case. Of course, the data was binary … there was no upper or lower case, it was just a matter of how the software you used to read the data capture presented the information to you.)

    For more follow-up, head over to the discussion board.


  6. Dear Bryce,

    i know that i should post my messages in the forum but because it's an urgent question.

    i'm sending this http request to the nowsms:

    so the SMPPOption_user_message_reference is blank but they still receive @^@^.

    any idea??

    how can i debug my request in the nowsms??

  7. Bryce Norwood says:

    user_message_reference is an integer field. If it is present in the request, but blank, then NowSMS is going to encode it with an integer value of 0.

    If you leave the parameter out of the URL request, then it will not be included in the SMPP submission.

    To troubleshoot this further, we would need to see an SMPPDEBUG.LOG (which is enabled when you enable the SMSDEBUG.LOG).

    However, I expect that we are going to see proper integer encoding of this parameter in that SMPPDEBUG.LOG.

    I can only guess that mBlox does not support user_message_reference encoded in the way defined by the SMPP standard. (We have experience submitting the other parameters to them … as you can see in the original post, the only information that we have from them about the user_message_reference parameter is a suggestion in one of the FAQs that this parameter can be used.)

    The SMPP specification defined user_message_reference as tag 0x204 with a 2 byte integer encoding.

    If they are interpreting this value as “@” characters, then this suggests that they do are not expecting integer encoding, but are instead expecting some type of string encoding.

    I suggest you ask them how the user_message_reference value should be encoded. You are using a 2 byte integer format, as defined by the SMPP 3.4 specification.

    If you want to post debug logs for further interpretation/explanation, they are better posted in the discussion forum.