You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 44.199.0.0/16 has been blocked (disabled) by ‪Blablubbs‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider or colocation provider. To prevent abuse, web hosts and colocation providers may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host or colocation provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a colocation provider's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a colocation web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host or colocation provider (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host or colocation provider.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and requests should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 12:56, 12 May 2024.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪AntiCompositeNumber‬. The reason given is Open proxy/Webhost: Visit the FAQ if you are affected .
- Start of block: 13:55, 18 August 2022
- Expiry of block: 13:55, 18 May 2025
Your current IP address is 44.199.189.47. The blocked range is 44.199.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((Short description|Protocol for transferring short messages))
((More footnotes needed|date=November 2018))

'''Short Message Peer-to-Peer''' ('''SMPP''') in the telecommunications industry is an open, industry standard protocol designed to provide a flexible data communication interface for the transfer of [[short message service|short message]]<ref>[http://www.3gpp.org/ftp/Specs/html-info/0340.htm "GSM 03.40 Technical realization of the Short Message Service (SMS)"], ''3GPP'', 2003-12-03</ref> data between [[External Short Messaging Entity|External Short Messaging Entities]] (ESMEs), Routing Entities (REs) and [[Short Message service center|SMSC]].<ref name="smpp50">((cite web| url = http://docs.nimta.com/smppv50.pdf| title = Short Message Peer-to-Peer Protocol Specification v5.0))</ref>

SMPP is often used to allow third parties (e.g. [[value-added service provider]]s like news organizations) to submit messages, often in bulk, but it may be used for SMS peering as well. SMPP is able to carry [[Short Message Service|short messages]] including [[Enhanced Messaging Service|EMS]], [[voicemail]] notifications, [[Cell Broadcast]]s, [[Wireless Application Protocol|WAP]] messages including [[Wireless Application Protocol#WAP Push|WAP Push]] messages (used to deliver [[Multimedia Message Service|MMS]] notifications), [[Unstructured Supplementary Service Data|USSD]] messages and others. Because of its versatility and support for non-[[GSM]] SMS protocols, like [[UMTS]], [[IS-95]] (CDMA), [[CDMA2000]], [[IS-136|ANSI-136]] (TDMA) and [[iDEN]], SMPP is the most commonly used protocol for short message exchange outside [[Signalling System No. 7|SS7]] networks.

==History==
((More citations needed section|date=December 2023))

SMPP (Short Message Peer-to-Peer) was originally designed by [[Aldiscon]], a small [[Ireland|Irish]] company that was later acquired by [[Logica]] (since 2016, after a number of changes [[Mavenir]]).  The protocol was originally created by a developer, Ian J Chambers, to test the functionality of the [[short message service center|SMSC]] without using SS7 test equipment to submit messages.

In 1995 the [[ETSI]] included the SMPP protocol into the technical report TR 03.39.<ref>((cite book |author=Friedhelm Hillebrand |url=https://books.google.com/books?id=YPgfNaoYHUsC |title=Short Message Service (SMS): The Creation of Personal Global Text Messaging |publisher=[[Wiley (publisher)|Wiley]] |year=2010 |isbn=978-0-470-68865-6 |page=112))</ref>

In 1999 Logica formally handed over SMPP to the SMPP Developers Forum, later renamed as The SMS Forum.

The SMS Forum disbanded in 2007, with this announcement: "The SMS Forum, a non-profit organization with a mission to develop, foster and promote SMS (short message service) to the benefit of the global wireless industry will disband by July 27, 2007."<ref>((Cite web |date= |title=SMS Forum Homepage |url=http://smsforum.net/ |url-status=dead |archive-url=https://web.archive.org/web/20071222221600/http://smsforum.net/ |archive-date=2007-12-22 |access-date= |website=smsforum.net))</ref>  As part of the original handover terms, SMPP ownership returned to Mavenir.

==Operation==

SMPP uses the [[client–server model]] of operation, despite "peer-to-peer" in the name. The [[short message service center|Short Message Service Center (SMSC)]] usually acts as a server, awaiting connections from ESMEs. When SMPP is used for SMS peering, the sending MC usually acts as a client.

The protocol is based on pairs of request/response PDUs ([[protocol data unit]]s, or packets) exchanged over [[Open Systems Interconnection|OSI]] layer 4 ([[Transmission Control Protocol|TCP]] session or [[X.25]] SVC3) connections.<ref>((cite book
 |author=Neil Croft
 |title=2012 Information Security for South Africa
 |chapter=On forensics: A silent SMS attack
 |chapter-url=https://ieeexplore.ieee.org/document/6320454
 |publisher=[[IEEE]]
 |year=2012
 |pages=1–4
 |issn=2330-9881
 |doi=10.1109/ISSA.2012.6320454|isbn=978-1-4673-2159-4
 |s2cid=13448347
 ))</ref> The [[well-known port]] assigned by the [[Internet Assigned Numbers Authority|IANA]] for SMPP when operating over [[Transmission Control Protocol|TCP]] is 2775, but multiple arbitrary port numbers are often used in messaging environments.

Before exchanging any messages, a bind command must be sent and acknowledged. The bind command determines in which direction will be possible to send messages; bind_transmitter only allows client to submit messages to the server, bind_receiver means that the client will only receive the messages, and bind_transceiver (introduced in SMPP 3.4) allows message transfer in both directions.<ref>((cite book|url=https://books.google.com/books?id=P0xs_9NSIy8C|pages=137–138|title=SMS and MMS Interworking in Mobile Networks|author1=A. Henry-Labordère|author2=Vincent Jonack|publisher=[[Artech House]]|year=2004|isbn=1-58053-890-8))</ref> In the bind command the ESME identifies itself using system_id, system_type and password; the address_range field designed to contain ESME address is usually left empty. The bind command contains interface_version parameter to specify which version of SMPP protocol will be used.

Message exchange may be synchronous, where each peer waits for a response for each PDU being sent, or asynchronous, where multiple requests can be issued without waiting and acknowledged in a skew order by the other peer; the number of unacknowledged requests is called a ''window''; for the best performance both communicating sides must be configured with the same window size.

===Versions===

The SMPP standard has evolved during the time. The most commonly used versions of SMPP are:

* SMPP 3.3 the oldest used version (despite its limitations, it is still widely used); supports [[GSM]] only. Generates an immediate response for each message sent.
* SMPP 3.4 adds optional [[tag–length–value]] (TLV) parameters, support of non-GSM SMS technologies and the [[transceiver]] support (single connections that can send and receive messages). The exchange of SMPP request and response PDUs between an ESME Transmitter and SMSC may occur synchronously or asynchronously.
* SMPP 5.0 is the latest version of SMPP; adds support for cell broadcasting, smart flow control. ((As of|2023)), it is not widely used.

The applicable version is passed in the interface_version parameter of a bind command.

==PDU format (after version 3.4)==

The SMPP PDUs are [[Binary protocol|binary encoded]] for efficiency. They start with a header which may be followed by a body:

{| class="wikitable" style="text-align:center"
|- 
| style="background: black; color: white; font-weight: bold" colspan="5" | SMPP PDU
|-
| colspan="4" | PDU Header (mandatory)
| PDU Body (Optional)
|-
| Command <br/> length || Command <br/> Id || Command <br/> Status || Sequence <br/> Number || PDU Body
|- 
| 4 octets
|  colspan="4" | Length = (Command Length value - 4) octets
|}

===PDU header===

Each PDU starts with a header. The header consists of 4 fields, each of length of 4 octets:

;<code>command_length</code>: Is the overall length of the PDU in octets (including command_length field itself); must be ≥ 16 as each PDU must contain the 16 octet header
;<code>command_id</code>: Identifies the SMPP operation (or command). If the most significant bit is cleared, this is a request operation. Otherwise it is a response.
;<code>command_status</code>: Always has a value of 0 in requests; in responses it carries information about the result of the operation
;<code>sequence_number</code>: Is used to correlate requests and responses within an SMPP session; allows asynchronous communication (using a [[Sliding window protocol|sliding window]] method)

All numeric fields in SMPP use the [[big endian]] order, which means that the first octet is the Most Significant Byte (MSB).

==Example==
This is an example of the binary encoding of a 60-octet ''submit_sm'' PDU. The data is shown in Hex [[Octet (computing)|octet]] values as a single dump and followed by a header and body break-down of that PDU.

This is best compared with the definition of the submit_sm PDU from the SMPP specification in order to understand how the encoding matches the field by field definition.

The value break-downs are shown with decimal in parentheses and Hex values after that. Where you see one or several hex octets appended, this is because the given field size uses 1 or more octets encoding.

Again, reading the definition of the submit_sm PDU from the spec will make all this clearer.

===PDU header===
 'command_length', (60) ... 00 00 00 3C
 'command_id',      (4) ... 00 00 00 04
 'command_status',  (0) ... 00 00 00 00
 'sequence_number', (5) ... 00 00 00 05

===PDU body===
 'service_type',                 () ... 00
 'source_addr_ton',             (2) ... 02
 'source_addr_[[Numbering plan|npi]]',             (8) ... 08
 'source_addr',               (555) ... 35 35 35 00
 'dest_addr_ton',               (1) ... 01
 'dest_addr_[[Numbering plan|npi]]',               (1) ... 01
 'dest_addr',           (555555555) ... 35 35 35 35 35 35 35 35 35 00
 'esm_class',                   (0) ... 00
 'protocol_id',                 (0) ... 00
 'priority_flag',               (0) ... 00
 'schedule_delivery_time',      (0) ... 00
 'validity_period',             (0) ... 00
 'registered_delivery',         (0) ... 00
 'replace_if_present_flag',     (0) ... 00
 'data_coding',                 (3) ... 03
 'sm_default_msg_id',           (0) ... 00
 'sm_length',                  (15) ... 0F
 'short_message', (Hello Wikipedia) ... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

Note that the text in the short_message field must match the data_coding. When the data_coding is 8 (UCS2), the text must be in UCS-2BE (or its extension, [[UTF-16|UTF-16BE]]). When the data_coding indicates a 7-bit encoding, each septet is stored in a separate octet in the short_message field (with the most significant bit set to 0). SMPP 3.3 data_coding exactly copied TP-DCS values of [[Data Coding Scheme|GSM 03.38]], which make it suitable only for GSM 7-bit default alphabet, UCS2 or binary messages; SMPP 3.4 introduced a new list of data_coding values:

{| class="wikitable"
! <code>data_coding</code> !! Meaning
|-
| style="text-align:center" | 0 || SMSC Default Alphabet (SMPP 3.4) / MC Specific (SMPP 5.0)
|-
| style="text-align:center" | 1 || IA5 ([[ITU T.50|CCITT T.50]])/[[ASCII]] (ANSI X3.4)
|-
| style="text-align:center" | 2 || Octet unspecified (8-bit binary)
|-
| style="text-align:center" | 3 || Latin 1 ([[ISO-8859-1]])
|-
| style="text-align:center" | 4 || Octet unspecified (8-bit binary)
|-
| style="text-align:center" | 5 || JIS ([[JIS X 0208|X 0208-1990]])
|-
| style="text-align:center" | 6 || Cyrillic ([[ISO-8859-5]])
|-
| style="text-align:center" | 7 || Latin/Hebrew ([[ISO-8859-8]])
|-
| style="text-align:center" | 8 || UCS2 ([[Universal Coded Character Set|ISO/IEC-10646]])
|-
| style="text-align:center" | 9 || Pictogram Encoding
|-
| style="text-align:center" | 10 || [[ISO-2022-JP]] (Music Codes)
|-
| style="text-align:center" | 11 || Reserved
|-
| style="text-align:center" | 12 || Reserved
|-
| style="text-align:center" | 13 || Extended Kanji JIS (X 0212–1990)
|-
| style="text-align:center" | 14 || [[KS C 5601]]
|-
| style="text-align:center" | 15-191 || reserved
|-
| style="text-align:center" | 192-207 || GSM MWI control - see [[Data Coding Scheme|GSM 03.38]]
|-
| style="text-align:center" | 208-223 || GSM MWI control - see [[Data Coding Scheme|GSM 03.38]]
|-
| style="text-align:center" | 224-239 || reserved
|-
| style="text-align:center" | 240-255 || GSM message class control - see [[Data Coding Scheme|GSM 03.38]]
|}

The meaning of the <code>data_coding=4</code> or <code>8</code> is the same as in SMPP 3.3. Other values in the range 1-15 are reserved in SMPP 3.3. Unfortunately, unlike SMPP 3.3, where data_coding=0 was unambiguously GSM 7-bit default alphabet, for SMPP 3.4 and higher the GSM 7-bit default alphabet is missing in this list, and <code>data_coding=0</code> may differ for various [[Short message service center]]s—it may be [[ISO-8859-1]], [[ASCII]], GSM 7-bit default alphabet, [[UTF-8]] or even configurable per ESME. When using <code>data_coding=0</code>, both sides (ESME and SMSC) must be sure they consider it the same encoding. Otherwise it is better not to use <code>data_coding=0</code>. It may be tricky to use the GSM 7-bit default alphabet, some [[Short message service center]]s requires <code>data_coding=0</code>, others e.g. <code>data_coding=241</code>.

== Quirks ==

Despite its wide acceptance, the SMPP has a number of problematic features:

* No <code>data_coding</code> for GSM 7-bit default alphabet
* Not standardized meaning of <code>data_coding=0</code>
* Unclear support for Shift-JIS encoding
* Incompatibility of <code>submit_sm_resp</code> between SMPP versions
* Using of SMPP 3.3 SMSC Delivery Receipts, especially the Message Id format in them

=== No data_coding for GSM 7-bit default alphabet ===

Although data_coding value in SMPP 3.3 are based on the [[GSM 03.38]], since SMPP 3.4 there is no data_coding value for GSM 7-bit alphabet ([[GSM 03.38]]).  However, it is common for DCS=0 to indicate the GSM 7-bit alphabet, particularly for SMPP connections to SMSCs on GSM mobile networks. It is further ambiguous whether the 7-bit alphabet is packed, as in GSM, allowing sending 160 characters in 140 octets, or whether the each 7-bit character takes up an entire octet (with the high bit set to zero, as with ASCII).

=== Not standardized meaning of data_coding=0 ===

According to SMPP 3.4 and 5.0 the <code>data_coding=0</code> means ″SMSC Default Alphabet″. Which encoding it really is, depends on the type of the SMSC and its configuration.

=== Unclear support for Shift-JIS encoding ===

One of the encodings in CDMA standard C.R1001 is [[Shift-JIS]] used for Japanese. SMPP 3.4 and 5.0 specifies three encodings for Japanese (JIS, ISO-2022-JP and Extended Kanji JIS), but none of them is identical with CDMA MSG_ENCODING 00101. It seems that the Pictogram encoding (data_coding=9) is used to carry the messages in Shift-JIS in SMPP.

=== Incompatibility of submit_sm_resp between SMPP versions ===

When a submit_sm fails, the SMSC returns a <code>submit_sm_resp</code> with non-zero value of command_status and ″empty″ message_id.

* SMPP 3.3 explicitly states about the <code>message_id field</code> ″If absent this field must contain a single NULL byte″. The length of the PDU is at least 17 octets.
* SMPP 3.4 contains an unfortunate note in the <code>SUBMIT_SM_RESP</code> section ″The <code>submit_sm_resp</code> PDU Body is not returned if the <code>command_status</code> field contains a non-zero value.″ Then the length of the PDU is 16 octets.
* SMPP 5.0 just specifies that <code>message_id</code> is a mandatory parameter of the type C-Octet string of the <code>submit_sm_resp</code> message. According to the section 3.1.1 NULL Settings, ″A NULL string ″″ is encoded as 0x00″. The length of the PDU is at least 17 octets.

For the best compatibility, any SMPP implementation should accept both variants of negative <code>submit_sm_resp</code> regardless of the version of SMPP standard used for the communication.

((Blockquote
|text=The original intention of error scenarios was that no body would be returned in the PDU response. This was the standard behavior exhibited on all Aldiscon/Logica SMSC and also in most of the other vendors. When SMPP 3.4 was being taken on by the WAP forum, several clarifications were requested on whether a body should be included with NACKed response and measures were taken to clarify this in several places in the specification including the <code>submit_sm</code> section and also in the <code>bind_transceiver</code> section. What should have been done was to add the clarification that we eventually added in V5.0.. that bodies are not supposed to be included in error responses. Some vendors have been very silly in their implementations including bodies on rejected <code>bind_transmitter</code> responses but not on <code>bind_transceiver</code> responses etc. The recommendation I would make to vendors.. as suggested above.. accept both variants. But its also wise to allow yourself issue NACKed <code>submit_sm_resp</code> and <code>deliver_sm_resp</code> PDUs with and without an empty body. In the case of these two PDUs, that empty body will look like a single NULL octet at the end of the stream. The reason you may need this ability to include what I call dummy bodies with NACKed requests is that the other side of the equation may be unable or unwilling to change their implementation to tolerate the missing body. (I worked on three versions of SMPP specification in Aldiscon/Logica and designed the ESME solution for Openmind Networks)
|author=Cormac Long ((Quote without source|date=December 2023))))

=== Message ID in SMPP 3.3 SMSC Delivery Receipts ===

The only way to pass delivery receipts in SMPP 3.3 is to put information in a text form to the <code>short_message</code> field; however, the format of the text is described in Appendix B of SMPP 3.4, although SMPP 3.4 may (and should) use <code>receipted_message_id</code> and <code>message_state</code> TLVs for the purpose. While SMPP 3.3 states that Message ID is a C-Octet String (Hex) of up to 8 characters (plus terminating '\0'), the SMPP 3.4 specification states that the id field in the Delivery Receipt Format is a C-Octet String (Decimal) of up to 10 characters. This splits SMPP implementations to 2 groups:

* Implementations using the decimal representation of an integer Message Id in the id field of the Delivery Receipt body and the hexadecimal representation of an integer Message Id in <code>message_id</code> and <code>receipted_message_id</code> fields
* Implementations using the same hexadecimal number (or even the same arbitrary string) both in <code>message_id</code> parameter and in the id field of the Delivery Receipt body

The SMPP 3.4 specification does however state that the delivery receipt format is SMSC vendor specific, and therefore the format included in the specification is merely one possibility. As noted above, when using SMPP 3.4 <code>receipted_message_id</code> and <code>message_state</code> TLVs should be used to convey the outcome of a message.

== Extensibility, compatibility and interoperability ==

Since introduction of TLV parameters in version 3.4, the SMPP may be regarded an [[Extensibility|extensible]] protocol. In order to achieve the highest possible degree of compatibility and [[interoperability]] any implementation should apply the Internet [[robustness principle]]: ″Be conservative in what you send, be liberal in what you accept″. It should use a minimal set of features which are necessary to accomplish a task. And if the goal is communication and not quibbling, each implementation should overcome minor nonconformities with standard:

* Respond with a <code>generic_nack</code> with <code>command_status=3</code> to any unrecognised SMPP command, but do not stop the communication.
* Ignore any unrecognised, unexpected or unsupported TLV parameters.
* The borders of PDUs are always given by the PDUs' <code>command_length</code> field. Any message field must not exceed the end of PDU. If a field is not properly finished, it should be treated as truncated at the end of PDU, and it should not affect further PDUs.

Information applicable to one version of SMPP can often be found in another version of SMPP, for example with the case of SMPP 3.4 describing the only mechanism of delivery receipts in SMPP 3.3 described above.

== Security ==
The SMPP protocol is designed on a clear-text binary protocol which needs to be considered if using for potentially sensitive information such as one-time passwords via SMS. There are, however, implementations of SMPP over SSL/TLS if required.<ref>[http://www.academic-pub.org/ojs/index.php/ijecs/article/viewFile/1013/125 "Secure Short Message Peer-to-Peer Protocol"], International Journal of Electronic Commerce Studies, 2012</ref>

==See also==
* [[EMI (protocol)|Universal Computer Protocol/External Machine Interface (UCP/EMI)]]
* [[CIMD|Computer Interface for Message Distribution (CIMD)]]
* [[Rich Communication Services]]

==References==
((Reflist))

==External links==
*[https://smpp.org/SMPP_v3_3.pdf Short Message Peer-to-Peer Protocol Specification v3.3]
*[https://smpp.org/SMPP_v3_4_Issue1_2.pdf Short Message Peer-to-Peer Protocol Specification v3.4]
*[https://smpp.org/smppv50.pdf Short Message Peer-to-Peer Protocol Specification v5.0]
*[https://smpp.org/smppv34_gsmumts_ig_v10.pdf SMPP v3.4 Protocol Implementation guide for GSM / UMTS]
*[https://smpp.org/SMPP_WAP_Implementation_Guide.pdf SMPP v3.4 Implementation Guide for WAP]
*[https://github.com/opentelecoms-org/jsmpp SMPP implemented in Java]
*[https://gitlab.com/wireshark/wireshark/-/wikis/SMPP SMPP Wireshark]

((DEFAULTSORT:Short Message Peer-To-Peer Protocol))
[[Category:GSM standard]]
[[Category:Mobile technology]]
[[Category:Network protocols]]

Pages transcluded onto the current version of this page (help):

Short Message Peer-to-Peer (edit)
Template:Ambox (view source) (template editor protected)
Template:As of (view source) (template editor protected)
Template:Blockquote (view source) (template editor protected)
Template:Blockquote/styles.css (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Cite book (view source) (protected)
Template:Cite web (view source) (protected)
Template:Comma separated entries (view source) (template editor protected)
Template:DMCA (view source) (template editor protected)
Template:Dated maintenance category (view source) (template editor protected)
Template:Dated maintenance category (articles) (view source) (template editor protected)
Template:Delink (view source) (protected)
Template:FULLROOTPAGENAME (view source) (template editor protected)
Template:Fix (view source) (protected)
Template:Fix/category (view source) (protected)
Template:If empty (view source) (protected)
Template:Main other (view source) (protected)
Template:More citations needed (view source) (template editor protected)
Template:More citations needed section (view source) (template editor protected)
Template:More footnotes needed (view source) (template editor protected)
Template:Ns has subpages (view source) (protected)
Template:Pagetype (view source) (protected)
Template:Quote without source (view source) (semi-protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Sp (view source) (template editor protected)
Template:Yesno (view source) (protected)
Template:Yesno-no (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:If empty (view source) (protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Ns has subpages (view source) (protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:Separated entries (view source) (protected)
Module:String (view source) (protected)
Module:TableTools (view source) (protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Short Message Peer-to-Peer.

Retrieved from "https://en.wikipedia.org/wiki/Short_Message_Peer-to-Peer"