Proposal for "Net_SMPP"

» Metadata » Status
  • Category: Networking
  • Proposer: Ian Eure 
  • License: PHP v3.0
» Description
Net_SMPP is a basic implementation of the SMPP (Short Message Peer-to-Peer) protocol. This protocol is used in the wireless industry for exchanging SMS messages.

This only implements portions of the base protocol, and does not include a client or server. It's not intended to be directly used by end-users, but by package developers writing SMPP ESMEs or SMSCs. I have written a client, Net_SMPP_Client, which i have proposed as well.

I have also written a SMPP driver for Net_SMS, which I have sent to the package maintainers for inclusion. People wishing to send SMS messages via SMPP should use one of those packages to do so.


  1. Supports SMPP v3.4
  2. Supports vendor protocol extensions.
  3. Automagic PDU sequence generation.
  4. Each SMPP command is contained in a separate class.
  5. Currently supported commands: bind_transmitter, bind_transmitter_resp, submit_sm, submit_sm_resp, unbind, unbind_resp, generic_nack. The SMPP protocol defines many more commands, but this is enough to send SMS messages with. The other commands can be added without much difficulty.
  6. Can generate binary PDU data from the command classes, as well as parse that raw data into the correct classes.
  7. Documented with PHPDoc.

Package Structure

This is the main class, and what developers will interact with to get instances of the individual command classes. It's used statically.

This class handles parsing and generation of the PDU header, functions and data which operate on the header portion of the PDU, and other functions common to this data.

This class extends Net_SMPP_PDU, and contains higher-level PDU functions and data. It contains constants for PDU parameters which are shared among multiple PDUs; for example, the data_coding parameter is present in both the submit_sm and data_sm PDUs. It also handles generation and parsing of the headers needed for optional parameters.

These classes contain the parameter definitions and PDU-specific data for a single PDU. These classes also contain variables for each parameter which may be set in the PDU.

This class contains code for loading and working with vendor extensions to the SMPP protocol. Specific vendor implementations must extend this class.

These classes contain the vendor-specific data necessary for a vendor extension to work.

These classes extend the Net_SMPP_Command_* classes, and have additional vendor parameters or vendor changes from the plain SMPP PDUs. For example, Net_SMPP_Vendor_mBlox_Command_submit_sm contains the mBlox PSMS extensions to the submit_sm SMPP command.

There are quite a few files in this package, so I'm only extracting the most important. Please look at the PEAR package to get a better idea of what's included.

Because Net_SMPP is written to conform to the SMPP v3.4 specification, there is one place where it doesn't fully adhere to PEAR CS for url=]Naming Conventions. SMPP commands are specified with underscores in the specification, and the classes and filenames follow this standard. For example, the "submit_sm" command is in the Net_SMPP_Command_submit_sm class, which is in Net/SMPP/Command/submit_sm.php.

I believe this is acceptable; other packages, such as PHP_Compat, do this same thing for the same reasons. Other people disagree. There was a long thread on pear-dev about this, with no resolution reached.

If you feel that this is a problem, please make your vote conditional, and note that this is the reason in your vote comment.
» Dependencies » Links
» Timeline » Changelog
  • First Draft: 2005-04-21
  • Proposal: 2005-04-21
  • Call for Votes: 2005-08-03
  • Ian Eure
    [2005-04-25 19:35 UTC]

    - Upload new package version.
    - Update file locations.
    - Update description to better reflect the intent of this package, and link to the Net_SMPP_Client proposal.

    This version should address most of the negative comments received so far. Globals are replaced with static vars in class methods. The vendor extensions are heavily reworked to reflect this, and vendor extensions are stored in vendor classes, instead of being largely procedural.

    The only remaining issue has to do with vendor extensions. When a vendor is loaded, it sets a static var and alters the command list, status descriptions, and optional parameters. This could potentially be an issue if you want to send SMPP through multiple vendors in a single script run. I don't think it's a huge deal, since:

    a- So far as I know, this is not a common practice.
    b- Vendor extensions should be a superset of the existing SMPP functionality, and there should be no difference unless the actual extensions are used. E.g. the data generated from a plain submit_sm is identical to that generated from a mBlox submit_sm so long as the mBlox extensions aren't used. Additionally, SMPP systems should ignore optional parameters they don't understand, so it would likely work even if there was a difference, or a vendor-specific parameter was set on accident.

    Comments on this scenario are welcome.
  • Ian Eure
    [2005-06-02 19:09 UTC]

    Updated package URLs to the new version of Net_SMPP. Code has been changed to remove the one-vendor restriction, which was mentioned as being a problem. Also, some bugs were fixed and some PDUs were added.

    Would everyone who had issues with the previous code please look this over and make sure it's acceptable?
  • Ian Eure
    [2005-08-03 17:57 UTC]

    Updated link to point to v0.4.2.
    Added "Issues" section.