ちょうど1年前、以前の同僚は、通信事業者のVoIPエンジンの変更に参加するという提案で私たちに頼りました。 タスクは、アカウントを完全にやり直し、システムのスケーリングを確保し、課金システムを作成し、LCRを作成し、ユーザー費用を監視し、会話の時間を制御し、分析を呼び出すことでした。 話は悲しいことに終わった、なぜなら 伝えられるところでは、システムの拡張機能は作業指示書に対応していませんでした。作業指示書は紙で正式化されておらず、オペレーターのマネージャーの頭にしかありません。 顧客が本当に気に入っていた開発された機能に対して管理者が支払いたくないという事実のために、私たちは関係を断ち切りました。 私たちはNDAと契約を持っていなかったため、同僚と相談した後、開発の一部を無料で利用することにしました。 これは一連の記事になると思います。 そして、基本的なものとアーキテクチャから始めましょう。

少なくとも一度はIPテレフォニーに携わった管理者は、IPテレフォニーサービスをエンドユーザーにいくつかの方法で提供できることを知っています。

• 通信事業者からの部屋のレンタル。 この場合、ユーザーには、電話番号が「結び付けられた」個人ユーザー名/パスワードが与えられます。 ログイン/パスワードリンクを使用してオペレーターの機器に接続すると、ユーザーはレンタルした番号への呼び出しを受信し、この番号から他のサブスクライバーへの呼び出しを行うことができます。
• ルームブロックのレンタルとSIPトランク（トランク）による接続。 SIPトランク経由で接続すると、サービスプロバイダーは事前に合意したIPアドレスに、このオペレーターからレンタルした番号に着信するすべてのコールを送信します。 SIPトランクの編成方法に応じて、パスワード認証を使用する場合と使用しない場合があります。 この場合、発信コール中に着信側に表示される正しいCallerIDの設定は、IP PBX管理者の肩にかかっています。
• 発信トラフィックを購入せずに通信事業者からDID番号を購入する。 オペレータは、この番号に着信したコールを指定されたサーバーにリダイレクトするだけです。
• 発信トラフィックの購入。 発信トラフィックを販売する通信事業者はかなりいます。 この場合、料金プランによっては、着信者に送信されるCallerIDは、目的の方向のトラフィックを終了（最終クライアントに配信）するオペレータチェーンを通過するときに送信または失われる可能性があります。 ルートが安価だったため、モスクワのオペレーターを介したモスクワの番号への呼び出しが、たとえばロンドンの番号またはベルギーの番号から発信される場合が非常に頻繁にあります。

いくつかの国に駐在員事務所を持つ企業や、他の国に拠点を置きたい企業は、顧客の便宜のために、たとえば英国の電話番号を購入し、モスクワで着信を処理できます。 さらに、そのような番号を提供したオペレーターは、英国への通話の配信に関与していない可能性があります。 ベラルーシ共和国などの一部の国では、非居住者に番号を提供していません。

そのため、次の初期要件から進めます。

1. コールサーバーはどこにでも立つことができます
2. サーバーの数に制限はありません
3. 通信事業者の数に制限はありません
4. あらゆるタイプの部屋のレンタル（ログイン/パスワードまたはトランク）で電話を受けることができます
5. 特定のCallerIDでの呼び出しは、そのサーバーからのみ、このCallerIDが現在関連付けられているアカウントからのみ、またはCallerIDを変更できる演算子を介して発生する必要があります。
6. 隣接サーバー間のコールは、着信側に関する情報を失うことなく透過的でなければなりません。 たとえば、ロンドンの番号を別の地域の内線、携帯電話、または固定電話に転送する
7. 発信コールの場合、料金プランに応じて、より高価なルートを介して予約する最も安いルートを選択する必要があります。 通信の品質を制御するには、ABR、ASR（特定のテレフォニーノードを介して特定の方向の通信の品質を決定する統計パラメーター）を監視する必要があります。
8. システムを使用している外部ユーザーがいる場合、リアルタイムで現在の残高と現在の会話を確認する必要があります
9. 現在の残高値が特定の金額よりも少ない場合、ユーザーは会話の終了とともにマイナス残高に関する音声メッセージを受信する必要があります
10. ユーザーは、Webブラウザー（WebRTC）を介して呼び出しを行える必要があります。
11. 着信コールと発信コールを処理するサーバー、および加入者にサービスを提供するサーバーを分割できます。
12. 分析とコールルーティングには、着信コールと発信コールの位置情報が必要です

ちょっとした注意：説明された構成は普遍的ですが、クライアントのパーソナライズと、1つのマネージャーまたはマネージャーのグループへのクライアントのバインドが必要な場合、クライアント指向のサービス、たとえばコールセンターに適しています 説明されているメカニズムのほとんどは普遍的であり、他の構成で効果的に使用できます。

多くの要件があるので、どこから始めればいいのでしょうか？ アスタリスクは呼び出しを受け入れ、呼び出しを行い、Pythonのアプリケーションサーバーは呼び出しの準備を処理し、すべての作業データをMariaDBに保存し、ほとんどのロジックはプロシージャとして実装されます。 これにより、アスタリスクのロジックをダイヤルプランの不要なルールから最大限に引き離し、構成の統合とともにスケーラビリティを提供できます。

交通

トラフィックを決定します。 キプロス、アメリカ、イギリス、ロシアなどに存在が必要です。 ロシアのトラフィックの観点からは、ロシアの通信事業者を介して作業する方が収益性が高くなります。 たとえば、Westcol、IPPortなど。 ロシア（モスクワ）のオペレーターも、コード495および499の電話番号をリーズナブルな価格で借りていますが、Zadarma、Multilel、または他の人から電話番号を購入することで、キプロス、アメリカ、イギリスでの存在を確保できます。 ロシアのオペレーターからの国際電話はかなり高価なので、VoiceBuyやVoxBeamなどの外国のオペレーターからトラフィックを購入できます。

「ログイン/パスワード」オプションで通信事業者に接続すると、PBXへの呼び出しは、登録が行われている事業者のサーバーのIPアドレスから発信されます。 ただし、発信コールの場合、サーバーアドレスは異なる場合があります。

SIPトランクを介してオペレータに接続する場合、着信コールはオペレータのプールの複数のサーバーから発信され、発信コールは単一のDNS名を使用して発信されます。ほとんどの場合、複数のIPアドレスが含まれます。 すでに決定したように、オペレーターは発信通話のCallerIDを置き換えることができる場合があります。これは、料金プランまたは契約で規制できます。 ロシアでは、発信通話に対するCallerIDの置換（番号置換）は禁止されています。 外国のオペレーターを使用すると、状況ははるかに単純になり、CallerIDの置換が完全にサポートされます。

データベースを作成します。

この記事で公開されているデータと表のほとんどは、電話番号とIPアドレスを除いて、実際のデータベースのコアからの抜粋です。

マルチ通貨の電気通信事業者がいるという事実により、電気通信事業者の表には通貨表へのリンクが必要です。 少し後で、オペレーターの関税の多通貨再計算の可能性を検討します。

CREATE TABLE `currency` ( `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `iso` CHAR(3) NOT NULL DEFAULT '' COLLATE 'utf8mb4_unicode_ci', `name_en` VARCHAR(200) NOT NULL DEFAULT '' COLLATE 'utf8mb4_unicode_ci', `name_ru` VARCHAR(200) NOT NULL DEFAULT '' COLLATE 'utf8mb4_unicode_ci', `numcode` INT(3) UNSIGNED ZEROFILL NULL DEFAULT NULL COMMENT 'numcode for country', PRIMARY KEY (`id`), UNIQUE INDEX `iso` (`iso`) ) COMMENT=' , iso   ' COLLATE='utf8mb4_unicode_ci' ENGINE=InnoDB AUTO_INCREMENT=1 ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通貨

 CREATE TABLE `providers` ( `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, `providername` VARCHAR(50) NULL DEFAULT '0' COLLATE 'utf8mb4_unicode_ci', `currency_id` INT(10) UNSIGNED NOT NULL DEFAULT '0', `noncli_prefix` VARCHAR(10) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', `cli_prefix` VARCHAR(10) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', `premcli_prefix` VARCHAR(10) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', `cli_allowed` ENUM('Y','N') NOT NULL DEFAULT 'N' COLLATE 'utf8mb4_unicode_ci', `dynamic_calls` CHAR(1) NULL DEFAULT 'N' COLLATE 'utf8mb4_unicode_ci', `append_plus` TINYINT(1) NOT NULL DEFAULT '1', `dynamic_calls_caller_id` VARCHAR(30) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', PRIMARY KEY (`id`), INDEX `FK_providers_currency` (`currency_id`), CONSTRAINT `FK_providers_currency` FOREIGN KEY (`currency_id`) REFERENCES `currency` (`id`) ) COMMENT='       ' COLLATE='utf8mb4_unicode_ci' ENGINE=InnoDB AUTO_INCREMENT=1 ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロバイダー

だから。 オペレーター。

通常、外国の事業者は、2〜3の関税を課されており、その料金で着信加入者にトラフィックを配信します。 CLIとNonCLIのテクニックの違いについては、 こちらをご覧ください 。

関税プランを選択するには、通常、コールラインの形成中に着番号の前にプレフィックス（ noncli_prefix、cli_prefix、premcli_prefix ）が使用されます。

フィールドの説明：

• providername-オペレーター名
• currency_id-オペレーター通貨
• noncli_prefix -CLIサポートなしの料金
• cli_prefix -CLIサポート付きの料金
• premcli_prefix-プレミアムレートプラン
• cli_allowed-オペレーターが発信呼び出しのCLIを変更できることを示します
• dynamic_calls-オペレーターがCLIを使用して任意の方向に呼び出しを行うことができることを示します。
• append_plus-着信番号の前に「+」を追加するかどうか。 「+」を必要とする演算子と、必要としない演算子があります。
• dynamic_calls_caller_id-デフォルトステートメントのCID。

WestCallおよびSIPトランク経由で接続を提供する他のオペレーターの場合、番号のプールを購入し、呼び出しを行うと、このプールから発信番号を任意の番号に変更できます。 IPPortは、他のオペレーターと同様に、単一の購入番号でログイン/パスワードスキームを使用する場合、発信番号の変更を許可しません。 VoxBeamおよびVoiceBuyオペレーターは、あらゆる方向の発信通話に使用され、発信番号を他の番号に変更できます。 確かに、一つだけあります！ そして、発呼者番号が国または地域の内線番号に対応する場合、着呼者に呼を配信する最終通信事業者は、呼を拒否したり、発呼者の番号を自分の番号に変更したりすることができます。 つまり たとえば、ロシアからウクライナ（キエフ）に電話をかける場合、CallerIDをキエフのウクライナの番号に変更します。電話をかけているサービスプロバイダーは、単に電話を「打ち切る」ことができます。 「外部の着信国際トランクを経由するコールには内部番号を含めることはできません。」という内部コール処理ポリシーに準拠していません。 ZadarmaとMultitelのオペレーターを番号のプロバイダーとして使用し、必要に応じて発信トラフィックを送信しません。

呼処理の重要な側面はセキュリティです。 IPテレフォニーサーバーが正しく構成されていないと、他の人の通話を通過できる場合がよくあります。 着信および発信コールを処理する回線のセキュリティを確保するには、異なるコンテキストに従ってオペレーターを分離することに加えて、通信サービスを提供する通信オペレーターのIPアドレスのデータベースを作成する価値があります。 第一に、ファイアウォールへのアドレスのエクスポートを設定し、不必要な「着信」を排除することができます。第二に、通信事業者への接続方法に関するより完全な情報を提供します。

 CREATE TABLE `providers_ips` ( `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, `provider_id` INT(11) UNSIGNED NOT NULL DEFAULT '0', `ipaddress` INT(11) UNSIGNED NOT NULL DEFAULT '2130706433', `domainname` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', `direction` ENUM('IN','OUT','IN/OUT') NOT NULL DEFAULT 'IN' COLLATE 'utf8mb4_unicode_ci', `proto` ENUM('SIP','IAX2','H323') NOT NULL DEFAULT 'SIP' COLLATE 'utf8mb4_unicode_ci', PRIMARY KEY (`id`), INDEX `FK_providers_ips_providers` (`provider_id`), CONSTRAINT `FK_providers_ips_providers` FOREIGN KEY (`provider_id`) REFERENCES `providers` (`id`) ) COMMENT='      . direction    / ' COLLATE='utf8mb4_unicode_ci' ENGINE=InnoDB AUTO_INCREMENT=1 ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

provider_ips

フィールドの説明：

• provider_idは、プロバイダーテーブルからアドレスをオペレーターにバインドすることを示します
• ipaddressは、組み込み関数INET_NTOAを使用した変換用のオペレーターサーバーのfqdnアドレスのInt表現です。
• domainnameは、fqdnが呼び出しを処理するオペレーターのサーバーの名前であることを示します。
• directionは、指定されたIPアドレスの呼び出し方向を示します（出力のみにOUT、入力のみにIN、入力と出力の両方にIN / OUT）
• protoは、通信事業者との通信が発生するプロトコルを示します（SIP / IAX2 / H323）

したがって、演算子とアドレスの組み合わせは次のようになります。

vw_providers

これは何のためですか？

1. 特定のオペレーターからレンタルした電話番号への着信コールは、このオペレーターのサーバーのIPアドレスのプールからのものでなければなりません。 したがって、着信時に、オペレーターのIPアドレスのテーブルを使用して、オペレーターに関連付けられた番号を確認する価値があります。
2. オペレーターは、サーバーからの発信呼び出しを処理する複数のサーバーを持つことができるため、ダイヤラーキューを形成する際にこれを考慮する必要があります。
3. このスキームにより、コール文字列を即座に受信できます。 同時に、domainnameをsip.confまたはiax.confで定義されたトランクの名前に置き換えても、システムは破損しません。
4. 番号は、フォールトトレランスのために複数のサーバーに「展開」でき、各サーバーにしっかりと割り当てることができます。 この番号が接続されていないサーバーでコールを処理することは意味がありません。

番号74957777777の電話番号を取得してみましょう。

 SELECT CONCAT_WS('/', pips.proto, pips.domainname, CONCAT(IF(p.append_plus IS TRUE,'+',''), IFNULL(p.cli_prefix,''),74957777777)) AS dial_string FROM providers_ips AS pips LEFT JOIN providers AS p ON p.id=pips.provider_id WHERE pips.direction IN ('OUT', 'IN/OUT')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ダイヤル文字列リクエスト

ご覧のように、ダイヤルの準備ができたデータを取得しました。これをアスタリスクサーバーのダイヤルアプリケーションに渡す必要があります。 今のところこれで停止します。

通信事業者から借りた番号をバインドするには、これらの番号がサービスされるサーバーのリストを指定する必要があります。

 CREATE TABLE `servers` ( `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, `servername` VARCHAR(50) NULL DEFAULT '0' COLLATE 'utf8mb4_unicode_ci', `location` INT(11) NOT NULL DEFAULT '0' COMMENT 'country code where server is located', `ipaddress` INT(11) NOT NULL DEFAULT '2130706433' COMMENT 'localhost by default', `comment` VARCHAR(50) NULL DEFAULT '0' COLLATE 'utf8mb4_unicode_ci', `sip` VARCHAR(50) NULL DEFAULT NULL COMMENT 'SIP URI' COLLATE 'utf8mb4_unicode_ci', `iax2` VARCHAR(50) NULL DEFAULT NULL COMMENT 'IAX2 address and user binding if rsa keys used' COLLATE 'utf8mb4_unicode_ci', `iax2control` VARCHAR(50) NULL DEFAULT NULL COMMENT 'IAX2 address and control user binding for pair and route control' COLLATE 'utf8mb4_unicode_ci', `protocol` ENUM('SIP','IAX2') NOT NULL DEFAULT 'SIP' COLLATE 'utf8mb4_unicode_ci', PRIMARY KEY (`id`) ) COMMENT='   ' COLLATE='utf8mb4_unicode_ci' ENGINE=InnoDB AUTO_INCREMENT=1 ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバー

フィールドの説明：

• servername-内部サーバー名
• location-サーバーが配置されている地理的エリア。 この場合、ロシア
• ipaddress-実サーバーのIPアドレス
• sip-サーバーに接続するためのSIP URL
• iax2-サーバー間のコール転送用のサーバー識別子とRSAキーのペアリング
• iax2control-リモートサーバー管理およびサーバー間通信のための特別なコマンドチャネル。 最大80文字のコマンド長
• プロトコル -サーバー間通信のタイプでソートするための情報フィールド

このテーブルは何のためにあり、なぜそんなに奇妙なのですか？ アスタリスクサーバーのサーバー間接続の場合、IAXプロトコルを使用するのが最も便利です。 いくつかの理由があります。

1. サーバー間のすべての通過トラフィックを暗号化できます
2. SIPプロトコルとは異なり、オペレーターがファイアウォールを通過するのは簡単です（作業に必要なUDPポートは1つだけです）
3. 暗号化キーなしでサーバーへの攻撃者との接続を確立できない
4. サーバー間でデータを転送する機能。 たとえば、セッション変数。 SIPプロトコルでは、セッションパケットのヘッダーにデータを追加できますが、多くの場合、余分なヘッダーは中間サーバーによってパケットから単に「クリア」されます。 IAXプロトコルでは、接続を確立する前にストリームで必要な変数を転送できます
5. サーバー上のコンテキストへのホストとユーザー/キーのバインディングのクリア

 [macomnet] type=user username=macomnet auth=rsa inkeys=asterisk-corbina:asterisk-msm context=incoming_dialer encryption=yes qualify=yes disallow=all allow=gsm allow=ulaw [msm] type=peer host=89.208.16.1 username=msm auth=rsa outkey=asterisk-macomnet encryption=yes qualify=yes disallow=all allow=gsm allow=ulaw trunk=yes [corbina] type=peer host=83.102.161.1 username=corbina auth=rsa outkey=asterisk-macomnet encryption=yes qualify=yes disallow=all allow=gsm allow=ulaw trunk=yes
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初期段階でサーバーを整理しました。 ここで、リースした番号を特定のサーバーにバインドする必要があります。 これは、正しいコールルーティングに必要です。

numbers_pool

フィールドの説明：

• 番号 -国際フォーマット番号
• provider_id-番号を演算子にバインドします
• server_id-サーバーに番号をバインドします
• 有効 -この番号でのサービスコールの有無
• 方向 -呼び出し方向番号によって提供されます
• virtualflag-数値は「実」または「仮想」です。 「実際の」番号はダイヤラに関連付けられ、「仮想」の番号は関連付けられていません
• echotest-番号テストモードを有効にします。 モードが有効になっている場合、呼び出しはAsteriskサーバーのEcho（）アプリケーションに転送されます

システムの開発時点では、リースされた番号の数は約400で、サーバーの数は4でした。コールルーティングをテストするために、MegafonのMultifonも追加されました。 ログイン/パスワードに関連付けられた「実際の」番号を使用する場合、正しいダイヤルピアを介して呼び出しが行われるようにする必要があります。 アスタリスクは、どのダイヤルピアを介してコールをルーティングする必要があるかを知ることができないため、接続テーブルを作成する必要があります。

 CREATE TABLE `gates` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `numbers_pool_id` INT(11) UNSIGNED NOT NULL DEFAULT '0', `serverid` INT(11) UNSIGNED NOT NULL DEFAULT '0', `gatename` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', `gatenumber` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', `cid_support` ENUM('Y','N') NULL DEFAULT 'Y' COLLATE 'utf8mb4_unicode_ci', `contextname` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', `comment` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8mb4_unicode_ci', PRIMARY KEY (`id`), UNIQUE INDEX `name_number` (`gatename`, `gatenumber`), INDEX `FK_gates_servers` (`serverid`), INDEX `FK_gates_numbers_pool` (`numbers_pool_id`), CONSTRAINT `FK_gates_numbers_pool` FOREIGN KEY (`numbers_pool_id`) REFERENCES `numbers_pool` (`id`), CONSTRAINT `FK_gates_servers` FOREIGN KEY (`serverid`) REFERENCES `servers` (`id`) ) COMMENT='List of gates on servers' COLLATE='utf8mb4_unicode_ci' ENGINE=InnoDB AUTO_INCREMENT=1 ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

門

フィールドの説明：

• numbers_pool_id -numbers_poolテーブルの番号識別子
• serverid-ゲートをサーバーにバインド
• ゲート名-ゲート名
• ゲート番号-ゲートに接続された番号
• cid_support-発信コールでcalleridインストールがサポートされているかどうか
• contextname-この番号への発信呼び出しを提供するサーバー上のコンテキスト

これにより、サービスコールのベースがほぼ完成します。 これは非常に大きなトピックであり、別の記事に含める必要があるため、意図的に関税システムと通話制御システムの作業を検討しません。

呼処理とルーティングのメインロジックがAsteriskからApplication Serverに移動し、プロシージャがMariaDBにあるという事実により、プロシージャの動作をデバッグおよび制御するメカニズムを提供する必要があります。 これを行うには、次のスキームを使用できます。

デバッグ情報を保存するには、追加のデバッグデータベースを作成し、 そこにdebug_recordsテーブルを作成します

 CREATE TABLE `debug_records` ( `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `logtime` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, `procedure_name` VARCHAR(50) NOT NULL COLLATE 'utf8mb4_unicode_ci', `debug_text` TEXT NOT NULL COLLATE 'utf8mb4_unicode_ci', PRIMARY KEY (`id`) ) COLLATE='utf8mb4_unicode_ci' ENGINE=InnoDB AUTO_INCREMENT=1 ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このデータテーブルに書き込むには、 デバッグプロシージャを作成します

 CREATE DEFINER=`root`@`localhost` PROCEDURE `debug`( IN `ProcedureName` VARCHAR(50), IN `DebugText` TEXT ) LANGUAGE SQL NOT DETERMINISTIC CONTAINS SQL SQL SECURITY DEFINER COMMENT 'Save debug info to log' BEGIN DECLARE DebugEnabled TINYINT DEFAULT False; SET DebugEnabled=True; IF DebugEnabled THEN INSERT INTO debug_records (procedure_name,debug_text) VALUES (ProcedureName,DebugText); COMMIT; END IF; END
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

開発段階でのプロシージャの操作のデバッグと制御が楽しみに変わります。 各手順の最初に、2つの変数を定義します。1つ目は手順の名前、2つ目はデバッグを有効にするかどうかを決定するフラグです。 そして、プロシージャが正しく動作しない可能性のあるさまざまな場所で、最初にデバッグログにレコードを追加します。

 CREATE DEFINER=`root`@`localhost` PROCEDURE `usp_gettypeofcall`( IN `IncomingPhoneNumber` VARCHAR(30), IN `TargetGateNumber` VARCHAR(30), IN `CHANID` VARCHAR(60), IN `SYSTEMNAME` VARCHAR(30) ) LANGUAGE SQL NOT DETERMINISTIC CONTAINS SQL SQL SECURITY DEFINER COMMENT '        ' BEGIN DECLARE ProcedureName VARCHAR(50) DEFAULT 'usp_gettypeofcall'; DECLARE ProcedureDebug TINYINT DEFAULT True; IF ProcedureDebug THEN CALL debug.debug(ProcedureName,CONCAT_WS(' ','Call from ',IncomingPhoneNumber,'to',TargetGateNumber,'at server',SYSTEMNAME,'with channelid',CHANID)); END IF; END
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このロジックの使用は推奨されないという事実に注意してください!!! デバッグ情報の出力によりパフォーマンスが大幅に低下する可能性があるため、負荷が高い生産モードでは。

アスタリスクを構成する

Asteriskサーバーのセットアップに移りましょう。 ほとんどの既存の構成で、 パブリックコンテキストに該当するコールを処理するための標準的な手順は次のとおりです。

 [public] exten => 74951815000,1,NoOp(Incoming Call to ${EXTEN}) same => n,Dial(SIP/1000,60) same => n,Hangup()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ダイヤルアウトコンテキストからの発信コールの処理は次のようになります

 [dialout] exten => _X.,1,NoOp(Outgoing Call to ${EXTEN}) same => n,Dial(SIP/dialpeer_name/${EXTEN},60) same => n,Hangup()  [dialout] exten => _X.,1,NoOp(Outgoing Call to ${EXTEN}) same => n,Dial(SIP/sip.n1.ipport.net/${EXTEN},60) same => n,Hangup()  [dialout] exten => _X.,1,NoOp(Outgoing Call to ${EXTEN}) same => n,Dial(SIP/${EXTEN}@sip.n1.ipport.net,60) same => n,Hangup()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般的に、誰があなたが好きで、あなたが好きです。 このような発信コールの組織で見られるように、コールのステータスに関する情報は事実上ありません。 ダイヤルプランコール処理を変更し、サービス機能を追加しました

 [service] ; GetIP subroutine exten => getip,1,Set(TESTAT=${CUT(SIP_HEADER(From),@,2)}) same => n,GotoIf($["${TESTAT}" != ""]?hasat) same => n,Set(FROM_IP=${CUT(CUT(SIP_HEADER(From),>,1),:,2)}) same => n,Goto(gotip) same => 20(hasat),Set(FROM_IP=${CUT(CUT(CUT(SIP_HEADER(From),@,2),>,1),:,1)}) same => n(gotip),NoOp(Incoming Server IP is ${FROM_IP}) same => n,Return() exten => set_handler,1,Set(CHANNEL(hangup_handler_push)=service,outbound_handler,1) same => n,AGI(/usr/local/etc/asterisk_scripts/create_channel_record.py) same => n,Return() ; Set Hangup handler for channel exten => outbound_handler,1,NoOp(Hungup handler python started) same => n,AGI(/usr/local/etc/asterisk_scripts/hangup.py) same => n,HangupCauseClear() same => n,Return() exten => no_more_paths,1,NoOp(No more dial paths) same => n,Hangup() [predial] exten => s,1,NoOp(PreDial handler python started) same => n,AGI(/usr/local/etc/asterisk_scripts/predial.py) same => n,Return() [public] exten => _X.,1,GoSub(service,getip,1) same => n,AGI(/usr/local/etc/asterisk_scripts/incoming.py) exten => _+X.,1,GoSub(service,getip,1) same => n,AGI(/usr/local/etc/asterisk_scripts/incoming.py) [users_context] exten => _X.,1,NoOp() same => n,AGI(/usr/local/etc/asterisk_scripts/make_a_route.py) [make_a_call] exten => h,1,NoOp(Hangup) exten => _.,1,NoOp(${EXTEN}) same => n,SET(__LoopCount=1) same => n(try),AGI(/usr/local/etc/asterisk_scripts/incoming_dialer.py) same => n,Dial(${DIALSTRING},60,b(service^set_handler^1)U(predial)) same => n,SET(__LoopCount=${IF($[${HANGUPCAUSE}=17]?10:${LoopCount})}) same => n,Set(__LoopCount=${INC(LoopCount)}) same => n,NoOp(Current LoopCount ${LoopCount}) same => n,GotoIf($["${LoopCount}" < 10]?try) same => n,Hangup() [redirect] exten => h,1,NoOp(Hangup) exten => _.,1,NoOp(${ForwardPath}) same => n,Dial(${ForwardPath}/${EXTEN},60,b(service^set_handler^1)) same => n,Hangup()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

[サービス]コンテキストには、次のようなサービス機能が含まれます。

• getip-着信サーバーのIPアドレスを決定します
• set_handler-現在の発信コールにハンドラーを設定します。 このハンドラーは、チャネルを作成するときに呼び出しを行う前に呼び出されます。
• outbound_handler-完了ハンドラを呼び出します。 着信者が電話を切るすべての場合に呼び出される
• no_more_paths-サブスクライバーを呼び出すために使用可能なすべてのオプションが使い果たされた場合に使用されます

コンテキスト[predial]は、着信側でのピックアップに成功すると、サブスクライバーの接続の前に呼び出されます。

すべての外部呼び出しは[public]コンテキストに分類されます。

サーバーからサーバーに転送する必要があるすべての呼び出しは、 [リダイレクト]コンテキストに分類されます。

[users_context]コンテキストは、通話のルートを準備するためのメインユーザーコンテキストです。

コンテキスト[make_a_call]は、発信呼び出しを行うときのメインコンテキストです。

着信コールを処理する手順をより詳細に検討してください。

1. 呼び出しはオペレーターのサーバーから来て、コンテキストを入力します[public]
2. SIPパケットヘッダーに基づいて、呼び出し元のサーバーのIPアドレスを決定する手順が呼び出されます。
3. AGI incoming.pyアプリケーションが呼び出され、着信呼び出しが初期化されます。
4. アプリケーションの内部ロジックはデータベースに接続し、最初の使用可能なパラメーターを接続検証手順に送信します：サーバーIPアドレス、着信番号、サーバーID。 サーバー識別子は一意であり、サーバーテーブルに対応し、 asterisk.confファイルで定義されます。
5. すべてが番号の識別で正常である場合、以前に使用された発信者へのユーザーコールの検索が行われます。 検索が成功すると、呼び出しは前の呼び出しの開始者に転送されます。 . , "".

[users_context] [make_a_call] .

:

2. [users_context]
3. AGI make_a_route.py , , , . , :
   
   
   • CallerID
   • ...
     
     make_a_route.py [make_a_call] [redirect]
4. [redirect] , , , .
5. [make_a_call] . 10 . , 1 , .
6. AGI incoming_dialer.py , , AGI make_a_route.py , DialString .
7. , Dial , U b. b , . AGI , . , , . U , .. . .
8. 17(), .
9. . ABR, ASR
10. , [no_more_paths] ,

Asterisk . , Asterisk, , RSA IAX . .

AGI Python Application . AGI . , AGI HTTP Application Server uwsgi . , , CURL .

, LCR .

© Aborche 2017