クラウドPBXにおけるUDP通信トラブルについて

はじめに

クラウドPBXを扱う上で多く発生するトラブルは、音声品質ではないでしょうか。片通話や、音切れ、不快なブツブツ音などの発生は、エンジニアであれば聞いたことがあると思います。

ただ、これらのトラブルの原因はクラウドPBXではなく、実はネットワークフィルタリングの問題である、ということが多いと思います。

ここでは一旦、クラウドPBXは正常稼働している前提で、フィルタリングの問題点を確認したいと思います。また、特にフィルタリング設定で多様される”any"について持論を述べたいと思います。

クラウドPBXの正常稼働を仮定する

クラウドPBXの音声トラブル発生時に、クラウドPBXは正常稼働していることを仮定することは重要です。

ここには2つの理由があります。

1つは音声トラブルの状況から、ネットワークの可能性が高いと判断できることです。

もう一つはクラウドPBX開発者にとって、ネットワークは範疇外であることが多いため、確認しても回答が得られない傾向にあるためです。

クラウドPBXが浸透しにくい理由にもつながることですが、ここでは説明を省きたいと思います。

トラブルの発生

  • クラウドPBXの設定が完了し、端末の設定も終わらせる。
  • 小人数での通信テストを実施しユーザ―へのリリースを実施する。

この段階までで、エンジニアは順調と判断すると思います。ただし、リリースを実施すると様々な声が聞こえてきます。

  1. 端末がレジストしない。
  2. 着信音が鳴らない
  3. 通話中に音声ブランクが発生する。
  4. 相手に声が届かない。
  5. 自分の声が届かない。

一般的なIT関連システムの導入でもリリース後にトラブルが発生することはよくあることです。ですが、前回の記事でも説明した通り、音声関連の場合、システムアラートは上がらず、人の声がアラートになることも多くなっています。

UTMやルーターの設定の ”any"

経験上、前段で上げた1~5までの現象は、UTMやルーターの設定が問題であることがほとんどです。

しかしながら、ネットワーク設定の記述上は間違いが無く、疑いようがないように見えるため、ネットワークエンジニアが設定に疑いを持つことは難しいようです。

そのため、トラブルの解消に時間がかかってしまう、という事が散見されます。

ここでは前段で上げた「1.」のケースについて、例に挙げて説明します。

「1. 端末がレジストしない」ケースの例

端末アカウントのレジストレーションについて見て行きます。

クラウドPBXを利用する際における、端末のレジストレーション実施時のルータ設定です。

通信要件は下記の様になります。

  • SIPサーバーアドレス:XXX.XXX.XXX.XXX
  • プロトコル:UDP
  • DSTポート: 5060

上記の要件を満たすためのネットワーク機器側の設定は、通常、以下のようになります。

  • protocol:UDP
  • source address:Any
  • destination address:XXX.XXX.XXX.XXX(クラウドPBXのSIPサーバーアドレス,またはFQDN)
  • source port:Any
  • destination port:5060

ご覧の通り、設定には何も間違いがないと見えます。しかしながら、実際にこの設定において、端末がレジストしない問題が発生しました。

この設定において端末がレジストレーションできないことは想像が難しいでしょう。

ただ、実は、トラブルの解消方法自体は難しくはありません。"any"で指定していた箇所にアドレスを明示することで解消します。

”any"とは何だったのか、疑問は残りますが、ユーザ―の問題は解消されました。

"any"の定義とは

私もクラウドPBXの導入は多く扱っていますが、UDP anyで設定した場合の通信成功率は低く、アドレスの明示はほぼ必須となっていることを見ています。

ただし、設定に疑念を持つ方は多くいます。私もその一人です。anyで通信せず、アドレスの明示で解決する通信するようになるのは何故なのか、疑問が残ります。

anyついて、それぞれのメーカーの定義があるのであれば理解し安いと考えいますが、”any"は”any"であり、それ以外ではないと考えています。

しかしながら同じ製造元でもFIRMWARE等のバージョンによりany設定で結果が異なることもあり、定義にブレを感じます。

最後に

実際に、複数のネットワーク機器において、"any"が使えたり使えなかったしているのが現状です。

そのため、経験から得た持論になりますが、クラウドPBXの導入に際しては、UDPポートの開放設定において、アドレスの明示またはFQNDを確実に設定する、ということを依頼するようにしています。

ただ、なぜ明示が必要かを説明することはとても難しく、同じ社員同士においてでも説明に苦慮します。

メーカーやルーターOSにそれぞれanyの定義にポリシーがあることは聞いたことが無いため、状況に困惑しつつも、クラウドPBXの設定を実施する場合はアドレス明示することを信じていただくしかないと思います。

この問題ですが、今後も引き続き情報を収集する予定です。

執筆担当者プロフィール
高山 智行

高山 智行(日本ビジネスシステムズ株式会社)

入社24年目、パケット音声にまつわる技術をJBSにため込みたいと考えています。 そのため、レガシーPBXからクラウドPBXまた通信端末として電話機やスマホに詳しいです。 WindowsよりLinuxやAsteriskに精通しています。 音声パケット通信のためのネットワーク構成もここに残します。

担当記事一覧