一つの番号をテストする2つの方法:外部からダイヤルするか、内部からSIPシグナリングをチェックするか。[ /caption]
「電話番号の監視方法」を検索すると、ほとんどが監視に関する内容です。スパイアプリ、GPSトラッカー、誰があなたに電話したかを追跡すること。それは別の読者向けの別の問題です。
このガイドは運用側向けです。顧客や患者、市民があなたに電話をかける電話番号を所有していて、その番号が使えなくなった瞬間を知る必要があります。死んだSIPトランク、どこにもルーティングされないIVRメニュー、深夜2時に話し中信号を返すフリーダイヤル。ウェブサイトのダッシュボードはすべて正常を示しています、ウェブサイトは問題ありません。電話が問題なのです。
この種の障害を検出する方法は2つあり、異なる層をテストします。一つは外部から実際の発信者のように番号をダイヤルします。もう一つは内部からサーバーでSIPシグナリングをチェックします。どちらも有用で、興味深いのはどちらをいつ使うかです。このガイドでは各方法の動作、検出できるもの、見逃すもの、そして両方を一緒に設定する方法を説明します。
電話番号を監視するとはどういう意味か?
運用では、電話番号の監視とはつまり、スケジュールに従ってその番号がまだ機能していることを証明することを意味します。誰が所有しているかではなく、通話内容でもありません。かけた発信者が正しい場所に繋がるかどうかだけです。
電話番号が問題なく見えても壊れる可能性は多岐にわたります。キャリア側の変更でSIPトランクが登録解除される。PBXのファームウェア更新で特定のDID範囲の着信ルーティングが失われる。フリーダイヤルのプロバイダーが地域的な障害を起こし、ある州の発信者だけが話し中信号を受ける。IVRスクリプトが編集され、オプション3が請求部門に届かずメインメニューにループする。コーデックの不一致で接続はあるが音声が乱れる。
これらはウェブやサーバのダッシュボードには表示されません。番号は静かに停止し、顧客の苦情や営業担当がキューの静けさに気づくまでわかりません。電話番号監視は、その時間差を数時間から数分に短縮するために、同じ方法で同じ間隔で24時間テストを行います。
電話番号を監視する2つの方法
すべての電話通話は2つの大きな層を越え、各監視方法はそのうちの一つをターゲットにしています。
第一層は通話体験:実際に発信者が聞くものです。番号が鳴るか、何かが応答するか、IVRが正しいメッセージを流すか、音質は良好か。これは外部から実際に電話をかけてテストします。これがインワードダイヤル監視です。
第二層はその下のシグナリング層です。音声が流れる前にSIPが通話を交渉します。エンドポイントを登録し、INVITEを送信し、セッションのセットアップ、維持、切断のためステータスコードを交換します。これは内部からゲートウェイやPBXに直接話しかけてテストします。これがSIP監視です。
これらは異なる2つのプロバイダーの別製品なので所有権を明確にしてください。SIP監視はDotcom-Monitorのサービスです。インワードダイヤルチェックはPhone Number Monitoring の単独サービスでphonenumbermonitoring.comで提供されています。それぞれ独自のプラットフォーム上にあり、無料トライアルが用意されているため、購入前に自分の番号でどちらが何を検出するか試せます。
どちらか一方が完全なアップグレードというわけではありません。ダイヤルインテストは通話体験全体を確認できますが、どのサーバーコンポーネントが故障したかは判別できません。SIPチェックは登録やシグナリングの障害を秒で特定できますが、保留音が無音になっているような問題は検知できません。適切な運用では両方を走らせ、それぞれが最も検出しやすい層を監視します。
同じ通話の2つの視点:発信者側からはダイヤルイン監視、サーバー側からはSIP監視。[ /caption]
インワードダイヤル監視の仕組み
インワードダイヤル監視は電話回線のミステリーショッパーに近いものです。外部回線から監視サービスが指定した番号を一定間隔でかけ、相手側で起こることを記録します。
最初に分類するのは通話結果です。通話は応答されたか、回線は話し中か、応答なしか。それだけで最も重大な障害を検出します:着信を受け付けなくなったトランク、ずっと鳴り続ける番号、負荷で話し中信号を返す回線。
次に発信者体験に深く入り込みます。IVRや録音メッセージが応答した場合、音声認識で音声が発信者が聞くべき内容と一致するか確認します。例えば「お電話ありがとうございます」と言うはずが無音や誤ったプロンプトが流れた場合、通話は成立してもテストは失敗します。同じナビゲーションロジックがDTMF入力によるメニューオプション選択に使われ、オプション2は依然として指定部署に届くかチェックします。
さらに回線自体の品質検査もできます。応答した通話の音声の明瞭さ、遅延、歪みを調べ、接続はしているが音声が壊れている劣化は通過/失敗を返すpingでは検出できない問題を捕捉します。
このダイヤルインテストはPhone Number Monitoringが提供し、2012年以来固定電話、携帯電話、フリーダイヤル、FAX番号への自動テストコールを実施しています。これはDotcom-Monitorの機能ではなく独自製品であり独自のダッシュボードと無料トライアルがあります。重要な点は、顧客がいる「外部」からテストしている点であり、そこが強みであり限界でもあります。発信者が見るものだけを見ています。
ダイヤルインテストは顧客が実際に気にする疑問に答えます:「今この番号にかけたら繋がるか?」ただし、繋がらなかった場合にどの装置を再起動すべきかは教えてくれません。
SIP監視の仕組み
SIP監視は番号の反対側からアプローチします。PSTNからダイヤルインする代わりに自社の音声インフラにクライアントとして登録し、シグナリング経路を直接テストします。
Session Initiation Protocolは音声・ビデオセッションを確立、維持、終了するためのシグナリング層です。通話で音声が流れる前後の処理:登録、通話設定、切断を担います。定義されたプロトコルと応答があるため、正確にテスト可能です。
Dotcom-MonitorのSIPチェックの流れは次の通りです。監視エージェントがVoIPサーバーのホスト名、ポート、SIPユーザー名、認証情報を取得し、RFC 3261に従ってPBXにSIPエクステンションとして登録します。登録完了したらゲートウェイを通じてSIP INVITEを送り、実際の音声呼を完了させずに通話設定フローをシミュレートします。プロトコル応答を読み取り、期待する応答と比較します。200 OKは通話受け入れ、486 Busy Hereはエンドポイントが使用中、408 Request Timeoutはシグナリング応答が時間内に無いことを示します。期待結果と合致しなければチェックは失敗しアラートが発生します。
安全な分散音声環境向けの要点として、まずチェックはTLS通信とSRTPメディア暗号化をサポートし、暗号を解除せずに監視可能です。次に30以上のグローバル監視ノードから実施されるため、一部地域のみの登録失敗(多くはキャリアやルーティング問題)が地域別の結果として可視化されます。これは平均に埋もれません。
SIPチェックはシグナリングのみ交換するため実行コストが低く、高頻度でポーリング可能です。ゲートウェイがINVITEへの応答が遅くなっている段階で検知し、通話途絶前に警告を出せます。これはDotcom-Monitorがネットワーク監視全般で用いるプロトコルレベルアプローチで、SIPは通常、トランスポート層のUDP監視とセットで監視されます。VoIPの健全性維持のため、これらはVoIP監視に含まれます。
SIP監視でわからないのは通話の音質や、2ホップ先のキャリア提供IVRが正しいスクリプトを流しているかどうかです。インフラが通話を正しく受け入れ設定したかどうかを検証し、ゲートウェイ以降は不透明です。
インワードダイヤル監視とSIP監視の比較
この2つの方法は意外に重ならないところがあります。運用チームがどちらを使うか判断する際のポイントは下表の通りです。
| 項目 | インワードダイヤル監視 | SIP監視 |
|---|---|---|
| 提供元 | Phone Number Monitoring (phonenumbermonitoring.com) | Dotcom-Monitor |
| テスト対象 | 発信者側から見たエンドツーエンドの通話体験 | SIPシグナリング経路とVoIPサーバーまたはPBX |
| 監視場所 | 公衆電話網の外部回線 | 自社インフラ内の登録済みクライアント |
| 必要なアクセス | 公開されている電話番号のみ | SIPホスト名、ポート、ユーザー名、認証情報 |
| 技術レベル | 低: 番号を入力するだけで開始可 | 高: サーバーアクセスとSIP設定が必要 |
| 典型的な結果 | 着信音、応答、話し中、無応答、IVR一致、音声品質 | 200 OK、486 話し中、408 タイムアウト、登録と応答時間 |
| 検出可能な問題 | 誤ルーティングIVR、無音の挨拶、音声異常、死んだ番号 | 登録失敗、拒否されたINVITE、遅いシグナリング、ゲートウェイ障害 |
| 判別不能な問題 | どのサーバーコンポーネントが故障したか | 下流の通話品質やキャリアホストIVRの挙動 |
| 最適利用例 | コールセンター、医療、行政、金融サービス向け回線 | SIPトランクとPBXインフラを運用するIT・DevOpsチーム |
それぞれの方法を使うタイミング
選択は所有しているものと守りたいものに依存します。
インフラを運用するならSIP監視を選びます。SIPトランク、PBX、セッションボーダーコントローラーを管理する場合、SIPチェックは故障箇所の名称付きプロトコルコードや所在地を最速で示し、根本原因に近い情報を提供します。シグナリングチェックは軽量で頻繁に実行でき、多くの内線にスケールします。大企業内線を持つPBXならこれが主な監視手段です。
公に公開された通話体験が重要な場合はインワードダイヤル監視を使います。キャリア提供フリーダイヤル、ベンダー管理のIVR、挨拶やメニュールーティングがサービスそのものの顧客対応回線など。自社のゲートウェイでのSIPチェックは通過しても、3ホップ先の壊れたメニューには気づけません。実際の通話のみがそれを捕えます。このためコールセンター、医療ホットライン、行政サービス、金融サービス対応デスクはダイヤルインテストに頼っています。リスクはサーバーだけでなく通話体験全体にあります。
重要な番号なら両方実施し、「故障した」と「どこが」両方を知るべきです。SIP監視でゲートウェイのINVITE拒否を把握し、ダイヤルイン監視で顧客が通話できないことを検知します。これにより「電話が変だ」から「2つの欧州ノードで登録失敗し、そこの発信者が話し中信号に当たる」という具体的な問題に変わります。この多層セットアップは売上重要回線や法令遵守回線では標準的な運用です。
電話番号監視の設定方法
両層をカバーしつつメンテナンス負荷を増やさない設定例です。
- ステップ 1: 電話番号と背後の経路をリストアップします。顧客がダイヤルする番号をすべて棚卸しし、背後にあるもの(SIPトランク、PBX内線、キャリア提供IVRなど)をマッピングします。これによりどの層をテストする必要があるか、ダイヤルインチェックがSIPチェックのカバー外を補う場所がわかります。
- ステップ 2: ゲートウェイやPBXごとにSIPチェックを追加します。ダッシュボードにVoIPサーバーのホスト名、ポート、SIPユーザー名、認証情報を入力します。エージェントはSIPエクステンションとして登録し、ゲートウェイ経由でシグナリングを送信可能になります。通信が暗号化されている場合はここでTLSとSRTPを有効にします。
- ステップ 3: 期待するSIP応答と閾値を設定します。通常は
200 OKを目標にし、最大待機時間を設定します。遅延や失敗登録、483や408などの応答が返る場合はチェックがトリップします。 - ステップ 4: 顧客向け電話番号に対しダイヤルインテストコールを追加します。公開番号に外部から定期的に電話をかけ、着信音、応答、ルーティングを確認します。IVRナビゲーションを追加し、音声認識で挨拶やメニュープロンプトが期待通りか検証します。
- ステップ 5: グローバル監視ロケーションを割り当てます。複数の地理的ノードからSIPチェックを実施し、地域特有のキャリアやルーティング障害が位置依存の故障として判別できるようにします。これにより「当社サーバーがダウン」と「あるキャリア経路がダウン」の区別が可能です。
- ステップ 6: アラートのルーティングとレポートの確認を行います。障害は電話、メール、SMSにエスカレーションポリシー付きで通知し、過去のSLAおよび稼働時間レポートで一時的な問題と徐々に悪化する問題を区別します。
2つの実世界の監視シナリオ
この2つの方法は以下の2つの典型的状況に対応します。
内部VoIP PBXの場合。 企業内でSIP PBXを運用し、内部と外部の通話を賄っています。予測外の障害を低減するため、ITチームは定期的にSIPゲートウェイ経由で内線と外部パートナー番号にシグナリングチェックを行う合成SIP監視を構築します。呼設定の成功率や遅延を計測し、登録失敗や応答遅延が生じたらすぐに通知されます。日次・週次レポートでトレンドを把握し、遅いゲートウェイがドロップコール問題になる前にメンテナンスを予定します。SIP監視はこの場合、主な監視手段です。リスクは直接制御できるインフラにあります。
多数の着信顧客回線の場合。 店舗やサービス運営で多数の着信回線(固定電話、携帯電話、VoIP)を管理します。静かに故障する回線があるため、チームは外部回線から選択された番号に定期的に電話をかけ、それぞれが繋がるか、話し中か、無応答でないかを検証します。録音メッセージやIVR応答は音声認識で正しいプロンプトかチェックされます。こちらは発信者体験がリスクの中心であり、そのためインワードダイヤル監視が主な監視手段です。自社では管理していないキャリアやベンダー経由のラインも多いです。
PBXと大量のカスタマー向け番号双方を運用するチームは両方行い、層ごとに異なる方法を使います。
何をアラートにするか
監視は正しい担当者に迅速に問題を伝えなければ役に立ちません。アラートを役立つものにし、騒音にしないための原則をいくつか紹介します。
単なる「ダウン」ではなく特定の障害をアラートにします。3ノードで408 Timeoutが出るのと全ノードで486 Busyが出るのは別の問題を指します。前者は接続やルーティング、後者は容量の問題です。プロトコルコードと障害ノードをアラートに含めてオンコールエンジニアの診断ステップを省けます。
重大度でルーティングを変えます。収益性の高い回線や緊急ホットラインは電話連絡やエスカレーション、利用頻度の低い内部内線はメール通知に使い分けます。マルチチャネルアラート(電話・メール・SMS+アラートグループ)で重要度とチャネルの緊急性を一致させます。
障害発生後ではなく事前に閾値を設定します。SIP応答時間の伸びはゲートウェイの負荷増加の早期警告です。ハード障害だけでなく閾値を監視することで営業時間中に対応可能になり、深夜対応を減らします。レポートの傾向分析で回線が安定か劣化しているかも判断できます。
まとめ
運用上、電話番号監視とはスケジュールで発信者が通話可能か証明することです。検証方法は2つあり、異なる層を監視します。インワードダイヤル監視は外部から実際に電話をかけ、発信者が聞く着信音、応答、IVRルーティング、音質を確認します。SIP監視は自社ゲートウェイに登録してシグナリング(登録、INVITE、プロトコルコード)を確認します。
インフラを所有し迅速で具体的なシグナルが必要ならSIP監視を選びます。通話体験がサービスの一部であり、一部経路が制御外ならダイヤルイン監視を選びます。絶対に静かに故障させられない重要回線は両方を実施し、故障の有無だけでなく場所も特定できるようにします。2つの層をそれぞれ別のプロバイダーがカバー:Dotcom-MonitorはグローバルネットワークからSIPとVoIP監視を担当し、Phone Number Monitoringはネットワークの外部からダイヤルインテストを担当します。どちらもセルフサービスで無料トライアルが利用でき、購入前に自分の番号を試せます。
顧客に気づかれる前に電話回線を監視しよう
2つの製品で1つの目標:あなたの番号がまだ機能していることを証明します。SIPとVoIP監視にDotcom-Monitorの無料トライアルを、ダイヤルインコールテストにPhone Number Monitoringの無料トライアルをどうぞ。どちらもセルフサービスでクレジットカード不要です。