Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン ガイド Cisco CallManager Release 3.3
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月31日
章のタイトル： IP フォン サービス
IP フォン サービス
Cisco IP フォン サービスは、Cisco IP Phone 7940 および 7960 で Web クライアント機能を利用するアプリケーションです。Cisco IP フォンのファームウェアには、限定された Web ブラウズ機能を使用可能にするマイクロブラウザが搭載されています。この章で説明するフォン サービスとは、Cisco IP Phone との間でコンテンツを送受信するアプリケーションのことです。
•
ユーザによる開始：IP フォンのユーザが Services ボタンを押し、Cisco CallManager に HTTP GET メッセージを送信して、ユーザが加入しているフォン サービスのリストを表示します。
• フォンによる開始：IP フォン ファームウェア内で IDLE URL タイムアウトを設定できます。このタイムアウト値を超えると、IP フォン ファームウェア自身が、IP フォンの Enterprise Parameter 設定で指定された IDLE URL ロケーションに対する HTTP GET を開始します。
• フォン サービスによる開始：フォン サービス アプリケーションは、IP フォンへの HTTP POST メッセージを介して、IP フォンにコンテンツを「プッシュ」できます。
図 11-1 では、これらの方法を示しています。
表 11-1 では、IP フォンに対して設定できる各種 URL をリストしています。
IP フォンは、IP フォンと、実行中のフォン サービスを含む Web サーバとの間のユーザ インターフェイス（UI）を使用可能にするために、Cisco 定義の XML（eXtensible Markup Language）オブジェクトの限定セットを処理します。図 11-2 では、このインターフェイス上のメッセージ フローを示しています。
図 11-2 Cisco IP フォン サービスの基本メッセージ フロー
図 11-2 では、次のメッセージ フロー シーケンスを示しています。
1. Cisco IP フォンの HTTP クライアントが、指定された URL に対する HTTP GET を実行します。
2. HTTP Web サーバが、要求を処理し、戻されるデータをフォーマットします。
3. HTTP Web サーバが、XML オブジェクトまたはプレーン テキストの HTTP 応答を IP フォンに戻します。
4. IP フォンが、HTTP 応答ヘッダーを解析して、ContentType 「text」または XML を見付けます。
5. IP フォンが、サーバ応答に応じて、ユーザにデータとオプションを提示します。
Cisco CallManager サーバは、実際のフォン サービスを実行しません。このサービスは、セキュリティを考慮して通常、企業ファイアウォールの背後にある、Cisco CallManager サーバとは別の Web サーバで実行されます。そのサーバは、リモート サーバの代わりに、インターネット コンテンツを取得することもできます。
（注） IP フォン サービスは、Cisco CallManager サーバとは別の Web サーバで実行される必要があります。Cisco CallManager サーバ上でのフォン サービスの実行はサポートされません。
統合上の考慮事項
Cisco IP Phone サービス アプリケーションは、大部分の場合、HTTP クライアントです。このアプリケーションは、Cisco CallManager を、加入しているサービスのロケーションへのリダイレクト サーバとしてのみ使用します。ここでは、IP フォン サービスを Cisco CallManager と統合する場合の、設計上の考慮事項を説明します。
スケーラビリティ（拡張容易性）
Cisco CallManager は、フォン サービスへのリダイレクト サーバの役目をするので、ユーザが Services キーを押してフォン サービス要求を開始するときに、Cisco CallManager に対するパフォーマンスの影響は最小限に抑えられます。
IP フォンは HTTP クライアントまたはサーバなので、IP フォン サービスが使用する帯域幅所要量を見積もることは、Web ホスト サーバ上にある HTTP コンテンツ テキストにアクセスする HTTP ブラウザの帯域幅を見積もることとほぼ同じです。
セキュリティ
既存の IP テレフォニー セキュリティ設計ガイドラインでは、IP フォンが、データ ストアとは別の VLAN 上にあることを推奨しています。IP フォン サービスに次のオプションを設定するときは、このガイドラインに留意してください。
• フォン サービスを実行するプロキシ Web サーバを、音声 VLAN に置くことができます。この設定は実装が比較的に簡単であり、アクセス フィルタは、プロキシ Web サーバのみから設定できます。
フォン サービスは、音声 VLAN 上の専用サーバに置かなければなりません。プロキシ Web サーバではすべてのメディアを保存する必要があるので、メディアのストリーミングのパフォーマンスは低下します。コンテンツがインターネットからのものである場合、メディアを最初にバッファに入れる必要があります。
• フォン サービスを実行するプロキシ Web サーバを、データ VLAN に置くことができます。
IP フォン サービスの任意のトラフィックが、音声 VLAN 外の保護された任意のネットワーク セグメントにアクセスできるようにするには、このトラフィックにタグを付ける必要があります。このアクセスを可能にする 1 つの方法は、音声とデータの VLAN セグメントを分離するルータまたはファイアウォールで、ポート アクセス フィルタを適用することです。 表 11-2 では、IP フォン サービスが使用できる適切なポートの一部をリストしています。
冗長性
IP フォン ユーザに対して信頼性の高いサービスを確保するには、システム障害時の冗長システムへのシームレスな移行により、高レベルのシステム可用性を保持する必要があります。フォン サービスのバックエンド処理はほとんど Web サーバ上で行われますが、IP フォンは、フォン サービスへのリダイレクトに、引き続き Cisco CallManager を使用します。
冗長性の考慮事項を説明する前に、フォン サービスがデフォルトでどのようにプロビジョニングされるかを知っておくと便利です。図 11-3 に示されているように、ユーザが Services ボタンを押すと、HTTP GET メッセージが、デフォルトで IP フォンから Cisco CallManager の getservicesmenu.asp スクリプトに送信されます（Cisco CallManager Enterprise Parameters の設定値を変更すると、別のスクリプトを指定できます）。getservicesmenu.asp スクリプトは、個々のユーザが加入しているフォン サービス URL ロケーションのリストを戻します。HTTP 応答は、このリストを IP フォンに戻します。ユーザが他のフォン サービス メニュー オプションを選択すると、ユーザと、選択されたフォン サービス アプリケーションが入っている Web サーバとの間で、引き続き HTTP メッセージのやり取りが行われます。
図 11-3 Cisco CallManager が管理するフォン サービス
図 11-3 のメッセージ フローを前提とすると、次の 2 つの主な障害シナリオがあります。
• 「障害シナリオ 1：Cisco CallManager サーバとの接続が失敗する」
• 「障害シナリオ 2：IP フォン サービスをホスティングする Web サーバとの接続が失敗する」
表 11-3 では、これらの障害シナリオを説明しています。
障害シナリオ 1：Cisco CallManager サーバとの接続が失敗する
この場合の冗長性は、フォン サービスの設定内容だけでなく、フォン サービスの機能によっても決まります。プライマリ Cisco CallManager サーバに障害が発生した場合、すべてのフォンは、バックアップ Cisco CallManager サーバに再登録されます。しかし、TFTP サーバからダウンロードされた IP フォンのコンフィギュレーション ファイルは、プライマリ Cisco CallManager サーバで設定されていた URL を保持します。したがって、Cisco CallManager に依存しない URL 設定（たとえば、URL Idle と URL Proxy）は、使用可能なままです。
また、Catalyst 6000 上の Cisco LocalDirector または Cisco IOS の Server Load Balancing（SLB）を使用して、サーバ ロード バランシングを実装して、冗長性を確保することもできます（図 11-4 を参照）。
障害シナリオ 2：IP フォン サービスをホスティングする Web サーバとの接続が失敗する
このシナリオでは、Cisco CallManager サーバとの接続が保持されますが、ユーザが加入しているフォン サービスをホスティングする Web サーバとのリンクは失敗します。このシナリオの方が、冗長性のプロビジョニングが簡単です。これは、Services ボタンが押されたときに、IP フォンが引き続き Cisco CallManager サーバにアクセスできるからです。この場合、IP フォンは、Web サーバにアクセスする他の任意の HTTP クライアントとほぼ同じように扱われます。その結果、Server Load Balancing（SLB）などの任意のコンテンツ配信ネットワーク（CDN）テクノロジーを使用して、フォンからホット スタンバイ Web サーバに HTTP 要求を転送できます。
QoS
IP フォンからの IP パケットには、トラフィックを分類するために適切なマーキングを行う必要があります。優先キューイングの場合、これらのパケットには、DSCP マーク AF31 および EF を含めることをお勧めします（ 表 11-4 を参照）。
|
|
|
|
|
|---|---|---|---|
Cisco CallManager が 2 台の IP フォン間で RTP ストリーミングを開始する場合、自動的に設定されます。 IP フォン サービスによって RTP ストリーミングが開始される場合は、設定されません。したがって、アプリケーションによってトラフィックにマーキングする必要があります。 |
|||
フィードバック