コミュニケーションとコラボレーション

音声が OCS 2007 にもたらす力

Rajesh Ramanathan

概要 :

• OCS 2007 で通話を行う
• 通話のセキュリティ保護のしくみ
• OCS でのマルチモーダルな会話
• Exchange UM と連携してボイスメールを提供する

目次

基本的な音声通話
電話番号を使用する
セキュリティで保護された通話
NAT とファイアウォールを通過する
電話番号に基づいてルーティングを実行する
着信ルーティング
品質報告とトラブルシューティング
すべての側面を一元管理する
マルチモーダルな動作と会話
ボイスメール
まとめ

Microsoft Office Communication Server (OCS) 2007 に関するこのシリーズの第 1 部では、優れた機能を提供する Live Communication Server (LCS) 2005 を基に OCS がどのように構築されたかについて説明しました。

この LCS を基に構築された OCS では、強化された企業規模のインスタント メッセージング (IM) 機能とプレゼンス機能、および高度なメディア機能と電話機能が提供されます。詳細については、TechNet Magazine 2008 年 2 月号の記事 (technet.microsoft.com/magazine/cc194409) を参照してください。この記事では、その続編として、OCS とボイス オーバー IP (VoIP) とのかかわりについて詳しく説明します。具体的には、OCS システムで行われる単純な音声通話のしくみを取り上げ、そのテクノロジを構成する各層について説明します。各コンポーネントの詳細については、対応する機能と共に説明します。

以前の記事でも説明したように、OCS では、次のようなさまざまな構成を使用するユーザーにテレフォニーを提供できます。

エンタープライズ ボイス PBX を使用する必要なく、OCS を Microsoft® 仲介サーバーと共に使用する、完全なユニファイド コミュニケーション ソリューションです。このシステムでは、Exchange ユニファイド メッセージング (UM) によってボイスメール機能が提供されます。この記事の残りの部分では、このサービスを使用するユーザーを "UC ユーザー" と呼びます。また、この構成を使用するクライアントを "UC エンドポイント" と呼びます。

PBX 統合を利用したエンタープライズ ボイス この構成によって、ユーザーはデスクトップ上で既存の PBX 電話を使用し、それと同時にユニファイド コミュニケーションのメリットを得ることができます。また、OCS と PBX を並列に構成できるので、着信通話で Office Communicator エンドポイントと PBX エンドポイントの両方を同時に呼び出すことができます。さらに、PBX によって、通話のルーティング機能とボイスメール サービスも提供されます。

リモート通話コントロール この機能によって、ユーザーは PBX 電話を通常の電話として使用し、その電話を Office Communicator クライアントから制御できるようになります。

基本的な音声通話

ここでは、エンタープライズ ボイス ユーザーの動きに注目します。単純な音声通話は、RFC 3261 で定義されているように、OCS システム内で SIP INVITE メカニズムを使用してセットアップされます。OCS サーバーは、ポストマスタの役割に似たプロキシとして機能し、クライアント (またはエンドポイント) 間でメッセージを中継します。リアルタイムのセッション (通話セッションやインスタント メッセージング セッションなど) が作成されるたびに、クライアントによって新しい SIP INVITE が生成されます。INVITE が確認され、応答が返される (つまり、リモート エンドポイントから 200 OK 応答が送信される) と、通話が確立されます (図 1 参照)。

図 1. INVITE の形式と 200 OK

INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**

図 2 では、Alice が Office Communicator (OC) 2007 で [Communicator での通話] をクリックして Bob を呼び出します。そして、OC 2007 から Bob の SIP URI (Uniform Resource Identifier) である sip:bob@example.com に INVITE が送信されます。この INVITE には、Alice が音声を受信できるメディア エンドポイントの音声セッション記述子 (SDP、これは Session Description Protocol の略語としても使用されます) が含まれます。OCS は、INVITE を Bob の登録済みの SIP エンドポイント (Communicator Phone Edition や Communicator デスクトップなど) に分岐します。INVITE には、sip:alice@example.com という値を持つ From ヘッダーが含まれます。Bob のクライアント エンドポイントは、このヘッダーを使用して名前の後方参照 (RNL) を実行し、着信通話の通知に使用する名前 (Alice) を検索します。

図 2 複数のエンドポイントへの通話のルーティング (画像をクリックすると拡大表示されます)

各エンドポイントは、Globally Routable User Agent URI (GRUU) を保持しています。GRUU は、SIP エンドポイントを一意に識別するための URI で、登録処理中に OCS サーバーから取得されます。GRUU のアドレスは、SIP メッセージのルーティングに役立ちます。一度エンドポイントが通話に応答すると、それ以降、通話中に実行されるその他の処理に関する SIP 通知は、GRUU アドレスを使用して、直接エンドポイント間で送信されます。

図 3 は処理の続きを示しており、Bob が Communicator デスクトップから応答しています。Bob の OC は 200 OK メッセージを送信し、音声を受信できる場所を通知します。OCS プロキシは、あるエンドポイントからの応答を検出するとすぐに、別の Communicator Phone Edition エンドポイントへの通話を取り消します。Alice の Communicator エンドポイントが 200 OK 応答を受信すると、両方の Communicator エンドポイントが、メディアを起動するために必要な情報 (IP ポートや暗号化パラメータなど) を保持します。

図 3 あるエンドポイントからの応答 (画像をクリックすると拡大表示されます)

電話番号を使用する

ここまでは、ユーザーが [Communicator での通話] をクリックしたときに招待を作成する処理のしくみについて説明しましたが、ユーザーが電話番号を選択または入力した場合は、少し異なる処理が実行されます。

• クライアントは、まず電話番号を正規化し、それを電話 URI として表します。電話 URI は、RFC 3966 で定義されているように、電話番号によって識別されるリソースを示します。
• OCS サーバーは SIP URI のみを認識するので、クライアントは、ドメイン サフィックスと user=phone タグを追加して、電話 URI を対応する SIP URI に変換します。
• 番号が内部ユーザーと一致する場合、OCS は招待を直接ルーティングします。番号が内部ユーザーと一致しない場合、招待は最も近い SIP-PSTN ゲートウェイにルーティングされます。

公衆交換電話網 (PSTN) 番号への一部の通話では、通話への応答が返される前に、メディア パスが設定される必要があります。これは、通話を完了するために、リモートのアナウンスを再生したり、追加の数字を収集したりすることを目的としています。このようなシナリオでは、PSTN ゲートウェイが、音声 SDP を含む 183 Session Progress インジケータを送信します。Communicator は、この情報を使用して、リモート ユーザーが通話に応答する前に、1 つの通話先エンドポイントとの間に双方向のメディア パスを設定します。

初期メディア パスの設定を完了すると、Communicator でデュアル トーン多重周波数 (DTMF、電話のトーン信号) キーパッドを使用できるようになります。これによって、ユーザーは、リモート システムが必要とする追加の数字を入力できます。入力された DTMF の数字は、RFC 2833 パケットとしてメディア パスに送信されます。PSTN ゲートウェイでは、PSTN 側の適切な DTMF トーン信号が生成されます。

Bob が携帯電話への同時呼び出しを有効にしている場合、OCS プロキシによって通話がゲートウェイにルーティングされ、それと同時に Bob の他の Communicator エンドポイントが呼び出されることに注意してください。このようなシナリオでは、分岐処理が有効になっていることが、OCS プロキシからの 183 Session Progress 応答によって通知されます。その後、Communicator によって、PSTN ゲートウェイとの間に受信専用メディア チャネルが確立されます。

セキュリティで保護された通話

OC によってセットアップされる音声通話の重要な機能の 1 つは、RFC3711 で定義されているように、Secure Real-Time Transport Protocol (SRTP) を使用することによって、メディアが既定で暗号化されることです。SRTP によって、機密性、メッセージの認証、および再生の保護が RTP トラフィックに提供されます。通話のセットアップ中、クライアントは、他のクライアントとの間でセキュリティ機能のネゴシエーションを行い、INVITE メカニズムの一環として暗号化キーを交換します。

OC は、通話を "任意で" 暗号化できるように既定で設定されています。これにより、2 つの OC エンドポイント間で、暗号化されたメディア チャネルを設定できます。管理者は、組織の規制遵守要件に基づいて、この設定を調整できます。たとえば、制限を厳しくしてすべての通話で暗号化を強制したり、それらをまとめて無効にしたりできます。

NAT とファイアウォールを通過する

OCS システム内のクライアントは、既存の NAT コンポーネントに変更を加える必要なく、Interactive Connectivity Establishment (ICE) テクノロジを使用して、ネットワーク アドレス変換 (NAT) デバイスとファイアウォールの外側にいるユーザーにメディア接続を提供します。ICE テクノロジは、現在、インターネット技術標準化委員会 (IETF) によって標準化されています。各クライアントは、音声ビデオ (A/V) エッジ サーバーを検出します。これは、インバンド プロビジョニングというメカニズムを使用して ICE テクノロジを提供し、サインオン中に A/V エッジへの認証済みの接続を維持するサーバーです。

クライアントは、通話を開始する前に、A/V エッジ サーバー (メディア リレー用)、NAT、またはホスト クライアント自体が保持する "候補" (接続する可能性のあるアドレスとポート) にリソースを割り当てます。セッション開始プロトコル (SIP) の INVITE が送信されるときに、この接続情報が INVITE の一部として含まれます。同様に、200 OK 応答には、ピアの候補に関する情報が含まれます。各エンドポイントがピアの候補の一覧を取得すると、複雑なランク付けおよび確認メカニズムによって、2 つのピア間におけるメディアの正常な処理を保証する最適なパスが選択されます。

電話番号に基づいてルーティングを実行する

電話番号に基づいたルーティングは、基本的な通話メカニズムよりも多少複雑です。この複雑さを生む要因を次に示します。

• 組織が複数の異なるダイヤル プランを用意し、そのダイヤル プランを内部で短縮ダイヤル用に展開している可能性があります。
• 番号が標準的でない形式で保存されている可能性があります (ユーザーが 7 桁の数字を Microsoft Office Outlook® で保存した場合など)。
• 異なる発信番号に異なるポリシーがマップされている可能性があります。たとえば、特定のユーザーによる国際電話番号への発信がブロックされる場合があります。

OCS システムで正常に電話番号をルーティングするには、電話番号が RFC 3966 の電話 URI 形式に従っている必要があります。この形式に従っていない番号は、クライアントが INVITE を送信する前に変換されます。図 4 は、OCS システム内で発生するこの処理のしくみを示しています。

図 4 電話番号のルーティング (画像をクリックすると拡大表示されます)

クライアントが使用できる番号は、さまざまなソースから提供される可能性があります。アドレス帳サービス (ABS) からは、事前に正規化された番号が提供されます。ABS では、管理者が定義した正規化ルールを使用して、番号を正規の E.164 形式に変換できます。この正規化された番号にクライアントから SIP INVITE が送信されると、OCS は変換処理を適用して、番号を内部ユーザーにマップします。

• 手順 1 は、OCS システムで受信する番号が、一意である (E.164 番号計画に従って正規化されている) か、場所を識別する電話のコンテキストを含むことを示しています。これらの番号は、SIP INVITE の一部としてサーバーに送信されます。OCS は、INVITE を変換処理にルーティングします。
• 変換処理 (手順 2) では、サーバー側の RNL を使用する UC エンドポイントへの電話番号のマッピングが試行されます。この変換処理では、受信した番号から発信ルーティングまたは UC ユーザーへのルートが識別されます。番号を正常に変換できなかった場合、この通話は失敗し、4xx コードが返される可能性があります。
• 番号が非 UC または外部の番号に変換された場合、その番号は発信ルーティング コンポーネントに送信されます。このコンポーネントによって、発信者に関連付けられた番号を対象とするポリシーが適用された後、その後の処理を実行するために、INVITE が適切な SIP-PSTN ゲートウェイにリダイレクトされます (手順 3A)。発信ルーティングでは、必要に応じて、ゲートウェイ間での通話の負荷分散や、代替ゲートウェイへのフェールオーバーが実行されます。特定の番号へのアクセスが禁止されている場合、発信ルーティング処理では、通話が失敗するか拒否され、SIP 403 応答コードが返されます。発信ルーティングは、発信者が UC ユーザーである場合にのみ適用されることに注意してください。発信者が UC ユーザーでない場合、OCS は、その URI 用に設定されたゲートウェイへの静的ルートを使用することを試みます。
• 番号が UC ユーザーの番号に変換された場合、そのユーザーの SIP URI に INVITE がルーティングされます (手順 3B)。着信ルーティングは、UC ユーザーと、SIP URI に発信された通話のみに適用される OCS の機能です。この後説明しますが、着信ルーティングでは、UC ユーザーの呼び出しのタイムアウト、通話の転送、およびボイスメールの転送に関するルールが適用されます。

正規化処理によって生成される番号は、クライアントの場所によって異なる可能性があることに注意してください。管理者は場所のプロファイルを構成し、特定の場所に固有の番号変換ルール (その場所での 4 桁のダイヤルの処理方法など) を割り当てることができます。各 UC ユーザーには、場所のプロファイルが割り当てられます。システム内のすべてのクライアントは、インバンド プロビジョニングを使用し、割り当てられた場所のプロファイルに固有のルールをダウンロードします。次は、着信ルーティングについて詳しく説明します。

着信ルーティング

着信ルーティングのルールでは、システム内に登録されたクライアントが応答可能である場合とそうでない場合に、どのように通話をユーザーにルーティングするかが指定されます。着信ルーティング コンポーネントでは、着信通話にもプレゼンスに基づくルールが適用されます。たとえば、ユーザーがプレゼンス状態を [応答不可] に設定している場合、着信通話はボイスメールに送信されます。着信ルーティングではプレゼンス コンテナのレベルが認識され、ブロックされたコンテナに属するユーザーからの通話が自動的に拒否されます。図 5 は、OCS 着信ルーティング コンポーネントによってサポートされる機能の概要を示しています。

図 5. 着信ルーティング機能

着信ルーティングのルールは、XML スキーマ形式で、ユーザーのセルフ プロビジョニング情報の一部としてサーバーにアップロードされます。図 6 は、着信ルーティングのしくみを示しています。OCS システム内のユーザーへの着信通話では、既定でユーザーが呼び出されます。既定では、着信転送までの時間が経過する前に、そのユーザーが通話に応答しなかった場合、不在時の着信がボイスメールに送信されます。ユーザーは、既定の構成を変更し、電話番号、別のユーザー、またはボイスメールに通話を直接転送することもできます。

図 6 通話のルーティング (稼働時間中) (画像をクリックすると拡大表示されます)

別のユーザーまたは番号に通話が直接転送された場合、そのユーザーまたは番号用の着信ルーティングのルールが適用されます。ユーザーは、別の番号またはユーザーに不在時の着信を転送するように設定することもできます。

ユーザーが転送ルールの [Apply only during my Outlook Working Hours] (Outlook で指定した稼働時間中にのみ適用する) チェック ボックスをオンにすると、図 6 のルールは稼働時間中に適用され、それ以外の時間に、登録済みのエンドポイントを呼び出す既定の動作が適用されます。この動作を提供するには、組織に Microsoft Exchange Server 2007 および Outlook 2007 クライアントが展開されている必要があることに注意してください。Communicator は、Exchange 2007 可用性 Web サービスから提供される稼働時間情報を使用します。また、Outlook 2007 の自動検出サポートを活用して、サーバーの場所を取得します。

品質報告とトラブルシューティング

OCS 2007 システムのクライアントでは、次世代のオーディオ コーデックである RTAudio が使用されます。このコーデックは、ジッターやパケット損失などの不完全なネットワーク状態に対処できます。ただし、管理者が潜在的なホットスポットを見つけて修正できるように、監視は必ず行う必要があります。OCS 2007 システムのクライアントは、各通話の終了時に、それぞれの通話品質と詳細な統計情報を、一元管理された Quality of Experience (QoE) サーバーに報告します。具体的には、帯域幅、損失、ジッター、平均オピニオン評点 (ユーザーの認識を調査するための評価尺度)、使用されたデバイスなどの情報を提供します。この報告は、ペイロードを SIP SERVICE 要求で QoE サーバーに送信することによって行われます。QoE サーバーのアドレスは、インバンド プロビジョニング メカニズムを使用して自動的に取得されます。

すべてのクライアント エンドポイントが、個別に通話品質を QoE サーバーに報告することに注意してください。シグナリングのエラーが原因で通話が失敗した場合、クライアントは同じ内容を OCS にも報告します。これにより、クライアントで作成されたすべてのエラーのリポジトリが提供されます。

すべての側面を一元管理する

ここまで、番号の入力、着信ルーティングと発信ルーティング、接続の確認など、通話の設定に関するいくつかの側面について説明しました。次は、この処理を全体的な視点から見ていきましょう。図 7 は、ユーザーが通話を開始した時点からの処理の流れを示しています。OCS システムのクライアントは、通話のセットアップにおいて重要な役割を果たし、このセットアップ処理全体を取り仕切っています。また、OCS は通話の最初のルーティングに関与し、エッジ サーバーは、クライアントがメディアの最適なルートを検出する処理を支援します。では、その次の処理、つまり会話について見ていきましょう。

図 7 エンド ツー エンドの通話の流れ (画像をクリックすると拡大表示されます)

マルチモーダルな動作と会話

会話は、OCS システムの最も重要な概念です。会話は 2 人以上のユーザー間で発生するマルチモーダルなセッションで、音声、ビデオ、IM に加え、セッション中のファイル転送、Outlook の電子メール、Microsoft Office OneNote® に保存されたノートなど、さまざまなアイテムを同時に使用できます。

次に示す会話のいくつかの側面は、OCS クライアント システムの設計に影響を与える可能性があります。

• 会話に関連するすべてのモダリティでは、同じウィンドウが使用されます。たとえば、音声会話に追加されたインスタント メッセージは、音声会話と同じウィンドウに関連付けられます。
• 会話はさまざまなデバイス間で発生します。ユーザーは、Communicator Phone Edition で音声を使用し、同時に Communicator デスクトップで IM を使用できます。
• すべてのモードが同時に会議に昇格します。昇格が発生した場合、現在デバイスでどのモダリティを使用しているかにかかわらず、会話のすべてのモダリティが同時に昇格します。たとえば、Communicator Phone Edition で音声モードが有効になっており、Communicator デスクトップで同じ会話の IM モードが有効になっている場合、会議への昇格が発生したときに、音声と IM の両方でその会話に必ず同じ参加者が含まれます。
• 会話 (個々のセッション単位ではありません) はログに記録されます。通話ログには、会話中に取ったメモの詳細、インスタント メッセージの交換、音声の継続時間など、会話に関する情報がすべて記録されます。これによってユーザーは、Outlook で通話ログを開いて、会話の内容全体をまとめて簡単に確認できます。
• 会話のログから会話を続行できます。OCS クライアントは、会話 ID (デバイスとアプリケーション間の会話を一意に識別する番号) を使用して会話どうしを関連付けます。新しい会話が古い会話の履歴ログから開始されると、複雑なメカニズムによって会話の差分が計算されます。また、同じ会話 ID が電子メールの ID として Outlook に保存されます。

会話 ID は、SIP INVITE に含まれるカスタム プロパティ Ms-Conversation-Id として送受信されます。図 8 は、最初に音声が追加され、次に IM が追加されるトランザクションを示しています。マルチモーダルな会話の最後に、同じ会話 ID を持つ履歴ログが Outlook に保存されることに注意してください。

図 8 マルチモーダルな会話と会話 ID (画像をクリックすると拡大表示されます)

Exchange UM は、OCS 2007 に対応したボイスメール システムです。OCS は、UC に対応したユーザーの通話のみを Exchange UM にルーティングします。OCS では、Exchange UM との連動に必要ないくつかの機能が提供されます。

• ユーザーは、Communicator の電話 UI で [ボイス メールの呼び出し] をクリックすると (図 9 参照)、PIN を入力する必要なく、UM メールボックスの管理、案内応答の変更などの操作を行うことができるようになります。その理由は、このユーザーが既に認証されているためです。
• ユーザーは、Communicator の UI に表示される、未開封のメッセージを示すインジケータ (図 10 参照) を使用して、Outlook でボイスメール フォルダを開くことができます。また一方で、Communicator Phone Edition のインジケータを使用して、直接電話から音声メッセージを再生することもできます。
• 通話を Communicator の UI からボイスメールに転送できます。
• 拒否された通話は、自動的にボイスメールにルーティングされます。
• Outlook でボイスメール アイテムの [電話で再生] を使用して、Office Communicator クライアントを直接呼び出すことができます。

図 9 Communicator の [ボイス メールの呼び出し]

図 10 未開封のメッセージを示す Communicator のインジケータ

OC がボイスメール通知を受信するメカニズムは、Communicator Phone Edition とは異なります。OC は、新しいメールが届いたことを示す通知を Outlook のボイスメール検索フォルダに登録し、このフォルダで新しいメッセージを報告します。また、Communicator では不在着信した会話と通話ログも使用されます。

まとめ

この記事では、いくつかの RFC を利用した SIP を基に構築されたシステムである OCS 2007 の音声通話のしくみについて説明しました。クライアント エンドポイントは、OCS での通話の管理において中心的な役割を果たします。すべての音声通話は、既定で安全に暗号化されます。また、OCS によって、番号の操作とシステム全体のフロー制御を可能にする柔軟なコンポーネントが提供されます。

会話は、音声、IM、およびビデオが関連する、OCS の中心的な概念です。OCS は Exchange UM と連動しているので、Communicator エンドポイントにボイスメールに関する通知を送信したり、Communicator エンドポイントで Outlook を使用してボイスメールにアクセスしたり、サーバーから直接ボイスメールにアクセスしたりできます。

Rajesh Ramanathan は通信業界に 14 年間携わっており、Office Communicator 2007 の音声プロトコル、ユーザー エクスペリエンス、音声、および会議を設計しました。現在はマイクロソフトで Office Communicator チームのリード プログラム マネージャを務めています。連絡先は rajeshra@microsoft.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved. 許可なしに一部または全体を複製することは禁止されています。