Remote Call Control in Office Communications Server (OCS) 2007 R2

[アーティクル]
08/25/2016

Office Communications Server

リモート通話コントロールが OCS 2007 R2 にもたらす力

Rajesh Ramanathan

概要:

リモート通話コントロールで実行できる処理
RCC のしくみ
OCS での一般的な RCC 実装シナリオ

この記事は、Office Communications Server (OCS) 2007 でユニファイドコミュニケーション、ボイスオーバー IP (VoIP)、および会議の機能がどのように提供されるのかを紹介するシリーズの続編です。ここでは、Office Communications Server がどのようにレガシ PBX を使用してリモート通話コントロール (RCC) 機能を提供し、RCC を使用してさまざまな通話シナリオをサポートするのかについて説明します。また、デュアルフォーク構成の概要を紹介し、この構成でどのように RCC を使用すれば Office Communicator と PBX 電話のどちらでも通話できる柔軟なオプションをユーザーに提供できるかについても簡単に説明します。

私が以前に執筆した「プレゼンスが OCS 2007 にもたらす力」という記事では、OCS 2007 ソリューションの概要と、さまざまな通信手段がどのように統合されるかについて説明しました。また、プレゼンスがユニファイドコミュニケーションにおいてどのように重要な役割を果たしているのか、音声通話の効率的なルーティングを実現するのにプレゼンスがどのように使用されているのかについても説明しました。そして、「音声が OCS 2007 にもたらす力」では、OCS で VoIP 機能が提供されるしくみを紹介しました。また、ユーザー向けのさまざまな構成オプションについても簡単に説明し、特にエンタープライズボイス構成を重点的に取り上げました。

これ以外に、RCC 構成についても簡単に説明しました。RCC は Live Communication Server 2005 に組み込まれており、これを使用すると Office Communicator 2005 で PBX 電話からの通話を制御できます。OCS 2007 でも、この機能は、PBX が既に展開されている場合の代替の構成として提供されています。エンタープライズボイスで RCC を有効にするオプションもあります。このオプションを使用すると、ユーザーは、通話の管理に PBX 電話と Office Communicator の両方を使用できます。

RCC は、自分のコンピュータ以外のデバイスで通話できるようにする機能です。OCS の場合は、次のような操作を行えます。

PBX 電話に着信があると、Communicator に通知が表示されます。ユーザーはこの通知から呼び出しに応答できます。
Communicator で電話番号をクリックすると、PBX 電話はスピーカーフォンモードで受話器が外れた状態になり、PBX 電話ではクリックした電話番号がダイヤルされます。
PBX 電話で着信の転送を設定できます。
特定の電話番号への着信を他の電話番号に転送することができます。
PBX 電話で、通話に対して、通話コントロール (シングルステップ転送、保留転送など) を適用することができます。Communicator の UI を使用して、PBX 電話から DTMF 信号を送信することができます。

図 1 RCC 構成

RCC 構成とエンタープライズボイス構成の大きな違いの 1 つは、RCC 構成の Office Communicator クライアントでは PBX のシグナリングコントロールしか設定されていないということです (VoIP 通話が Office Communicator クライアントに配信されることはありません)。つまり、RCC 構成では Office Communicator は Softphone として使用されません。

非常に単純な構成では、PBX と OCS との間に SIP/CSTA ゲートウェイをセットアップすることで RCC を展開できます。SIP/CSTA ゲートウェイでは、OCS 側に対してはセッション開始プロトコル (SIP) インターフェイスを提供し、SIP メッセージにラップされた CSTA シグナリングメッセージを使用して Office Communicator クライアントと通信します。

PBX 側に対しては、PBX ベンダ固有の専用のシグナリングインターフェイスを使用します。図 1 に示すように、RCC の展開では、公衆交換電話網 (PSTN) の番号に電話をかけるために PBX が提供する PSTN 接続が利用されます。このような展開では、PBX に付属するボイスメールシステムも利用されます。

図 2 は、RCC システムにおける音声通話の位置付けを示す論理図です。ご覧のとおり、Office Communicator クライアントによってシグナリングセッションが作成されます。このセッションでは、通話を制御する CSTA プロトコルベースのメッセージが Office Communicator クライアントと SIP/CSTA ゲートウェイとの間でやり取りされます。実際の通話は PBX 電話とリモートエンドポイントとの間で行われます。リモートエンドポイントは、別の PBX 電話の場合もあれば PSTN エンドポイントの場合もあれば、エンタープライズボイス対応の別の OCS 電話ユーザーの場合もあります。

図 2 RCC 構成での通話

CSTA 標準

Office Communicator の RCC 実装は、欧州電子計算機工業会 (ECMA) の技術報告書 87 (TR-87) に基づいています。これは CSTA モデルの SIP 実装であり、この CSTA モデルも ECMA で提案されたものです。また、ECMA 323 というもう 1 つの標準では、CSTA 実装の SIP チャネルで送信される XML メッセージの詳細なスキーマが規定されています。Office Communicator では、TR-87 で規定されている機能や方法の一部が採用されています。Communicator での CSTA 標準のサポートに関する詳細なドキュメントは、Microsoft Connect プログラムで入手できます。この記事では、これ以降、CSTA という言葉は、Office Communicator クライアントと PBX との間で使用される汎用プロトコルを指します。

RCC チャネルをブートストラップする

「プレゼンスが OCS 2007 にもたらす力」という記事では、SIP Uniform Resource Identifier (URI) が OCS システムにおいてどれほど重要な部分を占めるかについて説明しました。また、ユーザーに通話をルーティングできるようにする SIP URI が各ユーザーにどのように割り当てられるかについても説明しました。Office Communicator クライアントから SIP/CSTA ゲートウェイへの通信を行う際、Office Communicator クライアントでは、Office Communicator で制御する必要がある電話を特定する必要があります。この電話番号は回線 URI として識別されます。これは、基本的には RFC 3966 形式の電話番号です。この回線 URI プロパティは Active Directory のユーザーレコードに格納され、Office Communicator ではインバンドプロビジョニングの一環としてこのプロパティを使用できるようになります。

Office Communicator クライアントは、起動中に、永続的な INVITE チャネルをセットアップするために SIP/CSTA ゲートウェイ (OCS のユーザー構成のサーバー URI で定義されているとおりにアドレス指定されます) に接続する必要もあります。Communicator では、インバンドプロビジョニングメカニズムを使用して RCC 機能とサーバー URI を認識します (インバンドプロビジョニングメカニズムについては、「プレゼンスが OCS 2007 にもたらす力」という記事でも説明しました)。

RCC システムでは、コマンド/応答モデルが採用されています。Office Communicator から SIP/CSTA ゲートウェイに送信される各メッセージには、XML (ECMA 323) ペイロードとしてエンコードされたコマンドが含まれています。SIP/CSTA ゲートウェイからの応答や通知にも、それぞれ XML (ECMA 323) ペイロードが含まれています。最初の SIP INVITE 要求では、セッションが作成されます。また、この要求には RequestSystemStatus という CSTA メッセージが含まれます。SIP/CSTA ゲートウェイは要求を受け取り、RequestSystemStatusResponse という CSTA メッセージが含まれる 200 OK 応答を返します (図 3 参照)。

図 3 SIP/CSTA ゲートウェイに対する INVITE 要求のモデル

INVITE に対応する BYE がないことに注目してください。これは、INVITE が永続的なセッションとしてセットアップされており、このセッションで Office Communicator から後続のコマンドを送信したり、SIP/CSTA ゲートウェイから通知を受け取ったりできるようになっているからです。

INVITE 要求と 200 OK 応答のシーケンスが完了すると、Office Communicator では、SIP/CSTA ゲートウェイの機能 (PBX の機能に関係しています) を照会し、サポートされている機能を特定します。続いて、電話回線の監視を開始します。

SIP/CSTA ゲートウェイでサポートされている機能によっては、Office Communicator のさまざまな UI 要素が無効になったり、まったく表示されなくなったりする可能性があるため、PBX の機能の照会は、ブートストラップでは重要なステップです。たとえば、SIP/CSTA ゲートウェイでシングルステップ転送機能がサポートされていない場合、Office Communicator の通話コントロールに通話の転送ボタンは表示されません。

そのため、RCC 構成では、Office Communicator クライアントで使用する 2 つのパラメータが必要となります。1 つ目はサーバー URI です。これは、SIP/CSTA ゲートウェイのアドレスが含まれる SIP URI で、Office Communicator クライアントはこの URI に対して SIP INVITE を発行することによりサーバーに接続できます (通常、この URI は gateway@contoso.com という形式です)。

2 つ目は回線 URI です。これは、PBX システムの電話番号を一意に識別する電話 URI です。この URI では RFC 3966 準拠の形式が採用されています (たとえば、TEL:+14255551212 や TEL:4255551212;ext=1212 のような形式です)。

最初のブートストラップが完了すると、監視されている電話回線 (電話番号で指定されます) で状態が変化するたびに、Office Communicator では PBX からイベントを受け取ります。Office Communicator では、通話を開始したり、通話に応答したりする必要があるときは、CSTA ベースの XML メッセージが含まれる INFO メッセージを SIP/CSTA ゲートウェイに送信します。SIP/CSTA ゲートウェイから受け取るイベントにも、SIP INFO メッセージに埋め込まれた形で CSTA ベースの XML メッセージが含まれています (例については図 4 参照)。

図 4 INFO メッセージと 200 OK 応答

INFO sip:gateway@contoso.com SIP/2.0
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
Content-Disposition: signal;handling=required
Content-Type: application/csta+xml
Content-Length: 277
<?xml version="1.0"?>
<MakeCall xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>tel:+14255551212;ext=1212</callingDevice>
  <calledDirectoryNumber>tel:+14258828080;ext=5555</calledDirectoryNumber>
  <autoOriginate>doNotPrompt</autoOriginate>
</MakeCall>

SIP/2.0 200 OK
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
Content-Disposition: signal;handling=required
Supported: 100rel,replaces,timer
User-Agent: Example Gateway Release 1.0 version 4.2.3
Contact: <sip:gateway@ocs.contoso.com>
Content-Type: application/csta+xml
Content-Length: 247
<?xml version="1.0" encoding="UTF-8"?>
<MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>
    <callID>17772</callID>
    <deviceID> tel:+14255551212;ext=1212</deviceID>
  </callingDevice>
</MakeCallResponse>

このシナリオでは、OCS は SIP プロキシの役割を果たしています。Office Communicator クライアントと SIP/CSTA ゲートウェイとの間でやりとりされるシグナリングメッセージはすべて、OCS サーバーを自動的に経由します。SIP/CSTA ゲートウェイが機能していることと、シグナリングリンクが使用できることを確認するために、Office Communicator では、10 分おきに RequestSystemStatus という CSTA メッセージを含む INVITE 要求を再送信して INVITE セッションを更新します。

基本的な MakeCall フロー

電話をかける際には、図 5 に示すような一連の処理が実行されます。ユーザーは、Office Communicator の検索ボックスに電話番号を入力するか、呼び出し一覧から連絡先の電話番号を選択することによって、電話をかけることができます。ユーザーが電話をかけるために番号を選択すると、Office Communicator では、通話先の電話番号が含まれる MakeCall コマンドを SIP/CSTA ゲートウェイに対して発行します。RCC インターフェイスで、ユーザーが行える操作は、選択した電話番号に電話をかけることだけです。ユーザーが [Communicator での通話] オプションを選択して電話をかけると、Office Communicator によって、リモートユーザーの SIP URI への VoIP 通話が開始されます。

図 5 電話をかけたときの状態

図 5 のメッセージシーケンスは、SIP/CSTA ゲートウェイがどのようにして MakeCall コマンドを PBX 固有のメッセージに変換するかを示しています。PBX 電話は受話器を外した状態になり、指定の電話番号に PBX 電話から電話をかけられます。

SIP/CSTA ゲートウェイへのインターフェイスでは、電話のさまざまな状態を示す複雑なメカニズムが提供されていることに注目してください。この例では、Office Communicator が PBX 電話で行われている操作を示す複数のイベントを受け取っていることがわかります。最初に受け取っているイベントは (PBX 電話が発信を開始していることを示す) OriginatedEvent で、最後に受け取っているイベントは (呼び出し中の状態を示す) DeliveredEvent です。DeliveredEvent イベントを受け取るときには、呼び出し音を再生するためのメディアパスが電話とリモートユーザーとの間で既に確立されている可能性があります。

呼び出しへの応答があると、PBX では SIP/CSTA ゲートウェイに適切な信号を送信し、呼び出しへの応答が行われたことを示す EstablishedEvent イベントが Office Communicator に送信されます (図 6 参照)。

図 6 呼び出しへの応答が行われたときの状態

呼び出しへの応答の基本的なフロー

PBX システムに着信があると、PBX では SIP/CSTA ゲートウェイに通知を送信します。すると、SIP/CSTA ゲートウェイによって、Office Communicator に送信される DeliveredEvent という CSTA 通知が生成されます (図 7 参照)。Office Communicator で DeliveredEvent イベントを受け取ると、ユーザー側では着信通知が表示されます。

図 7 呼び出しに応答するときの状態

Office Communicator では、発信者の表示名を表示するために、アドレス帳サービスおよびユーザーの Microsoft Office Outlook 連絡先に対して名前の後方参照 (RNL) も実行します。これで、ユーザーは、通知から呼び出しに応答できるようになりました。応答すると、AnswerCall という CSTA コマンドが SIP/CSTA ゲートウェイに対して発行されます。この時点で、SIP/CSTA ゲートウェイによって AnswerCall コマンドが PBX 固有の応答メッセージに変換され、発信者と PBX 電話との間で双方向のメディアチャネルがセットアップされます。

RCC とプレゼンスの統合

RCC の統合により、ユーザーの電話の状態はプレゼンスと統合されるようになりました。たとえば、ユーザーが PBX で通話中のときは、Office Communicator によってそのユーザーの状態が "通話中" に変更されます。この状態は、他のユーザーの Office Communicator クライアントにも反映されます。また、ユーザーは、プレゼンスを通じて自分の電話番号を公開し、他のユーザーが Office Communicator を使用して、自宅や携帯電話の番号に電話をかけられるようにすることができます。

ただし、Office Communicator 2007 のプレゼンスが "応答不可" に設定されていても、PBX システムの "応答不可" 機能は連動しないことに注意してください。ユーザーは、PBX システムの "応答不可" 状態を手動で管理する必要があります。

RCC と会議

ユーザーは、Office Communicator 2007 を使用した RCC 通話中に、Office Communicator を使用してその通話に別のユーザーを追加することはできません。しかし、ユーザーは、PBX 電話の会議機能を使用して、PBX 電話で会議を作成することはできます。このようにして会議が作成されても、Office Communicator では、その通話は、電話会議としてではなく、引き続きピアツーピア通話として表示されます。

通話の参加者を 3 名に増やすシナリオと同様に、PBX 電話への電話会議の着信は、Office Communicator ではピアツーピア通話として表示され、Office Communicator ではピアツーピア通話として応答することができます。

PBX を使用したエンタープライズボイスでの RCC

RCC は、PBX 統合を使用したエンタープライズボイスのシナリオ (通称、デュアルフォーク) で使用することができます。このシナリオでは、ユーザーが呼び出しへの応答に PBX 電話と Office Communicator Softphone のどちらも使用できるように、PBX システムと OCS システム間の発信を分岐しています。このオプションを使用すると、ユーザーはエンタープライズボイスのメリットをすべて利用できます。

PBX 統合を使用したエンタープライズボイスのシナリオに RCC を加えると、他の方法では実現できないことが可能になります。ユーザーは、電話または Office Communicator への着信に、Office Communicator の着信通知から応答できるようになります (図 8 参照)。

図 8 着信に応答するエンドポイントの選択

さらに、ノートブックコンピュータを使用しているユーザーは、社外で電話をかける Softphone として Office Communicator を使用することができます。また、ユーザーは、Office Communications Server の A/V Multipoint Control Unit (MCU) で提供される会議機能を利用して、Office Communicator から電話会議を作成することもできます。

RCC の制約

RCC を使用すると、既に展開されている PBX との統合を簡単に行えます。ただし、有線の PBX 電話で実行できる処理は限られているため、RCC 対応のユーザーが実行できる処理も限られます。たとえば、エンタープライズボイスユーザーは、OCS で提供される組織外での音声機能のネイティブサポートを利用して、組織の内外から VoIP 通話を発信したり、着信したりすることができます。

また、エンタープライズボイスシナリオでは、OCS で提供されるいくつかのプレゼンス機能が有効になります (たとえば、プレゼンスアクセスレベルを "チーム" にすることができます。チームアクセスレベルを付与されたユーザーは、応答不可状態の相手に対して緊急の割り込みが可能になります)。RCC 専用のユーザーは、こうした機能にアクセスできません。他にも、2 名での会議を大勢での会議へと拡大するなど、エンタープライズボイスユーザーしか実行できない機能があります。

RCC システムでは、PBX によって通話処理ルールが制御されます。そのため、着信を自動的に転送したり、共有の回線に送信したりする設定やルールはすべて、PBX で制御されます。RCC 専用ユーザーは、OCS 2007 R2 で導入された同時呼び出しや委任など、エンタープライズボイスユーザーが使用できる新機能を使用できません。

RCC 構成は、1 つの場所で展開された PBX のみをサポート対象とするように設計されています。複数の場所で展開された場合に固有のダイヤルルールが RCC トポロジでサポートされていないのは、このためです。一方、エンタープライズボイス構成では、複数の場所を指定することが可能で、ユーザーには、各自の場所に固有の電話番号正規化ルールが与えられます。

とはいえ、特定のシナリオにおいては、RCC は OCS でテレフォニー機能を提供するための便利な方法を提供します。RCC で提供される機能は、エンタープライズボイスと比べると限られていますが、エンタープライズボイス構成 (デュアルフォーク) で RCC を使用すると、ユーザーは豊富な OCS 機能を使用することができ、卓上電話と Office Communicator のどちらでも通話できる柔軟性を手に入れることができます。

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

目次

図 4 INFO メッセージと 200 OK 応答

その他のリソース