この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章では、ビデオ テレフォニーについて説明します。 Cisco Unified Communications Manager は、音声コールとビデオ コールの領域を一体化するビデオ テレフォニーのサポートを提供します。 ビデオ エンドポイントは、 Cisco Unified Communications Manager のコール処理機能を使用し、音声およびビデオによる統合ソリューションにアクセスすることで、ビデオ コールのダイヤリングおよび接続を行います。
Cisco Unified Communications Manager のビデオ テレフォニー ソリューションは、次の機能を提供します。
Cisco Unified Communications Manager は、音声コールとビデオ コールの領域を一体化するビデオ テレフォニーのサポートを提供します。 ビデオ エンドポイントは、 Cisco Unified Communications Manager のコール処理機能を使用し、音声およびビデオによる統合ソリューションにアクセスすることで、ビデオ コールのダイヤリングおよび接続を行います。
Cisco Unified Communications Manager のビデオ テレフォニー ソリューションは、次の機能を提供します。
Cisco Unified Communications Manager の管理ページでビデオ テレフォニーを設定するには、次の手順を実行します。
次の各トピックでは、 Cisco Unified Communications Manager 環境におけるビデオ テレフォニーの詳細を説明します。
一般的なビデオ コールには、上下用の 2 つまたは 3 つの Real-Time Protocol(RTP)のストリーム(つまり、4 または 6 ストリーム)があります。 コールには、次のタイプのストリームを含めることができます。
ビデオ(H.261、H.263、H.263+、H.264-SVC、X-H.264UC、H.264-AVC、H.265、および Cisco VT Camera wideband video コーデック)
遠端カメラ制御(FECC)(オプション)
Binary Floor Control Protocol(BFCP)
ビデオ コールのコール制御は、他のすべてのコールを管理するコール制御と同じように動作します。 メディア リソースの概要を参照してください。
![]() (注) |
ビデオ会議ブリッジを Cisco Unified Communications Manager で自動的に割り当てる方法の詳細については、インテリジェント ブリッジ選択を参照してください。 |
15.2(2)T 以前の IOS メディア ターミネーション ポイント(MTP)では、Real-Time Transport Control Protocol(RTCP)パケットをパススルーできないため、Real-Time Protocol(RTP)のフィードバック データを交換して RTP 送信を拡張することはできません。 RTCP の主な機能は、ストリーミング マルチメディア セッションの参加者に統計情報を定期的に送信することにより、メディア配信のフィードバックを提供することです。 RTCP は、メディア接続に関する情報、および送信されたオクテット数とパケット数、失われたパケット数、ジッタ、ラウンドトリップ遅延時間などの情報を収集します。 アプリケーションは、この情報を使用して、フローを制限するか別のコーデックを使用することにより、サービス パラメータの品質を管理できます。
IOS MTP バージョン 15.2(2)T 以降では、MTP が含まれたコールのエンドポイントが RTP 送信で引き続きフィードバックとステータスを送信できるように、RTCP パススルー機能をサポートしています。 RTCP パススルー機能は、メディア チャネルに適用されます。
RTCP パススルー機能は、特定のコール シグナリング プロトコルに限定されません。 たとえば、SIP 間、SIP と非 SIP 間、または非 SIP 間でも構いません。
Cisco Unified CM で RTCP パススルー対応 MTP を割り当てるには、コールが次の条件を満たしている必要があります。
MTP をメディア パススルー モードにすることが必要な機能で、MTP が必要。 たとえば、TRP、DTMF 変換、IP アドレス V4/V6 変換などです。RTCP パススルーは、メディアがパススルー モードになっている場合のみ適用可能です。
RTCP パススルーの MTP を、MTP のスポンサーとなるエンドポイントのメディア リソース グループ リスト(MRGL)に含める必要がある。 MTP は、RSVP、E2ERSVP、TRP、DTMF 不一致の理由により挿入できます。
コールがビデオ チャネルを確立できる場合、Cisco Unified CM が RTCP パススルー対応 MTP の検索を試みる。 たとえば、Cisco Unified CM は、MRGL 内の他の RTCP パススルー非対応の MTP の中から RTCP パススルー対応 MTP を選択します。 RTCP パススルー対応 MTP が利用できない場合でも、Cisco Unified CM がコールに MTP を割り当てます。
コールがオーディオ チャネルのみ確立できる場合、Cisco Unified CM が、ビデオ コール以外のコールに対して意図的には RTCP パススルー対応 MTP を要求しない。 ただし、MRGL に RTCP パススルー対応 MTP のみ含まれている場合、Cisco Unified CM はそれらの MTP のいずれかをオーディオ コールに挿入します。
RTCP パススルー対応 MTP を割り当てるためには、コールがビデオ コールの現在の CAC 帯域幅も満たしている必要がある。
![]() (注) |
コールが最初にコール内の RTCP パススルー非対応の MTP(バージョン 15.2(2)T 以前)を使用して確立されており、コールがビデオ対応のコールにエスカレートされる場合、Cisco Unified CM は RTCP パススルー対応 MTP に再割り当てしません。 この場合、コールがビデオ コールにエスカレートされても、既存の MTP では RTCP パケットをパススルーできません。 |
通常のビデオ コーデックには、古いビデオ コーデックの H.261、インターネット プロトコル(IP)ビデオの提供時に使用される新しいコーデックの H.263、および高品質コーデックの H.264 があります。 システムでは、H.264 は、発信および終端エンドポイントで Skinny Client Control Protocol(SCCP)、H.323、および SIP を使用するコール専用にサポートされています。 また、リージョンとロケーションもサポートされています。
リリース 10.01 では、H.265 高効率ビデオ コーデック(HEVC)、H.264 スケーラブル ビデオ コーデック(SVC)、および SIP プロトコルでのみサポートされる X-H.264UC(Lync)ビデオ コーデックを導入しています。
H. 264 SVC は H.264-AVC ビデオ圧縮標準に新しく追加されました。つまり、H.264-AVC をさらに機能強化したものです。 1 つのコンテナにさまざまなフレームレートと解像度で複数のビデオ ストリームをカプセル化する機能を備えています。
H.261 および H.263 コーデックのパラメータおよび標準値は、次のとおりです。
ビット レートの範囲は、64 kb/s ~数 mb/s です。 これらのビット レートは、100 b/s の任意の倍数にすることができます。 H.261 および H.263 はビット レートが 64 kb/s 未満でも機能しますが、このような低ビット レートの場合はビデオ品質が低下します。
解像度:
フレーム レート:15 fps、30 fps
Annex:F、D、I、J、K、L、P、T、N
Cisco Unified Video Advantage(CUVA)は、クラスタ内コールに使用可能な H.263 コーデックと、クラスタ間コールに使用可能な H.264 コーデックをサポートしています。 関連する機能とリージョンを正しく設定していることが、サポートの前提になります。 また、このサポートは通話中にも適用されます。
ビデオ コールの帯域幅は、オーディオとビデオの帯域幅の合計に一致します。 合計帯域幅には、オーバーヘッドは含まれません。
384 kb/s のビデオ コールを、64 kb/s(オーディオ)による G.711 と 320 kb/s(ビデオ)で構成することができます。 この合計には、オーバーヘッドは含まれません。 ビデオ コールのオーディオ コーデックが 24 kb/s による G.729 である場合、ビデオ レートは、合計帯域幅 384 kb/s を維持するために増加します。 コールが H.323 エンドポイントを使用する場合、H.323 エンドポイントは、利用可能な合計ビデオ帯域幅より少ない帯域幅を使用することができます。 プロトコルに関係なく、エンドポイントは常にコールの最大ビット レート未満で送信することを選択できます。
以下の図に、単一の Cisco Unified Communications Manager クラスタを使用するビデオ ネットワークの例を示します。 正常なビデオ ネットワークでは、任意のエンドポイントが、他のすべてのエンドポイントにコールできます。 両方のエンドポイントでビデオが有効である場合だけ、ビデオを利用できます。 ビデオ機能は、トランク全体に拡張できます。
シスコのビデオ会議のポートフォリオは、次のビデオ ブリッジで構成されます。
Cisco UC エンドポイント ポートフォリオは、ビデオをサポートする次のエンドポイントで構成されます。
Cisco Unified IP Phone 9971
Cisco Unified IP Phone 9951
Cisco Unified IP Phone 8941
Cisco Unified IP Phone 8945
Cisco Unified IP Phone 7985
Cisco IP Video Phone E20
Cisco TelePresence EX60
Cisco TelePresence EX90
Cisco TelePresence Quick Set C20
Cisco TelePresence Codec C40
Cisco TelePresence Codec C60
Cisco TelePresence Codec C90
Cisco TelePresence 1000
Cisco TelePresence 1100
Cisco TelePresence 1300-47
Cisco TelePresence 1300-65
Cisco TelePresence 1310-65
Cisco TelePresence 3000
Cisco TelePresence 3200
Cisco TelePresence 500-32
Cisco TelePresence 500-37
Cisco TelePresence MX200
Cisco TelePresence MX300
Cisco TelePresence TX9000
Cisco TelePresence TX9200
詳細については、該当する IP Phone のユーザ ガイドおよびアドミニストレーション ガイドを参照してください。
![]() (注) |
サードパーティの SIP ビデオ エンドポイントは、回線側デバイスまたはトランク側デバイスとして Cisco Unified Communications Manager に接続できます。 詳細については、サードパーティの SIP エンドポイントを参照してください。 |
IPv4 オーディオ専用デバイスをビデオに対して有効にするには、シスコ アプリケーションの Cisco Unified Video Advantage を使用します。 使用中の PC またはラップトップにビデオ コンポーネントを表示するために、アプリケーションを Cisco Unified IP Phone に関連付けることができます。 この関連付けを実行できるのは、コールの発信前またはコール中(通話中)です。 7975、7940、7960、7975、6961、6941、および 6921 などの Cisco Unified IP Phone は、Cisco Unified Video Advantage をサポートしています。
たとえば、 Cisco Unified IP Phone 7975 から Video Phone にコールを発信するとします。 コールはオーディオ専用として確立されます。 Cisco Unified Video Advantage を Cisco Unified IP Phone 7975 に関連付けると、コールはビデオ コールとして再確立されます。
関連付けが存在する間、 Cisco Unified Communications Manager は既存の SCCP メッセージを介して IP Phone の最新機能を受信します。 最新機能を受信すると、 Cisco Unified Communications Manager はビデオに関してネゴシエートします。
最初のコールで IP Phone を使用し、ビデオを使用しない場合は、オーディオ ロケーションの帯域幅だけが予約され、メディア レイヤがオーディオ専用コールを確立します。
音声電話器の他に、9971、9951 などのシスコ ビデオ電話でも、Cisco Unified Video Advantage をサポートします。
H.323 エンドポイントを H.323 電話機、H.323 ゲートウェイ、または H.323 トランクとして設定可能です。
自動転送、ダイヤル プラン、他のコール ルーティング関連機能が、H.323 エンドポイントで機能します。
H.323 ビデオ エンドポイントは、保留、再開、転送、パーク、およびその他の類似機能を開始することはできません。
H.323 エンドポイントが Empty Capability Set(ECS)をサポートする場合は、エンドポイントの保留、パークなどが可能です。
一部のベンダーでは、コールが転送またはリダイレクトされる際に、コールの帯域幅を増やすことができないようにコール設定を実装しています。 このようなケースでは、最初のコールがオーディオであると、ビデオ エンドポイントに転送された場合に、ユーザはビデオを受信できません。
現在、ビデオのメディア ターミネーション ポイント(MTP)またはビデオ トランスコーダは存在しません。 オーディオ トランスコーダまたは MTP がコールに挿入されている場合、そのコールはオーディオだけになります。 これに該当するのは、IPVC オーディオ変換機能を使用していない場合です。 IPVC トランスコーダを使用する場合は、オーディオを変換して、ビデオを送信/受信することができます。
H.323 ビデオ コールでは、ユーザがビデオ コールの帯域幅を指定する必要があります。
H.323 クライアントには、ゲートキーパーに登録されている E.164 アドレスを設定できます。 E.164 アドレッシングを使用すると、 Cisco Unified Communications Manager がゲートキーパーに代わってすべてのコールをルーティングできるため、H.323 設定とコール ルーティングが容易になります。 設定対象のゲートキーパーには、次の特性が必要です。
Cisco Unified Communications Manager はブート時に、E.164 アドレスや、H.323 クライアントごとに設定されたゲートキーパーなどの、スタティック設定情報をロードします。 同一のゲートキーパー ゾーンにある H.323 クライアントは、同一グループのままになります。 そのグループに対して、ゲートキーパーへの登録が起動されます。 このプロセスで、グループの各メンバーを個別に登録する必要はありません。
同じゲートキーパーとゾーンに所属する H.323 クライアントは、同じグループに所属し、このグループに対して登録が 1 回だけ起動されます。 同じゲートキーパーに最初のグループとして所属するものの、所属するゲートキーパー ゾーンが異なる H.323 デバイスは、別々のグループであり、このグループに対して登録が 1 回だけ起動されます。 同一グループのメンバーはすべて、同一のテクノロジー プレフィックスを使用します。
H.323 クライアントを着信側とする発信コールでは、 Cisco Unified Communications Manager が H.323 デバイスにコールを DN 単位でルーティングします。 Cisco Unified Communications Manager は H.323 デバイス設定を使用して、ゲートキーパーが設定されているかどうかを判別し、設定済みの E.164 アドレスを使用して許可要求(ARQ)を送信します。 デバイスがゲートキーパーに登録されると、ゲートキーパーはデバイスの現在の IP アドレスを使用して、アドミッション確認(ACF)を送信します。 Cisco Unified Communications Manager はコールをこのアドレスに直接ルーティングします。
H.323 デバイスを発呼側とする着信コールでは、ゲートキーパーが Cisco Unified Communications Manager にコールをルーティングします。 Cisco Unified Communications Manager は発信元の E.164 アドレスを使用して、発信側デバイスが設定されているかどうかを判別します。 Cisco Unified Communications Manager は、この設定を使用して、その電話機の設定を特定します。 電話機の設定には、リージョン、ロケーション、MRGL などが含まれています。
システムでは、H.323 トランク、クラスタ間トランク、および H.323 ゲートウェイに対する E.164 アドレッシングはサポートされていません。
ゲートキーパーによって制御される H.323 クライアントが設定されている場合、 Cisco Unified Communications Manager はデバイス名を解決しません。 Cisco Unified Communications Manager は H.323 クライアントのゲートキーパー フィールドにアクセスして、デバイスを検出することができます。 このため、 Cisco Unified Communications Manager はデバイス名の名前解決を避けることができます。
Cisco Unified Communications Manager は、ゲートキーパーによって制御される H.323 クライアントごとに、E.164 番号を最大で 1 つサポートします。 ゲートキーパー フィールドにデータを入力した場合、2 番目の DN を設定することはできません。 複数の DN が設定されている H.323 クライアントがある場合、追加のゲートキーパー情報をデータベースに追加することはできません。
ゾーン プレフィックスがない場合、ゲートキーパーはゾーン情報を使用してコールをルーティングします。
H.323 クライアントの設定でゲートキーパーを指定するには、そのゲートキーパーが Cisco Unified Communications Manager で設定されていることを確認する必要があります。 デフォルトでは、ゲートキーパー フィールドは空になっています。
H.323 クライアント設定に、[ゲートキーパー名(Gatekeeper Name)]、[テクノロジープレフィックス(Technology Prefix)]、[ゾーン(Zone)]、および [E.164] フィールドを必ず追加してください。 [ターミナルタイプ(Terminal Type)] を追加する必要はありません。 デフォルトは、ゲートウェイ タイプです。 これらの各フィールドを設定するときにゲートキーパーが [ゲートキーパー(Gatekeeper)] フィールドで選択されていない場合、これらのフィールドにデータを入力することはできません。
[ゲートキーパー(Gatekeeper)] フィールド、[ゾーン(Zone)] フィールド、[テクノロジープレフィックス(Technology Prefix)] フィールド、および E.164 情報は、H.323 クライアント設定の [ゲートキーパー情報(Gatekeeper Information)] グループの下に表示されます。
H.323 クライアントが別のクライアントと同じゲートキーパー、ゾーン、およびテクノロジー プレフィックスを使用する場合は、両方のクライアントを同一グループに含めることを考慮します。 このグループは、ゲートキーパーに対する単一エンドポイントを表します。
H.323 クライアントおよびトランクに、同一のゾーン名を使用することはできません。 H.323 クライアントが使用するゾーンは、H.323 トランクや、ゲートキーパーによって制御されるクラスタ間トランクが使用するゾーンとは異なる必要があります。
Send Product Id and Version ID サービス パラメータが [True] に設定されていることを確認します。
H.323 クライアントに E.164 アドレスとゲートキーパーを設定する場合、設定が更新されると、データベースにこの情報が格納されます。 この情報は、ブート時またはデバイスのリセット時にロードされます。
拡張ビデオ チャネル機能は、H.239 プロトコルを介して機能し、複数のビデオ チャネルのサポートを実現します。 Cisco Unified Communications Manager は、ダイレクト ポイントツーポイント H.323 コールで H.239 プロトコルを使用して拡張ビデオ チャネルをネゴシエートする処理をサポートしています。 これには、H.323 クラスタ間トランク上のコールも含まれます。
Cisco Unified Communications Manager は、H.239 の勧告で指定されている H.239 サポート関連の信号とコマンドをすべてサポートしています。
拡張ビデオ チャネル機能は、サードパーティのビデオ エンドポイント間での H.239 の相互運用性と、Cisco Unified Voice Conferencing をサポートしています。 Cisco Unified Communications Manager では、プレゼンテーションや、会議のライブ転送に拡張ビデオ チャネルを使用できます。 この機能は、H.245 シグナリングによるマルチ ビデオ チャネルのサポートに重点を置いています。 このマルチチャネルのサポートの基盤となるのが次のプレゼンテーション アプリケーションです。
Natural Presenter Package と People+Content のいずれも、H.239 プロトコルを使用して機能のネゴシエートを実行し、追加ビデオ チャネルのロールを定義します。
![]() (注) |
Tandberg 製の Natural Presenter Package と Polycom 製の People+Content のみがプレゼンテーション モード用に H.239 をサポートしています。 |
![]() (注) |
Tandberg と Polycom から提供されているプレゼンテーション アプリケーションはオプションの機能です。 追加ビデオ チャネルのネゴシエートを実行するには、このオプション機能のいずれかが使用可能になっている必要がある他、発信者と被発信者の両方のエンドポイントで H.239 が有効になっている必要があります。そうでない場合、コールのビデオ チャネルが 1 つに制限されます。 |
Tandberg と Polycom のビデオ エンドポイントを使用すると、さまざまなコンポーネント(VCR、プロジェクタ、PC など)のプレゼンテーション資料を共有できます。 このコンポーネントをエンドポイントに物理的に接続できます。また、ベンダーから提供されるプレゼンテーション アプリケーションを PC で実行して、プレゼンテーション イメージを転送することも可能です。 プレゼンテーション ソースと、ビデオ エンドポイントへのコンポーネントの接続は、H.239 を使用してビデオ チャネルを確立するメカニズムとは無関係です。
![]() (注) |
プレゼンテーション ソースの設定方法の詳細については、ビデオ エンドポイントのユーザ ガイドを参照してください。 |
H.239 対応の 2 台のエンドポイントがビデオ コールを確立するとき、これらの端末は、会議の参加者用のメイン ビデオ チャネルと、追加ビデオ チャネル用の拡張ビデオ機能(H.239 機能)を確保するために、自身のビデオ機能を宣言します。 H.239 機能の信号は次のように構成されます。
H.239 をサポートしていることを示す信号をエンドポイントが送信します。 また、これらの端末は、関連コマンドや追加ビデオ チャネルを管理する指示信号も送信します。 これにより、両方のエンドポイントがコールで複数のビデオ チャネルを開くことができると認識できます。
エンドポイントは、1 つまたは複数の拡張ビデオ コーデックの機能を送信して、追加チャネルのビデオ コーデックの機能を提示します。 このエンドポイントでは、追加ビデオ チャネルのロールを指定する必要があります。 定義されるロールのラベルを次に示します。
機能に関するやり取りが行われた直後、従来のビデオ コールと同じように、両方のエンドポイントは双方向のオーディオ チャネルとメイン ビデオ チャネルを開きます。
Tandberg の場合、要求に応じて追加ビデオ チャネルが開始されます。 Tandberg のデバイスは、メイン ビデオ チャネルが確立されても、追加ビデオ チャネルをすぐに開きません。 追加チャネルが開かれるのは、発信者のいずれか(プレゼンター)がプレゼンテーションのソースを指定し、プレゼンテーションを開始するコマンドを実行したときです。
Tandberg ユーザがプレゼンテーションの共有を開始することを決定すると、Tandberg は、プレゼンテーションのイメージを受信するための拡張ビデオ チャネルを開くことをコール相手に要求します。このため、Tandberg ユーザ間のコールでは、一方向のみの追加ビデオ チャネルが使用されます。
Tandberg とは異なり、Polycom のビデオ エンドポイントは、そのメカニズムのデフォルトの動作として、両方のビデオ エンドポイントが追加ビデオ チャネルをサポートしていることを確認した後、すぐに追加ビデオ エンドポイントを開きます。
![]() (注) |
両方の端末が H.239 をサポートし、拡張ビデオ チャネル機能が有効になっている場合、チャネルは自動的に確立されますが、 どちらかの端末がプレゼンテーションの共有を開始するまで、追加チャネルからは何も表示されません。 |
Polycom は、追加ビデオ チャネルを使用するかどうかに関係なく、追加ビデオ チャネルをコール相手に要求します。このため、Polycom ユーザ間のコールでは、1 つのデバイスのみがプレゼンテーションのイメージやビデオを送信する場合でも、双方向のビデオ チャネルがデバイス間で開かれます。
このような実装により、何かを提示するトークンを取得することを決定したときには、コールの両端で追加ビデオ チャネルでの転送準備ができていることになります。 2 つのビデオ チャネルのどちらかはアイドル(何も送信しない)状態ですが、Polycom デバイスは帯域幅を制御して負荷を効率化します。
![]() (注) |
この追加ビデオ チャネルの扱い方の違いは、H.239 の実装には影響しません。 Cisco Unified Communications Manager は、H.323 対 H.323 のコールでは受信チャネル要求を行いません。 Cisco Unified Communications Manager は、端末間ですべてのチャネル要求を中継するだけです。 |
![]() (注) |
Cisco Unified Communications Manager は、追加のビデオ チャネルのセットに対して双方向の転送を強制しません。これは、H.239 プロトコルの要件ではないためです。 |
Cisco Unified Communications Manager の次のコール アドミッション制御ポリシーが追加ビデオ チャネルに適用されます。
Cisco Unified Communications Manager は、ロケーション設定に基づいて、追加ビデオ チャネルによる帯域幅の使用を制限します。 追加ビデオ チャネルが確立されているとき、 Cisco Unified Communications Manager はロケーション プールで充分なビデオ帯域幅が使用できる状態が維持されることを確認し、適切な帯域幅を予約します。 必要な帯域幅が使用できない場合、 Cisco Unified Communications Manager は使用可能な帯域幅をゼロにするようにチャネルに指示します。
リージョンの設定やポリシーが、追加ビデオ チャネルをサポートするために変更されることはありません。
従来の Cisco Unified Communications Manager のリージョン ポリシーは、ビデオ チャネルが 1 つのコールのみをサポートしており、このコールの帯域幅の合計使用量がリージョンの設定で指定されている値を超えることはありません。
管理者が H.239 コールを対象としてリージョンのビデオ帯域幅に一定の制限を設定した場合、そのリージョンの値が、ビデオ チャネルごとに独立して要求される帯域幅に対して使用されるため、 Cisco Unified Communications Manager でリージョン ポリシーの違反が発生します。
If the region video bandwidth is set to 384Kbps and the audio channel uses 64Kb/s, the maximum allowed bandwidth for each video channel will be (384Kb/s - 64Kb/s)= 320Kb/s. i.e. the maximum bandwidth to be used by the H.239 call will be (audio bw + 2*(384 - audio bw)) = 704Kb/s, which goes beyond the 384Kb/s bandwidth that the region specifies.
![]() (注) |
H.239 コールのリージョンとロケーションの両方の帯域幅制限を緩和して、 Cisco Unified Communications Manager が関与しなくても H.239 デバイスが両方のビデオ チャネルの負荷を再調整およびバランシングできるようにすることを検討する必要があります。 |
Cisco Unified Communications Manager は、次の理由により、最大で 2 つのビデオ チャネルだけをサポートしています。
Command and Indication(C&I)メッセージは、H.239 がプレゼンテーション ロールや Live ロールのトークンを管理したり、ビデオ フロー制御の解放要求をデバイスに許可して、追加のメディア チャネルを操作できるようにしたりするために使用されます。 Cisco Unified Communications Manager はすべての C&I メッセージをサポートしています。 Cisco Unified Communications Manager は、C&I メッセージを受け取ると、コール相手に適切に中継します。
フロー制御解放の要求メッセージと応答メッセージは、相手側のフロー制御解放の要求に使用できるため、エンドポイントは指定されたチャネルを指定されたビット レートで送信できます。
![]() (注) |
コール相手は、フロー制御解放の応答に示されているとおりに要求を受け付けることもあれば、受け付けないこともあります。 |
プレゼンテーション ロールのトークンのメッセージにより、H.239 デバイスはプレゼンテーションのトークンを取得できます。 コール相手は、要求を受諾または拒否できます。 プレゼンターのデバイスは、不要になった時点で、トークンの解放メッセージを送信します。
Cisco Unified Communications Manager は、H.323 対 H.323 のコールで H.239 だけをサポートしています。 Cisco Unified Communications Manager により、H.239 コールを H.323 クラスタ間トランクまたは複数のノード経由で確立できます。 H.239 対応のデバイスが、非 H.323 デバイスにコールを実行した場合、H.239 の機能は無視され、コールは Cisco Unified Communications Manager でサポートされる従来のビデオ コールと同じように実行されます。
メディア ターミネーション ポイントまたはトランスコーダがコールに挿入されていると、追加ビデオ チャネルは Cisco Unified Communications Manager でサポートされません。 この場合、コールは通常のビデオ コールにフォールバックされます。
Cisco Unified Communications Manager では、H.323 対 H.323 のダイレクト コールでのみ、追加ビデオ チャネルを開くことができます。
![]() 注意 |
コール転送や保留/再開操作など、コール中の機能を実行しないでください。 実行すると、問題が発生し、追加ビデオ チャネルが切断されることがあります。 |
ビデオ会議では、Skinny Client Control Protocol ビデオ ブリッジが必要になります。 Skinny Client Control Protocol ビデオ ブリッジの特性は、次のとおりです。
ビデオ対応のスマートフォンで実行され、Cisco Unified Communications Manager に登録されているデュアル モード スマート クライアントでは、スマートフォンと別のビデオ対応エンドポイント間で VoIP 経由でビデオ コールを行うことができます。
Cisco Dual Mode for iPhone(TCT)がビデオに対応している場合、Cisco Unified Communications Manager により IP 経由で別のビデオ対応エンドポイントにコールできます。
ビデオの有効化/無効化の切り替えオプションは、CCMAdmin のデバイス ページで使用できます。 また、ビデオを使用した保留/再開、会議、転送などの通話中の機能も使用できます。
コール設定全体で、Cisco Unified Communications Manager によってソフトウェア MTP が割り当てられている場合、MTP ではビデオ ストリーミングがサポートされないため、ビデオ ストリーミングはサポートされません。
コールにハードウェアのマルチメディア IOS MTP が割り当てられている場合、ビデオの使用は次の特定の条件に基づきます。
トランクとゲートウェイで [メディアターミネーションポイントが必須(Media Termination Point Required)] がオンになっているために MTP が割り当てられている場合、ビデオ ストリーミングは使用できません。
Unified Mobility で DTMF の検出用に MTP が必要な場合、ビデオは使用できません。
トランスコーダのため、またデバイス、トランク、およびゲートウェイでの TRP チェックのために MTP が割り当てられている場合、ビデオを使用できます。
SIP ビデオは、SIP シグナリング インターフェイス(SSI)を使用して、次のビデオ コールをサポートします。
SIP ビデオ コールには、ビデオ会議のメディア制御機能もあります。
Cisco Unified Communications Manager ビデオは、両方の SIP トランクで SIP をサポートし、回線はビデオ シグナリングをサポートします。 SIP は、H.261、H.263、H.263+、H.264(AVC)、H.264(SVC)、X-H.264UC(Lync)、および H.265 の各ビデオ コーデックをサポートします(VTA で使用される wideband video コーデックはサポートしません)。
RFC 2833 に使用されるメディア ターミネーション ポイント(MTP)は、1 つのセッション内で複数の論理チャネルをサポートします。 論理チャネルは、オーディオ用でもビデオ用でもかまいません。 ビデオ チャネルをサポートするため、MTP はパススルー モードを使用します。 ビデオ パススルーは、MTP がパススルーと複数の論理チャネルの両方をサポートしている場合に使用可能です。 MTP デバイスの中には、複数の論理チャネルとパススルー モードをサポートしていないものもあります。
Cisco Unified Communications Manager の管理ページの [電話の設定(Phone Configuration)] ウィンドウで、シスコのカメラおよびビデオ機能製品固有の設定を [有効(Enabled)] に設定します。
電話機をリセットします。
詳細については、『 Cisco Unified IP Phone 8961, 9951, 9971 User Guide for Cisco Unified Communications Manager (SIP)』を参照してください。
Cisco Unified Communications Manager は、ビデオ会議用のさまざまなソリューションをサポートしています。 次のビデオ会議ブリッジは、アドホック ビデオ会議とミートミー ビデオ会議をサポートしています。
Cisco TelePresence MCU は、Cisco Unified Communications Manager 用のハードウェア会議ブリッジのセットです。
Cisco TelePresence MCU は、高解像度(HD)のマルチポイント ビデオ会議ブリッジです。 毎秒 30 フレームで最大 1080p の性能を持ち、あらゆる会議で十分な連続表示を実現し、フルトランスコーディング機能を備えているため、マルチベンダーの HD エンドポイント環境に最適です。 Cisco TelePresence MCU では、シグナリング コール制御プロトコルとして SIP をサポートしています。 詳細に設定でき、システムおよび会議を制御およびモニタする、ビルトイン Web サーバを装備しています。 Cisco TelePresence MCU には、HTTP 通信による XML 管理 API が用意されています。
Cisco TelePresence MCU を使用すると、アドホックとミートミーの両方の音声会議とビデオ会議を実現できます。 どの方式の会議ブリッジも、複数の参加者による複数の会議を同時にサポートしています。 Cisco TelePresence MCU は、ポート予約モードで設定する必要があります。
Cisco TelePresence Conductor を使用すると、会議の管理をインテリジェントに制御できます。Cisco TelePresence Conductor は、クラスタ化をサポートする、拡張性の高いデバイスで、MCU 間のロード バランシングを行い、複数のデバイスを利用可能にします。 管理者は、アプライアンスまたは VMware 上の仮想アプリケーションとして Cisco TelePresence Conductor を導入して、Cisco Unified Computing System(Cisco UCS)プラットフォームまたはサードパーティベースのプラットフォームをサポートすることができます。 動的な 2 方向または 3 方向会議が可能な多方向会議もサポートしています。
Cisco TelePresence Conductor を使用すると、アドホックとミートミーの両方の音声会議とビデオ会議を実現できます。 Cisco TelePresence Conductor は、新しい会議ごとに最適な Cisco TelePresence リソースを動的に選択します。 アドホック、「ミートミー」、およびスケジュール済みの音声会議とビデオ会議では、MCU 単体のキャパシティを超えて動的に規模を拡張できます。 Cisco TelePresence Conductor アプライアンスまたは Cisco TelePresence Conductor クラスタ 1 つで、30 MCU または 2400 MCU ポートをサポートします。 最大 3 つの Cisco TelePresence Conductor アプライアンスまたは仮想アプリケーションをクラスタ化して、復元力をさらに高めることができます。
Cisco Unified MeetingPlace は総合的なコラボレーション ソリューションで、アドホック ビデオ会議とミートミー ビデオ会議の両方をサポートするビデオ会議ブリッジとして機能するように設定できます。 また、Cisco Unified MeetingPlace を Cisco WebEx と連動させると、Web 会議とコンテンツ共有のさまざまなソリューションを利用できます。
Cisco Unified MeetingPlace の展開は、規模と複雑さによって異なります。 このソリューションの配備は、単一サーバ上でも複数サーバ上でも構いません。 Cisco Unified MeetingPlace のすべての展開に、Cisco MCS にインストールされるアプリケーション サーバが含まれます。 アプリケーション サーバは、ソリューションのメディア サーバを制御します。
ビデオ会議機能は、メディア サーバによって提供されます。 Cisco Unified MeetingPlace ソリューションでは、Express Media Server と Hardware Media Server の 2 つのメディア サーバ オプションが用意されています。 Express Media Server は、アプリケーション サーバ上にインストールされるソフトウェアベースのメディア サーバで、シングルボックスの展開が可能です。 Hardware Media Server は、別の Cisco 3500 シリーズ メディア サーバにインストールされる音声ブレードとビデオ ブレードで構成されます。
Web 展開の場合は、オプションの Web サーバを含めることもできます。
Cisco Unified MeetingPlace を会議ブリッジとして設定しており、Express Media Server 展開を使用している場合、この会議ブリッジはアドホック ビデオ会議とミートミー ビデオ会議の両方をサポートします。 Express Media Server は H.263 と H.264/AVC の両方のビデオ コーデックをサポートしていますが、1 つの会議での異なるコーデック間のトランスコーディングはサポートしていません。
Express Media Server では、会議を始める前に、表示解像度の指定を行うビデオ モードを設定する必要があります。 アドホック会議では、すべてのアドホック会議で 1 つのシステム全体の設定を共有します。 従来の CIF エンドポイントをアドホック ビデオ会議に参加させる場合、すべてのアドホック会議を CIF の解像度 352 x 288 に制限する必要があります。
Hardware Media Server 展開を使用している場合、会議ブリッジでサポートされるのはミートミー ビデオ会議だけです。 ビデオ コーデック間のトランスコーディングはサポートされます。 また、参加者は、会議の音声部分とビデオ部分を記録できます。
次の表に、Cisco Unified MeetingPlace で利用できる主なビデオ会議機能について概要を示します。 全体的な会議キャパシティは、設定値、物理的なハードウェアなどのさまざまな要因によって異なります。 全体的なキャパシティは、ビデオ解像度が低く、かつ G.711 などの低帯域幅の音声コーデックの場合に最も大きくなります。 高解像度のビデオや高帯域幅の音声コーデックでは、キャパシティが小さくなります。
Cisco Unified MeetingPlace の機能の詳細については、Cisco Unified MeetingPlace の製品マニュアルを参照してください。
機能 | Express Media Server | Hardware Media Server | ||
---|---|---|---|---|
会議 | アドホックとミートミー | ミートミー | ||
音声コーデック | G.711 G.722 G.729a |
G.711 G.722 G.729a iLBC |
||
ビデオ コーデック | H.263 H.264/AVC |
H.261 H.263 H.264/AVC |
||
記録 | ビデオは記録不可 | 会議の音声部分とビデオ部分の両方を記録可能 | ||
H.264 と H.263AVC 間のトランスコーディング | いずれのコーデックもサポートされるが、同じ会議内ではサポートされない | サポートされる | ||
ビデオ解像度 | 最大 1280 X 720 | 352 X 288 | ||
コール合計数 | 音声の場合、最大1300 ビデオの場合、最大 650
|
音声の場合、最大2000 ビデオの場合、最大 300 |
第 2 世代シスコ サービス統合型ルータ(ISR G2)は、アドホックとミートミーのオーディオ会議およびビデオ会議をサポートする IOS ベースの会議ブリッジとして動作するよう有効にできます。 会議を有効にするには、PVDM3 DSP モジュールを ISR G2 ルータにインストールする必要があります。 ISR G2 ルータには、次のシリーズがあります。
アドホック ビデオ会議の場合、ISR G2 ルータは最大 8 人の参加者をサポートします。 ミートミー ビデオ会議の場合、最大 16 人の参加者をサポートします。 ビデオ会議では、解像度、ビット レート、およびフレーム レートは使用されるビデオ フォーマットによって異なりますが、ISR G2 ルータは最大 30 f/s のフレーム レート、最大 2 Mb/s のストリーム ビット レート、および最大 704 X 568 ピクセルのビデオ解像度をサポートできます。 各ビデオ フォーマットのコーデック、フレーム レート、ビット レート、およびビデオ解像度の詳細については、『Configuring Video Conferences and Video Transcoding』のマニュアルを参照してください。
Cisco Unified Communications Manger 内で、次の 3 つの会議ブリッジ タイプのいずれかとして ISR G2 ルータを設定できます。
Cisco IOS Homogeneous Video Conference Bridge:同種間ビデオ会議で、すべての会議参加者が、同じビデオ フォーマット属性をサポートしている電話機により会議ブリッジに接続します。 すべてのテレビ電話が同じビデオ フォーマットをサポートし、会議ブリッジは同じデータ ストリーム フォーマットをすべてのビデオ参加者に送信します。
Cisco IOS Heterogeneous Video Conference Bridge:異種間ビデオ会議で、すべての会議参加者が、異なるビデオ フォーマット属性を使用する電話機により会議ブリッジに接続します。 信号を別のビデオ フォーマットに変換するために、DSP からのトランスコーディング機能が必要です。
Cisco IOS Guaranteed Audio Video Conference Bridge:保証されたオーディオ ビデオ会議で、オーディオ会議ブリッジ用の DSP リソースは予約されますが、ビデオ サービスは保証されません。 これは、DSP リソースが限られている場合に必要になる可能性があります。 テレビ電話の発信側は、会議の開始時点で DSP リソースが使用可能であれば、ビデオ サービスを利用できます。 それ以外の場合、発信側はオーディオ会議参加者として会議に接続されます。
ISR G2 ルータによるビデオ会議の詳細については、『Configuring Video Conferences and Video Transcoding』のマニュアルを参照してください。
Cisco Unified Communications Manager は、Cisco TelePresence Video Communications Server(VCS)との相互運用が可能です。 2 つのシステムに互換性を持たせるため、Cisco Unified Communications Manager が Cisco VCS に接続する SIP トランクに SIP 正規化スクリプトを設定する必要があります。 この正規化スクリプトによって、2 つの製品が通信できるように SIP シグナリングを調整します。
Cisco TelePresence Video Communication Server は、Cisco TelePresence 製品ラインに対する、高度なテレプレゼンスとビデオ会議のコール制御を提供し、 標準対応のすべての SIP デバイスと H.323 デバイス間でエニーツーエニーの相互運用性を可能にします。次の 3 つの展開オプションを利用できます。
Server Control として、Cisco TelePresence Video Communication Server は、標準対応のすべてのテレプレゼンス エンドポイント、インフラストラクチャ、および管理ソリューションに対して、高度なテレプレゼンス アプリケーションとセッション管理を提供します。 Cisco VCS Control は、Session Initiation Protocol(SIP)プロキシおよび H.323 ゲートキーパー サービスを提供します。
Server Expressway として、Cisco TelePresence Video Communication Server は、SIP デバイスと H.323 デバイスに対して標準ベースのセキュアなファイアウォール トラバーサルを提供します。 Cisco VCS Expressway により企業間のコミュニケーションが可能になり、リモートおよび自宅ベースのワーカーに能力を与えることができます。また、サービス プロバイダーは、顧客にビデオ コミュニケーションを提供できます。
Starter Pack Express の展開では、Cisco TelePresence Video Communication Server は、中小規模の Cisco TelePresence システムを初めて導入する企業を対象としたオールインワンのソリューションを提供します。
Cisco Unified Communications Manager と Cisco VCS の相互運用を可能にするには、Cisco Unified Communications Manager が Cisco VCS に接続する SIP トランクで次の手順を実行します。
ステップ 1 | Cisco Unified Communications Manager の管理ページで、 を選択します。 |
ステップ 2 | Cisco Unified Communications Manager が Cisco VCS に接続する SIP トランクを選択します。 |
ステップ 3 | [SIP プロファイル(SIP Profile)] ドロップダウン リスト ボックスで、[VCSの標準SIPプロファイル(Standard SIP Profile for VCS)] を選択します。 |
ステップ 4 | [正規化スクリプト(Normalization Script)] ドロップダウン リスト ボックスで、[vcs-interop] を選択します。 |
ステップ 5 | [正規化スクリプト(Normalization Script)] 領域で、[パラメータ名(Parameter Name)] フィールドと [パラメータ値(Parameter Value)] フィールドを空白のままにします。 これらのフィールドにすでに値が設定されている場合は、フィールドの内容を削除します。 |
Cisco Unified Communications Manager は、通信にかかわる個々のエンドポイントでも暗号化がサポートされている場合、オーディオ、ビデオなどのメディア ストリームの暗号化をサポートします。 Cisco Unified Communications Manager は、Secure Real-Time Transport Protocol(SRTP)を使用して、メディア ストリームを暗号化します。 機能の一部として、次のサポートを含みます。
SIP および H.323 のエンドポイントのサポート
メディア ターミネーション ポイント(MTP)passthru モードで動作時のメインのオーディオおよびビデオ回線の暗号化のサポート
複数の暗号化方式のサポート
RFC 4568 に従った Session Description Protocol(SDP)crypto-suite セッション パラメータのサポート
暗号化された通信を提供するため、SIP コール設定時にエンドポイントと Cisco Unified Communications Manager の間で暗号キーが交換されます。 このような理由から、SIP シグナリングは TLS を使用して暗号化する必要があります。 初期コール設定時に、ビデオ エンドポイントは、サポートする暗号化方式のリストを交換し、両方のエンドポイントでサポートされる暗号スイートを選択して、暗号キーを交換します。 エンドポイント間で共通の暗号スイートが得られない場合、メディア ストリームは暗号化されず、Real-Time Transport Protocol(RTP)を使用して転送されます。
![]() (注) |
個々のエンドポイントが暗号化をサポートしていない場合、RTP を使用して通信が行われます。 |
Cisco Unified Communications Manager は、さまざまな暗号スイートをサポートしています。 暗号化方式は、SIP メッセージの SDP 部分の Crypto-suite オプションを使用して特定します。 次の表に、 Cisco Unified Communications Manager でサポートされる SDP 暗号スイートを示します。
暗号化規格 |
説明 |
---|---|
AES_CM_128_HMAC_SHA1_80 |
128 ビット暗号キーおよび 80 ビット メッセージ認証タグ |
AES_CM_128_HMAC_SHA1_32 |
128 ビット暗号キーおよび 32 ビット メッセージ認証タグ |
F8_128_HMAC_SHA1_80 |
128 ビット暗号キーおよび 80 ビット メッセージ認証タグ |
上記の方式に加えて、Cisco Unified Communications Manager はメディア ストリームの DTLS 暗号化もサポートしています。
個々のコールに使用する暗号化方式の選択は、個々のエンドポイント自体で使用できる暗号スイートに従って行われます。 エンドポイント間で暗号化方式が一致しない場合、メディアは暗号化されず、RTP を使用して転送されます。
Cisco Unified Communications Manager は、SIP オファー/アンサー モデルを使用して、RFC 3264 に定義されているように、SIP セッションを確立します。 このコンテキストでは、発信側デバイスが SIP メッセージの本文にある SDP フィールド内に含まれるオファーを作成します。 オファーは通常、デバイスでサポートされる暗号化方式を含め、デバイスでサポートされるメディア特性を定義します。その他に、使用するメディア ストリーム、コーデック、IP アドレス、およびポートも定義します。
受信側デバイスは、SIP 応答の SDP フィールドのアンサーで、対応する自身の暗号スイート、一致するメディア ストリーム、コーデック、およびメディア ストリームを受信する IP アドレスとポートを指定して応答します。 Cisco Unified Communications Manager は、このオファー/アンサー モデルを使用して、重要な SIP 規格である RFC 3261 で定義される SIP セッションを確立します。
SIP オファー/アンサー モデルの動作は、機能によって異なります。 早期オファーと遅延オファーのプロセスは、わずかに異なります。
早期オファー セッションでは、着信側デバイスは、適切な暗号スイートを選択します。 この場合、発信側デバイスは、元の SIP invite メッセージで優先する暗号スイートを送信します。 着信側デバイスは、発信者が提供する暗号化方式のリストを、自身が使用可能な暗号化方式のリストと比較し、最適なオプションを選択します。 Re-Invite は、早期オファーと同じように処理されます。
遅延オファー セッションでは、発信側デバイスは、サポートする暗号化方式のリストを含めます。 最初の invite を受信すると、 Cisco Unified Communications Manager は、暗号化方式を含む SDP 部分を含めずに、INVITE を着信側デバイスに転送します。 着信側デバイスは、暗号化方式の自身のリストを含めて応答します。 Cisco Unified Communications Manager は、2 つのリストを比較し、両方のエンドポイントでサポートされる適切な暗号化方式を選択します。
Cisco Unified Communications Manager には、ビデオの暗号化に関する次の制限事項があります。
次の表に、特定のシグナリング方式を使用する場合にサポートされる暗号化方式を示します。
シナリオ |
サポート |
---|---|
SIP-SCCP |
SCCP を介したビデオの暗号化はサポートされません。 |
MTP/RSVP/TRP を使用する SIP-SIP |
ビデオの暗号化がサポートされます。 ただし、MTP passthru モードでは、メインのオーディオおよびビデオ回線だけが暗号化されます。 |
H.323 ICT を介した SIP-SIP |
H.323 トランクを介したビデオの暗号化はサポートされません。 オーディオの暗号化だけがサポートされます。 |
SIP-H.323 |
SIP エンドポイントから H.323 エンドポイントへのコールではビデオの暗号化はサポートされません。 |
H.323-H.323 |
H.235 を使用してビデオの暗号化がサポートされます。 |
Cisco Unified Communications Manager 8.6(2) は、特定のシスコのビデオ エンドポイントとサードパーティのビデオ エンドポイントで Binary Floor Control Protocol(BFCP)をサポートします。 BFCP を使用すると、ユーザは通話中のビデオによる会話内でプレゼンテーションを共有できます。
次に、BFCP を使用したプレゼンテーション共有の仕組みの例を示します。
2 つのテレビ電話間で通話中のビデオによる会話が行われています。 ユーザ A は、ラップトップに保存されているスライドのプレゼンテーションをユーザ B に見せることにします。 ユーザ A は、ラップトップを Cisco EX90 テレビ電話に接続し、電話機の [表示] ボタンを押します。 SIP INVITE メッセージが相手の電話機に対して開始され、BFCP ストリームへの招待が行われます。 BFCP セッションがネゴシエートされた後に、さらにストリームがオーディオおよびビデオのストリームに追加されます。 BFCP ストリームにより、ユーザ B は、ユーザ A のラップトップのデスクトップを表示できます。
次のシスコのビデオ エンドポイントでは、エンドポイントのデバイスの認定と評価(QED)設定により、BFCP がデフォルトで有効になります。 BFCP が自動的に有効になるため、Cisco Unified Communications Manager ではこれらのエンドポイントの構成オプションを提供していません。
Cisco E20
Cisco TelePresence Codec C40
Cisco TelePresence Codec C60
Cisco TelePresence Codec C90
Cisco TelePresence EX60
Cisco TelePresence EX90
Cisco TelePresence Quick Set C20
Cisco TelePresence Profile 42(C20)
Cisco TelePresence Profile 42(C60)
Cisco TelePresence Profile 52(C40)
Cisco TelePresence Profile 52 Dual(C60)
Cisco TelePresence Profile 65(C60)
Cisco TelePresence Profile 65 Dual(C90)
Cisco TelePresence
Cisco TelePresence 1000
Cisco TelePresence 1100
Cisco TelePresence 1300-47
Cisco TelePresence 1300-65
Cisco TelePresence 1310-65
Cisco TelePresence 3000
Cisco TelePresence 3200
Cisco TelePresence 500-32
Cisco TelePresence 500-37
次のサードパーティのビデオ エンドポイントでは、BFCP がデフォルトで無効になりますが、サポートは [電話の設定(Phone Configuration)] ウィンドウの [プロトコル固有情報(Protocol Specific Information)] で有効にできます。
BFCP を使用するプレゼンテーション共有は、完全な SIP ネットワークだけでサポートされます。 エンドポイント、およびすべての中間デバイスとトランクを含むネットワーク全体が SIP である必要があります。 BFCP は、すべての SIP トランクおよび SIP 回線で有効になっている必要があります。
SIP トランクで BFCP を設定するには、[SIP プロファイルの設定(SIP Profile Configuration)] ウィンドウの [トランク固有の設定(Trunk Specific Configuration)] セクションにある [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスをオンにします。
SIP 回線で BFCP を設定するには、次の手順を実行します。
BFCP をサポートするシスコのビデオ エンドポイントでは、SIP 回線の設定は必要ありません。
BFCP をサポートするサードパーティのビデオ エンドポイントでは、[電話の設定(Phone Configuration)] ウィンドウの [プロトコル固有情報(Protocol Specific Information)] セクションにある [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスをオンにすることにより、BFCP を有効にします。
![]() (注) |
この機能で、次の GUI の変更が行われています。
|
新しいバージョン(15.2(2)T)の IOS メディア ターミネーション ポイント(MTP)ルータが利用できるようになり、セッションあたり最大 16 のメディア ストリーム(以前のリリースでは最大 3 ストリームのみ)が可能になったため、Cisco Unified Communications Manager で BFCP および追加ビデオ チャネルをサポートできるようになりました。 BFCP コールでは、追加ビデオ チャネルでビデオ会議とプレゼンテーション共有を達成するために、通常、4 つ以上チャネル(オーディオ、メイン ビデオ、追加ビデオ、および BFCP 制御チャネル)が必要です。 コールの両側が遠端カメラ制御(FECC)に対応している場合、5 つ目のチャネルを確立する必要があります。
![]() (注) |
MTP には、BFCP セッションをサポートするために十分なメディア ポートがないため、コールが確立されるときに BFCP メディア回線はネゴシエートされません。 |
Cisco Unified Communications Manager は、Binary Floor Control Protocol(BFCP)を使用した通話中のビデオによる会話内でプレゼンテーション共有をサポートします。
Cisco Unified Communications Manager は、BFCP セッションが確立するまで、2 つのエンドポイント間で SIP メッセージをリレーすることで、BFCP ストリームのネゴシエーションを支援します。 このネゴシエーションには、共有リソースへのアクセスの一時的な権限である、フロアの確立を伴います。 BFCP ストリームは、エンドポイント間のポイントツーポイント ストリームです。 Cisco Unified Communications Manager が BFCP ストリームのターゲットになることはありません。
BFCP によるプレゼンテーション共有の仕組みについての例として、2 つの SIP テレビ電話間で通話中のビデオによる会話を行っていたとします。 ユーザ A は、ラップトップに保存されているスライドのプレゼンテーションをユーザ B に見せることにします。 ユーザ A は、ラップトップを Cisco EX90 テレビ電話に接続し、電話機の [表示] ボタンを押します。 これにより、BFCP ストリームの作成のために、SDP パラメータを含む SIP INVITE メッセージが相手の電話機に送信されます。 BFCP セッションがネゴシエートされた後に、さらにストリームがオーディオおよびビデオのストリームに追加されます。 BFCP ストリームにより、ユーザ B は、ユーザ A のラップトップのデスクトップを表示できます。
BFCP は、SIP ネットワークだけでサポートされます。 すべてのエンドポイント、中間デバイス、およびトランクを含むネットワーク全体が SIP である必要があります。 BFCP は、すべての SIP トランクおよび SIP 回線で有効になっている必要があります。
![]() (注) |
BFCP は IME トランクではサポートされないため、IME トランクに使用される SIP プロファイルでは、BFCP が無効になっている必要があります。 |
次のネットワーク図に、BFCP に使用されるネットワーク トポロジを示します。 Cisco Unified Communications Manager クラスタは、デバイス間での SIP メッセージの転送時だけ関与します。 エンドポイントが BFCP をネゴシエートした後は、BFCP ストリーム自体がデバイス間のポイントツーポイント ストリームです。
次の図に、BFCP 対応のネットワークの例を示します。 このネットワークは完全に SIP に対応しています。 Cisco Unified Communications Manager クラスタは中央に配置され、エンドポイント間の SIP シグナリングをリレーします。 オーディオおよびビデオのストリームだけでなく、BFCP ストリームもエンドポイント間のポイントツーポイントです。
Cisco Unified Communications Manager で BFCP を有効にするには、[SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウの [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスをオンにします。 チェックボックスをオンにしない場合、すべての BFCP オファーは拒否されます。 デフォルトでは、このチェックボックスはオフです。
BFCP は、完全な SIP ネットワークだけでサポートされます。 プレゼンテーション共有を機能させるには、BFCP は、エンドポイント間のすべての SIP 回線および SIP トランクだけでなく、すべての SIP エンドポイントで有効になっている必要があります。
次の図に、複数の Cisco Unified Communications Manager クラスタを使用する複雑なビデオ ネットワークの例を示します。 BFCP は、デバイスに接続されているすべてのトランクおよび回線で有効になっている必要があります。 このネットワークの場合、BFCP は、エンドポイントに接続する 4 つの SIP トランクと 2 つの SIP 回線で有効になっている必要があります。
次のシナリオにおいて、 Cisco Unified Communications Manager は BFCP ストリー ムを拒否します。
ネットワーク内の SIP 回線または SIP トランクのうちいずれかの [SIPプロファイル(SIP Profile)] ページの [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスがオフにされている。
一方のエンドポイントが BFCP をオファーするが、相手側のエンドポイントはオファーしない。
SIP 回線または SIP トランクが、MTP、RSVP、信頼されたリレー ポイント(TRP)、またはトランスコーダを使用する。 これらの場合、BFCP はサポートされません。
![]() (注) |
BFCP は、コールに MTP が不要である場合に限り、Cisco Unified CM Release 8.6 でサポートされます。 Cisco Unified CM リリース 9.0 以降では、MTP コールの BFCP は、MTP が 15.2.(2) T を実行している IOS ルータから割り当てられている場合、サポートされます。 |
BFCP は、SIP エンドポイントだけでサポートされます。
![]() (注) |
BFCP は、Cisco Unified Communications Manager と Cisco TelePresence MCU 間で使用されている場合、サポートされません。 |
次の表に、BFCP プレゼンテーションを進行しながら一般的な機能を扱う方法を紹介します。
通話中の機能 |
サポート |
---|---|
保留と再開 |
保留と再開の機能は、BFCP 対応エンドポイントを使用している場合、エンドポイントが現在 BFCP プレゼンテーションの最中かどうかにかかわらず完全にサポートされます。 ただし、再開の操作の後に続けてプレゼンテーションの再有効化が必要になる場合があります。 |
転送 |
転送機能は、BFCP 対応エンドポイントを使用している場合、エンドポイントが現在 BFCP プレゼンテーションの最中かどうかにかかわらず完全にサポートされます。 ただし、転送の操作の後に続けてプレゼンテーションの再有効化が必要になる場合があります。 |
会議(非 BFCP 会議コントローラ) |
BFCP 対応会議コントローラを使用する場合、BFCP メディア回線およびプレゼンテーション ビデオはサポートされません。 ただし、メイン ビデオ ストリームはサポートされます。 2 つの BFCP 対応エンドポイントが、非 BFCP 会議コントローラを使用する会議に入る場合、メイン ビデオは会議全体で有効ですが、BFCP メディアおよびプレゼンテーション ビデオは無効です。 |
オーディオおよびビデオ コールの帯域幅の割り当ては、Cisco Unified Communications Manager Administration で設定するリージョンおよびロケーションによって管理されます。
特定のコールに使用可能な帯域幅の量は、音声、ビデオ、シグナリング、および BFCP プレゼンテーションなどのその他のメディアを含め、セッションに関連付けられたすべてのメディア ストリームの組み合わせを管理できる必要があります。 Cisco Unified Communications Manager は、帯域幅を管理できる機能を備えています。
コール アドミッション制御では、広域(IP WAN)リンク上で同時に許可されるコール数を制限することにより、このリンクを経由するコールの音質およびビデオ品質を制御できます。 たとえば、メイン キャンパスとリモート サイトを接続する 56 kb/s フレーム リレー回線の音声品質は、コール アドミッション制御で調整できます。
コール アドミッション制御は、コールを確立するために使用できる十分な帯域幅があるかどうかを確認します。 コール アドミッション制御は、帯域幅が十分でないことを理由に、コールを拒否できます。
Cisco Unified Communications Manager では、ロケーションに基づいたコール アドミッション制御をリージョンと併用して、ネットワーク リンクの特性を定義します。 リージョンとロケーションは次のように機能します。
リージョンを使用して、ビデオ コールの帯域幅を設定できます。 リージョンでのオーディオ制限によって、ビット レートの高いコーデックが除外されることがあります。 ただし、ビデオ コールの場合は、ビデオ制限によってビデオの品質(解像度および伝送速度)が制約されます。 リージョンの詳細については、リージョンを参照してください。
ロケーションは、そのリンク上のすべてのコールに使用できる帯域幅の合計量を定義します。 リンク上にコールが確立すると、そのコールのリージョンの値は、そのリンクに使用できる合計帯域幅から差し引く必要があります。 ロケーションの詳細については、ロケーションを参照してください。
コール アドミッション制御の詳細については、コール アドミッション制御を参照してください。
Cisco Unified Communications Manager は、セッション レベルの帯域幅修飾子を処理するためのロケーションのコール アドミッション制御をサポートしています。 セッション レベルの帯域幅修飾子は、初期 SIP シグナリングの SDP 部分のパラメータの一部として伝達されます。 これらのパラメータは、各エンドポイントがコールのそのタイプに対してサポートする帯域幅の最大量を示します。 これらのパラメータを、リージョンおよびロケーションの設定とともに使用して、各コールの帯域幅を設定します。
初期コールの設定中、コールの両側では、 Cisco Unified Communications Manager にそのコールの最大許容帯域幅を伝達します。 Cisco Unified Communications Manager は、この伝達内容を相手側のエンドポイントに渡しますが、エンドポイントで指定されている帯域幅がリージョンの設定よりも大きい場合、 Cisco Unified Communications Manager はこの値をリージョンの帯域幅の値に置き換えます。
Cisco Unified Communications Manager は、次のルールを使用して、特定のコールに割り当てる帯域幅の量を決定します。
Cisco Unified Communications Manager は、エンドポイントからオファーまたはアンサーを受信した場合、SDP にセッション レベルの帯域幅修飾子があるかどうかをチェックします。
セッション レベルの帯域幅修飾子がある場合、 Cisco Unified Communications Manager は、修飾子から帯域幅の値を取得します。 修飾子のタイプが 2 つ以上ある場合は、Transport Independent Application Specific(TIAS)、Application Specific(AS)、Conference Total(CT)の優先順位で修飾子を取得します。
セッション レベルの帯域幅修飾子がない場合、 Cisco Unified Communications Manager は、メディア レベルの帯域幅修飾子の合計から帯域幅の値を取得します。
割り当てる帯域幅は、リージョン設定の最大値を上限として、2 つのエンドポイントがサポートするタイプの最大値です。 割り当てる帯域幅は、リージョン設定を超えることはできません。
Cisco Unified Communications Manager は、エンドポイントとの通信時に次のロジックを使用します。
2 つ以上のセッション レベルの帯域幅修飾子タイプ(TIAS、AS、CT)を含むエンドポイントへのアンサー、早期オファー、または Re-Invite オファーを生成する場合、 Cisco Unified Communications Manager は、それぞれに同じ帯域幅の値を使用します。
アンサーを生成する場合、 Cisco Unified Communications Manager は初期オファーで受信したものと同じセッション レベルの帯域幅修飾子タイプ(TIAS、CT、AS)を使用します。
旧バージョンの Tandberg エンドポイント(MXP 1700 など)との下位互換の場合、 Cisco Unified Communications Manager は、ビデオ コールが保留され保留音(MOH)が挿入されたときに、セッション レベルの帯域幅修飾子を削除します。
![]() (注) |
現在、w360p(640 x 360)ビデオ解像度をサポートする Cisco IP Phone モデル 9951、9971、または 8961 があり、Cisco Unified Communications Manager リリース 8.5(1) 以降にアップグレードしている場合は、ビデオ コールの解像度の変更に気付かない可能性があります。 w360p 解像度は、電話機ロード 9.2(1) で導入されました。 |
RSVP は、SCCP と SIP のビデオ コールをサポートします。 コール アドミッション制御の RSVP ポリシーは、 Cisco Unified Communications Manager の管理ページの [ロケーションの設定(Location Configuration)] ウィンドウを使用して設定します。
エンドポイントが、ビデオ コールに必要な帯域幅を取得できない場合、デフォルトの動作でビデオ コールはオーディオ コールとして再試行します。 このようなビデオ コールでルート/ハント リストまたは自動代替ルーティング(AAR)グループを使用して別のルートを試行するには、該当するゲートウェイ、トランクおよび電話機の [ビデオコールをオーディオとして再試行(Retry Video Call as Audio)] 設定をオフにします。
DiffServ コード ポイント(DSCP)パケット マーキングは、各パケットのサービス クラスを指定するために使用され、次の特性を備えています。
デバイスおよびアプリケーションは、DiffServ コード ポイント(DSCP)マーキングを使用し、IP 通信の Quality of Service(QoS)処理を示します。 たとえば、デスクトップ ビデオ エンドポイントはビデオ メディア ストリームにマルチメディア会議 AF41 マーキングを使用し、その一方、高解像度のビデオ ルーム システムはリアルタイム インタラクティブ CS4 マーキングを使用することがあります。 アプリケーションが同じタイプのアプリケーションとの間で IP 通信を送受信するとき、DSCP マーキングは対称であり、それぞれのアプリケーションが送受信する IP 通信の QoS 処理は同じです。 ただし、アプリケーションが異なるタイプのアプリケーションとの間でメディアを送受信する場合には、DSCP マーキングは非対称であり、それぞれのアプリケーションが送受信する IP 通信の QoS 処理は一貫しません。 たとえば、ビデオ ルーム システムがデスクトップ ビデオ エンドポイントから受信する QoS 処理は、ビデオ ルーム システムで必要とされる品質をサポートするには不十分であることがあります。
デバイスやアプリケーションは、確立されたセッション中に十分な帯域幅を確保するため、コール アドミッション制御(CAC)に従います。 確立されたセッションによって利用される帯域幅は、セッションの開始時と終了時に更新されます。 新しいセッションを確立しようとする際、そのセッションによって利用可能な帯域幅を超える場合には、そのセッションがブロックされます。 利用可能な帯域幅は、デバイスや異なるタイプのアプリケーションごとに個別に追跡できます。 たとえば、ビデオ メディア ストリームを送受信するデスクトップ ビデオ エンドポイントと高解像度ビデオ ルーム システムについて、帯域幅を個別に追跡することができます。
同じタイプのデバイスやアプリケーションが相互に通信を送受信すると、各方向で同じタイプの帯域幅削減が行われます。 ただし、異なるタイプのデバイスやアプリケーションが相互に通信を送受信する場合には、各方向で異なるタイプの帯域幅削減を行う必要があります。 また帯域幅削減の量は、IP ネットワークの通常の動作を反映し、通常、計画的に対称となります。 その結果、異なるタイプのデバイスやアプリケーションが相互に通信を送受信すると、帯域幅削減の合計が、実際に利用されているネットワーク量の最大 2 倍にまで達することがあります。 帯域幅におけるこの計算の不一致により、新しいセッションを確立しようとしても、不必要にブロックされてしまうことがあります。 たとえば、デスクトップ ビデオ エンドポイントと Cisco TelePresence イマーシブ ビデオ エンドポイントが通話中の場合、リリース 9.x Unified Communications Manager CAC デザインは、ビデオ帯域幅プールとイマーシブ帯域幅プールの両方から同じ量を削減します。これは、これらの 2 つのビデオ エンドポイントが DSCP を別々にマーキングし、メディア パケットが異なるキューで走査する可能性があるためです。 この動作により、必要な帯域幅の 2 倍が不必要に削減され、新しいビデオ コールがブロックされてしまう可能性があります。
Unified Communications Manager リリース 10.0(1) 以降のリリースでは、システム管理者は、より有利な CAC および QoS 処理を受けるアプリケーションを優先して帯域幅計算の不一致を調整するように、ビデオ プロモーション ポリシーを設定することができます。 たとえば、デスクトップ ビデオ エンドポイントと高解像度ビデオ ルーム システムの間のセッションがビデオ ルーム システムを優先して調整される場合、その調整はデスクトップ ビデオ エンドポイントのプロモーションと見なされます。
異なるタイプのデバイスとアプリケーションの間で調整が行われている場合、調整で優先されているアプリケーションのタイプについてのみ帯域幅が削減されます。 このタイプの承認対象のセッションに対して充分な帯域幅がある場合には、調整で優先されていないタイプのデバイスまたはアプリケーションは、使用する DSCP マーキングを、調整で優先されるタイプのアプリケーションで使用されるマーキングに変更するように指示を受けます。
たとえば、デスクトップ ビデオ エンドポイントが、高解像度ビデオ ルーム システムとのセッションでプロモートされると、そのデスクトップ ビデオ エンドポイントがビデオ ルーム システムと同じタイプのアプリケーションであるものとして帯域幅計算が行われます。 デスクトップ ビデオ エンドポイントは、その DSCP マーキングを、ビデオ ルーム システムで使用されるものに変更するように指示を受けます。 QoS 処理は両方向において一致します。帯域幅は、ビデオ ルーム システムと同じタイプのデバイスやアプリケーションの間のセッションに対して削減され、デスクトップ ビデオ エンドポイントと同じタイプのデバイスやアプリケーションの間のセッションに対しては削減されません。
フレキシブル DSCP マーキングとビデオ プロモーション機能をアクティブ化するには、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで、Use Video BandwidthPool for Immersive Video Calls サービス パラメータを [False] に設定し、Video Call QoS Marking Policy サービス パラメータを [Promote to Immersive] に設定します。 フレキシブル DSCP マーキングとビデオ プロモーション機能がアクティブになっていると、Unified Communications Manager は、ネゴシエートされた各メディア ストリームを示すトラフィック クラス ラベルをデスクトップ ビデオ デバイスに動的に伝達します。
フレキシブル DSCP とビデオ プロモーション機能は、システム管理者によって定義されたビデオ プロモーション ポリシーに基づき、トラフィック クラス ラベル(TCL)を使用して動的に SIP エンドポイントを指示し、その DSCP をコールごとにマークします。 TCL はメディア回線ごとに定義された SIP Session Description Protocol(SDP)属性のため、TCL とその関連 DSCP マーキングは、ビデオ コールのオーディオ メディア回線とビデオ メディア回線で異なることがあります。 システム管理者は、ビデオ コールのオーディオ ストリームとビデオ ストリームに異なる DSCP マーキングを選択できます。
フレキシブル DSCP マーキングとビデオ プロモーション機能には、以下のインタラクションおよび制限が適用されます。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、SIP クラスタ間経由でサポートされます。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、H.323 トランクや Media Gateway Control Protocol(MGCP)ゲートウェイ経由ではサポートされません。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、Skinny Client Control Protocol(SCCP)デバイスでサポートされます。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、デスクトップ SIP ビデオ エンドポイントに依存します。 Unified Communications Manager リリース 10.0(1) の初期リリース時点においては、Cisco DX650 シリーズの SIP 電話機のみが必要なエンドポイント サポートを提供しています。
パススルー MTP がコールに挿入されると、Unified Communications Manager は、ビデオ ストリームのパケットを最初に発したエンドポイント デバイスから求められる DSCP マーキングで、パケットをマークするように MTP に信号を送ります。 1 つのコール内の 2 つのエンドポイントで異なる DSCP マーキングが使用されている場合(たとえば、Cisco TelePresence イマーシブ ビデオ エンドポイントとビデオ プロモーションなしのデスクトップ ビデオ エンドポイントなど)には、MTP は各ストリーム方向で DSCP マーキングを保持します。
シスコでは、フレキシブル DSCP マーキングとビデオ プロモーション機能を Multilevel Precedence and Preemption(MLPP)サービス コールで使用しないようにお勧めしています。 MLPP サービス機能が必要な場合には、シスコでは、Video Call QoS Marking Policy および Use Video BandwidthPool for Immersive Video Calls サービス パラメータをそれぞれのデフォルト値に設定することを推奨しています。 Video Call QoS Marking Policy および Use Video BandwidthPool for Immersive Video Calls サービス パラメータのデフォルト値を使用すると、Unified Communications Manager とエンドポイントはメディア パケットに MLPP DSCP マーキングを使用します。
Unified Communications Manager リリース 10.0(1) 以降のリリースでは、フレキシブル DSCP マーキングとビデオ プロモーション機能を設定するために、次のクラスタ全体のサービス パラメータが提供されています。
Video Call QoS Marking Policy。 このパラメータを使用すると、管理者は、デスクトップ ビデオ エンドポイントと Cisco TelePresence イマーシブ ビデオ エンドポイントの間の帯域幅割り当ての不一致をイマーシブ エンドポイントを優先して調整するように、Promote to Immersive ポリシーを設定できます。 プロモーションが実行されると、オーディオおよびビデオ帯域幅はイマーシブ帯域幅プール割り当てから予約されます。 Promote to Immersive ポリシーは、フレキシブル DSCP マーキングをサポートするイマーシブ ビデオ デバイスとデスクトップ ビデオ デバイスの間のコールでのみ適用されます。
Promote to Immersive ポリシーを設定するには、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで Use Video BandwidthPool for Immersive Video Calls パラメータを [False] に設定し、Video Call QoS Marking Policy パラメータを [Promote to Immersive] に設定します。
Use Video BandwidthPool for Immersive Video Calls。 このパラメータは、Unified Communications Manager がイマーシブ ビデオ コールのデスクトップ ビデオ帯域幅プールから帯域幅を予約するかどうかを指定します。
DSCP for Video Calls。 このパラメータは、ビデオ コールのビデオ ストリームの DSCP 値を指定します。
DSCP for Audio Portion of Video Calls。 このパラメータは、ビデオ コールのオーディオ ストリームの DSCP 値を指定します。
DSCP for TelePresence Calls。 このパラメータは、Cisco TelePresence ビデオ コールのビデオ ストリームの DSCP 値を指定します。
DSCP for Audio Portion of TelePresence Calls。 このパラメータは、Cisco TelePresence ビデオ コールのオーディオ ストリームの DSCP 値を指定します。
Default Intraregion Max Immersive Video Call Bit Rate (Includes Audio)。 このパラメータは、リージョンとそれ自体の関係の [リージョンの設定(Region Configuration)] ウィンドウで、最大イマーシブ ビデオ コール ビット レートとして [システムデフォルトの使用(Use System Default)] オプションが選択された場合に、特定のリージョン内の各イマーシブ ビデオ コールのデフォルトの最大合計ビット レートを指定します。 [リージョンの設定(Region Configuration)] ウィンドウでのオプション選択の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。
Default Interregion Max Immersive Video Call Bit Rate (Includes Audio)。 このパラメータは、そのリージョンと別のリージョンの関係の [リージョンの設定(Region Configuration)] ウィンドウで、最大イマーシブ ビデオ コール ビット レートとして [システムデフォルトの使用(Use System Default)] オプションが選択された場合に、特定のリージョンと別のリージョンの間の各イマーシブ ビデオ コールのデフォルトの最大合計ビット レートを指定します。 [リージョンの設定(Region Configuration)] ウィンドウでのオプション選択の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。
フレキシブル DSCP マーキングとビデオ プロモーションのサービス パラメータを設定するには、以下の手順を実行します。
ステップ 1 |
Cisco Unified Communications Manager の管理ページで、 を選択します。 [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウが表示されます。 |
||||||||||||
ステップ 2 | [サーバ(Server)] ドロップダウン リストから、パラメータを設定するサーバを選択します。 | ||||||||||||
ステップ 3 |
[サービス(Service)] ドロップダウン リストで、[Cisco CallManager(アクティブ)(Cisco CallManager (Active))] サービスを選択します。 サービスが「Active」と表示されていない場合は、そのサービスを Cisco Unified Serviceability でアクティブにします。 |
||||||||||||
ステップ 4 |
パラメータを設定するには、 [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで該当の領域にスクロールし、パラメータ値を更新します。
|
||||||||||||
ステップ 5 | [保存(Save)] をクリックします。 |
ビデオ対応デバイスの次の設定は、ビデオ コールに影響を与えます。
次の設定考慮事項も、 Cisco Unified Communications Manager でビデオ コールを実行可能であるかどうかに影響します。
ビデオ コールでのトランクと H.323 クライアントの相互対話は、オーディオ コールの相互対話と同じように機能します。 Cisco Unified Communications Manager におけるトランクとゲートキーパーを参照してください。
H.323/H.320 ゲートウェイを経由する一部のボンディング コールでは、ゲートウェイで H.323 TCS メッセージの交換にかかる時間が長くなります。 必要な時間が複数の Cisco CallManager サービス パラメータのタイマー設定値を超えていると、 Cisco Unified Communications Manager によってコールがドロップされます。
デフォルトの Cisco Unified Communications Manager ゲートウェイ タイマー値が小さすぎると、 Cisco Unified Communications Manager がコール接続の完了前にコールをドロップします。 このようなコール失敗を防ぐために、次のサービス パラメータのタイマー値を増やすことをお勧めします。
Cisco Unified Communications Manager は、次の会議制御機能をサポートしています。
Roster/Attendee List
Drop Participant
Terminate Conference
Show Conference Chairperson/Controller
Continuous Presence
また、 Cisco Unified Communications Manager は、Skinny Client Control Protocol 電話機に対する次のビデオ会議機能をサポートしています。
Cisco Unified Communications Manager では、シスコのビデオ エンドポイントと、Polycom などのサードパーティのビデオ エンドポイント間の、ネイティブまたは直接的な相互運用がサポートされています。 つまり、 Cisco Unified Communications Manager では、サポートされているエンドポイント間の簡単なポイントツーポイント コールに、メディア ゲートウェイや Cisco Unified Video Conferencing(CUVC)などの会議ブリッジは不要です。
ビデオと相互運用では、次のプロトコルがサポートされています。
SIP から SIP
H323 から H323
SIP から SIP クラスタ間トランク(ICT)、SIP ICT から SIP
H323 から H323 ICT、H323 ICT から H323
SIP から H323(ICT あり、またはなし)
この機能の制限事項および特別な考慮事項の詳細は、制限事項を参照してください。
ポイントツーポイント コールの高画質の相互運用
ロケーションベースのコール アドミッション制御(CAC)のみ
TelePresence と、Telepresence Interop Protocol(TIP)をサポートするサードパーティのエンドポイント間の、プレゼンテーション共有およびセキュアな相互運用
Cisco TelePresence System(CTS)、 Cisco Unified Communications Manager、およびサードパーティのエンドポイントを含むマルチポイント コールでの Media Transcoding Engine(MXE)および Cisco Unified Video Conferencing(CUVA)の使用
ビデオと相互運用では、次のエンドポイントがサポートされています。
シスコ認定のサードパーティのビデオ エンドポイント
Cisco E20(Tandberg E20)
Cisco Unified Communication interface for Microsoft Office Communicator(CUCiMOC)または CUCiConnect(Cisco WebEx など)などの Cisco Unified Clients Services Framework(CSF)ベースのクライアント
Cisco Unified Video Advantage(CUVA)
Cisco Unified Personal Communicator(CUPC)
MP Hardware Media Switch(HMS)または Software Media Switch(SMS)などの MeetingPlace 会議ブリッジ
シスコ認定のサードパーティ デバイスを検索するには、Cisco Developer Network にアクセスして次の手順を実行します。
Cisco Developer Network(CDN)にログインします(該当する場合)。
CDN のメイン ウィンドウから、[Technology Partners] タブをクリックします。
[Partner Search] タブをクリックします。
検索ボックスで、(すべての技術を対象として)サードパーティ会社の名前を入力します(Polycom など)。
サードパーティ会社の情報が表示された場合は、該当するリンクをクリックして詳細を表示します。
サードパーティ デバイスは、 Cisco Unified Communications Manager の管理ページの [電話の設定(Phone Configuration)] で設定します。 サポートされているデバイス タイプおよびライセンス要件の一覧については、サードパーティの SIP エンドポイントを参照してください。
高度なプレゼンテーション共有とセキュリティの相互運用は、2 つの TelePresence Interop Protocol(TIP)対応のエンドポイント間でのみサポートされます。
H239 プレゼンテーション共有および H235 セキュリティは、2 つの H323 エンドポイント間でのみサポートされます。
2 つのエンドポイント間で最適な解像度を保証するには、エンドポイントのプロトコルとトランクのプロトコルが同一である必要があります。たとえば、SIP トランクで接続された SIP ポイントツーポイント エンドポイントなどです。
TelePresence との相互運用についてはロケーションベースの CAC のみです。
アドホック会議およびミートミー会議では、CUVC と MeetingPlace ソフトウェアのメディア サーバがサポートされます。 会議ブリッジでは SCCP がサポートされ、エンドポイントでは SIP または H323 がサポートされているため、解像度は標準画質に制限されることがあります。
Cisco Intercompany Media Engine(IME)は、 Cisco Unified Communications Manager のエンドポイントと Telepresence 間ではサポートされていません。
Cisco Unified Communications Manager は、デュアル スタック モードと同様に、IPv6 モードで SIP 回線と SIP トランクでのビデオおよびアプリケーション メディア ストリームの送信をサポートします。 Cisco Unified Communications Manager はまた、IPv4 または IPv6 を使用するように設定された SIP 回線と SIP トランクで、他の Unified Communications Manager クラスタおよび Video Communications Server(VCS)とのインターワーキングをサポートします。
遠端カメラ制御(FECC)プロトコルを使用すると、リモートのカメラを制御できます。 ビデオ コールでは、FECC により、コールの一方の側で遠端のカメラを制御することができます。 これには、カメラのパンニング、チルト、ズームインとズームアウトが含まれます。 複数のカメラを使用するビデオ会議では、FECC を使用して別のカメラに切り替えることができます。
Cisco Unified Communications Manager は、FECC 対応のビデオ エンドポイントで FECC プロトコルをサポートしています。 Cisco Unified Communications Manager は、SIP から SIP へのコールまたは H.323 から H.323 へのコールで FECC をサポートしていますが、SIP から H.323 へのコールでは FECC をサポートしていません。 FECC をサポートするため、Cisco Unified Communications Manager は SIP または H.323 シグナリングを介したアプリケーション メディア チャネルを設定します。 メディア チャネルが確立されると、個々のエンドポイントで FECC シグナリングを伝達できるようになります。
![]() (注) |
メディア ターミネーション ポイント(MTP)(バージョン 15.2(2)T 以降)が SIP-SIP コールに存在し、コールに利用できるチャネルが 5 チャネルある場合は、FECC を有効化できます。 |
保留ビデオは、ビデオ コンタクト センターに電話をかけるお客様がエージェントに初めてご相談された後、コンタクト センターで特定のビデオを見ることができるビデオ コンタクト センター向けの機能です。 この場合、お客様が保留状態になっている間に再生されるビデオ ストリームをエージェントが選択します。
Cisco Unified Communications Manager(Unified Communications Manager)には、[保留ビデオ サーバ(Video on Hold Server)] という新しい設定が加わり、既存の [メディア リソース(Media Resources)] メニューの下でメディア コンテンツ サーバをプロビジョニングできるようになっています。 メディア コンテンツ サーバは、Unified Communications Manager から指示を受けた場合に音声とビデオ コンテンツをストリーミングできます。 メディア コンテンツ サーバは、SIP を信号プロトコルとして使用して、Unified Communications Manager 制御の下で音声とビデオ コンテンツの保存とストリーミングを行える外部デバイスです。 メディア コンテンツ サーバは、1080p、720p、または 360p などの低解像度で高解像度ビデオ コンテンツを提供することができます。
ビデオ コンタクト センターだけでなく、一般的な保留ビデオ機能が必要な配置で、企業内に保留ビデオを使用できます。 保留ビデオ サーバの設定済みのデフォルト ビデオ コンテンツ ID を使用して、保留ユーザにビデオ ストリームを再生します。
特定のセッション用のメディア コンテンツ サーバの設定と割り当ては、Unified Communications Manager の [メディアリソースグループ(Media Resource Group)] および [メディアリソースグループリスト(Media Resource Group List)] の構成に従います。
Cisco MediaSense は、メディア コンテンツ サーバとして使用されます。
![]() (注) |
配置のルーティング後、Customer Voice Portal(CVP)を持つ Unified Contact Center では、保留ビデオ機能を取得するため、Unified Communications Manager と CVP の間で実行される SIP トランクで、保留ビデオのリソースを割り当てる必要があります。 |
この機能では、Unified Communications Manager クラスタ内に Cisco MediaSense サーバを配置できます(Cisco MediaSense クラスタは、保留にした側が登録されているクラスタに直接接続されます)。 その場合、Unified Communications Manager クラスタは保留中のロケーションと Cisco MediaSense ロケーション間の帯域幅を削減する役割を担います。 保留ビデオのインタラクションで 720p または 1080p ビデオ ストリームが使用されるので、既存のセッションのビデオ品質を保つため、新しいセッションを許可する前に、帯域幅の使用状況を考慮することが大切です。
SIP トランクを使用する Unified Communications Manager を Cisco MediaSense クラスタに設定します。 Cisco MediaSense サーバへの SIP トランクには、Cisco MediaSense ノードの IP アドレスが設定されます。 Unified Communications Manager の SIP トランクは、最大 16 個の宛先 IP アドレスをサポートします。
![]() (注) |
冗長性およびスケーラビリティの目的で、Cisco MediaSense クラスタには、2 つ以上のノードが必要です。 |
Cisco MediaSense は、保留にした側の Unified Communications Manager クラスタに直接接続されます。
保留ビデオ サーバが保留にした側として同じクラスタにある場合は、保留ビデオ サーバ設定の SIP トランクが Cisco MediaSense サーバを指し、デフォルトのコンテンツ識別子が MediaSense サーバに存在するストリーム ID を指す必要があります。 コンテンツ識別子は、任意の英数字の文字列にすることができます。 追加の設定は必要ありません。
Cisco MediaSense は、Session Management Edition(SME)とともに中央に配置されます。
保留ビデオ サーバが SME から外れたところに配置されている場合、保留にした側をホストするリーフ クラスタに保留ビデオ サーバを設定する必要があります。 この保留ビデオ サーバの SIP トランクは、SME SIP トランクを指す必要があります。 SME では、Cisco MediaSense サーバを指すように SIP トランクをプロビジョニングしなければなりません。
この集中型の配置をサポートするための Unified Communications Manager の設定方法が 3 つあります。
コンテンツ識別子が数値の場合。この場合、INVITE を Cisco MediaSense サーバにルーティングするには、ルート パターンを SME にプロビジョニングする必要があります。 基本的に、リーフ クラスタによって送信された INVITE URI の左側を使用して、Cisco MediaSense サーバにコールをルーティングします。 INVITE URI の右側には、SME ノードの IP アドレスが含まれます。
コンテンツ識別子が英数字で、Cisco MediaSense の IP アドレスが含まれる場合。この場合、リーフ クラスタに設定されたコンテンツ識別子には、Cisco MediaSense サーバのストリーム ID と IP アドレスが含まれている必要があります(stream-id@mediasense-ipaddress)。
SME クラスタには、MediaSense サーバの IP アドレスがデフォルトのコンテンツ識別子に一致する IP アドレス ルーティングを使用する SIP ルート パターンを設定する必要があります。 このシナリオでは、ルートは、リーフ クラスタによって送信された INVITE URI(MediaSense の IP アドレス)の右側に基づいています。
コンテンツ識別子が英数字で、ドメイン名が含まれる場合。この場合、リーフ クラスタに設定されたコンテンツ識別子には、Cisco MediaSense サーバのストリーム ID とドメイン名が含まれている必要があります(stream-id@cisco.com)。
SME クラスタでは、ルート文字列として URI カタログが SIP ルート パターンとともに作成される必要があります。 Cisco MediaSense サーバからのコンテンツ識別子は、URI インフラストラクチャを使用してこのカタログにインポートされなければなりません。
![]() (注) |
ドメイン ルーティングを使用するように、SIP ルート パターンを設定する必要があります。 この SIP ルート パターンは、SIP トランクから Cisco MediaSense サーバを指す必要があります。 |
保留ビデオを指す SIP トランクが、デフォルト設定で設定されている必要があります。 次の情報が SIP トランクの設定に必要です。
[名前(Name)]
[説明(Description)]
[デバイスプール(Device Pool)]
[ロケーション(Location)]
[接続先アドレス(Destination Address)] と [接続先ポート(Destination Port)](複数の IP アドレスとポートの指定が可能)
[SIPトランクセキュリティプロファイル(SIP Trunk Security Profile)]
[SIPプロファイル(SIP Profile)]:オプションの ping が設定された SIP プロファイルを選択する必要があります。 存在しない場合は作成してください。 これは必須ではありませんが、ユーザ エクスペリエンスを改善します。
![]() (注) |
SIP トランクの他の設定は、保留ビデオではサポートされていません。 |
ステップ 1 | Cisco Unified Communications Manager の管理ページで、 を選択します。 |
ステップ 2 | [新規追加(Add New)] をクリックして、新規の保留ビデオ サーバを設定します。 |
ステップ 3 | 保留ビデオ サーバの名前を入力します。 |
ステップ 4 | サーバの説明を入力します。 |
ステップ 5 | デフォルトのビデオ コンテンツ ID を入力します。 |
ステップ 6 | ドロップダウン リストから、使用する SIP トランクを選択します。 SIP トランクを新しく作成する必要がある場合には、[SIP トランクの作成(Create SIP Trunk)] ボタンをクリックします。 |
ステップ 7 | [保存(Save)] をクリックします。 |
Cisco Unified Serviceability は、パフォーマンス モニタリング カウンタ、ビデオ ブリッジ カウンタ、およびコール詳細レコード(CDR)を更新することによって、ビデオ コールおよび会議をトラッキングします。
ビデオ テレフォニー イベントによって、次の Cisco Unified Serviceability のパフォーマンス モニタリング カウンタが更新されます。
詳細については、 『Cisco Unified Serviceability Administration Guide』を参照してください。
ビデオ会議イベントによって、次の Cisco Video Conference Bridge のパフォーマンス モニタリング カウンタが更新されます。
ConferencesActive
ConferencesAvailable
ConferencesCompleted
ConferencesTotal
OutOfConferences
OutOfResources
ResourceActive
ResourceAvailable
ResourceTotal
これらのカウンタは、 Cisco Unified Communications Manager オブジェクト内に VCB プレフィックスとともに表示されます。
ビデオ テレフォニー イベントによって、 Cisco Unified Serviceability 内のコール詳細レコード(CDR)が更新されます。 これらの CDR には、次の情報が含まれます。
ビデオ チャネルの IP アドレスおよびポート
コーデック:H.261、H.263、H.264、Cisco VT Camera wideband video
コール帯域幅
解像度:QCIF、CIF、SQCIF、4CIF、16CIF、または Custom Picture Format
また、 Cisco Unified Communications Manager は通話中のビデオの CDR を保管し、次のコール シナリオをサポートします。
目次
- ビデオ テレフォニー
- ビデオ テレフォニーの設定
- ビデオ テレフォニーについて
- ビデオ コール
- Real-Time Transport Control Protocol のパススルー
- ビデオ コーデック
- ビデオ ネットワーク
- ビデオに対するオーディオ専用デバイスの有効化
- H.323 ビデオ
- ダイナミック H.323 アドレッシング
- ゲートキーパーへの登録
- コール処理
- 設定に関する注意事項
- H.323 コールの H.239 拡張ビデオ チャネル
- サードパーティの H.323 デバイスのサポート
- H.323 デバイスによるプレゼンテーション機能の起動
- 追加ビデオ チャネルのオープン
- 追加ビデオ チャネルでのコール アドミッション制御(CAC)
- 許容ビデオ チャネル数
- H.239 Command and Indication(C&I)メッセージ
- トポロジとプロトコルの相互運用性の制限
- コール中の機能の制限
- Skinny Client Control Protocol ビデオ
- Skinny Client Control Protocol ビデオ ブリッジ
- Wi-Fi 経由でのビデオ
- SNR コール用のビデオ
- SIP ビデオ
- ビデオ コール用の SIP デバイスの設定
- シスコのビデオ会議ブリッジ
- Cisco TelePresence MCU ビデオ会議ブリッジ
- Cisco TelePresence Conductor ビデオ会議ブリッジ
- Cisco Unified MeetingPlace ビデオ会議ブリッジ
- ISR G2 ルータ ビデオ会議ブリッジ
- Cisco TelePresence Video Communications Server
- Cisco TelePresence Video Communications Server との相互運用性の設定
- ビデオの暗号化
- 暗号化方式
- 暗号化方式のネゴシエーション
- サポートされるプロトコル
- エンドポイントでの Binary Floor Control Protocol のサポート
- Binary Floor Control Protocol によるプレゼンテーション共有
- BFCP 設定のヒント
- BFCP に関する制限事項
- BFCP でサポートされる機能
- 帯域幅管理
- コール アドミッション制御
- セッション レベルの帯域幅修飾子
- SIP 電話機のビデオ解像度のサポート
- RSVP
- 代替ルーティング
- DSCP マーキング
- フレキシブル DSCP マーキングとビデオ プロモーション
- トラフィック クラス ラベル
- インタラクションおよび制限事項
- フレキシブル DSCP マーキングとビデオ プロモーションのサービス パラメータ
- フレキシブル DSCP マーキングとビデオ プロモーションのサービス パラメータの設定
- ビデオ コール用の電話機の設定
- ビデオ コール用の追加設定
- トランクと H.323 クライアントの相互対話
- ビデオ コールのコール ルーティング
- ゲートウェイ タイマー パラメータ
- ビデオ会議に対する会議制御
- ビデオと相互運用
- プロトコルおよび配置
- サポートされるシスコおよびサードパーティのエンドポイント
- 制限事項
- インターネット プロトコル バージョン 6(IPv6)
- 遠端カメラ制御プロトコルのサポート
- 保留ビデオ
- 保留ビデオの設定
- ビデオ テレフォニーおよび Cisco Unified Serviceability
- パフォーマンス モニタリング カウンタ
- ビデオ ブリッジ カウンタ
- コール詳細レコード
この章では、ビデオ テレフォニーについて説明します。 Cisco Unified Communications Manager は、音声コールとビデオ コールの領域を一体化するビデオ テレフォニーのサポートを提供します。 ビデオ エンドポイントは、 Cisco Unified Communications Manager のコール処理機能を使用し、音声およびビデオによる統合ソリューションにアクセスすることで、ビデオ コールのダイヤリングおよび接続を行います。
Cisco Unified Communications Manager のビデオ テレフォニー ソリューションは、次の機能を提供します。
ビデオ テレフォニーの設定
手順Cisco Unified Communications Manager は、音声コールとビデオ コールの領域を一体化するビデオ テレフォニーのサポートを提供します。 ビデオ エンドポイントは、 Cisco Unified Communications Manager のコール処理機能を使用し、音声およびビデオによる統合ソリューションにアクセスすることで、ビデオ コールのダイヤリングおよび接続を行います。
Cisco Unified Communications Manager のビデオ テレフォニー ソリューションは、次の機能を提供します。
- 遠端カメラ制御(FECC)などのビデオおよびビデオ関連機能のサポート
- ビデオ ストリームの伝送を許可するために必要な複数の論理チャネルのサポート
- ビデオに必要なメディア関連メッセージのコール中の転送(ビデオ コールに必要なコマンドまたは指示を転送します)
- H.323、Skinny Client Control Protocol(SCCP)、および Session Initiation Protocol(SIP)のサポート
- リージョンとロケーションの拡張による帯域幅の管理
- ビデオ コールに関するコール詳細レコード(CDR)などのサービスアビリティ情報の提供
Cisco Unified Communications Manager の管理ページでビデオ テレフォニーを設定するには、次の手順を実行します。
ステップ 1 コール アドミッション制御でリージョンを使用する場合は、ビデオ コール帯域幅に対してリージョンを設定します。
(注) すべてのデバイスには、デフォルト リージョンが設定されています。ビデオのデフォルト値は、384 kb/s です。
ヒント リージョン設定で、目的の解像度に十分な高さの帯域幅を設定します(たとえば、高画質のビデオ コールの場合は 2 Mb/s に増やします)。 ステップ 2 コール アドミッション制御でロケーションを使用する場合は、ビデオ コール帯域幅に対してロケーションを設定します。 ステップ 3 RSVP を SIP ビデオ コールの帯域幅の管理に使用している場合は、RSVP サービス パラメータを設定するか、[ロケーションの設定(Location Configuration)] ウィンドウで RSVP ポリシーを設定します。 ステップ 4 Cisco Video Conference Bridge を使用する場合は、ネットワークに対して適切な会議ブリッジを設定します。 ステップ 5 ユーザが他の会議ブリッジではなく、ビデオ会議ブリッジを使用するように設定するには、それに応じてユーザのメディア リソース グループおよびメディア リソース グループ リストを設定します。 ステップ 6 システムに H.323 ゲートウェイを設定して、オーディオ コールとしてビデオ コールを再試行(デフォルト動作)するか、AAR グループおよびルート/ハント リストを設定して、接続できないビデオ コールに対する代替ルーティングを使用します。 ステップ 7 システムに H.323 電話機を設定して、オーディオ コールとしてビデオ コールを再試行(デフォルト動作)するか、AAR グループおよびルート/ハント リストを設定して、接続できないビデオ コールに対する代替ルーティングを使用します。[ビデオ機能の有効化(Enabled for Video Capabilities)] を選択します。 ステップ 8 システムに H.323 トランクを設定して、オーディオ コールとしてビデオ コールを再試行(デフォルト動作)するか、AAR グループおよびルート/ハント リストを設定して、接続できないビデオ コールに対する代替ルーティングを使用します。 ステップ 9 ビデオをサポートする Cisco Unified IP Phone を設定します。 ステップ 10 ビデオをサポートするサードパーティの SIP エンドポイントを設定します。 ステップ 11 システムに SIP トランクを設定して、オーディオ コールとしてビデオ コールを再試行(デフォルト動作)します。
関連情報
ビデオ テレフォニーについて
- ビデオ コール
- Real-Time Transport Control Protocol のパススルー
- ビデオ コーデック
- ビデオ ネットワーク
- ビデオに対するオーディオ専用デバイスの有効化
- H.323 ビデオ
- ダイナミック H.323 アドレッシング
- H.323 コールの H.239 拡張ビデオ チャネル
- Skinny Client Control Protocol ビデオ
- Skinny Client Control Protocol ビデオ ブリッジ
- Wi-Fi 経由でのビデオ
- SNR コール用のビデオ
- SIP ビデオ
- シスコのビデオ会議ブリッジ
- Cisco TelePresence Video Communications Server
- ビデオの暗号化
- エンドポイントでの Binary Floor Control Protocol のサポート
- Binary Floor Control Protocol によるプレゼンテーション共有
- 帯域幅管理
- ビデオ コール用の電話機の設定
- ビデオ コール用の追加設定
- ビデオ会議に対する会議制御
- ビデオと相互運用
- 遠端カメラ制御プロトコルのサポート
- 保留ビデオ
ビデオ コール
一般的なビデオ コールには、上下用の 2 つまたは 3 つの Real-Time Protocol(RTP)のストリーム(つまり、4 または 6 ストリーム)があります。 コールには、次のタイプのストリームを含めることができます。
ビデオ(H.261、H.263、H.263+、H.264-SVC、X-H.264UC、H.264-AVC、H.265、および Cisco VT Camera wideband video コーデック)
遠端カメラ制御(FECC)(オプション)
Binary Floor Control Protocol(BFCP)
ビデオ コールのコール制御は、他のすべてのコールを管理するコール制御と同じように動作します。 メディア リソースの概要を参照してください。
(注)
ビデオ会議ブリッジを Cisco Unified Communications Manager で自動的に割り当てる方法の詳細については、インテリジェント ブリッジ選択を参照してください。
Real-Time Transport Control Protocol のパススルー
MTP トポロジ内の Real-Time Transport Control Protocol のパススルー
15.2(2)T 以前の IOS メディア ターミネーション ポイント(MTP)では、Real-Time Transport Control Protocol(RTCP)パケットをパススルーできないため、Real-Time Protocol(RTP)のフィードバック データを交換して RTP 送信を拡張することはできません。 RTCP の主な機能は、ストリーミング マルチメディア セッションの参加者に統計情報を定期的に送信することにより、メディア配信のフィードバックを提供することです。 RTCP は、メディア接続に関する情報、および送信されたオクテット数とパケット数、失われたパケット数、ジッタ、ラウンドトリップ遅延時間などの情報を収集します。 アプリケーションは、この情報を使用して、フローを制限するか別のコーデックを使用することにより、サービス パラメータの品質を管理できます。
IOS MTP バージョン 15.2(2)T 以降では、MTP が含まれたコールのエンドポイントが RTP 送信で引き続きフィードバックとステータスを送信できるように、RTCP パススルー機能をサポートしています。 RTCP パススルー機能は、メディア チャネルに適用されます。
RTCP パススルー機能は、特定のコール シグナリング プロトコルに限定されません。 たとえば、SIP 間、SIP と非 SIP 間、または非 SIP 間でも構いません。
Cisco Unified CM で RTCP パススルー対応 MTP を割り当てるには、コールが次の条件を満たしている必要があります。
MTP をメディア パススルー モードにすることが必要な機能で、MTP が必要。 たとえば、TRP、DTMF 変換、IP アドレス V4/V6 変換などです。RTCP パススルーは、メディアがパススルー モードになっている場合のみ適用可能です。
RTCP パススルーの MTP を、MTP のスポンサーとなるエンドポイントのメディア リソース グループ リスト(MRGL)に含める必要がある。 MTP は、RSVP、E2ERSVP、TRP、DTMF 不一致の理由により挿入できます。
コールがビデオ チャネルを確立できる場合、Cisco Unified CM が RTCP パススルー対応 MTP の検索を試みる。 たとえば、Cisco Unified CM は、MRGL 内の他の RTCP パススルー非対応の MTP の中から RTCP パススルー対応 MTP を選択します。 RTCP パススルー対応 MTP が利用できない場合でも、Cisco Unified CM がコールに MTP を割り当てます。
コールがオーディオ チャネルのみ確立できる場合、Cisco Unified CM が、ビデオ コール以外のコールに対して意図的には RTCP パススルー対応 MTP を要求しない。 ただし、MRGL に RTCP パススルー対応 MTP のみ含まれている場合、Cisco Unified CM はそれらの MTP のいずれかをオーディオ コールに挿入します。
RTCP パススルー対応 MTP を割り当てるためには、コールがビデオ コールの現在の CAC 帯域幅も満たしている必要がある。
(注)
コールが最初にコール内の RTCP パススルー非対応の MTP(バージョン 15.2(2)T 以前)を使用して確立されており、コールがビデオ対応のコールにエスカレートされる場合、Cisco Unified CM は RTCP パススルー対応 MTP に再割り当てしません。 この場合、コールがビデオ コールにエスカレートされても、既存の MTP では RTCP パケットをパススルーできません。
ビデオ コーデック
通常のビデオ コーデックには、古いビデオ コーデックの H.261、インターネット プロトコル(IP)ビデオの提供時に使用される新しいコーデックの H.263、および高品質コーデックの H.264 があります。 システムでは、H.264 は、発信および終端エンドポイントで Skinny Client Control Protocol(SCCP)、H.323、および SIP を使用するコール専用にサポートされています。 また、リージョンとロケーションもサポートされています。
リリース 10.01 では、H.265 高効率ビデオ コーデック(HEVC)、H.264 スケーラブル ビデオ コーデック(SVC)、および SIP プロトコルでのみサポートされる X-H.264UC(Lync)ビデオ コーデックを導入しています。
Unified Communications Manager は、応答時に可能であれば、オファー側のビデオ コーデックの優先順位を維持します。 エンドポイントで利用できる場合、H.265 が優先ビデオ コーデックで、それ以外の場合は、Unified Communications Manager は次のコーデックの優先順位に従います。H. 264 SVC は H.264-AVC ビデオ圧縮標準に新しく追加されました。つまり、H.264-AVC をさらに機能強化したものです。 1 つのコンテナにさまざまなフレームレートと解像度で複数のビデオ ストリームをカプセル化する機能を備えています。
H.261 および H.263 コーデックのパラメータおよび標準値は、次のとおりです。
ビット レートの範囲は、64 kb/s ~数 mb/s です。 これらのビット レートは、100 b/s の任意の倍数にすることができます。 H.261 および H.263 はビット レートが 64 kb/s 未満でも機能しますが、このような低ビット レートの場合はビデオ品質が低下します。
解像度:
フレーム レート:15 fps、30 fps
Annex:F、D、I、J、K、L、P、T、N
Cisco Unified Video Advantage(CUVA)は、クラスタ内コールに使用可能な H.263 コーデックと、クラスタ間コールに使用可能な H.264 コーデックをサポートしています。 関連する機能とリージョンを正しく設定していることが、サポートの前提になります。 また、このサポートは通話中にも適用されます。
ビデオ コールの帯域幅は、オーディオとビデオの帯域幅の合計に一致します。 合計帯域幅には、オーバーヘッドは含まれません。
例
384 kb/s のビデオ コールを、64 kb/s(オーディオ)による G.711 と 320 kb/s(ビデオ)で構成することができます。 この合計には、オーバーヘッドは含まれません。 ビデオ コールのオーディオ コーデックが 24 kb/s による G.729 である場合、ビデオ レートは、合計帯域幅 384 kb/s を維持するために増加します。 コールが H.323 エンドポイントを使用する場合、H.323 エンドポイントは、利用可能な合計ビデオ帯域幅より少ない帯域幅を使用することができます。 プロトコルに関係なく、エンドポイントは常にコールの最大ビット レート未満で送信することを選択できます。
ビデオ ネットワーク
以下の図に、単一の Cisco Unified Communications Manager クラスタを使用するビデオ ネットワークの例を示します。 正常なビデオ ネットワークでは、任意のエンドポイントが、他のすべてのエンドポイントにコールできます。 両方のエンドポイントでビデオが有効である場合だけ、ビデオを利用できます。 ビデオ機能は、トランク全体に拡張できます。
シスコのビデオ会議のポートフォリオは、次のビデオ ブリッジで構成されます。
Cisco UC エンドポイント ポートフォリオは、ビデオをサポートする次のエンドポイントで構成されます。
Cisco Unified IP Phone 9971
Cisco Unified IP Phone 9951
Cisco Unified IP Phone 8941
Cisco Unified IP Phone 8945
Cisco Unified IP Phone 7985
Cisco IP Video Phone E20
Cisco TelePresence EX60
Cisco TelePresence EX90
Cisco TelePresence Quick Set C20
Cisco TelePresence Codec C40
Cisco TelePresence Codec C60
Cisco TelePresence Codec C90
Cisco TelePresence 1000
Cisco TelePresence 1100
Cisco TelePresence 1300-47
Cisco TelePresence 1300-65
Cisco TelePresence 1310-65
Cisco TelePresence 3000
Cisco TelePresence 3200
Cisco TelePresence 500-32
Cisco TelePresence 500-37
Cisco TelePresence MX200
Cisco TelePresence MX300
Cisco TelePresence TX9000
Cisco TelePresence TX9200
詳細については、該当する IP Phone のユーザ ガイドおよびアドミニストレーション ガイドを参照してください。
(注)
サードパーティの SIP ビデオ エンドポイントは、回線側デバイスまたはトランク側デバイスとして Cisco Unified Communications Manager に接続できます。 詳細については、サードパーティの SIP エンドポイントを参照してください。
ビデオに対するオーディオ専用デバイスの有効化
IPv4 オーディオ専用デバイスをビデオに対して有効にするには、シスコ アプリケーションの Cisco Unified Video Advantage を使用します。 使用中の PC またはラップトップにビデオ コンポーネントを表示するために、アプリケーションを Cisco Unified IP Phone に関連付けることができます。 この関連付けを実行できるのは、コールの発信前またはコール中(通話中)です。 7975、7940、7960、7975、6961、6941、および 6921 などの Cisco Unified IP Phone は、Cisco Unified Video Advantage をサポートしています。
たとえば、 Cisco Unified IP Phone 7975 から Video Phone にコールを発信するとします。 コールはオーディオ専用として確立されます。 Cisco Unified Video Advantage を Cisco Unified IP Phone 7975 に関連付けると、コールはビデオ コールとして再確立されます。
関連付けが存在する間、 Cisco Unified Communications Manager は既存の SCCP メッセージを介して IP Phone の最新機能を受信します。 最新機能を受信すると、 Cisco Unified Communications Manager はビデオに関してネゴシエートします。
最初のコールで IP Phone を使用し、ビデオを使用しない場合は、オーディオ ロケーションの帯域幅だけが予約され、メディア レイヤがオーディオ専用コールを確立します。
音声電話器の他に、9971、9951 などのシスコ ビデオ電話でも、Cisco Unified Video Advantage をサポートします。
H.323 ビデオ
H.323 エンドポイントを H.323 電話機、H.323 ゲートウェイ、または H.323 トランクとして設定可能です。
自動転送、ダイヤル プラン、他のコール ルーティング関連機能が、H.323 エンドポイントで機能します。
H.323 ビデオ エンドポイントは、保留、再開、転送、パーク、およびその他の類似機能を開始することはできません。
H.323 エンドポイントが Empty Capability Set(ECS)をサポートする場合は、エンドポイントの保留、パークなどが可能です。
一部のベンダーでは、コールが転送またはリダイレクトされる際に、コールの帯域幅を増やすことができないようにコール設定を実装しています。 このようなケースでは、最初のコールがオーディオであると、ビデオ エンドポイントに転送された場合に、ユーザはビデオを受信できません。
現在、ビデオのメディア ターミネーション ポイント(MTP)またはビデオ トランスコーダは存在しません。 オーディオ トランスコーダまたは MTP がコールに挿入されている場合、そのコールはオーディオだけになります。 これに該当するのは、IPVC オーディオ変換機能を使用していない場合です。 IPVC トランスコーダを使用する場合は、オーディオを変換して、ビデオを送信/受信することができます。
H.323 ビデオ コールでは、ユーザがビデオ コールの帯域幅を指定する必要があります。
ダイナミック H.323 アドレッシング
ゲートキーパーへの登録
Cisco Unified Communications Manager はブート時に、E.164 アドレスや、H.323 クライアントごとに設定されたゲートキーパーなどの、スタティック設定情報をロードします。 同一のゲートキーパー ゾーンにある H.323 クライアントは、同一グループのままになります。 そのグループに対して、ゲートキーパーへの登録が起動されます。 このプロセスで、グループの各メンバーを個別に登録する必要はありません。
同じゲートキーパーとゾーンに所属する H.323 クライアントは、同じグループに所属し、このグループに対して登録が 1 回だけ起動されます。 同じゲートキーパーに最初のグループとして所属するものの、所属するゲートキーパー ゾーンが異なる H.323 デバイスは、別々のグループであり、このグループに対して登録が 1 回だけ起動されます。 同一グループのメンバーはすべて、同一のテクノロジー プレフィックスを使用します。
コール処理
H.323 クライアントを着信側とする発信コールでは、 Cisco Unified Communications Manager が H.323 デバイスにコールを DN 単位でルーティングします。 Cisco Unified Communications Manager は H.323 デバイス設定を使用して、ゲートキーパーが設定されているかどうかを判別し、設定済みの E.164 アドレスを使用して許可要求(ARQ)を送信します。 デバイスがゲートキーパーに登録されると、ゲートキーパーはデバイスの現在の IP アドレスを使用して、アドミッション確認(ACF)を送信します。 Cisco Unified Communications Manager はコールをこのアドレスに直接ルーティングします。
H.323 デバイスを発呼側とする着信コールでは、ゲートキーパーが Cisco Unified Communications Manager にコールをルーティングします。 Cisco Unified Communications Manager は発信元の E.164 アドレスを使用して、発信側デバイスが設定されているかどうかを判別します。 Cisco Unified Communications Manager は、この設定を使用して、その電話機の設定を特定します。 電話機の設定には、リージョン、ロケーション、MRGL などが含まれています。
システムでは、H.323 トランク、クラスタ間トランク、および H.323 ゲートウェイに対する E.164 アドレッシングはサポートされていません。
ゲートキーパーによって制御される H.323 クライアントが設定されている場合、 Cisco Unified Communications Manager はデバイス名を解決しません。 Cisco Unified Communications Manager は H.323 クライアントのゲートキーパー フィールドにアクセスして、デバイスを検出することができます。 このため、 Cisco Unified Communications Manager はデバイス名の名前解決を避けることができます。
Cisco Unified Communications Manager は、ゲートキーパーによって制御される H.323 クライアントごとに、E.164 番号を最大で 1 つサポートします。 ゲートキーパー フィールドにデータを入力した場合、2 番目の DN を設定することはできません。 複数の DN が設定されている H.323 クライアントがある場合、追加のゲートキーパー情報をデータベースに追加することはできません。
ゾーン プレフィックスがない場合、ゲートキーパーはゾーン情報を使用してコールをルーティングします。
設定に関する注意事項
H.323 クライアントの設定でゲートキーパーを指定するには、そのゲートキーパーが Cisco Unified Communications Manager で設定されていることを確認する必要があります。 デフォルトでは、ゲートキーパー フィールドは空になっています。
H.323 クライアント設定に、[ゲートキーパー名(Gatekeeper Name)]、[テクノロジープレフィックス(Technology Prefix)]、[ゾーン(Zone)]、および [E.164] フィールドを必ず追加してください。 [ターミナルタイプ(Terminal Type)] を追加する必要はありません。 デフォルトは、ゲートウェイ タイプです。 これらの各フィールドを設定するときにゲートキーパーが [ゲートキーパー(Gatekeeper)] フィールドで選択されていない場合、これらのフィールドにデータを入力することはできません。
[ゲートキーパー(Gatekeeper)] フィールド、[ゾーン(Zone)] フィールド、[テクノロジープレフィックス(Technology Prefix)] フィールド、および E.164 情報は、H.323 クライアント設定の [ゲートキーパー情報(Gatekeeper Information)] グループの下に表示されます。
H.323 クライアントが別のクライアントと同じゲートキーパー、ゾーン、およびテクノロジー プレフィックスを使用する場合は、両方のクライアントを同一グループに含めることを考慮します。 このグループは、ゲートキーパーに対する単一エンドポイントを表します。
H.323 クライアントおよびトランクに、同一のゾーン名を使用することはできません。 H.323 クライアントが使用するゾーンは、H.323 トランクや、ゲートキーパーによって制御されるクラスタ間トランクが使用するゾーンとは異なる必要があります。
Send Product Id and Version ID サービス パラメータが [True] に設定されていることを確認します。
H.323 クライアントに E.164 アドレスとゲートキーパーを設定する場合、設定が更新されると、データベースにこの情報が格納されます。 この情報は、ブート時またはデバイスのリセット時にロードされます。
H.323 コールの H.239 拡張ビデオ チャネル
- サードパーティの H.323 デバイスのサポート
- H.323 デバイスによるプレゼンテーション機能の起動
- 追加ビデオ チャネルのオープン
- 追加ビデオ チャネルでのコール アドミッション制御(CAC)
- 許容ビデオ チャネル数
- H.239 Command and Indication(C&I)メッセージ
- トポロジとプロトコルの相互運用性の制限
- コール中の機能の制限
サードパーティの H.323 デバイスのサポート
拡張ビデオ チャネル機能は、サードパーティのビデオ エンドポイント間での H.239 の相互運用性と、Cisco Unified Voice Conferencing をサポートしています。 Cisco Unified Communications Manager では、プレゼンテーションや、会議のライブ転送に拡張ビデオ チャネルを使用できます。 この機能は、H.245 シグナリングによるマルチ ビデオ チャネルのサポートに重点を置いています。 このマルチチャネルのサポートの基盤となるのが次のプレゼンテーション アプリケーションです。
Natural Presenter Package と People+Content のいずれも、H.239 プロトコルを使用して機能のネゴシエートを実行し、追加ビデオ チャネルのロールを定義します。
(注)
Tandberg 製の Natural Presenter Package と Polycom 製の People+Content のみがプレゼンテーション モード用に H.239 をサポートしています。
(注)
Tandberg と Polycom から提供されているプレゼンテーション アプリケーションはオプションの機能です。 追加ビデオ チャネルのネゴシエートを実行するには、このオプション機能のいずれかが使用可能になっている必要がある他、発信者と被発信者の両方のエンドポイントで H.239 が有効になっている必要があります。そうでない場合、コールのビデオ チャネルが 1 つに制限されます。
H.323 デバイスによるプレゼンテーション機能の起動
Tandberg と Polycom のビデオ エンドポイントを使用すると、さまざまなコンポーネント(VCR、プロジェクタ、PC など)のプレゼンテーション資料を共有できます。 このコンポーネントをエンドポイントに物理的に接続できます。また、ベンダーから提供されるプレゼンテーション アプリケーションを PC で実行して、プレゼンテーション イメージを転送することも可能です。 プレゼンテーション ソースと、ビデオ エンドポイントへのコンポーネントの接続は、H.239 を使用してビデオ チャネルを確立するメカニズムとは無関係です。
(注)
プレゼンテーション ソースの設定方法の詳細については、ビデオ エンドポイントのユーザ ガイドを参照してください。
H.239 対応の 2 台のエンドポイントがビデオ コールを確立するとき、これらの端末は、会議の参加者用のメイン ビデオ チャネルと、追加ビデオ チャネル用の拡張ビデオ機能(H.239 機能)を確保するために、自身のビデオ機能を宣言します。 H.239 機能の信号は次のように構成されます。
H.239 をサポートしていることを示す信号をエンドポイントが送信します。 また、これらの端末は、関連コマンドや追加ビデオ チャネルを管理する指示信号も送信します。 これにより、両方のエンドポイントがコールで複数のビデオ チャネルを開くことができると認識できます。
エンドポイントは、1 つまたは複数の拡張ビデオ コーデックの機能を送信して、追加チャネルのビデオ コーデックの機能を提示します。 このエンドポイントでは、追加ビデオ チャネルのロールを指定する必要があります。 定義されるロールのラベルを次に示します。
機能に関するやり取りが行われた直後、従来のビデオ コールと同じように、両方のエンドポイントは双方向のオーディオ チャネルとメイン ビデオ チャネルを開きます。
追加ビデオ チャネルのオープン
Natural Presenter Package(Tandberg)
Tandberg の場合、要求に応じて追加ビデオ チャネルが開始されます。 Tandberg のデバイスは、メイン ビデオ チャネルが確立されても、追加ビデオ チャネルをすぐに開きません。 追加チャネルが開かれるのは、発信者のいずれか(プレゼンター)がプレゼンテーションのソースを指定し、プレゼンテーションを開始するコマンドを実行したときです。
Tandberg ユーザがプレゼンテーションの共有を開始することを決定すると、Tandberg は、プレゼンテーションのイメージを受信するための拡張ビデオ チャネルを開くことをコール相手に要求します。このため、Tandberg ユーザ間のコールでは、一方向のみの追加ビデオ チャネルが使用されます。
People+Content(Polycom)
Tandberg とは異なり、Polycom のビデオ エンドポイントは、そのメカニズムのデフォルトの動作として、両方のビデオ エンドポイントが追加ビデオ チャネルをサポートしていることを確認した後、すぐに追加ビデオ エンドポイントを開きます。
(注)
両方の端末が H.239 をサポートし、拡張ビデオ チャネル機能が有効になっている場合、チャネルは自動的に確立されますが、 どちらかの端末がプレゼンテーションの共有を開始するまで、追加チャネルからは何も表示されません。
Polycom は、追加ビデオ チャネルを使用するかどうかに関係なく、追加ビデオ チャネルをコール相手に要求します。このため、Polycom ユーザ間のコールでは、1 つのデバイスのみがプレゼンテーションのイメージやビデオを送信する場合でも、双方向のビデオ チャネルがデバイス間で開かれます。
このような実装により、何かを提示するトークンを取得することを決定したときには、コールの両端で追加ビデオ チャネルでの転送準備ができていることになります。 2 つのビデオ チャネルのどちらかはアイドル(何も送信しない)状態ですが、Polycom デバイスは帯域幅を制御して負荷を効率化します。
(注)
この追加ビデオ チャネルの扱い方の違いは、H.239 の実装には影響しません。 Cisco Unified Communications Manager は、H.323 対 H.323 のコールでは受信チャネル要求を行いません。 Cisco Unified Communications Manager は、端末間ですべてのチャネル要求を中継するだけです。
(注)
Cisco Unified Communications Manager は、追加のビデオ チャネルのセットに対して双方向の転送を強制しません。これは、H.239 プロトコルの要件ではないためです。
追加ビデオ チャネルでのコール アドミッション制御(CAC)
Cisco Unified Communications Manager の次のコール アドミッション制御ポリシーが追加ビデオ チャネルに適用されます。
Cisco Unified Communications Manager は、ロケーション設定に基づいて、追加ビデオ チャネルによる帯域幅の使用を制限します。 追加ビデオ チャネルが確立されているとき、 Cisco Unified Communications Manager はロケーション プールで充分なビデオ帯域幅が使用できる状態が維持されることを確認し、適切な帯域幅を予約します。 必要な帯域幅が使用できない場合、 Cisco Unified Communications Manager は使用可能な帯域幅をゼロにするようにチャネルに指示します。
リージョンの設定やポリシーが、追加ビデオ チャネルをサポートするために変更されることはありません。
従来の Cisco Unified Communications Manager のリージョン ポリシーは、ビデオ チャネルが 1 つのコールのみをサポートしており、このコールの帯域幅の合計使用量がリージョンの設定で指定されている値を超えることはありません。
管理者が H.239 コールを対象としてリージョンのビデオ帯域幅に一定の制限を設定した場合、そのリージョンの値が、ビデオ チャネルごとに独立して要求される帯域幅に対して使用されるため、 Cisco Unified Communications Manager でリージョン ポリシーの違反が発生します。
例
If the region video bandwidth is set to 384Kbps and the audio channel uses 64Kb/s, the maximum allowed bandwidth for each video channel will be (384Kb/s - 64Kb/s)= 320Kb/s. i.e. the maximum bandwidth to be used by the H.239 call will be (audio bw + 2*(384 - audio bw)) = 704Kb/s, which goes beyond the 384Kb/s bandwidth that the region specifies.
(注)
H.239 コールのリージョンとロケーションの両方の帯域幅制限を緩和して、 Cisco Unified Communications Manager が関与しなくても H.239 デバイスが両方のビデオ チャネルの負荷を再調整およびバランシングできるようにすることを検討する必要があります。
H.239 Command and Indication(C&I)メッセージ
Command and Indication(C&I)メッセージは、H.239 がプレゼンテーション ロールや Live ロールのトークンを管理したり、ビデオ フロー制御の解放要求をデバイスに許可して、追加のメディア チャネルを操作できるようにしたりするために使用されます。 Cisco Unified Communications Manager はすべての C&I メッセージをサポートしています。 Cisco Unified Communications Manager は、C&I メッセージを受け取ると、コール相手に適切に中継します。
フロー制御解放の要求メッセージと応答メッセージは、相手側のフロー制御解放の要求に使用できるため、エンドポイントは指定されたチャネルを指定されたビット レートで送信できます。
(注)
コール相手は、フロー制御解放の応答に示されているとおりに要求を受け付けることもあれば、受け付けないこともあります。
プレゼンテーション ロールのトークンのメッセージにより、H.239 デバイスはプレゼンテーションのトークンを取得できます。 コール相手は、要求を受諾または拒否できます。 プレゼンターのデバイスは、不要になった時点で、トークンの解放メッセージを送信します。
トポロジとプロトコルの相互運用性の制限
Cisco Unified Communications Manager は、H.323 対 H.323 のコールで H.239 だけをサポートしています。 Cisco Unified Communications Manager により、H.239 コールを H.323 クラスタ間トランクまたは複数のノード経由で確立できます。 H.239 対応のデバイスが、非 H.323 デバイスにコールを実行した場合、H.239 の機能は無視され、コールは Cisco Unified Communications Manager でサポートされる従来のビデオ コールと同じように実行されます。
メディア ターミネーション ポイントまたはトランスコーダがコールに挿入されていると、追加ビデオ チャネルは Cisco Unified Communications Manager でサポートされません。 この場合、コールは通常のビデオ コールにフォールバックされます。
Skinny Client Control Protocol ビデオ ブリッジ
Wi-Fi 経由でのビデオ
ビデオ対応のスマートフォンで実行され、Cisco Unified Communications Manager に登録されているデュアル モード スマート クライアントでは、スマートフォンと別のビデオ対応エンドポイント間で VoIP 経由でビデオ コールを行うことができます。
Cisco Dual Mode for iPhone(TCT)がビデオに対応している場合、Cisco Unified Communications Manager により IP 経由で別のビデオ対応エンドポイントにコールできます。
ビデオの有効化/無効化の切り替えオプションは、CCMAdmin のデバイス ページで使用できます。 また、ビデオを使用した保留/再開、会議、転送などの通話中の機能も使用できます。
SNR コール用のビデオ
Cisco Unified Communications Manager では、リモート接続先を含む 2 つのエンドポイントがビデオに対応している場合、モビリティでオーディオとともにビデオ ストリーミングを使用できます。 次の例で、このシナリオを説明します。制限と条件
コール設定全体で、Cisco Unified Communications Manager によってソフトウェア MTP が割り当てられている場合、MTP ではビデオ ストリーミングがサポートされないため、ビデオ ストリーミングはサポートされません。
コールにハードウェアのマルチメディア IOS MTP が割り当てられている場合、ビデオの使用は次の特定の条件に基づきます。
トランクとゲートウェイで [メディアターミネーションポイントが必須(Media Termination Point Required)] がオンになっているために MTP が割り当てられている場合、ビデオ ストリーミングは使用できません。
Unified Mobility で DTMF の検出用に MTP が必要な場合、ビデオは使用できません。
トランスコーダのため、またデバイス、トランク、およびゲートウェイでの TRP チェックのために MTP が割り当てられている場合、ビデオを使用できます。
SIP ビデオ
SIP ビデオは、SIP シグナリング インターフェイス(SSI)を使用して、次のビデオ コールをサポートします。
SIP ビデオ コールには、ビデオ会議のメディア制御機能もあります。
Cisco Unified Communications Manager ビデオは、両方の SIP トランクで SIP をサポートし、回線はビデオ シグナリングをサポートします。 SIP は、H.261、H.263、H.263+、H.264(AVC)、H.264(SVC)、X-H.264UC(Lync)、および H.265 の各ビデオ コーデックをサポートします(VTA で使用される wideband video コーデックはサポートしません)。
RFC 2833 に使用されるメディア ターミネーション ポイント(MTP)は、1 つのセッション内で複数の論理チャネルをサポートします。 論理チャネルは、オーディオ用でもビデオ用でもかまいません。 ビデオ チャネルをサポートするため、MTP はパススルー モードを使用します。 ビデオ パススルーは、MTP がパススルーと複数の論理チャネルの両方をサポートしている場合に使用可能です。 MTP デバイスの中には、複数の論理チャネルとパススルー モードをサポートしていないものもあります。
ビデオ コール用の SIP デバイスの設定
シスコのビデオ会議ブリッジ
Cisco Unified Communications Manager は、ビデオ会議用のさまざまなソリューションをサポートしています。 次のビデオ会議ブリッジは、アドホック ビデオ会議とミートミー ビデオ会議をサポートしています。
- Cisco TelePresence MCU ビデオ会議ブリッジ
- Cisco TelePresence Conductor ビデオ会議ブリッジ
- Cisco Unified MeetingPlace ビデオ会議ブリッジ
- ISR G2 ルータ ビデオ会議ブリッジ
Cisco TelePresence MCU ビデオ会議ブリッジ
Cisco TelePresence MCU は、Cisco Unified Communications Manager 用のハードウェア会議ブリッジのセットです。
Cisco TelePresence MCU は、高解像度(HD)のマルチポイント ビデオ会議ブリッジです。 毎秒 30 フレームで最大 1080p の性能を持ち、あらゆる会議で十分な連続表示を実現し、フルトランスコーディング機能を備えているため、マルチベンダーの HD エンドポイント環境に最適です。 Cisco TelePresence MCU では、シグナリング コール制御プロトコルとして SIP をサポートしています。 詳細に設定でき、システムおよび会議を制御およびモニタする、ビルトイン Web サーバを装備しています。 Cisco TelePresence MCU には、HTTP 通信による XML 管理 API が用意されています。
Cisco TelePresence MCU を使用すると、アドホックとミートミーの両方の音声会議とビデオ会議を実現できます。 どの方式の会議ブリッジも、複数の参加者による複数の会議を同時にサポートしています。 Cisco TelePresence MCU は、ポート予約モードで設定する必要があります。
Cisco TelePresence Conductor ビデオ会議ブリッジ
Cisco TelePresence Conductor を使用すると、会議の管理をインテリジェントに制御できます。Cisco TelePresence Conductor は、クラスタ化をサポートする、拡張性の高いデバイスで、MCU 間のロード バランシングを行い、複数のデバイスを利用可能にします。 管理者は、アプライアンスまたは VMware 上の仮想アプリケーションとして Cisco TelePresence Conductor を導入して、Cisco Unified Computing System(Cisco UCS)プラットフォームまたはサードパーティベースのプラットフォームをサポートすることができます。 動的な 2 方向または 3 方向会議が可能な多方向会議もサポートしています。
Cisco TelePresence Conductor を使用すると、アドホックとミートミーの両方の音声会議とビデオ会議を実現できます。 Cisco TelePresence Conductor は、新しい会議ごとに最適な Cisco TelePresence リソースを動的に選択します。 アドホック、「ミートミー」、およびスケジュール済みの音声会議とビデオ会議では、MCU 単体のキャパシティを超えて動的に規模を拡張できます。 Cisco TelePresence Conductor アプライアンスまたは Cisco TelePresence Conductor クラスタ 1 つで、30 MCU または 2400 MCU ポートをサポートします。 最大 3 つの Cisco TelePresence Conductor アプライアンスまたは仮想アプリケーションをクラスタ化して、復元力をさらに高めることができます。
Cisco Unified MeetingPlace ビデオ会議ブリッジ
Cisco Unified MeetingPlace は総合的なコラボレーション ソリューションで、アドホック ビデオ会議とミートミー ビデオ会議の両方をサポートするビデオ会議ブリッジとして機能するように設定できます。 また、Cisco Unified MeetingPlace を Cisco WebEx と連動させると、Web 会議とコンテンツ共有のさまざまなソリューションを利用できます。
Cisco Unified MeetingPlace の展開は、規模と複雑さによって異なります。 このソリューションの配備は、単一サーバ上でも複数サーバ上でも構いません。 Cisco Unified MeetingPlace のすべての展開に、Cisco MCS にインストールされるアプリケーション サーバが含まれます。 アプリケーション サーバは、ソリューションのメディア サーバを制御します。
ビデオ会議機能は、メディア サーバによって提供されます。 Cisco Unified MeetingPlace ソリューションでは、Express Media Server と Hardware Media Server の 2 つのメディア サーバ オプションが用意されています。 Express Media Server は、アプリケーション サーバ上にインストールされるソフトウェアベースのメディア サーバで、シングルボックスの展開が可能です。 Hardware Media Server は、別の Cisco 3500 シリーズ メディア サーバにインストールされる音声ブレードとビデオ ブレードで構成されます。
Web 展開の場合は、オプションの Web サーバを含めることもできます。
会議機能
Cisco Unified MeetingPlace を会議ブリッジとして設定しており、Express Media Server 展開を使用している場合、この会議ブリッジはアドホック ビデオ会議とミートミー ビデオ会議の両方をサポートします。 Express Media Server は H.263 と H.264/AVC の両方のビデオ コーデックをサポートしていますが、1 つの会議での異なるコーデック間のトランスコーディングはサポートしていません。
Express Media Server では、会議を始める前に、表示解像度の指定を行うビデオ モードを設定する必要があります。 アドホック会議では、すべてのアドホック会議で 1 つのシステム全体の設定を共有します。 従来の CIF エンドポイントをアドホック ビデオ会議に参加させる場合、すべてのアドホック会議を CIF の解像度 352 x 288 に制限する必要があります。
Hardware Media Server 展開を使用している場合、会議ブリッジでサポートされるのはミートミー ビデオ会議だけです。 ビデオ コーデック間のトランスコーディングはサポートされます。 また、参加者は、会議の音声部分とビデオ部分を記録できます。
次の表に、Cisco Unified MeetingPlace で利用できる主なビデオ会議機能について概要を示します。 全体的な会議キャパシティは、設定値、物理的なハードウェアなどのさまざまな要因によって異なります。 全体的なキャパシティは、ビデオ解像度が低く、かつ G.711 などの低帯域幅の音声コーデックの場合に最も大きくなります。 高解像度のビデオや高帯域幅の音声コーデックでは、キャパシティが小さくなります。
Cisco Unified MeetingPlace の機能の詳細については、Cisco Unified MeetingPlace の製品マニュアルを参照してください。
機能 Express Media Server Hardware Media Server 会議 アドホックとミートミー ミートミー 音声コーデック G.711
G.722
G.729a
G.711
G.722
G.729a
iLBC
ビデオ コーデック H.263
H.264/AVC
H.261
H.263
H.264/AVC
記録 ビデオは記録不可 会議の音声部分とビデオ部分の両方を記録可能 H.264 と H.263AVC 間のトランスコーディング いずれのコーデックもサポートされるが、同じ会議内ではサポートされない サポートされる ビデオ解像度 最大 1280 X 720 352 X 288 コール合計数 音声の場合、最大1300
ビデオの場合、最大 650
(注) この値は、低解像度のビデオと G.711 音声コーデックを使用した場合を想定しています。 ビデオ解像度が高くなったり、音声コーデックの帯域幅が高くなると、値が小さくなります。
音声の場合、最大2000
ビデオの場合、最大 300
ISR G2 ルータ ビデオ会議ブリッジ
第 2 世代シスコ サービス統合型ルータ(ISR G2)は、アドホックとミートミーのオーディオ会議およびビデオ会議をサポートする IOS ベースの会議ブリッジとして動作するよう有効にできます。 会議を有効にするには、PVDM3 DSP モジュールを ISR G2 ルータにインストールする必要があります。 ISR G2 ルータには、次のシリーズがあります。
アドホック ビデオ会議の場合、ISR G2 ルータは最大 8 人の参加者をサポートします。 ミートミー ビデオ会議の場合、最大 16 人の参加者をサポートします。 ビデオ会議では、解像度、ビット レート、およびフレーム レートは使用されるビデオ フォーマットによって異なりますが、ISR G2 ルータは最大 30 f/s のフレーム レート、最大 2 Mb/s のストリーム ビット レート、および最大 704 X 568 ピクセルのビデオ解像度をサポートできます。 各ビデオ フォーマットのコーデック、フレーム レート、ビット レート、およびビデオ解像度の詳細については、『Configuring Video Conferences and Video Transcoding』のマニュアルを参照してください。
Cisco Unified Communications Manger 内で、次の 3 つの会議ブリッジ タイプのいずれかとして ISR G2 ルータを設定できます。
Cisco IOS Homogeneous Video Conference Bridge:同種間ビデオ会議で、すべての会議参加者が、同じビデオ フォーマット属性をサポートしている電話機により会議ブリッジに接続します。 すべてのテレビ電話が同じビデオ フォーマットをサポートし、会議ブリッジは同じデータ ストリーム フォーマットをすべてのビデオ参加者に送信します。
Cisco IOS Heterogeneous Video Conference Bridge:異種間ビデオ会議で、すべての会議参加者が、異なるビデオ フォーマット属性を使用する電話機により会議ブリッジに接続します。 信号を別のビデオ フォーマットに変換するために、DSP からのトランスコーディング機能が必要です。
Cisco IOS Guaranteed Audio Video Conference Bridge:保証されたオーディオ ビデオ会議で、オーディオ会議ブリッジ用の DSP リソースは予約されますが、ビデオ サービスは保証されません。 これは、DSP リソースが限られている場合に必要になる可能性があります。 テレビ電話の発信側は、会議の開始時点で DSP リソースが使用可能であれば、ビデオ サービスを利用できます。 それ以外の場合、発信側はオーディオ会議参加者として会議に接続されます。
ISR G2 ルータによるビデオ会議の詳細については、『Configuring Video Conferences and Video Transcoding』のマニュアルを参照してください。
Cisco TelePresence Video Communications Server
Cisco Unified Communications Manager は、Cisco TelePresence Video Communications Server(VCS)との相互運用が可能です。 2 つのシステムに互換性を持たせるため、Cisco Unified Communications Manager が Cisco VCS に接続する SIP トランクに SIP 正規化スクリプトを設定する必要があります。 この正規化スクリプトによって、2 つの製品が通信できるように SIP シグナリングを調整します。
Cisco TelePresence Video Communication Server は、Cisco TelePresence 製品ラインに対する、高度なテレプレゼンスとビデオ会議のコール制御を提供し、 標準対応のすべての SIP デバイスと H.323 デバイス間でエニーツーエニーの相互運用性を可能にします。次の 3 つの展開オプションを利用できます。
Server Control として、Cisco TelePresence Video Communication Server は、標準対応のすべてのテレプレゼンス エンドポイント、インフラストラクチャ、および管理ソリューションに対して、高度なテレプレゼンス アプリケーションとセッション管理を提供します。 Cisco VCS Control は、Session Initiation Protocol(SIP)プロキシおよび H.323 ゲートキーパー サービスを提供します。
Server Expressway として、Cisco TelePresence Video Communication Server は、SIP デバイスと H.323 デバイスに対して標準ベースのセキュアなファイアウォール トラバーサルを提供します。 Cisco VCS Expressway により企業間のコミュニケーションが可能になり、リモートおよび自宅ベースのワーカーに能力を与えることができます。また、サービス プロバイダーは、顧客にビデオ コミュニケーションを提供できます。
Starter Pack Express の展開では、Cisco TelePresence Video Communication Server は、中小規模の Cisco TelePresence システムを初めて導入する企業を対象としたオールインワンのソリューションを提供します。
Cisco TelePresence Video Communications Server との相互運用性の設定
手順Cisco Unified Communications Manager と Cisco VCS の相互運用を可能にするには、Cisco Unified Communications Manager が Cisco VCS に接続する SIP トランクで次の手順を実行します。
ステップ 1 Cisco Unified Communications Manager の管理ページで、 を選択します。 ステップ 2 Cisco Unified Communications Manager が Cisco VCS に接続する SIP トランクを選択します。 ステップ 3 [SIP プロファイル(SIP Profile)] ドロップダウン リスト ボックスで、[VCSの標準SIPプロファイル(Standard SIP Profile for VCS)] を選択します。 ステップ 4 [正規化スクリプト(Normalization Script)] ドロップダウン リスト ボックスで、[vcs-interop] を選択します。 ステップ 5 [正規化スクリプト(Normalization Script)] 領域で、[パラメータ名(Parameter Name)] フィールドと [パラメータ値(Parameter Value)] フィールドを空白のままにします。 これらのフィールドにすでに値が設定されている場合は、フィールドの内容を削除します。
ビデオの暗号化
Cisco Unified Communications Manager は、通信にかかわる個々のエンドポイントでも暗号化がサポートされている場合、オーディオ、ビデオなどのメディア ストリームの暗号化をサポートします。 Cisco Unified Communications Manager は、Secure Real-Time Transport Protocol(SRTP)を使用して、メディア ストリームを暗号化します。 機能の一部として、次のサポートを含みます。
SIP および H.323 のエンドポイントのサポート
メディア ターミネーション ポイント(MTP)passthru モードで動作時のメインのオーディオおよびビデオ回線の暗号化のサポート
複数の暗号化方式のサポート
RFC 4568 に従った Session Description Protocol(SDP)crypto-suite セッション パラメータのサポート
暗号化された通信を提供するため、SIP コール設定時にエンドポイントと Cisco Unified Communications Manager の間で暗号キーが交換されます。 このような理由から、SIP シグナリングは TLS を使用して暗号化する必要があります。 初期コール設定時に、ビデオ エンドポイントは、サポートする暗号化方式のリストを交換し、両方のエンドポイントでサポートされる暗号スイートを選択して、暗号キーを交換します。 エンドポイント間で共通の暗号スイートが得られない場合、メディア ストリームは暗号化されず、Real-Time Transport Protocol(RTP)を使用して転送されます。
(注)
個々のエンドポイントが暗号化をサポートしていない場合、RTP を使用して通信が行われます。
暗号化方式
Cisco Unified Communications Manager は、さまざまな暗号スイートをサポートしています。 暗号化方式は、SIP メッセージの SDP 部分の Crypto-suite オプションを使用して特定します。 次の表に、 Cisco Unified Communications Manager でサポートされる SDP 暗号スイートを示します。
表 1 サポートされる SDP 暗号スイート 暗号化規格
説明
AES_CM_128_HMAC_SHA1_80
128 ビット暗号キーおよび 80 ビット メッセージ認証タグ
AES_CM_128_HMAC_SHA1_32
128 ビット暗号キーおよび 32 ビット メッセージ認証タグ
F8_128_HMAC_SHA1_80
128 ビット暗号キーおよび 80 ビット メッセージ認証タグ
上記の方式に加えて、Cisco Unified Communications Manager はメディア ストリームの DTLS 暗号化もサポートしています。
暗号化方式のネゴシエーション
個々のコールに使用する暗号化方式の選択は、個々のエンドポイント自体で使用できる暗号スイートに従って行われます。 エンドポイント間で暗号化方式が一致しない場合、メディアは暗号化されず、RTP を使用して転送されます。
Cisco Unified Communications Manager は、SIP オファー/アンサー モデルを使用して、RFC 3264 に定義されているように、SIP セッションを確立します。 このコンテキストでは、発信側デバイスが SIP メッセージの本文にある SDP フィールド内に含まれるオファーを作成します。 オファーは通常、デバイスでサポートされる暗号化方式を含め、デバイスでサポートされるメディア特性を定義します。その他に、使用するメディア ストリーム、コーデック、IP アドレス、およびポートも定義します。
受信側デバイスは、SIP 応答の SDP フィールドのアンサーで、対応する自身の暗号スイート、一致するメディア ストリーム、コーデック、およびメディア ストリームを受信する IP アドレスとポートを指定して応答します。 Cisco Unified Communications Manager は、このオファー/アンサー モデルを使用して、重要な SIP 規格である RFC 3261 で定義される SIP セッションを確立します。
SIP オファー/アンサー モデルの動作は、機能によって異なります。 早期オファーと遅延オファーのプロセスは、わずかに異なります。
早期オファー セッションでは、着信側デバイスは、適切な暗号スイートを選択します。 この場合、発信側デバイスは、元の SIP invite メッセージで優先する暗号スイートを送信します。 着信側デバイスは、発信者が提供する暗号化方式のリストを、自身が使用可能な暗号化方式のリストと比較し、最適なオプションを選択します。 Re-Invite は、早期オファーと同じように処理されます。
遅延オファー セッションでは、発信側デバイスは、サポートする暗号化方式のリストを含めます。 最初の invite を受信すると、 Cisco Unified Communications Manager は、暗号化方式を含む SDP 部分を含めずに、INVITE を着信側デバイスに転送します。 着信側デバイスは、暗号化方式の自身のリストを含めて応答します。 Cisco Unified Communications Manager は、2 つのリストを比較し、両方のエンドポイントでサポートされる適切な暗号化方式を選択します。
サポートされるプロトコル
次の表に、特定のシグナリング方式を使用する場合にサポートされる暗号化方式を示します。
表 2 サポートされるプロトコルの暗号化のサポート シナリオ
サポート
SIP-SCCP
SCCP を介したビデオの暗号化はサポートされません。
MTP/RSVP/TRP を使用する SIP-SIP
ビデオの暗号化がサポートされます。 ただし、MTP passthru モードでは、メインのオーディオおよびビデオ回線だけが暗号化されます。
H.323 ICT を介した SIP-SIP
H.323 トランクを介したビデオの暗号化はサポートされません。 オーディオの暗号化だけがサポートされます。
SIP-H.323
SIP エンドポイントから H.323 エンドポイントへのコールではビデオの暗号化はサポートされません。
H.323-H.323
H.235 を使用してビデオの暗号化がサポートされます。
エンドポイントでの Binary Floor Control Protocol のサポート
Cisco Unified Communications Manager 8.6(2) は、特定のシスコのビデオ エンドポイントとサードパーティのビデオ エンドポイントで Binary Floor Control Protocol(BFCP)をサポートします。 BFCP を使用すると、ユーザは通話中のビデオによる会話内でプレゼンテーションを共有できます。
次に、BFCP を使用したプレゼンテーション共有の仕組みの例を示します。
2 つのテレビ電話間で通話中のビデオによる会話が行われています。 ユーザ A は、ラップトップに保存されているスライドのプレゼンテーションをユーザ B に見せることにします。 ユーザ A は、ラップトップを Cisco EX90 テレビ電話に接続し、電話機の [表示] ボタンを押します。 SIP INVITE メッセージが相手の電話機に対して開始され、BFCP ストリームへの招待が行われます。 BFCP セッションがネゴシエートされた後に、さらにストリームがオーディオおよびビデオのストリームに追加されます。 BFCP ストリームにより、ユーザ B は、ユーザ A のラップトップのデスクトップを表示できます。
シスコのビデオ エンドポイントでの BFCP のサポート
次のシスコのビデオ エンドポイントでは、エンドポイントのデバイスの認定と評価(QED)設定により、BFCP がデフォルトで有効になります。 BFCP が自動的に有効になるため、Cisco Unified Communications Manager ではこれらのエンドポイントの構成オプションを提供していません。
Cisco E20
Cisco TelePresence Codec C40
Cisco TelePresence Codec C60
Cisco TelePresence Codec C90
Cisco TelePresence EX60
Cisco TelePresence EX90
Cisco TelePresence Quick Set C20
Cisco TelePresence Profile 42(C20)
Cisco TelePresence Profile 42(C60)
Cisco TelePresence Profile 52(C40)
Cisco TelePresence Profile 52 Dual(C60)
Cisco TelePresence Profile 65(C60)
Cisco TelePresence Profile 65 Dual(C90)
Cisco TelePresence
Cisco TelePresence 1000
Cisco TelePresence 1100
Cisco TelePresence 1300-47
Cisco TelePresence 1300-65
Cisco TelePresence 1310-65
Cisco TelePresence 3000
Cisco TelePresence 3200
Cisco TelePresence 500-32
Cisco TelePresence 500-37
サードパーティ電話機での BFCP のサポート
次のサードパーティのビデオ エンドポイントでは、BFCP がデフォルトで無効になりますが、サポートは [電話の設定(Phone Configuration)] ウィンドウの [プロトコル固有情報(Protocol Specific Information)] で有効にできます。
Cisco Unified Communications Manager の管理ページでの設定のヒント
BFCP を使用するプレゼンテーション共有は、完全な SIP ネットワークだけでサポートされます。 エンドポイント、およびすべての中間デバイスとトランクを含むネットワーク全体が SIP である必要があります。 BFCP は、すべての SIP トランクおよび SIP 回線で有効になっている必要があります。
SIP トランクで BFCP を設定するには、[SIP プロファイルの設定(SIP Profile Configuration)] ウィンドウの [トランク固有の設定(Trunk Specific Configuration)] セクションにある [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスをオンにします。
SIP 回線で BFCP を設定するには、次の手順を実行します。
BFCP をサポートするシスコのビデオ エンドポイントでは、SIP 回線の設定は必要ありません。
BFCP をサポートするサードパーティのビデオ エンドポイントでは、[電話の設定(Phone Configuration)] ウィンドウの [プロトコル固有情報(Protocol Specific Information)] セクションにある [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスをオンにすることにより、BFCP を有効にします。
(注)
この機能で、次の GUI の変更が行われています。
[デバイスの設定(Device Settings)] > [SIPプロファイル(SIP Profile)]:[BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスが [SIP プロファイルの設定(SIP Profile Configuration)] ウィンドウの [トランク固有の設定(Trunk Specific Configuration)] セクションに移動されています。
[デバイスの設定(Device Settings)] > [電話(Phone)]:次のサードパーティ電話機で、[BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスが [電話の設定(Phone Configuration)] ウィンドウの [プロトコル固有情報(Protocol Specific Information)] セクションに追加されています。MTP トポロジ内の BFCP ネゴシエーション
新しいバージョン(15.2(2)T)の IOS メディア ターミネーション ポイント(MTP)ルータが利用できるようになり、セッションあたり最大 16 のメディア ストリーム(以前のリリースでは最大 3 ストリームのみ)が可能になったため、Cisco Unified Communications Manager で BFCP および追加ビデオ チャネルをサポートできるようになりました。 BFCP コールでは、追加ビデオ チャネルでビデオ会議とプレゼンテーション共有を達成するために、通常、4 つ以上チャネル(オーディオ、メイン ビデオ、追加ビデオ、および BFCP 制御チャネル)が必要です。 コールの両側が遠端カメラ制御(FECC)に対応している場合、5 つ目のチャネルを確立する必要があります。
(注)
MTP には、BFCP セッションをサポートするために十分なメディア ポートがないため、コールが確立されるときに BFCP メディア回線はネゴシエートされません。
Binary Floor Control Protocol によるプレゼンテーション共有
Cisco Unified Communications Manager は、Binary Floor Control Protocol(BFCP)を使用した通話中のビデオによる会話内でプレゼンテーション共有をサポートします。
Cisco Unified Communications Manager は、BFCP セッションが確立するまで、2 つのエンドポイント間で SIP メッセージをリレーすることで、BFCP ストリームのネゴシエーションを支援します。 このネゴシエーションには、共有リソースへのアクセスの一時的な権限である、フロアの確立を伴います。 BFCP ストリームは、エンドポイント間のポイントツーポイント ストリームです。 Cisco Unified Communications Manager が BFCP ストリームのターゲットになることはありません。
BFCP によるプレゼンテーション共有の仕組みについての例として、2 つの SIP テレビ電話間で通話中のビデオによる会話を行っていたとします。 ユーザ A は、ラップトップに保存されているスライドのプレゼンテーションをユーザ B に見せることにします。 ユーザ A は、ラップトップを Cisco EX90 テレビ電話に接続し、電話機の [表示] ボタンを押します。 これにより、BFCP ストリームの作成のために、SDP パラメータを含む SIP INVITE メッセージが相手の電話機に送信されます。 BFCP セッションがネゴシエートされた後に、さらにストリームがオーディオおよびビデオのストリームに追加されます。 BFCP ストリームにより、ユーザ B は、ユーザ A のラップトップのデスクトップを表示できます。
BFCP は、SIP ネットワークだけでサポートされます。 すべてのエンドポイント、中間デバイス、およびトランクを含むネットワーク全体が SIP である必要があります。 BFCP は、すべての SIP トランクおよび SIP 回線で有効になっている必要があります。
(注)
BFCP は IME トランクではサポートされないため、IME トランクに使用される SIP プロファイルでは、BFCP が無効になっている必要があります。
次のネットワーク図に、BFCP に使用されるネットワーク トポロジを示します。 Cisco Unified Communications Manager クラスタは、デバイス間での SIP メッセージの転送時だけ関与します。 エンドポイントが BFCP をネゴシエートした後は、BFCP ストリーム自体がデバイス間のポイントツーポイント ストリームです。
次の図に、BFCP 対応のネットワークの例を示します。 このネットワークは完全に SIP に対応しています。 Cisco Unified Communications Manager クラスタは中央に配置され、エンドポイント間の SIP シグナリングをリレーします。 オーディオおよびビデオのストリームだけでなく、BFCP ストリームもエンドポイント間のポイントツーポイントです。
BFCP 設定のヒント
Cisco Unified Communications Manager で BFCP を有効にするには、[SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウの [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスをオンにします。 チェックボックスをオンにしない場合、すべての BFCP オファーは拒否されます。 デフォルトでは、このチェックボックスはオフです。
BFCP は、完全な SIP ネットワークだけでサポートされます。 プレゼンテーション共有を機能させるには、BFCP は、エンドポイント間のすべての SIP 回線および SIP トランクだけでなく、すべての SIP エンドポイントで有効になっている必要があります。
次の図に、複数の Cisco Unified Communications Manager クラスタを使用する複雑なビデオ ネットワークの例を示します。 BFCP は、デバイスに接続されているすべてのトランクおよび回線で有効になっている必要があります。 このネットワークの場合、BFCP は、エンドポイントに接続する 4 つの SIP トランクと 2 つの SIP 回線で有効になっている必要があります。
BFCP に関する制限事項
次のシナリオにおいて、 Cisco Unified Communications Manager は BFCP ストリー ムを拒否します。
ネットワーク内の SIP 回線または SIP トランクのうちいずれかの [SIPプロファイル(SIP Profile)] ページの [BFCPを使用するプレゼンテーション共有を許可(Allow Presentation Sharing using BFCP)] チェックボックスがオフにされている。
一方のエンドポイントが BFCP をオファーするが、相手側のエンドポイントはオファーしない。
SIP 回線または SIP トランクが、MTP、RSVP、信頼されたリレー ポイント(TRP)、またはトランスコーダを使用する。 これらの場合、BFCP はサポートされません。
(注)
BFCP は、コールに MTP が不要である場合に限り、Cisco Unified CM Release 8.6 でサポートされます。 Cisco Unified CM リリース 9.0 以降では、MTP コールの BFCP は、MTP が 15.2.(2) T を実行している IOS ルータから割り当てられている場合、サポートされます。
BFCP は、SIP エンドポイントだけでサポートされます。
(注)
BFCP は、Cisco Unified Communications Manager と Cisco TelePresence MCU 間で使用されている場合、サポートされません。
BFCP でサポートされる機能
次の表に、BFCP プレゼンテーションを進行しながら一般的な機能を扱う方法を紹介します。
表 3 BFCP でサポートされる機能 通話中の機能
サポート
保留と再開
保留と再開の機能は、BFCP 対応エンドポイントを使用している場合、エンドポイントが現在 BFCP プレゼンテーションの最中かどうかにかかわらず完全にサポートされます。 ただし、再開の操作の後に続けてプレゼンテーションの再有効化が必要になる場合があります。
転送
転送機能は、BFCP 対応エンドポイントを使用している場合、エンドポイントが現在 BFCP プレゼンテーションの最中かどうかにかかわらず完全にサポートされます。 ただし、転送の操作の後に続けてプレゼンテーションの再有効化が必要になる場合があります。
会議(非 BFCP 会議コントローラ)
BFCP 対応会議コントローラを使用する場合、BFCP メディア回線およびプレゼンテーション ビデオはサポートされません。 ただし、メイン ビデオ ストリームはサポートされます。
2 つの BFCP 対応エンドポイントが、非 BFCP 会議コントローラを使用する会議に入る場合、メイン ビデオは会議全体で有効ですが、BFCP メディアおよびプレゼンテーション ビデオは無効です。
帯域幅管理
- コール アドミッション制御
- セッション レベルの帯域幅修飾子
- SIP 電話機のビデオ解像度のサポート
- RSVP
- 代替ルーティング
- DSCP マーキング
- フレキシブル DSCP マーキングとビデオ プロモーション
- フレキシブル DSCP マーキングとビデオ プロモーションのサービス パラメータ
- フレキシブル DSCP マーキングとビデオ プロモーションのサービス パラメータの設定
コール アドミッション制御
コール アドミッション制御では、広域(IP WAN)リンク上で同時に許可されるコール数を制限することにより、このリンクを経由するコールの音質およびビデオ品質を制御できます。 たとえば、メイン キャンパスとリモート サイトを接続する 56 kb/s フレーム リレー回線の音声品質は、コール アドミッション制御で調整できます。
コール アドミッション制御は、コールを確立するために使用できる十分な帯域幅があるかどうかを確認します。 コール アドミッション制御は、帯域幅が十分でないことを理由に、コールを拒否できます。
Cisco Unified Communications Manager では、ロケーションに基づいたコール アドミッション制御をリージョンと併用して、ネットワーク リンクの特性を定義します。 リージョンとロケーションは次のように機能します。
リージョンを使用して、ビデオ コールの帯域幅を設定できます。 リージョンでのオーディオ制限によって、ビット レートの高いコーデックが除外されることがあります。 ただし、ビデオ コールの場合は、ビデオ制限によってビデオの品質(解像度および伝送速度)が制約されます。 リージョンの詳細については、リージョンを参照してください。
ロケーションは、そのリンク上のすべてのコールに使用できる帯域幅の合計量を定義します。 リンク上にコールが確立すると、そのコールのリージョンの値は、そのリンクに使用できる合計帯域幅から差し引く必要があります。 ロケーションの詳細については、ロケーションを参照してください。
コール アドミッション制御の詳細については、コール アドミッション制御を参照してください。
セッション レベルの帯域幅修飾子
Cisco Unified Communications Manager は、セッション レベルの帯域幅修飾子を処理するためのロケーションのコール アドミッション制御をサポートしています。 セッション レベルの帯域幅修飾子は、初期 SIP シグナリングの SDP 部分のパラメータの一部として伝達されます。 これらのパラメータは、各エンドポイントがコールのそのタイプに対してサポートする帯域幅の最大量を示します。 これらのパラメータを、リージョンおよびロケーションの設定とともに使用して、各コールの帯域幅を設定します。
初期コールの設定中、コールの両側では、 Cisco Unified Communications Manager にそのコールの最大許容帯域幅を伝達します。 Cisco Unified Communications Manager は、この伝達内容を相手側のエンドポイントに渡しますが、エンドポイントで指定されている帯域幅がリージョンの設定よりも大きい場合、 Cisco Unified Communications Manager はこの値をリージョンの帯域幅の値に置き換えます。
Cisco Unified Communications Manager は、次のルールを使用して、特定のコールに割り当てる帯域幅の量を決定します。
Cisco Unified Communications Manager は、エンドポイントからオファーまたはアンサーを受信した場合、SDP にセッション レベルの帯域幅修飾子があるかどうかをチェックします。
セッション レベルの帯域幅修飾子がある場合、 Cisco Unified Communications Manager は、修飾子から帯域幅の値を取得します。 修飾子のタイプが 2 つ以上ある場合は、Transport Independent Application Specific(TIAS)、Application Specific(AS)、Conference Total(CT)の優先順位で修飾子を取得します。
セッション レベルの帯域幅修飾子がない場合、 Cisco Unified Communications Manager は、メディア レベルの帯域幅修飾子の合計から帯域幅の値を取得します。
割り当てる帯域幅は、リージョン設定の最大値を上限として、2 つのエンドポイントがサポートするタイプの最大値です。 割り当てる帯域幅は、リージョン設定を超えることはできません。
Cisco Unified Communications Manager は、エンドポイントとの通信時に次のロジックを使用します。
2 つ以上のセッション レベルの帯域幅修飾子タイプ(TIAS、AS、CT)を含むエンドポイントへのアンサー、早期オファー、または Re-Invite オファーを生成する場合、 Cisco Unified Communications Manager は、それぞれに同じ帯域幅の値を使用します。
アンサーを生成する場合、 Cisco Unified Communications Manager は初期オファーで受信したものと同じセッション レベルの帯域幅修飾子タイプ(TIAS、CT、AS)を使用します。
旧バージョンの Tandberg エンドポイント(MXP 1700 など)との下位互換の場合、 Cisco Unified Communications Manager は、ビデオ コールが保留され保留音(MOH)が挿入されたときに、セッション レベルの帯域幅修飾子を削除します。
SIP 電話機のビデオ解像度のサポート
Cisco Unified Communications Manager は、高解像度ビデオ コールの SIP ヘッダーの SDP 部分にある imageattr 行をサポートします。 9951、9971、および 8961 などの w360p(640 x 360)をサポートする Cisco SIP 電話は、次の条件に応じて自動的に最適な解像度をビデオ コールに選択します。
(注)
現在、w360p(640 x 360)ビデオ解像度をサポートする Cisco IP Phone モデル 9951、9971、または 8961 があり、Cisco Unified Communications Manager リリース 8.5(1) 以降にアップグレードしている場合は、ビデオ コールの解像度の変更に気付かない可能性があります。 w360p 解像度は、電話機ロード 9.2(1) で導入されました。
次のビデオ コール フローは、imageattr 行をサポートしない 2 台の 9951 電話機(電話機 A と電話機 B)間のフローです(例: Cisco Unified Communications Manager リリース 8.0(1) 以前を使用)。DSCP マーキング
DiffServ コード ポイント(DSCP)パケット マーキングは、各パケットのサービス クラスを指定するために使用され、次の特性を備えています。
フレキシブル DSCP マーキングとビデオ プロモーション
デバイスおよびアプリケーションは、DiffServ コード ポイント(DSCP)マーキングを使用し、IP 通信の Quality of Service(QoS)処理を示します。 たとえば、デスクトップ ビデオ エンドポイントはビデオ メディア ストリームにマルチメディア会議 AF41 マーキングを使用し、その一方、高解像度のビデオ ルーム システムはリアルタイム インタラクティブ CS4 マーキングを使用することがあります。 アプリケーションが同じタイプのアプリケーションとの間で IP 通信を送受信するとき、DSCP マーキングは対称であり、それぞれのアプリケーションが送受信する IP 通信の QoS 処理は同じです。 ただし、アプリケーションが異なるタイプのアプリケーションとの間でメディアを送受信する場合には、DSCP マーキングは非対称であり、それぞれのアプリケーションが送受信する IP 通信の QoS 処理は一貫しません。 たとえば、ビデオ ルーム システムがデスクトップ ビデオ エンドポイントから受信する QoS 処理は、ビデオ ルーム システムで必要とされる品質をサポートするには不十分であることがあります。
デバイスやアプリケーションは、確立されたセッション中に十分な帯域幅を確保するため、コール アドミッション制御(CAC)に従います。 確立されたセッションによって利用される帯域幅は、セッションの開始時と終了時に更新されます。 新しいセッションを確立しようとする際、そのセッションによって利用可能な帯域幅を超える場合には、そのセッションがブロックされます。 利用可能な帯域幅は、デバイスや異なるタイプのアプリケーションごとに個別に追跡できます。 たとえば、ビデオ メディア ストリームを送受信するデスクトップ ビデオ エンドポイントと高解像度ビデオ ルーム システムについて、帯域幅を個別に追跡することができます。
同じタイプのデバイスやアプリケーションが相互に通信を送受信すると、各方向で同じタイプの帯域幅削減が行われます。 ただし、異なるタイプのデバイスやアプリケーションが相互に通信を送受信する場合には、各方向で異なるタイプの帯域幅削減を行う必要があります。 また帯域幅削減の量は、IP ネットワークの通常の動作を反映し、通常、計画的に対称となります。 その結果、異なるタイプのデバイスやアプリケーションが相互に通信を送受信すると、帯域幅削減の合計が、実際に利用されているネットワーク量の最大 2 倍にまで達することがあります。 帯域幅におけるこの計算の不一致により、新しいセッションを確立しようとしても、不必要にブロックされてしまうことがあります。 たとえば、デスクトップ ビデオ エンドポイントと Cisco TelePresence イマーシブ ビデオ エンドポイントが通話中の場合、リリース 9.x Unified Communications Manager CAC デザインは、ビデオ帯域幅プールとイマーシブ帯域幅プールの両方から同じ量を削減します。これは、これらの 2 つのビデオ エンドポイントが DSCP を別々にマーキングし、メディア パケットが異なるキューで走査する可能性があるためです。 この動作により、必要な帯域幅の 2 倍が不必要に削減され、新しいビデオ コールがブロックされてしまう可能性があります。
Unified Communications Manager リリース 10.0(1) 以降のリリースでは、システム管理者は、より有利な CAC および QoS 処理を受けるアプリケーションを優先して帯域幅計算の不一致を調整するように、ビデオ プロモーション ポリシーを設定することができます。 たとえば、デスクトップ ビデオ エンドポイントと高解像度ビデオ ルーム システムの間のセッションがビデオ ルーム システムを優先して調整される場合、その調整はデスクトップ ビデオ エンドポイントのプロモーションと見なされます。
異なるタイプのデバイスとアプリケーションの間で調整が行われている場合、調整で優先されているアプリケーションのタイプについてのみ帯域幅が削減されます。 このタイプの承認対象のセッションに対して充分な帯域幅がある場合には、調整で優先されていないタイプのデバイスまたはアプリケーションは、使用する DSCP マーキングを、調整で優先されるタイプのアプリケーションで使用されるマーキングに変更するように指示を受けます。
たとえば、デスクトップ ビデオ エンドポイントが、高解像度ビデオ ルーム システムとのセッションでプロモートされると、そのデスクトップ ビデオ エンドポイントがビデオ ルーム システムと同じタイプのアプリケーションであるものとして帯域幅計算が行われます。 デスクトップ ビデオ エンドポイントは、その DSCP マーキングを、ビデオ ルーム システムで使用されるものに変更するように指示を受けます。 QoS 処理は両方向において一致します。帯域幅は、ビデオ ルーム システムと同じタイプのデバイスやアプリケーションの間のセッションに対して削減され、デスクトップ ビデオ エンドポイントと同じタイプのデバイスやアプリケーションの間のセッションに対しては削減されません。
フレキシブル DSCP マーキングとビデオ プロモーション機能をアクティブ化するには、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで、Use Video BandwidthPool for Immersive Video Calls サービス パラメータを [False] に設定し、Video Call QoS Marking Policy サービス パラメータを [Promote to Immersive] に設定します。 フレキシブル DSCP マーキングとビデオ プロモーション機能がアクティブになっていると、Unified Communications Manager は、ネゴシエートされた各メディア ストリームを示すトラフィック クラス ラベルをデスクトップ ビデオ デバイスに動的に伝達します。
トラフィック クラス ラベル
フレキシブル DSCP とビデオ プロモーション機能は、システム管理者によって定義されたビデオ プロモーション ポリシーに基づき、トラフィック クラス ラベル(TCL)を使用して動的に SIP エンドポイントを指示し、その DSCP をコールごとにマークします。 TCL はメディア回線ごとに定義された SIP Session Description Protocol(SDP)属性のため、TCL とその関連 DSCP マーキングは、ビデオ コールのオーディオ メディア回線とビデオ メディア回線で異なることがあります。 システム管理者は、ビデオ コールのオーディオ ストリームとビデオ ストリームに異なる DSCP マーキングを選択できます。
インタラクションおよび制限事項
フレキシブル DSCP マーキングとビデオ プロモーション機能には、以下のインタラクションおよび制限が適用されます。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、SIP クラスタ間経由でサポートされます。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、H.323 トランクや Media Gateway Control Protocol(MGCP)ゲートウェイ経由ではサポートされません。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、Skinny Client Control Protocol(SCCP)デバイスでサポートされます。
フレキシブル DSCP マーキングとビデオ プロモーション機能は、デスクトップ SIP ビデオ エンドポイントに依存します。 Unified Communications Manager リリース 10.0(1) の初期リリース時点においては、Cisco DX650 シリーズの SIP 電話機のみが必要なエンドポイント サポートを提供しています。
パススルー MTP がコールに挿入されると、Unified Communications Manager は、ビデオ ストリームのパケットを最初に発したエンドポイント デバイスから求められる DSCP マーキングで、パケットをマークするように MTP に信号を送ります。 1 つのコール内の 2 つのエンドポイントで異なる DSCP マーキングが使用されている場合(たとえば、Cisco TelePresence イマーシブ ビデオ エンドポイントとビデオ プロモーションなしのデスクトップ ビデオ エンドポイントなど)には、MTP は各ストリーム方向で DSCP マーキングを保持します。
シスコでは、フレキシブル DSCP マーキングとビデオ プロモーション機能を Multilevel Precedence and Preemption(MLPP)サービス コールで使用しないようにお勧めしています。 MLPP サービス機能が必要な場合には、シスコでは、Video Call QoS Marking Policy および Use Video BandwidthPool for Immersive Video Calls サービス パラメータをそれぞれのデフォルト値に設定することを推奨しています。 Video Call QoS Marking Policy および Use Video BandwidthPool for Immersive Video Calls サービス パラメータのデフォルト値を使用すると、Unified Communications Manager とエンドポイントはメディア パケットに MLPP DSCP マーキングを使用します。
フレキシブル DSCP マーキングとビデオ プロモーションのサービス パラメータ
Unified Communications Manager リリース 10.0(1) 以降のリリースでは、フレキシブル DSCP マーキングとビデオ プロモーション機能を設定するために、次のクラスタ全体のサービス パラメータが提供されています。
Video Call QoS Marking Policy。 このパラメータを使用すると、管理者は、デスクトップ ビデオ エンドポイントと Cisco TelePresence イマーシブ ビデオ エンドポイントの間の帯域幅割り当ての不一致をイマーシブ エンドポイントを優先して調整するように、Promote to Immersive ポリシーを設定できます。 プロモーションが実行されると、オーディオおよびビデオ帯域幅はイマーシブ帯域幅プール割り当てから予約されます。 Promote to Immersive ポリシーは、フレキシブル DSCP マーキングをサポートするイマーシブ ビデオ デバイスとデスクトップ ビデオ デバイスの間のコールでのみ適用されます。
Promote to Immersive ポリシーを設定するには、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで Use Video BandwidthPool for Immersive Video Calls パラメータを [False] に設定し、Video Call QoS Marking Policy パラメータを [Promote to Immersive] に設定します。
Use Video BandwidthPool for Immersive Video Calls。 このパラメータは、Unified Communications Manager がイマーシブ ビデオ コールのデスクトップ ビデオ帯域幅プールから帯域幅を予約するかどうかを指定します。
DSCP for Video Calls。 このパラメータは、ビデオ コールのビデオ ストリームの DSCP 値を指定します。
DSCP for Audio Portion of Video Calls。 このパラメータは、ビデオ コールのオーディオ ストリームの DSCP 値を指定します。
DSCP for TelePresence Calls。 このパラメータは、Cisco TelePresence ビデオ コールのビデオ ストリームの DSCP 値を指定します。
DSCP for Audio Portion of TelePresence Calls。 このパラメータは、Cisco TelePresence ビデオ コールのオーディオ ストリームの DSCP 値を指定します。
Default Intraregion Max Immersive Video Call Bit Rate (Includes Audio)。 このパラメータは、リージョンとそれ自体の関係の [リージョンの設定(Region Configuration)] ウィンドウで、最大イマーシブ ビデオ コール ビット レートとして [システムデフォルトの使用(Use System Default)] オプションが選択された場合に、特定のリージョン内の各イマーシブ ビデオ コールのデフォルトの最大合計ビット レートを指定します。 [リージョンの設定(Region Configuration)] ウィンドウでのオプション選択の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。
Default Interregion Max Immersive Video Call Bit Rate (Includes Audio)。 このパラメータは、そのリージョンと別のリージョンの関係の [リージョンの設定(Region Configuration)] ウィンドウで、最大イマーシブ ビデオ コール ビット レートとして [システムデフォルトの使用(Use System Default)] オプションが選択された場合に、特定のリージョンと別のリージョンの間の各イマーシブ ビデオ コールのデフォルトの最大合計ビット レートを指定します。 [リージョンの設定(Region Configuration)] ウィンドウでのオプション選択の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。
フレキシブル DSCP マーキングとビデオ プロモーションのサービス パラメータの設定
手順
ステップ 1 Cisco Unified Communications Manager の管理ページで、 を選択します。 [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウが表示されます。
ステップ 2 [サーバ(Server)] ドロップダウン リストから、パラメータを設定するサーバを選択します。 ステップ 3 [サービス(Service)] ドロップダウン リストで、[Cisco CallManager(アクティブ)(Cisco CallManager (Active))] サービスを選択します。 サービスが「Active」と表示されていない場合は、そのサービスを Cisco Unified Serviceability でアクティブにします。
ステップ 4 パラメータを設定するには、 [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで該当の領域にスクロールし、パラメータ値を更新します。
(注) デスクトップ ビデオ エンドポイントをイマーシブ ビデオ エンドポイントにプロモートするビデオ プロモーション ポリシーを設定するには、Use Video BandwidthPool for Immersive Video Calls パラメータを [False] に設定し、Video Call QoS Marking Policy パラメータを [Promote to Immersive] に設定します。
スクロール先 サービス パラメータの設定 Clusterwide Parameters(System - QOS)
DSCP for Video Calls
DSCP for Audio Portion of Video Calls
DSCP for TelePresence Calls
DSCP for Audio Portion of TelePresence Calls
Clusterwide Parameters(System - Location and Region)領域
Default Intraregion Max Immersive Video Call Bit Rate(Includes Audio)
Default Interregion Max Immersive Video Call Bit Rate(Includes Audio)
Use Video BandwidthPool for Immersive Video Calls
Clusterwide Parameters(Call Admission Control)領域
Video Call QoS Marking Policy
ヒント サービス パラメータについては、パラメータ名をクリックするか、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウに表示される疑問符(?)アイコンをクリックしてください。
ステップ 5 [保存(Save)] をクリックします。
ビデオ コール用の追加設定
トランクと H.323 クライアントの相互対話
ビデオ コールでのトランクと H.323 クライアントの相互対話は、オーディオ コールの相互対話と同じように機能します。 Cisco Unified Communications Manager におけるトランクとゲートキーパーを参照してください。
ゲートウェイ タイマー パラメータ
H.323/H.320 ゲートウェイを経由する一部のボンディング コールでは、ゲートウェイで H.323 TCS メッセージの交換にかかる時間が長くなります。 必要な時間が複数の Cisco CallManager サービス パラメータのタイマー設定値を超えていると、 Cisco Unified Communications Manager によってコールがドロップされます。
デフォルトの Cisco Unified Communications Manager ゲートウェイ タイマー値が小さすぎると、 Cisco Unified Communications Manager がコール接続の完了前にコールをドロップします。 このようなコール失敗を防ぐために、次のサービス パラメータのタイマー値を増やすことをお勧めします。
ビデオ会議に対する会議制御
ビデオと相互運用
プロトコルおよび配置
ビデオと相互運用では、次のプロトコルがサポートされています。
SIP から SIP
H323 から H323
SIP から SIP クラスタ間トランク(ICT)、SIP ICT から SIP
H323 から H323 ICT、H323 ICT から H323
SIP から H323(ICT あり、またはなし)
この機能の制限事項および特別な考慮事項の詳細は、制限事項を参照してください。
ポイントツーポイント コールの高画質の相互運用
ロケーションベースのコール アドミッション制御(CAC)のみ
TelePresence と、Telepresence Interop Protocol(TIP)をサポートするサードパーティのエンドポイント間の、プレゼンテーション共有およびセキュアな相互運用
Cisco TelePresence System(CTS)、 Cisco Unified Communications Manager、およびサードパーティのエンドポイントを含むマルチポイント コールでの Media Transcoding Engine(MXE)および Cisco Unified Video Conferencing(CUVA)の使用
サポートされるシスコおよびサードパーティのエンドポイント
ビデオと相互運用では、次のエンドポイントがサポートされています。
シスコ認定のサードパーティのビデオ エンドポイント
Cisco E20(Tandberg E20)
Cisco Unified Communication interface for Microsoft Office Communicator(CUCiMOC)または CUCiConnect(Cisco WebEx など)などの Cisco Unified Clients Services Framework(CSF)ベースのクライアント
Cisco Unified Video Advantage(CUVA)
Cisco Unified Personal Communicator(CUPC)
MP Hardware Media Switch(HMS)または Software Media Switch(SMS)などの MeetingPlace 会議ブリッジ
シスコ認定のサードパーティ デバイスを検索するには、Cisco Developer Network にアクセスして次の手順を実行します。
Cisco Developer Network(CDN)にログインします(該当する場合)。
CDN のメイン ウィンドウから、[Technology Partners] タブをクリックします。
[Partner Search] タブをクリックします。
検索ボックスで、(すべての技術を対象として)サードパーティ会社の名前を入力します(Polycom など)。
サードパーティ会社の情報が表示された場合は、該当するリンクをクリックして詳細を表示します。
サードパーティ デバイスは、 Cisco Unified Communications Manager の管理ページの [電話の設定(Phone Configuration)] で設定します。 サポートされているデバイス タイプおよびライセンス要件の一覧については、サードパーティの SIP エンドポイントを参照してください。
制限事項
高度なプレゼンテーション共有とセキュリティの相互運用は、2 つの TelePresence Interop Protocol(TIP)対応のエンドポイント間でのみサポートされます。
H239 プレゼンテーション共有および H235 セキュリティは、2 つの H323 エンドポイント間でのみサポートされます。
2 つのエンドポイント間で最適な解像度を保証するには、エンドポイントのプロトコルとトランクのプロトコルが同一である必要があります。たとえば、SIP トランクで接続された SIP ポイントツーポイント エンドポイントなどです。
TelePresence との相互運用についてはロケーションベースの CAC のみです。
アドホック会議およびミートミー会議では、CUVC と MeetingPlace ソフトウェアのメディア サーバがサポートされます。 会議ブリッジでは SCCP がサポートされ、エンドポイントでは SIP または H323 がサポートされているため、解像度は標準画質に制限されることがあります。
Cisco Intercompany Media Engine(IME)は、 Cisco Unified Communications Manager のエンドポイントと Telepresence 間ではサポートされていません。
インターネット プロトコル バージョン 6(IPv6)
Cisco Unified Communications Manager は、デュアル スタック モードと同様に、IPv6 モードで SIP 回線と SIP トランクでのビデオおよびアプリケーション メディア ストリームの送信をサポートします。 Cisco Unified Communications Manager はまた、IPv4 または IPv6 を使用するように設定された SIP 回線と SIP トランクで、他の Unified Communications Manager クラスタおよび Video Communications Server(VCS)とのインターワーキングをサポートします。
遠端カメラ制御プロトコルのサポート
遠端カメラ制御(FECC)プロトコルを使用すると、リモートのカメラを制御できます。 ビデオ コールでは、FECC により、コールの一方の側で遠端のカメラを制御することができます。 これには、カメラのパンニング、チルト、ズームインとズームアウトが含まれます。 複数のカメラを使用するビデオ会議では、FECC を使用して別のカメラに切り替えることができます。
Cisco Unified Communications Manager は、FECC 対応のビデオ エンドポイントで FECC プロトコルをサポートしています。 Cisco Unified Communications Manager は、SIP から SIP へのコールまたは H.323 から H.323 へのコールで FECC をサポートしていますが、SIP から H.323 へのコールでは FECC をサポートしていません。 FECC をサポートするため、Cisco Unified Communications Manager は SIP または H.323 シグナリングを介したアプリケーション メディア チャネルを設定します。 メディア チャネルが確立されると、個々のエンドポイントで FECC シグナリングを伝達できるようになります。
(注)
メディア ターミネーション ポイント(MTP)(バージョン 15.2(2)T 以降)が SIP-SIP コールに存在し、コールに利用できるチャネルが 5 チャネルある場合は、FECC を有効化できます。保留ビデオ
概要
保留ビデオは、ビデオ コンタクト センターに電話をかけるお客様がエージェントに初めてご相談された後、コンタクト センターで特定のビデオを見ることができるビデオ コンタクト センター向けの機能です。 この場合、お客様が保留状態になっている間に再生されるビデオ ストリームをエージェントが選択します。
Cisco Unified Communications Manager(Unified Communications Manager)には、[保留ビデオ サーバ(Video on Hold Server)] という新しい設定が加わり、既存の [メディア リソース(Media Resources)] メニューの下でメディア コンテンツ サーバをプロビジョニングできるようになっています。 メディア コンテンツ サーバは、Unified Communications Manager から指示を受けた場合に音声とビデオ コンテンツをストリーミングできます。 メディア コンテンツ サーバは、SIP を信号プロトコルとして使用して、Unified Communications Manager 制御の下で音声とビデオ コンテンツの保存とストリーミングを行える外部デバイスです。 メディア コンテンツ サーバは、1080p、720p、または 360p などの低解像度で高解像度ビデオ コンテンツを提供することができます。
ビデオ コンタクト センターだけでなく、一般的な保留ビデオ機能が必要な配置で、企業内に保留ビデオを使用できます。 保留ビデオ サーバの設定済みのデフォルト ビデオ コンテンツ ID を使用して、保留ユーザにビデオ ストリームを再生します。
特定のセッション用のメディア コンテンツ サーバの設定と割り当ては、Unified Communications Manager の [メディアリソースグループ(Media Resource Group)] および [メディアリソースグループリスト(Media Resource Group List)] の構成に従います。
Cisco MediaSense は、メディア コンテンツ サーバとして使用されます。
(注)
配置のルーティング後、Customer Voice Portal(CVP)を持つ Unified Contact Center では、保留ビデオ機能を取得するため、Unified Communications Manager と CVP の間で実行される SIP トランクで、保留ビデオのリソースを割り当てる必要があります。拡張ロケーション コール アドミッション制御との相互作用
この機能では、Unified Communications Manager クラスタ内に Cisco MediaSense サーバを配置できます(Cisco MediaSense クラスタは、保留にした側が登録されているクラスタに直接接続されます)。 その場合、Unified Communications Manager クラスタは保留中のロケーションと Cisco MediaSense ロケーション間の帯域幅を削減する役割を担います。 保留ビデオのインタラクションで 720p または 1080p ビデオ ストリームが使用されるので、既存のセッションのビデオ品質を保つため、新しいセッションを許可する前に、帯域幅の使用状況を考慮することが大切です。
保留ビデオの設定
SIP トランクを使用する Unified Communications Manager を Cisco MediaSense クラスタに設定します。 Cisco MediaSense サーバへの SIP トランクには、Cisco MediaSense ノードの IP アドレスが設定されます。 Unified Communications Manager の SIP トランクは、最大 16 個の宛先 IP アドレスをサポートします。
(注)
冗長性およびスケーラビリティの目的で、Cisco MediaSense クラスタには、2 つ以上のノードが必要です。
保留ビデオの設定には、2 つのトポロジが考えられます。
Cisco MediaSense は、保留にした側の Unified Communications Manager クラスタに直接接続されます。
保留ビデオ サーバが保留にした側として同じクラスタにある場合は、保留ビデオ サーバ設定の SIP トランクが Cisco MediaSense サーバを指し、デフォルトのコンテンツ識別子が MediaSense サーバに存在するストリーム ID を指す必要があります。 コンテンツ識別子は、任意の英数字の文字列にすることができます。 追加の設定は必要ありません。
Cisco MediaSense は、Session Management Edition(SME)とともに中央に配置されます。
保留ビデオ サーバが SME から外れたところに配置されている場合、保留にした側をホストするリーフ クラスタに保留ビデオ サーバを設定する必要があります。 この保留ビデオ サーバの SIP トランクは、SME SIP トランクを指す必要があります。 SME では、Cisco MediaSense サーバを指すように SIP トランクをプロビジョニングしなければなりません。
この集中型の配置をサポートするための Unified Communications Manager の設定方法が 3 つあります。
コンテンツ識別子が数値の場合。この場合、INVITE を Cisco MediaSense サーバにルーティングするには、ルート パターンを SME にプロビジョニングする必要があります。 基本的に、リーフ クラスタによって送信された INVITE URI の左側を使用して、Cisco MediaSense サーバにコールをルーティングします。 INVITE URI の右側には、SME ノードの IP アドレスが含まれます。
コンテンツ識別子が英数字で、Cisco MediaSense の IP アドレスが含まれる場合。この場合、リーフ クラスタに設定されたコンテンツ識別子には、Cisco MediaSense サーバのストリーム ID と IP アドレスが含まれている必要があります(stream-id@mediasense-ipaddress)。
SME クラスタには、MediaSense サーバの IP アドレスがデフォルトのコンテンツ識別子に一致する IP アドレス ルーティングを使用する SIP ルート パターンを設定する必要があります。 このシナリオでは、ルートは、リーフ クラスタによって送信された INVITE URI(MediaSense の IP アドレス)の右側に基づいています。
コンテンツ識別子が英数字で、ドメイン名が含まれる場合。この場合、リーフ クラスタに設定されたコンテンツ識別子には、Cisco MediaSense サーバのストリーム ID とドメイン名が含まれている必要があります(stream-id@cisco.com)。
SME クラスタでは、ルート文字列として URI カタログが SIP ルート パターンとともに作成される必要があります。 Cisco MediaSense サーバからのコンテンツ識別子は、URI インフラストラクチャを使用してこのカタログにインポートされなければなりません。
(注)
ドメイン ルーティングを使用するように、SIP ルート パターンを設定する必要があります。 この SIP ルート パターンは、SIP トランクから Cisco MediaSense サーバを指す必要があります。
保留ビデオの SIP トランク
保留ビデオを指す SIP トランクが、デフォルト設定で設定されている必要があります。 次の情報が SIP トランクの設定に必要です。
[名前(Name)]
[説明(Description)]
[デバイスプール(Device Pool)]
[ロケーション(Location)]
[接続先アドレス(Destination Address)] と [接続先ポート(Destination Port)](複数の IP アドレスとポートの指定が可能)
[SIPトランクセキュリティプロファイル(SIP Trunk Security Profile)]
[SIPプロファイル(SIP Profile)]:オプションの ping が設定された SIP プロファイルを選択する必要があります。 存在しない場合は作成してください。 これは必須ではありませんが、ユーザ エクスペリエンスを改善します。
(注)
SIP トランクの他の設定は、保留ビデオではサポートされていません。
保留ビデオの設定
手順
ステップ 1 Cisco Unified Communications Manager の管理ページで、 を選択します。 ステップ 2 [新規追加(Add New)] をクリックして、新規の保留ビデオ サーバを設定します。 ステップ 3 保留ビデオ サーバの名前を入力します。 ステップ 4 サーバの説明を入力します。 ステップ 5 デフォルトのビデオ コンテンツ ID を入力します。 ステップ 6 ドロップダウン リストから、使用する SIP トランクを選択します。 SIP トランクを新しく作成する必要がある場合には、[SIP トランクの作成(Create SIP Trunk)] ボタンをクリックします。 ステップ 7 [保存(Save)] をクリックします。
ビデオ テレフォニーおよび Cisco Unified Serviceability
パフォーマンス モニタリング カウンタ
ビデオ ブリッジ カウンタ
ビデオ会議イベントによって、次の Cisco Video Conference Bridge のパフォーマンス モニタリング カウンタが更新されます。
ConferencesActive
ConferencesAvailable
ConferencesCompleted
ConferencesTotal
OutOfConferences
OutOfResources
ResourceActive
ResourceAvailable
ResourceTotal
これらのカウンタは、 Cisco Unified Communications Manager オブジェクト内に VCB プレフィックスとともに表示されます。
コール詳細レコード
ビデオ テレフォニー イベントによって、 Cisco Unified Serviceability 内のコール詳細レコード(CDR)が更新されます。 これらの CDR には、次の情報が含まれます。
ビデオ チャネルの IP アドレスおよびポート
コーデック:H.261、H.263、H.264、Cisco VT Camera wideband video
コール帯域幅
解像度:QCIF、CIF、SQCIF、4CIF、16CIF、または Custom Picture Format
また、 Cisco Unified Communications Manager は通話中のビデオの CDR を保管し、次のコール シナリオをサポートします。