音声通話のトラブルシューティング

デバッグツール

Twilioでは、開発者のアプリケーションとTwilioとの間でのやり取りを調査するためのツールをいくつかご用意しています。 通話が接続されなかったり、音声通話が予期しない振る舞いをした場合、デバッガーおよびリクエストインスペクターがデバッグの第一歩になります。

Debugger

Twilio Console内にあるDebuggerには、あなたのアプリケーション内のアクティビティーの詳細なログが含まれています。 このログはどの(そして誰によって)Twilioリソースに影響を及ぼしたかを詳細に調べ、理解する手助けになります。 

Debuggerにアクセスするには、Consoleナビゲーションを開いて、「Runtime」を探しクリックします。

Consoleナビゲーション: Runtime

 続いて、Debuggerに移動します:

RuntimeのTwilioデバッガー

デバッガーにアクセスすると、イベントの表示されている下の図のように、詳細なログを掘り下げて問題の根本原因を理解することができます。

Twilioデバッガー

アラートトリガー

Consoleでご自身のアラートトリガーを設定できます。 これらにより、お使いのアカウントでエラーが発生したとき、Webhookまたはメールによって通知されます。 

リクエストインスペクター

リクエストインスペクターはTwilioが開発者のアプリケーションとの間で送受信を行ったリクエストに関する情報を提供します。 Twilioはこのログを90日間保存します。

  • Twilioアカウントにログインします
  • Programmable Voiceダッシュボードに移動して通話ログにアクセスします

          Consoleナビゲーション: Programmable Vocie

  • 続いて、通話ログのリンクをクリックします: 

          Twilio通話ログを見つける

  • 通話ログにアクセスできたら、問題の発生した通話を見つけます。 日付のリンク部分をクリックし、この通話の詳細を掘り下げます。

          特定の日の通話ログを選択する

これでリクエストを調査できます!

リクエストインスペクターはこの通話で送信されたすべてのリクエストとレスポンスを表示します。 リクエストの右側に色付けされたステータスで、簡単にリクエストのエラーを確認できます。 

通話ログ: リクエストインスペクター 404

リクエストをクリックして情報を展開します。

通話ログ: リクエストインスペクター404b

上のスクリーンショットでは、Twilioは /action.xml にリクエストを送信しました。 しかしWebサーバーはこれに対して404を返しています。 Twilioは実行すべき新しいTwiMLを受信しなかったため、通話は終了しました。 これはWebサーバーがTwilioに404を返していることを表しており、次のステップはWebアプリケーションそのものをデバッグすることにあります。 

エラーコード

Twilioによって生成された全エラーコードはこちらにドキュメント化されています。 発生しているエラーコードを見つけて、原因と考えられる解決策を調べましょう。

一般的な諸問題

通話で「アプリケーションエラーが発生しました」という音声が流れる

「アプリケーションエラー」とは、開発者のサーバー上で指定されたURLからTwilioがフェッチしようとしたコードが使用できなかったか、コード中にエラーがあったかのどちらかを意味しています。 Console、または通話処理用のアプリケーションの命令の中で特定の電話番号に対するURLを確認できます。

Voice Webhook

このエラーが表示された場合は、詳細についてはTwilioアカウントのデバッガーログを確認します。

メモ: 開発者のサーバーがTwilioから公開インターネット経由で到達できるようにすることが必要です。 ローカル上で開発やテストを行っている場合、Webhookのテストにはngrokのご使用を推奨します。 こちらのガイドに従って、ngrokをTwilioで使用する方法を学習できます。

通話の着信を抑止する方法

Twilio電話番号で通話を一切着信させたくないない場合は、Twilio電話番号からVoiceリクエストURLを削除して空白のままにしておくことが必要です。 VoiceリクエストURLを空欄にしておくと、着信通話に対してこの電話番号は「使用していない」と見なされます。 着信通話に対しては課金されず、またアカウント内でこうした通話が着信したりログに記録されたりすることがなくなります。

特定の電話番号からの着信を拒否するには、<Reject>動詞を使用します。 通話に対するレスポンスの最初の動詞が <Reject> である限り、Twilioは通話に応答しません。 <Reject> の前に他のTwiML動詞が使用されている場合、アプリケーションは着信通話を取り、アカウントに課金が行われます。

<Gather>に関する問題

<Gather>にまつわる問題の原因を特定できる決定的なテストは存在しません。 取るべき最善のアプローチとしては、考えうるすべてのことを試して問題の切り分けを行うことです。 下記をお試しください: 

  1. 異なるキャリアーの複数の異なる電話機を使用します。 事象が確実に発生するが、特定のキャリアーの特定の電話機のみでそれが認められる場合は、キャリアーに問い合わせて直接事象を報告した方がよい可能性があります。 複数のサービス事業者の複数の電話機で確実に事象が発生する場合は、Twilioサポートにご連絡ください。  
  2. まれにしか事象が発生しない場合、環境的な要因か特定のユーザーの使用スタイルに依存している可能性があります。 この事象がよく発生する特定のユーザー、電話機、あるいは場所がないかどうか確認してください。
  3. アプリケーションの<Gather>の処理方法を確認します。 <Gather>はユーザーからの入力すべてを受信し得ますが、アプリケーションが<Gather action="">で指定されたURLへのリクエストを正しく処理していないことが考えられます。 action=""が正しいアドレスを指しているか、また指定されたアドレスが、リクエストに使用しているメソッドによる送信を受け付け可能か確認してください。

<Gather>の実装についての追加ヘルプについては、こちらのガイドを参照してください。

国際通話の問題

Twilioはワールドワイドでの通話をサポートしますが、国際パーミッションを明示的に有効にしておく必要があります。 国際パーミッションはこちらからオンにできます。

アカウントがまだ国際発信用にセットアップされていない場合は、Twilioサポートまでお問い合わせいただき、アクセスをリクエストしてください。 アカウントでアクセスが許可された後は、グローバルパーミッションページに再度アクセスして通話を発信したい国をオンにしてください。

他のツールとAdd-On

Twilio Status

Twilio Statusページ(英語)から、Twilioのシステムのリアルタイムステータスを常時確認できます。 Twilio側に何らかの問題が発生した場合は、こちらで確認することができます。

Voice InsightsとAdd-on

音声通話についての追加のインサイトをお探しの場合は、Voice Insightsをご検討いただくと良いかもしれません。 これは通話品質、キャリアー分析、およびWebRTCパフォーマンスに関するリアルタイムデータを使用して、お客様をプロアクティブに補助し、サポート時間を最小限にします。

Twilioはまた、Twilioでより多くのことを可能にするパートナー技術に簡単なアクセスに役立つ、さまざまな種類のAdd-onを提供しています。Marketplace内で、Twilio Carrier Information#1 Robocall and Spam Blocking solutionを含むAdd-onの全リストを確認できます。 

サポートへ問い合わせる

依然としてTwilioの音声通話に問題がある場合は、株式会社KDDIウェブコミュニケーションズのサポート間口にご連絡ください。

ヘルプが必要ですか?

誰しもが一度は考える「コーディングって難しい」。そんな時は、お問い合わせフォームから質問してください。 または、Stack Overflow でTwilioタグのついた情報から欲しいものを探してみましょう。