ショートメッセージピアツーピア

SMPP規格は、時間の経過とともに進化を遂げてきました。最も一般的に使用されているSMPPのバージョンは以下のとおりです。

• SMPP 3.3は最も古いバージョン（制限はあるものの、依然として広く使用されている）であり、GSMのみをサポートする。送信されたメッセージごとに即座に応答を生成する。
• SMPP 3.4では、オプションのタグ・長さ・値（TLV）パラメータ、非GSM SMS技術のサポート、およびトランシーバーサポート（メッセージの送受信が可能な単一接続）が追加されました。ESMEトランスミッターとSMSC間のSMPPリクエストおよびレスポンスPDUの交換は、同期または非同期で行われます。
• SMPP 5.0はSMPPの最新バージョンで、セルブロードキャストとスマートフロー制御のサポートが追加されています。2025年現在、広く使われているわけではない。

適用可能なバージョンは、bindコマンドのinterface_versionパラメータで渡されます。

各PDUはヘッダーで始まる。ヘッダーは4つのフィールドで構成され、各フィールドの長さは4オクテットである。

command_length

PDUの全体の長さ（コマンド長フィールド自体を含む）をオクテット単位で表したもので、16以上である必要があります。これは、各PDUに16オクテットのヘッダーが含まれている必要があるためです。

command_id

SMPP操作（またはコマンド）を識別します。最上位ビットがクリアされている場合は要求操作、そうでない場合は応答操作です。

command_status

リクエストでは常に値が0ですが、レスポンスでは操作の結果に関する情報が含まれます。

sequence_number

SMPPセッション内のリクエストとレスポンスを関連付けるために使用され、非同期通信（スライディングウィンドウ方式を使用）を可能にします。

SMPP のすべての数値フィールドはビッグエンディアン順序を使用します。つまり、最初のオクテットが最上位バイト (MSB) になります。

'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

'service_type', () ... 00 'source_addr_ton'、(2) ... 02 'source_addr_npi '、(8) ... 08 'source_addr'、(555) ... 35 35 35 00 'dest_addr_ton'、(1) ... 01 'dest_addr_npi '、(1) ... 01 'dest_addr', (555555555) ... 35 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', (こんにちは Wikipedia) ... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

short_message フィールドのテキストは data_coding と一致する必要があることに注意してください。data_coding が 8 (UCS2) の場合、テキストは UCS-2BE (またはその拡張であるUTF-16BE ) である必要があります。data_coding が 7 ビットのエンコーディングを示している場合、各セプテットは short_message フィールドの個別のオクテットに格納されます (最上位ビットは 0 に設定されます)。SMPP 3.3 の data_coding はGSM 03.38の TP-DCS 値を正確にコピーしたため、GSM 7 ビットのデフォルトアルファベット、UCS2、またはバイナリ メッセージにのみ適しています。SMPP 3.4 では、新しい data_coding 値のリストが導入されました。

data_coding=4またはの意味は8SMPP 3.3 と同じです。 1～15 の範囲の他の値は SMPP 3.3 で予約されています。 残念ながら、data_coding=0 が明確に GSM 7 ビットデフォルトアルファベットであった SMPP 3.3 とは異なり、SMPP 3.4 以降では、GSM 7 ビットデフォルトアルファベットはこのリストに含まれておらず、さまざまなショートメッセージサービスセンターdata_coding=0によって異なる場合があります。ISO -8859-1、ASCII、GSM 7 ビットデフォルトアルファベット、UTF-8、または ESME ごとに設定可能な場合もあります。 を使用する場合は、両側 (ESME と SMSC) が同じエンコーディングであることを確認する必要があります。そうでない場合は、 を使用しない方が良いでしょう。 GSM 7 ビットデフォルトアルファベットの使用は難しい場合があります。一部のショートメッセージサービスセンターではが必要で、他のセンターでは などが必要です。data_coding=0data_coding=0data_coding=0data_coding=241

SMPP 3.3 の値はGSM 03.38data_codingに基づいているものの、SMPP 3.4 以降ではGSM デフォルト アルファベット ( GSM 03.38 ) の標準化された値は存在しません。また、7 ビット文字が GSM のようにパックされて 140 オクテットで 160 文字を送信できるのか、それとも 7 ビット文字がそれぞれオクテット全体としてエンコードされるのか (ASCII のように最上位ビットがゼロに設定される) も曖昧です。data_coding

SMPP 3.4および5.0によると、この値はdata_coding=0「SMSCデフォルトアルファベット」を意味します。実際にどのエンコーディングになるかは、SMSCの種類とその構成によって異なります。

CDMA規格C.R1001のエンコーディングの1つに、日本語で使用されるShift-JISがあります。SMPP 3.4および5.0では、日本語用に3つのエンコーディング（JIS、ISO-2022-JP、拡張漢字JIS）が指定されていますが、いずれもCDMA MSG_ENCODING 00101とは一致しません。SMPPでは、Shift-JISのメッセージを伝送するためにピクトグラムエンコーディング（data_coding=9）が使用されているようです。

submit_sm が失敗した場合、SMSC はsubmit_sm_respcommand_status がゼロ以外の値で message_id が「空」である を返します。

• SMPP 3.3では、message_id field「このフィールドが存在しない場合は、単一のNULLバイトを含める必要がある」と明示的に規定されています。PDUの長さは少なくとも17オクテットです。
• SMPP 3.4 の「フィールドにゼロ以外の値が含まれている場合、PDU 本体は返されませんSUBMIT_SM_RESP」というセクションに、残念な注記があります。その場合、PDU の長さは 16 オクテットになります。submit_sm_respcommand_status
• SMPP 5.0では、メッセージmessage_idのCオクテット文字列型の必須パラメータとして指定されていますsubmit_sm_resp。セクション3.1.1「NULL設定」によると、「NULL文字列」は0x00としてエンコードされます。PDUの長さは少なくとも17オクテットです。

最高の互換性を確保するためには、SMPPの実装は、submit_sm_resp通信に使用されるSMPP規格のバージョンに関係なく、否定表現の両方のバリアントを受け入れるべきである。

エラーシナリオの本来の意図は、PDU 応答にボディが返されないことでした。これは、すべての Aldiscon/Logica SMSC および他のほとんどのベンダーで見られる標準的な動作でした。WAP フォーラムで SMPP 3.4 が取り上げられたとき、NACK 応答にボディを含めるべきかどうかについていくつかの明確化が求められ、仕様のセクションsubmit_smやbind_transceiverセクションなど、いくつかの場所でこの点を明確にするための措置が取られました。最終的に V5.0 で追加した明確化、つまりエラー応答にはボディを含めるべきではないという点を追加するべきでした。一部のベンダーは実装で非常に愚かで、拒否されたbind_transmitter応答にはボディを含めますが、bind_transceiver応答には含めません。ベンダーへの推奨事項は、上記のように、両方のバリアントを受け入れることです。しかし、空のボディの有無にかかわらず、NACKsubmit_sm_respおよびdeliver_sm_respPDU を発行することも賢明です。これら 2 つの PDU の場合、空のボディはストリームの最後に 1 つの NULL オクテットのように見えます。 NACKされたリクエストに、いわゆるダミーボディを含める機能が必要になる理由は、相手側がボディの欠落を許容するように実装を変更できない、あるいは変更したがらない可能性があるからです。（私はAldiscon/LogicaでSMPP仕様の3つのバージョンに携わり、Openmind Networks向けにESMEソリューションを設計しました。）

SMPP 3.3 で配信確認を渡す唯一の方法は、テキスト形式の情報をフィールドに入力することですshort_message。ただし、テキストの形式は SMPP 3.4 の付録 B に記載されていますが、SMPP 3.4 ではその目的で TLV を使用することもできます (また使用すべきです) receipted_message_id。SMPP message_state3.3 ではメッセージ ID は最大 8 文字 (末尾の '\0' を含む) の C オクテット文字列 (16 進数) であると規定されていますが、SMPP 3.4 仕様では配信確認フォーマットの id フィールドは最大 10 文字の C オクテット文字列 (10 進数) であると規定されています。これにより、SMPP の実装は 2 つのグループに分かれます。

• message_id配信受領書の本文の id フィールドでは整数メッセージ ID の 10 進数表現を、フィールドreceipted_message_idでは整数メッセージ ID の 16 進数表現を使用する実装
• message_idパラメータと配送受領書本文のidフィールドの両方で同じ16進数（または同じ任意の文字列）を使用する実装

ただし、SMPP 3.4仕様では、配信確認フォーマットはSMSCベンダー固有のものであると規定されており、仕様に含まれるフォーマットはあくまで可能性の一つに過ぎません。前述のとおり、SMPP 3.4を使用する場合はreceipted_message_id、message_stateメッセージの結果を伝達するためにTLVを使用する必要があります。