| SMS Communications using SMPP |
The Short Message Peer to Peer (SMPP) protocol is an open, industry standard protocol used to send and receive short message data.
Using the SMPP protocol, Connect’s SMPP components initiate an application layer connection with a SMSC over a TCP/IP network connection to send and receive short messages.
Following are some benefits of SMPP:
Here are some new features and terminology introduced with SMPP:
Short Message Service (SMS): is a mechanism of delivery of short messages over the mobile networks. It is a store and forward way of transmitting messages to and from mobiles. The message (text only) from the sending mobile is stored in a central short message center (SMS) which then forwards it to the destination mobile. This means that in the case that the recipient is not available, the short message is stored and can be sent later. Each short message can be no longer than 160 characters.
Short Message Peer to Peer (SMPP): is a telecommunications industry protocol for exchanging SMS messages between SMS peer entities such as short message service centres (SMSC). It is designed to provide a flexible data communications interface for transfer of short message data between a Message Center and a SMS application system.
Short Message Service Center (SMSC): is a network element in the mobile telephone network which delivers SMS messages. When a user sends a text message (SMS message) to another user, the message get stored in the SMSC which delivers it to the destination user when they are available.
Tag, Length, Value (TLV): TLV’s are "Tag, Length, Value" parameters. It's a way on the SMPP protocol to pass special parameters to and from the SMSC.
Users: The term “users” refers to Connect Users.
The term SMSC or SMSC gateway is used throughout this document to describe any SMPP server.

The SMS Sender and SMS Receiver are singleton components that can be installed on the node outside the firewall. Connect has them as singleton components in this release because of the limitation imposed by the SMSCs on the number of binds that can be made by a client.
The components maintain a cache of servers and are updated whenever the user changes the SMSC configuration in the UI. The components communicate with the CM (ConversationManager) and other internal components via socket.