MTS SMSサービスとの直接作業：1つの統合の歴史

多くの人々は、SMSがTwitterが欧米でこれほど成功した理由の1つだと考えています。 米国およびヨーロッパの多くの国では、ツイートはSMSを介して公開または受信できますが、発信ツイートの価格は通常のSMSの価格と等しく、着信メッセージは無料です。 スマートフォン（ほとんどのスマートフォン）を使用していないユーザーの場合、これによりエントリのしきい値が大幅に削減されます。



この記事では、ロシアの大手モバイルオペレーターと直接統合した経験を共有します（注：ゲートウェイ経由ではなく直接）、SMS技術とSMPPプロトコルについて-退屈なテーブルや仕様なしに、短いスタイルで紹介します探偵物語。

プロットプロット

私たち（ Rutvit ）が最大の電気通信事業者-MTSに提案したことがあります。 ツイートの価格を通常のSMSの価格と区別できないようにするには、OPSOSと直接統合する必要があります（ちなみに、この言葉は「Cellular Operator」の略です）。 MTSは大企業であり、大規模なパートナーとの協力に重点を置いているため、私たちの提案はすぐには考慮されず、特に成功することは期待していませんでした。 MTSが迅速に対応しただけでなく、建設的な交渉の結果としてRuthwitと共同プロジェクトを開始することを決定したとき、私たちの喜びは何でしたか。



大企業はしばしば遅いことを知っていますが、これはMTSには当てはまらないようです。 統合プロセス中に連絡したワーキンググループは、質問に迅速に対応し、前進しました。 これは、モバイルオペレータとの直接的な統合が、一般的なSMSゲートウェイを接続するよりもはるかに複雑であることが判明したという点で特に価値がありました。記事の終わり近くで技術的な詳細についても説明します。



そのため、最初にRutvitでアルファ版のSMSサービスを開始し（PRIME-TASSのWebサイトでMTSとの共同プレスリリースを読んでください）、今日、このサービスのアルファアイコンをベータ版に置き換えました。 。 このサービスを使用すると、ルートツイートだけでなく、エクスポートメカニズムを介して大規模なTwitterにも、（サブスクライバーの料金プランに応じて）通常のコストでツイートをSMS経由で送信できます。



そのため、他のSMSとまったく同じ金額で、SMSを介してツイートを送信できます。 同じ目的で、短い数字ではなく、より馴染みのある長い数字を使用することにしました： +7 916 140-0-140 。 多くの場合、人々は短い数字を信頼しません。 SMSのためにどれだけのお金が引き出されるのかわからない：数が多いと、あたかも存在しないかのような問題が発生します。

SMSでツイートを開始する方法は？

SMSでツイートを開始するには、Rootwith Webサイトで電話番号を入力します。







次に、「with」という単語（レジスタは重要ではありません）をRootwith +7 916 140-0-140の数に送信します。 ロボットがこのメッセージを見るとすぐに、あなたのアカウントにあなたの番号が添付され、+ 7 916 140-0-140への以降のSMSはすべてあなたに代わってツイートとして認識されます。

また、Twitter、FriendFeed、Facebook、LiveJournal、BuzzでSMSを有料で作成できます。

あなたがTwitterのファンなら、メッセージRutvit-> Twitter（またはFriendFeed、Facebook、LiveJournal、Buzz）のエクスポートを構成し、Rutvitをゲートウェイとして使用してTwitter（FriendFeed、Facebook、LiveJournal、Buzz）SMSに書き込みます。







（公平を期すために、外国のゲートウェイを介してTwitterにSMSを送信できることは注目に値しますが、ロシアでははるかに高価です。結局、Twitterが提供する英国番号+ 44xxxxへのSMSは、ロシアのRutvit番号+7 916 140-0-140 ）



今、ベータ版で存在する軟膏のハエ。 私たちの目標の1つは、ユーザーが通常のSMSの価格でRutvitにSMSを送信できるだけでなく、携帯電話で無料でSMS経由でツイートを受信できるようにすることです。 一部のマイクロブログサービスは、単にGSMモデム（またはLinuxを搭載したスマートフォン）を購入し、それを介してSMSを送受信しますが、この方法は少量のトラフィックでのみ機能します。 それにもかかわらず、このサービスを有効にして使用する際の追加費用からソーシャルネットワークのユーザーを節約したいと考えています。 ただし、これを実現できるのは、技術的な統合とオペレーターとの直接的な契約の締結のみです。 それまでの間、交渉は進行中であり、ベータ版では電話でSMSを受信する機能は実装されていません。システムにツイートのみを送信できます。 この問題では、将来に賭けています。

直接統合の技術詳細

SMSやSMPPを使用したことはありません。 そして、MTSとの契約に署名したとき、次の選択に直面しました。

• SMPPクライアントを手動で作成する（Perl用のモジュールを使用するなど）。
• または、既製の産業規模のSMPPサーバーを使用します（最も一般的なのはKannelです ）。

その結果、2番目のオプションを検討することになりましたが、統合プロセス中に多くの水中レーキを踏んだため、後悔しませんでした。その多くはKannelによって解決されました。

SMPP、SMSメッセージングプロトコルについて少し

SMPP （「ショートメッセージピアツーピア」の略）は、それ自体非常に複雑です。 非常に低いレベルです（仕様は170ページを占有します）。 困難は主に歴史的な理由によるものです。 音声伝送用のプロトコルグループは1975年に開発されました。当時、SMSはありませんでした（携帯電話自体のように、携帯電話用のLCDディスプレイさえありませんでした）。 したがって、1985年に、彼らはテキストメッセージのサポートを標準の音声伝送プロトコルパケットに「詰め込む」ことを決定しました。 しかし、これらのパッケージには有用なスペースがほとんどなかったため、メッセージは短く、160文字のみであることがわかりました-ショートメッセージ。



SMPPパケットで送信できる有用なデータ量は140バイトです。 これはタイプミスではありません。 160文字にどのように適合しましたか？ おそらくすでに推測されています：1 ASCII文字は7ビットでエンコードできます。 したがって、160 * 7 = 1120ビット、つまり140バイトになります。



ASCIIエンコードが「すべての人にとって十分なはず」である米国に住んでいる場合、160文字のサイズのツイートを静かに書きます。 ただし、ロシア語の文字をSMSで送信する場合、それらはUTF-16エンコードでパックされます。 1ロシア文字あたり2バイト。 したがって、1つのメッセージは、ロシア語のアルファベットの140/2 = 70文字を超えることはできません。 テキストが長い場合、2つ以上のSMSメッセージにパックされ、電話に表示されるときに「接着」されます。



しかし、それだけではありません。 2つのSMSメッセージでは、70 * 2 = 140のロシア文字ではなく、134だけを配信できます。サービス情報、特にチェーン内のSMSの数と現在のSMSの数に関する情報をエンコードするには、追加のスペースが必要です。

Kannelの仲間

実際に使用したKannelサーバーのスコープはより広くなっています。 要求がSMSであり、回答がSMSコンテンツである場合、コンテンツプロバイダーを対象としています：メロディ、写真など。 SMSの受信とブロードキャストを整理する部分のみを使用します。KannelはSMPPメッセージを受信し、それをアンパック/復号化して、HTTPリクエストとともに電話番号とテキストを送信します。 それに応じて、コンテンツは送信しません。



確かに、いくつかの驚きがありました。 MTSには非常に綿密なテストスキームがあります。メッセージを正しく受信するだけでなく、要求をキューに入れるときのあらゆる種類のタイムアウトに適合し、スロットルをサポートし、爆発的な負荷の増加に合わせて配信確認メッセージを送信します。 テストベンチで問題が発生しました。その解決のために、Kannelに少しパッチを適用する必要がありました（Cで記述されています）。 簡単に説明すると、次のように説明できます。2つのSMPPパケットがKannelに到着し、3番目のパケットがMTSによって設定された帯域幅制限に達し、キューでスタックしたと仮定します。 制限が解除されたが、4番目のメッセージがすぐに到着した場合、標準バージョンでは、Kannelは以前にスタックしたすべてのメッセージの前にこの4番目のメッセージを配置します。 したがって、3番目のメッセージは再びキューの最後にあり、新しいSMSが到着するとさらに移動します。 MTSの負荷テストでは、この動作が重要であることがわかりました-直接統合中に考慮しなければならなかった他の多くの側面のように。



SMPPを使用した経験はありませんでしたが、Kannelに出られました。 幸いなことに、Kannelは、基本構成であっても、OPSOSに必要なものの多くを処理します。 しかし、正直に言って、SMPPで既に「犬を食べた」ので、Kannelではなく、CPANでPerlとモジュールを使用してすべてを行います。 しかし、これはKannelで得た経験のおかげでのみ可能になります。 この経験がなければ、PerlでOPSOSとの直接統合をプログラミングすることは、崖から水の中に投げ込むことで泳ぐように教えることと同じです。 MTSは、さまざまなタイムアウトに耐え、エラー処理をテストするときに特に細心の注意を払っています。 たとえば、SMPPメッセージに確認* _respを送信する時間は明確に規制されています。遅延はMTSによって指定された時間間隔に収まる必要があります。 SMPPを直接使用する場合は、最初にKannelを検討してください。Kannelのアーキテクチャ、特にメッセージバッファリングの側面を繰り返して、独自の決定を下すことをお勧めします。