約1年前、私は自分自身の新しいタスク、つまり自動電話交換管理の自動化に直面しなければなりませんでした。 一見、複雑なことは何もありません。TCPまたはシリアルインターフェイスを介してPBX制御ポートに接続し、コマンドを送信して応答を分析する必要があります。 作業中に判明したように、この単純さは誤解を招くことが判明しました。

私の記事では、仕事の過程で直面しなければならなかった困難について話したいと思います。 この記事が幅広い読者にとって興味深いものになることはまずありませんが、おそらく電話の専門家は何か有用なものを見つけるでしょう。 説明資料として、プロジェクトで現在サポートされているAlcatel S12およびM200 PBXコマンドの例を使用します。

1.用語集

手始めに、用語を決定する必要があります。

1.1課題

タスクは、アトミックに実行されるアクションのセットです。 機器管理サブシステムの観点から見ると、タスクは一連のサービスで構成されています 。 各サービスは、特定のサービスへの加入者のアクセスを制御します（たとえば、長距離および国際電話へのアクセスサービスを選択することができます）。

タスクを完了すると、個々のサービスをオンまたはオフにできます。 さらに、多くのサービスについて、構成パラメーターの値を設定できます（たとえば、アラーム時刻やPINコード値など）。 特定のサービスの接続または切断の状態を決定するブール値もパラメーターと見なされます。

機器の観点から見ると、サービスの接続または切断のプロセスは、1つ以上のコマンドの実行に限定されます 。 機器でコマンドを実行するプロセスは、 アクティベーションと呼ばれます。

1.2仕様

仕様は、ジョブの実行を制御する注文管理サブシステムとアプリケーションを統合するように設計された特殊なORMの作業を制御します。 このトピックは、電話交換機とのやり取りの詳細とは関係がないため、詳しく説明しません。 次のステートメントを理解するには、この層がデータベースからロードされた値を含む名前付き変数への読み取りおよび書き込みアクセスを提供することを知るだけで十分です。

スカラー値へのアクセスに加えて、タプルコレクションへのアクセスが提供されます。 たとえば、「tk」（Tech。Card）という名前で表されるコレクションを開くと、「tk.phone」（加入者の電話番号）または「tk.ats_type」（PBXのタイプ）などの技術カードデータを含むレコードにアクセスできます。 また、これらのエントリには他のコレクションへのリンクが含まれる場合があります。 コレクションのネストは制限されていません。

上記のすべてから、仕様という用語が使用される理由はおそらく明確ではないでしょうか？ 実際、このレイヤーを開発する際には、仕様やポリシーなどのSIDの概念が積極的に使用されたため、私の観点からは開発が大幅に簡素化されました。 一般的に、機会のある人のためにTMフォーラムの資料をよく理解することを強くお勧めします。

1.3スクリプト

このサブシステムについてはすでに説明しました。 最初に、スクリプトは2つのタスクを実行しました。作業順序内でコマンドが実行される順序を記述し、プラットフォーム固有の機能を隠しました。 スクリプトは、PBXのタイプに応じて、仕様で提供された変数にアクセスし、コマンドを形成しました。 外観は次のとおりです。


上記のスニペットから、tk.attach.service変数を分析することにより、どのコマンドを実行する必要があるかがわかります。 次に、プラットフォームに応じて、電話番号をtk.phone変数から適切なコマンドテンプレートに置き換えることにより、機器で実行するためのコマンドが形成されます。

非常に多くの異なるコマンドがあったため、スクリプトは大きく（1000行を超える）、わかりにくいことが判明しました。 その結果、2番目のバージョンを開発する際、スクリプト内の個々のコマンドの形成を放棄し（下位レベルに移動）、既製のコマンドではなくサービスコードを渡すことにしました。 この決定は、スクリプトのサイズに非常に有益な効果をもたらしました。 次に、2番目のバージョンのスクリプト全体を示します。


次のセクションでその実装のロジックを説明しますが、今のところは、スクリプトはタスクのフレームワーク内でサービスの接続と切断のシーケンスを制御するだけだと言うだけです。 使用する機器の種類に応じて異なるコードを実行できますが、個々のコマンドではなく、タスク全体を実行するときにプラットフォームへの依存が重要な場合にのみ使用されます。

1.4アダプター

アダプターは、特定のタイプの機器を操作するロジックを実装するプラグインモジュールです。 最初のバージョンでは、アダプターはスクリプトから既製のコマンドを受信し、その役割は、TCPまたはシリアル接続を使用してこれらのコマンドをPBXに転送し、受信した応答を処理することでした。 現在の（2番目の）バージョンでは、特定のサービスを接続または切断するときに、一連のコマンドを形成するロジックがアダプターに転送されます。 これが行われた理由の説明は、この記事の主題です。

1.5同期

同期を、機器から加入者の現在の設定を取得するプロセスと呼びます。 このクラスのタスクでは、データベースに関するPBXのサブスクライバー設定のステータスに関するデータの不整合の問題が基本です。 この問題は、電話だけでなく関連しています。 シスコ機器の管理に関連する以前のアクティベーションプロジェクトでは、彼はそれほど鋭くはありませんでした。 この記事では、同期を使用してアクティベーションプロセスをより「スマート」にする方法について説明していると言えます。

2.職務レベル

明らかに、コマンドの完全に異なるシステムを使用して、さまざまなタイプの自動電話交換を制御します。たとえば、自動電話交換M-200の発信通信を無効にするには、次のコマンドを使用します。

 settune XXXXXXX cmn_outcome=off 

アルカテルS12の場合：

 MODIFY-SUBSCR:DN=K'XXXXXXX,OCB=REMOVE&TOTALBAR. 

しかし、このようなコマンド構文の違いは、複雑さだけではありません。 この問題をより詳細に扱います。

2.1チームへのサービスのマッピング

私たちが最初に直面することは、異なる取引所によって提供されるさまざまなサービスをアクティブにする可能性も異なるということです。 もちろん、発信コール管理、アラームの設定、自動リダイヤルの管理など、ほとんどのタイプの自動電話交換でサポートされる特定の一般的なサービスセットがあります。

同時に、ビジネスの観点から興味深いチームの大部分は、1つまたは別のタイプのPBXに実装されない場合があります（そして、サポートされるPBXのタイプのセットが大きいほど、このようなコマンドが多くなります）。 つまり、タスクの一部であるサービスは、アクティベーションが実行されるエクスチェンジで常に実行できるわけではありません。 そのようなサービスをアクティブにしようとする試みは間違いと見なされるか、単に無視されます。 サポートされているタイプの自動電話交換で実装されたサービスのタスクの一部として使用されるサービスを表示するメカニズムを実装することが重要です。

1つのジョブサービスを、PBXでサポートされるいくつかの異なるサービスにマップできます。 たとえば、M-200はPINコードを有効にする次のコマンドをサポートしています。

 settune XXXXXXX dvo_pincode=on settune XXXXXXX dvo_pincodetwo=on 

1つ目は、長距離電話と国際電話にPINコードを使用し、2つ目はすべての発信通話に使用します。 この場合、顧客の要件の1つは、これらのサービスの両方をタスクレベルで1つの共通PINCODEサービスに表示することでした。 実行されるサービスの種類は、追加の変数の値によって決まります。 Alcatel S12では、1つのPINコード有効化コマンドのみが実装されています。

 MODIFY-SUBSCR:DN=K'XXXXXXX,PASSWORD=ADD&"YYYY",SUBCTRL=ADD&OCBVAR. 

このサービスが2つのタイプに分離されていないことに加えて、このコマンドにはPINコードの使用が含まれるだけでなく、その値も設定されることに注意してください。 もちろん、M-200では、たとえば次のコマンドを実行できます。

 settune XXXXXXX dvo_pincode=on pincode=YYYY 

しかし、アクティベーションモジュールの最初のバージョンを商用運用に導入する過程で、これらのコマンドは個別にアクティベートする方が便利であることがわかりました。 さらに、PINコードが機能するためには、別のコマンドをアクティブにする必要があることが判明しました。 したがって、M-200の場合、PINインストールコマンドは、指定された順序で3つのコマンドをアクティブにする必要があります。

 settune XXXXXXX enb_pincode=on settune XXXXXXX dvo_pincode=on settune XXXXXXX pincode=YYYY 

さらに、PINコードを使用する可能性を制御するenb_pincodeコマンドを個別に実行できます（したがって、「PINCODE」サービスの別の表示オプションを追加します）。 この場合、PINコードは加入者が設定できます。 これはかなり重要な問題につながります。これについては、以下のセクション「同期に関連する問題」で説明します。

2.2発信制限

さまざまなタイプの自動電話交換は、サポートされるサービスのセットだけでなく、これらのサービスの実装方法も異なります。 したがって、イントラバンドへのM-200アクセスでは、都市間および国際通話を個別に制御できます。

 settune XXXXXXX cmn_82xxx=on settune XXXXXXX cmn_8xxx=on settune XXXXXXX cmn_10xxx=on 

Alcatel S12の場合、同様のコマンドは次のようになります。

 MODIFY-SUBSCR:DN=K'XXXXXXX,OCB=MODIFY&PERM&5. MODIFY-SUBSCR:DN=K'XXXXXXX,OCB=MODIFY&PERM&4. MODIFY-SUBSCR:DN=K'XXXXXXX,OCB=REMOVE. 

これらのコマンドは、1つの設定のみの状態を制御することに気付く場合があります（長距離通信を有効にすると、制限が単純に削除されます）。 これにより、次の問題が発生します。

• M-200の場合、ゾーン内、都市間、および国際インクルージョンサービスは、個別にアクティブ化する必要があります（割り当ての1対1の対応するサービスに割り当てられる）
• Alcatel S12でアクティブにした場合、含まれているサービスの1つのみをアクティブにする必要があります。

これは、Alcatel S12でエリア内および長距離通信を有効にする必要がある場合、長距離通信有効コマンドのみをアクティブ化する必要があることを意味します。 その後、ゾーン内通信有効化コマンドがアクティブになった場合、加入者の長距離通信は切断されます！ （M-200とは異なり）長距離切断を使用したゾーン内および国際通信の同時起動は不可能です。

これは、アクティベーションスクリプトレベルで実装された機能の良い例です。 これを実装する方法を見てみましょう。

 [200028] var_list:action = 1, is_dou_activated = 0, is_cat_activated = 0; [200029] target:tk.ats_type; foreach (tk.attach) { [200031] var_list:activate_command = 1; [200032] platform:S-12; if (tk.attach.service = 'C_INTRAAREAL' | tk.attach.service = 'C_INTERCITY' | tk.attach.service = 'C_INTERNATIONAL') { [200033] if (is_dou_activated = 1) { [200034] var_list:activate_command = 0; } [200035] var_list:is_dou_activated = 1; } [200036] if (activate_command = 1) { [200037] < text:%s; var_list:tk.attach.service; [200038] var_list:retry_cnt = 0; } } 

変数によって保存されます。 tk.attachコレクションからの発信通信を制御する最初のコマンドをアクティブにした後、is_dou_activatedフラグを設定し、後続のコマンドのアクティブ化を禁止します。 さらに、このコードはAlcatel S12でのみ機能します。

このアプローチが機能するために必要なことは、チームが正しい順序で到着することだけです。まず、国際的なコミュニケーション（存在する場合）を含め、次に長距離および地域内で行います。 幸いなことに、仕様によりサンプルをソートできます
あらゆる基準によるコレクション。 接続と切断の際にのみ、サービステーブルに優先度フィールドを追加する必要があります。

3.同期に関連する問題

上で述べたように、機器から現在の設定を取得する機能は、少なくともいくつかの正しいアクティベーションを実行するための主要な要件の1つです。 なぜそうなのか見てみましょう。

3.1インテリジェントなアクティベーション

製品の最初のバージョンを導入する際にお客様から受け取った最初の追加要件は、機器で以前にアクティブ化された設定を再アクティブ化しないことです。 これは、次の2つの理由で非常に重要です。

1. 機器でコマンドをアクティブ化するのは簡単なプロセスではありません。 Alcatel S12での1つのコマンドの平均実行時間は約10秒です（M-200は、はるかに少ないデータを返すため、はるかに高速に動作します（約1秒））。 これに、PBXとの接続が非常に不安定であり、これらの非常に10秒間で接続が失われる可能性があるという事実を追加します。 タスクを繰り返し実行するたびに（そして、実行のアトミック性を確保するためにタスクを構成するすべてのコマンドを実行する必要がある場合）、すべてのコマンドを最初から再アクティブ化し、最悪の場合、これらのコマンドを何度も何度もアクティブにします課題の終わりに到達する
2. 場合によっては（Alcatel S12で）、コマンドを再アクティブ化するとエラーが発生する場合があります。 この場合、このサブスクライバーのアクティベーションが初めて実行される可能性があるため、データベースの設定のステータスを確認できません。 この場合、唯一の正しい決定は、アクティベーションコマンドの前に、機器から設定のステータスを直接取得することです

つまり、コマンドをアクティブにする前に、このコマンドの実行に影響する現在の設定をPBXから受け取る必要があります。 設定がすでに必要な状態にある場合、アクティブ化されたコマンドを実行して先に進むことはできません（設定の競合によりアクティブ化されたコマンドを実行できない場合、コマンドを実行することはできませんが、すぐに例外を発生させます）。 このアプローチは、M-200に最適です：

1. すべてのサブスクライバー設定は、1つのgettuneコマンドに対する応答で返されます
2. M-200のアクティベーションは比較的速く、接続は安定しています。 各アクティベーションの開始時に追加のコマンドを実行する余裕があります

アルカテルS12の場合、すべてがそれほどバラ色ではありません。 設定を読み取るには、さまざまなコマンドを実行する必要があり、それらはすべてゆっくり実行されます。 したがって、データベースに設定の状態を保存することは不可欠です。 アクティブ化するとき、データベースから設定を取得でき、設定がない場合にのみ、必要なコマンドを生成して機器から欠損値を取得できます。

もちろん、これは理想的なソリューションではありません。手動でコマンドを実行し、アクティベーションサブシステムをバイパスすると、データベース内のデータが同期しなくなるためです。 さらに、コマンドのアクティブ化が完了すると、実際の設定が（チームが正常に変更したため）認識され、データベース内の非同期データを更新できるようになります。

M-200にも問題があります。 場合によっては、以下で説明するPBXとの対話に使用される調整サーバーが正しく動作しなくなります。 彼はすべてのsettuneコマンドにOkで応答しますが、交換のデータは変更されません！ この場合、gettuneを呼び出すとエラーが発生します。

これは、M-200の場合、アクティベーションの前だけでなく、gettuneを呼び出す必要があり、エラーが発生した場合は2番目のタスクを開始する必要があることを意味します。 調整サーバーが正常に機能し始めるとすぐに、アクティブ化が実際には前のタスクで機能しなかったチームをアクティブ化できます。 正常にアクティブ化されたものは再アクティブ化されません。

3.2依存サービス

前述したように、M-200 PBXでは、PINCODEサービスを含めると（仕様変数の値に応じて）、次の3つのコマンドシーケンスのいずれかがアクティブになります。

 settune XXXXXXX enb_pincode=on 

 settune XXXXXXX enb_pincode=on settune XXXXXXX dvo_pincode=on settune XXXXXXX pincode=YYYY 

 settune XXXXXXX enb_pincode=on settune XXXXXXX dvo_pincodetwo=on settune XXXXXXX pincode=YYYY 

enb_pincode設定は、3つの場合すべてで有効になります。 これらのコマンドをアクティブ化する単純な実装で発生する可能性のあるエラーは簡単に想像できます。

1. 加入者がPINコードを個別に設定できるようにするenb_pincode設定を含むサービスがアクティブ化されます。
2. 発信通信用のPINコードを設定するサービスがアクティブ化されます（その中で、enb_pincodeが再度アクティブ化されます）。
3. サブスクライバーがenb_pincodeサービスを拒否します

この一連のアクションの結果として、enb_pincode設定がオフになり、2番目のステップで設定されたPINコードが機能しなくなります！ これを防ぐために何ができますか？

一般的に、解決策は明らかです。 アクティブ化されたすべてのサービスをデータベースに記録し、シャットダウンコマンドをアクティブ化するときに追加のチェックを行う必要があります。 切断された設定がまだ切断されていない他のサービスによって使用されている場合、切断されたコマンドは無視する必要があります。

はい、サブスクライバーは実際に拒否したenb_pincodeサービスを使用できますが、設定されたPINコードはサブスクライバーからの苦情なしに機能します。 M200コマンドシステムには多くの同様の依存関係はありませんが、それらはすべて重要なサービス（アラームの設定や自動転送の有効化など）に関連付けられています。 これらの依存関係を考慮することは、正しいアクティベーションの観点から重要です。

3.3ロールバックの実装

すべてのタスクが正常に完了できるわけではありません。 コマンドを有効にすると、不正なデータ（このPBXが加入者の番号にサービスを提供していない、アラームを設定するときの時刻が正しくないなど）、または有効なサービスの競合（これはAlcatel S12で頻繁に発生します）によりエラーになる可能性があります。 このようなエラーは回復不能と呼ばれます。

タスクはアトミックに実行する必要があるため、修復できないエラーが発生した場合、同じタスクの一部として、以前に正常にアクティブ化されたすべてのコマンドを「ロールバック」する必要があります。 最初に思い浮かぶのは、実行できたすべてのコマンドを記憶し、エラーが発生した場合は、それらに対して逆のコマンドを実行することです。 このアプローチの実装は、スクリプトの古いバージョンで見ることができます。

 ... [002391] platform:M-200; if (tk.detach.service = 'PINCODE' & tk.detach.act_mode = 0 & tk.detach.act_level = 2) { [023910] < text:settune %s dvo_pincode=off; var_list:tk.phone; [001041] > is_error:1; regexp:(.+); var_list:error; [001610] < text:settune %s pincode=; var_list:tk.phone; [001041] > is_error:1; regexp:(.+); var_list:error; [022010] < text:settune %s enb_pincode=off; var_list:tk.phone; [001041] > is_error:1; regexp:(.+); var_list:error; [023911] is_rollback:1; if (tk.detach.value != '') { [001020] < device_id:tk.ats_id; [023912] < text:settune %s dvo_pincode=on; var_list:tk.phone; [001041] > is_error:1; regexp:(.+); var_list:error; [001603] < text:settune %s pincode=%s; var_list:tk.phone, tk.detach.value; [001041] > is_error:1; regexp:(.+); var_list:error; } } ... 

ここでは、「PINCODE」サービスが正常に切断された直後に、逆コマンドが保存され、ロールバックコマンドスタックでサービスがアクティブになります。 このアプローチには冗長すぎるだけでなく、他にも多くの欠点があります。

1. このアプローチの正しい実装は非常に面倒です。 実際には、リバースコマンドを実行するには、ダイレクトコマンドのアクティブ化時に変数の値が必要ですが、これらの変数の一部はforeachオペレーターによって表示されるコレクションにあります。 これは、逆コマンドを作成するときに、これらのコレクション（およびそれらに埋め込まれたサブコレクション）の状態の「スナップショット」を保存し、ロールバック時に元の仕様の代わりに使用する必要があることを意味します。 さらに、PINコードのリセットなどのコマンドは、復元できるようにリバースコマンドのPINコード値を必要とし、ダイレクトコマンドでは使用されませんが、この値を仕様に追加する必要があります
2. アクティベーションエラーが発生した後にロールバックコマンドを実行すると、Alcatel S12でエラーが発生する可能性があります。 たとえば、パラメータの1つが正しく設定されていない場合、PBXは正しい値を要求し、ロールバックコマンドではなく、その値を受け取ることを期待します。 このコンテキストでコマンドを受信するとエラーが発生し、その結果、ロールバックコマンドは実行されません。 「パラメーターの検証」セクションで、この質問をさらに詳しく分析します。
3. このアプローチは機能しません！ 実際、PINインストールコマンドだけでなく、enb_pincodeおよびdvo_pincode enableコマンドの正しいパラメーター値を取得する場所もありません。 タスク中にそれらをオフにした場合、これはタスクがアクティブになる前にオフにならなかったことを意味しません。 この場合、ロールバックプロセス中にこれらの設定を含めるとエラーになります

, , , — , , .

, , . , ( ).

tk , , . tk, , , . — , . , «» 'ROLLBACK' , :

 ... [200002] if (subtype = -1) { [200003] foreach (tk) { [200015] < device_id:tk.ats_id; [200006] < text:ROLLBACK; ... } } ... 

3.4

前のセクションで説明した回復不能なエラーに加えて、エラーが発生する可能性がありますが、その後はアクティブ化を続行できます。たとえば、アクティベーションプロセス中にPBXへのTCP接続が切断された場合、ロールバックする必要はありません。この場合、以前にアクティブ化されたコマンドの実行をスキップして、アクティブ化を繰り返すだけで十分です。アクティベーションプロセス中に発生した例外の階層は次のようになります。



, , RetryRequiredException. RollbackRequiredException . RuntimeAeException, . (TcpConnectionLostException) :

最初のケースでは、管理者による介入は必要ありません。原則として、PBXはアクティベーションを数回（数分遅れて）繰り返すことで利用できるため、遅かれ早かれ、タスクを完了します。

2番目のケースでは、たとえば、PBXへのアクセスパラメータが正しく設定されていないという事実によってエラーが発生する可能性があります。この場合、いくつかの接続を試行する必要があります。その後、エラーメッセージが生成されます。このロジックは、スクリプトによって実装されます。

 [002000] { [200001] var_list:retry_cnt = retry_cnt + 1, state = 1; ... [200008] if (subtype = 1) { [200009] foreach (tk) { ... [200014] target:tk.ats_type; foreach (tk.detach) { [200015] < device_id:tk.ats_id; ... [200025] if (activate_command = 1) { [200026] < text:%s; var_list:tk.detach.service; [200027] var_list:retry_cnt = 0; } } ... } 

, ( , ), , 0. , .

4.

, . , ( ):

 10.0.5.130:4001> MODIFY-SUBSCR:DN=K'8553377684,ALMCALL=ACTIVATE&06&00&00. 10.0.5.130:4001> SEQ=1306.130403 9002 10.0.5.130:4001> COM=4294 10.0.5.130:4001> JOB SUBMITTED 10.0.5.130:4001> 10.0.5.130:4001> 10.0.5.130:4001> ARGUMENT SEMANTIC ERROR : ALMCALL ARG 0004 10.0.5.130:4001> ERROR CODE = 0008 10.0.5.130:4001> < 10.0.5.130:4001< MODIFY-SUBSCR:DN=K'8553377684,ALMCALL=ACTIVATE&06&00&00. 10.0.5.130:4001> MODIFY-SUBSCR:DN=K'8553377684,SUBCTRL=REMOVE&CWTG. 10.0.5.130:4001> PARAMETER NOT EXISTENT ; MODIFY-S 10.0.5.130:4001> < 

, , , . . . , , , :

 ^([1-9])$ 

, Order Management, . , , , . .

5.

. Alcatel S12 M-200 ( tune) , . , - «» ( , , , ). :

1. . . , Alcatel S12 . 'PASSWORD' . , , , , . , , , 'INVALID PASSWORD'. , , , ,
2. . , - . , , , , ( ). , ,

Alcatel S12の多くの機能も考慮する必要があります。そのため、出力には印刷できない文字（0x05、0x17）が含まれている可能性があり、コマンドを入力するときに改行と復帰の文字は使用されません。Alcatel S12に送信されるコマンドラインは、文字「。」で終わる必要があります。または「;」（認証中に送信されるパスワードも、記号「;」で終了する必要があります）。交換機に送信される各バイトの最上位ビットは、パリティに使用できます（これは交換機で構成されます）。これらの設定は、PBXから送信されるテキストには適用されません。

現在、TelnetのようなTCP接続がAlcatel S12とM-200の両方に接続するために使用されていますが、このソリューションは唯一可能なソリューションではありません。以下に、これらのPBXに接続するための他のオプションについて簡単に説明します。

5.1シリアルvs TCP

, - Alcatel S12. , ( , ) Serial-, , . , .

, RXTX jSSC ( ) Serial- Java SE ( ) , :

1. , Serial-. , USB-Serial ( ) . , , . , Serial- «»
2. RS-232 , . , ( , ), !

このソリューションは、PBXとのやり取りの経験が豊富な顧客とのコミュニケーションの過程で見つかりました。もちろん、電話事業者もすべてのPBXを1か所から管理したいと考えており、MOXA通信機器を使用してこれを長期にわたって成功させ、イントラネットを介してシリアル接続を「スルー」できました。残念ながら、クライアント側でMOXAによって作成された仮想ポートに接続しようとすると問題が発生しました。

一部のMOXAモデルではTCP接続を使用できることが判明するまで、この問題の解決にかなりの時間を費やしました。このアプローチが使用されました。シリアルポートモニターとスニファーは、私たちの仕事に大いに役立ちました。

5.2チューニングとTCP

M-200 , TCP. « ». TCP-, , M-200 . ( TCP) , .

« » ( ), , , , tune- . , .

おわりに

この記事では、実際のアクティベーションプロジェクトで発生した問題を説明（および何らかの方法で分類）しようとしました。従来のテレフォニー機器に重点が置かれていましたが、この資料は、あらゆる機器（たとえば、シスコスイッチ）の制御の自動化に取り組む場合に役立ちます。この記事が誰かに役立つことを願っています。