Smpp V 3.4

[Frida Kosofsky]

We're about to begin a project which requires the use of SMPP as the primary integration exchange channel. Now since SMS isn't necessarily core to our business, I'd like to use an SMPP library for Java that will be the least hassle. Aside from riding on the actual protocol, its unlikely we'll need fancier abilities or to ever tweak under the hood.

Both the libraries fared well, and IMO jSMPP is more user-friendly to jump in and start coding right away. But I had came across a few bugs while using the latest version from GitHub, which still remain unfixed.

Apache Camel: We started off using this but there were some limitations to their library (we needed to insert custom heads to our SMPP packets). To be fair they were fairly prompt in responding to issues on their forums but their build cycles took a little too long for my sprints, so we scratched this.

JSMPP: This is the one we ended up using. Was pretty straightforward overall tho it did feel like it expected you to already have a fairly good idea of SMPP in general. Things are in staging so I can't tell you how it performs under production load. Will update when it goes live.

Cloudhopper: To be honest this was the one I was keen to use but more because like any geek I wanted to jump on the shiniest newest toy available. I didn't really get adequate responses to any queries we made from the off so was apprehensive to get on board. No reason to adopt a library that will require me to wade thru their codes when other more documented options were available.

It is very efficient as long as you stick to the asynchronous mode. If you need to keep a correlation between the message and its response use the "sequence number" that is both in the message and the response.

Our SMSC was written on Logica SMPP (v 1.3), it still works really well with enterprise loadings. There has been only a few small issues regarding the library mainly with message_payload, honestly I don't remember other issues. But it's easy to repair because it's an opensource product.

The blocking nature of jsmpp become source of big problems when the SMPP server I was connecting to were experiencing some performance problems and responded slower than usual. Suddenly I found all of my threads to be waiting for responses. Migration to smppapi solved the problems obviously.

I've used Logica SMPP for a production project. It's not actively maintained anymore and there are a few inherent bugs which resulted in having to produce workarounds or actually forking the codebase to fix. Having said that, I've found the API to be very stable and performant (300msg/s).

Just came across Cloudhopper SMPP which seems to be coded in a more up to date style but again it needs more examples. Having to chore through the code base is not attractive. Examples on gituhub are getting better though.

Cloudhopper is the best choice, Apache's Camel is also good but it's a very big project that has many interfaces to pdf, salesforce.... that you don't need.Other project is not updated to date. Cloudhopper is maintaining by Telestax and they add some useful features and look like they will give strong support it in future

presently I am using JSMPP and i found it's okay so far. Cloudhopper seems easier of the lot but i ended up with JSMPP and also found out that JSMPP is also at the heart of Apache camel implementation i might be wrong though.

SMPP is an open, industry standard protocol (see definition at Wikipedia) designed to simplify interconnections between various entities. SMPP also enables sending and receiving of short text messages (SMS) over the internet.

Connecting to Telesign using the SMPP protocol requires a thorough understanding of SMPP. To learn more before reading further about the specifics of Telesign SMPP integration, visit smpp.org. There you can also find reference documents for v3.4 and v5.0 of the specification (the versions that Telesign supports).

You can either reset the SMPP password yourself in TelePortal, or ask your Client Services representative to do so for you. Once the password is reset, the old password becomes obsolete, but only after a defined expiration window has elapsed.

If you are doing the reset yourself, select one of these options in TelePortal when you reset the password. If CS is doing the reset for you, let them know which expiration window you want to be applied.

Before using a sender ID as a source address, send that sender ID to Telesign so it can be whitelisted. Once the sender ID has been whitelisted (if it is supported for the destination), set it in the submit_sm PDU command by using the source address in each request. The source address is comprised of the source_addr_ton, source_addr_npi, and source_addr fields.

Because each destination address is usually represented in full international format, set the destination TON value (dest_addr_ton) in the submit_sm PDU command to 1 (for International) and the destination NPI value (dest_addr_npi) to 1 (for ISDN E163/E164). The destination address consists of those two fields as well as the dest_addr field.

SMPP supports several data coding schemes (DCSs); indicate your chosen DCS using the data_coding parameter. DCSs supported by Telesign and their corresponding parameter values are indicated below.
The default value is 0.

The Telesign MC can provide delivery reports (DLRs) in response to a client request. To check the status of each message sent, set registered_delivery in the submit_sm packet to one of the following values:

Telesign routes DLRs based on system ID by default. So if you are connecting to Telesign via SMPP from multiple data centers, DLRs are sent randomly to any of your connected data centers. If you want responses to be sent to the exact same data center that sent the request, include the system_type parameter in each submit_sm request to specify the data center the response should be routed back to. Contact our Customer Support Team to get a list of values you can use for system_type if you want to enable this type of routing.

Short message user data is the content of the SMS that you want the recipient to see. User data should be inserted in either the short_message parameter or the message_payload TLV. Use short_message to send a short message of up to 255 octets in size, including user data. Use message_payload to send messages longer than 255 octets; in this case, the sm_length field should be set to 0. Both fields should not be used simultaneously. If both fields are used, Telesign MC ignores the short_message parameter and uses only message_payload.

For each short message sent by the client, Telesign generates a reference ID. This is a 32-digit hex value used to identify the original message request. This value is unique for each submit_sm request and is randomly generated by Telesign.
Telesign returns the reference ID in the message_id parameter of the submit_sm_resp PDU command immediately following the original request. Using the reference ID, the client can identify and track each request sent to Telesign MC.

You can also consume MO (Mobile Originating) messages over SMPP. Telesign delivers these messages using the deliver_sm PDU and the short_message parameter. For inbound SMS to work, it must be enabled by our Customer Support Team.

Contains the mobile country code (MCC) for the destination phone number. Available in the deliver_sm PDU used for sending DLRs. To use this tag, ask our Customer Support Team to turn on the associated feature.

Contains the mobile network code (MNC) for the destination phone number. Available in the deliver_sm PDU used for sending DLRs. To use this tag, ask our Customer Support Team to turn on the associated feature.

Telesign provides error information as part of the command_status and error_status_code parameters. Telesign supports both a complete set of SMPP-defined error codes as well as some Telesign-specific error codes.

This module offers interoperability between SIP and SMPP(Short Message Peer-to-Peer) protocols. It provides themeans to build a messaging gateway/bridge between the twoprotocols, being able to convert messages from both directions.

In order to convert a SIP message to a SMPP all you need to dois to call the send_smpp_message() function,indicating the SMSc you want to send the message to. The modulewill build the PDU according to the parameters provisionedin the database.

In order to be able to deliver messages to SMSc, an ESME needs tofirst bind to the SMSc. This is done at OpenSIPS startup by sendinga SMPP bind_transciever command to connectto the SMSc, or an outbind command to informan SMSc it can now bind to our gateway.

Destination Number Plan Indicator (NPI) -Specifies the numbering scheme of the number used to send messages to. Can havethe same values as Source Number Plan Indicator (NPI)and default value is 0 - Unknown.

The maximum number of chunks in which a SMPP message is expected toarrive via TCP. If a received packet is more fragmented than this,the connection is dropped (either the connection is veryoverloaded and this leads to high fragmentation - or we are thevictim of an ongoing attack where the attacker is sending veryfragmented traffic in order to decrease server performance).

This function is used to convert a SIP message received in theOpenSIPS script to a SMPP PDU and send it to thesmsc_name (string) received as parameter.The SMPP parameters used to construct the PDU are provisionein the database, and the command sent is eithersubmit_sm or deliver_sm,depending on the type of the SMSc.

(2) including any documentation-related commits, excluding merge commits. Regarding imported patches/code, we do our best to count the work on behalf of the proper owner, as per the "fix_authors" and "mod_renames" arrays in opensips/doc/build-contrib.sh. If you identify any patches/commits which do not get properly attributed to you, please submit a pull request which extends "fix_authors" and/or "mod_renames".

SMPP v5.0, by design, is backward compatible with v3.4, so you would be able touse this module with 3.4 implementations. Even you can use this module with 3.3implementations as far as you don't use TLV parameters and don't bind in transceiver mode.

c80f0f1006