そこにtrixbox /アスタリスクの専門家はいますか?
特定のVoIPプロバイダーからのIAX2経由の着信コールの受け入れを拒否するtrixboxインストールがあります。当初はファイアウォールの問題だと思っていましたが、今ではそうではないと思います。私は思いつく限りすべてを試しましたが(そして私はこの分野の専門家ではありません)、成功しませんでした。これが私が確立したものです:
別のサイトにある別のTrixBox canこのインストールと(IAX2を介して)通信します。これはファイアウォールの問題ではないことを私が知っている1つの方法であり、これはVoIPプロバイダーの問題を示唆しているようですが...
VoIPプロバイダーはSwitchVoxのインストールで正常に動作できます。これは、問題がVoIPプロバイダーに完全にあるわけではないことを示唆しています。だが...
その同じSwitchVoxインストールは、私の「問題」Trixboxとも通信できます。これは、Trixboxに本質的に問題がないことを再度示唆しています。
矛盾する結果に直面して、私はアスタリスクデバッグに目を向け、IAX2デバッグをオンにすると、接続の試行が受信されていることがわかります-プロバイダーから着信する新しいメッセージの例を次に示します。
Rx-Frame Retry [No] -OSeqno:000 ISeqno:000 Type:IAX Subclass:NEW Timestamp:00004ms SCall:00043 DCall:00000 [xxxx:4569] VERSION:2 CALLED NUMBER:0845 [obfuscated] CODEC_PREFS:() CALLING NUMBER:anonymous CALLING PRESNTN:0 CALLING TYPEOFN:0 通話トランジット:0 通話名: 言語:en ユーザー名:[難読化] 形式:8 機能:65407 ADSICPE:2 日時:2010-12-03 12:18:58
ここで違いが生じます。呼び出しが成功すると、次に認証ハンドシェイクが表示され、AUTHREQが送信され、続いてAUTHREP応答が送信されます。動作していない接続の場合、この認証ハンドシェイクは表示されません(AUTHREQでもAUTHREPでもありません)。
NEWメッセージがファイアウォールを通過し、Trixboxによって正しく受信されているという事実は、これがファイアウォールの問題ではないという私の考えを裏付けています。したがって、問題の核心は、何らかの理由で、私のTrixboxが着信を嫌いであり、リモートボックスに認証を要求していないことです。これは何が原因でしょうか?これをさらにトラブルシューティングするにはどうすればよいですか?私はレンガの壁にぶつかったので、この時点で感謝の気持ちを込めて受け取った提案。
OKこれは、古いPiaF(1.4)ボックスとアスタリスク1.6を実行している新しいボックスの間で発生しました。
新しいアスタリスクには、相互互換性を保つためにオフにする必要のあるセキュリティ機能がいくつか追加されていることがわかりました。メッセージはアスタリスクのログファイルにあることが実際に判明しましたが、メッセージが表示される2時間前に無駄になりました。
[2011-01-1802:39:01]エラー[15257] chan_iax2.c:通話が拒否されました。CallTokenのサポートが必要です。予期しない場合は、アドレスXXXXXXXをcalltokenoptionalリストに配置するか、ユーザーXYZ requirecalltoken = noを設定して解決します
そこで、アスタリスク1.6サーバーのUSER DETAILSセクションにrequirecalltoken = noを追加し、すべて修正しました。うーん、反対側の送信セクションにrequirecalltoken = autoがあったようですが、それが必要だとは思いません。それについては、ダウンタイムをスケジュールする必要があります。
これに関するPDFがあります: http://downloads.asterisk.org/pub/security/IAX2-security.pdf