ステップ 5. 仲介サーバーの展開

トピックの最終更新日: 2009-05-06

仲介サーバーの展開前または展開後に、サードパーティの基本的なメディア ゲートウェイを展開できます。ただし、どちらの順序を選択した場合でも、論理ユニットとして機能するように、この 2 つのコンポーネントを構成する必要があります。仲介サーバーの構成方法の詳細については、「仲介サーバーの構成」を参照してください。

以下の一覧では、基本的なメディア ゲートウェイで構成する必要のある設定について説明します。個々のゲートウェイの設定方法の詳細については、製造元の製品ドキュメントを参照してください。エンタープライズ VoIP のゲートウェイの選択方法の詳細については、「計画とアーキテクチャ」の「エンタープライズ VoIP のサーバー側コンポーネント」を参照してください。

各ゲートウェイは、ベンダのドキュメントに従って構成する必要があります。ベンダによっては、多数の属性を設定する必要がある可能性がありますが、エンタープライズ VoIP 固有の属性は次のとおりです。

  • ゲートウェイに関連付けられている仲介サーバーの完全修飾ドメイン名 (FQDN) または IP アドレス。

  • 仲介サーバーへの伝送制御プロトコル (TCP) 接続またはトランスポート層セキュリティ (TLS) 接続に使用するリッスン ポート (5060)。

    Dd441327.important(ja-jp,office.13).gif重要:
    上記の設定は、仲介サーバーの対応する設定と一致する必要があります。設定が一致しない場合、ゲートウェイと仲介サーバー間の接続は失敗します。
  • セッション開始プロトコル (SIP) トランスポート。TLS (推奨) または TCP に設定する必要があります。

    Dd441327.important(ja-jp,office.13).gif重要:
    基本的なメディア ゲートウェイまたは基本的なハイブリッド メディア ゲートウェイで使用する SIP トランスポートとして TLS を指定した場合は、TLS に対応する仲介サーバーも構成する必要があります。TLS に対応する仲介サーバーを構成する方法の詳細については、「仲介サーバーの構成」を参照してください。
  • ゲートウェイと仲介サーバーの間のリンクに対する SIP トランスポートを TLS に設定した場合は、仲介サーバーとの相互 TLS (MTLS) ハンドシェイク時に認証を目的とする証明書を使用して、ゲートウェイを構成する必要があります。ゲートウェイの証明書は次のように構成する必要があります。

    • 証明書は、仲介サーバー上で構成された信頼された証明機関 (CA) で直接署名されることがあります。また、証明書チェーンをたどって、ゲートウェイによって提供されている証明書を検証しなければならないこともあります。ゲートウェイはこの証明書チェーンを、仲介サーバーとの TLS ハンドシェイク時に提供する必要があります。
    • サブジェクト フィールドの CN 部を、ゲートウェイの FQDN に設定する必要があります。サブジェクト フィールドの CN 部に設定されている FQDN がゲートウェイに対して構成されている予期された FQDN と一致しない場合、証明書内にサブジェクト代替名 (SAN) も指定する必要があります。サブジェクト代替名は、ゲートウェイに対して構成されている予期された FQDN を列挙したものです。
    • 仲介サーバーは、ゲートウェイから提供された証明書の妥当性を調べるため、証明書の FQDN が仲介サーバー上で構成されているゲートウェイ FQDN と一致するかどうかを検査します。FQDN が一致しない場合、セッションが終了します。さらに署名と有効期限を検査し、証明書が失効していないかどうかを確認します。
  • 受信する SIP 接続用に各ゲートウェイがリッスンしているポートを指定する必要があります。

    Dd441327.note(ja-jp,office.13).gif注:
    仲介サーバーが使用する既定の宛先ポートはポート 5060 です。
  • IP ゲートウェイと仲介サーバー間の SIP トランスポート リンクに対する TLS を構成する場合は、Secure RTP (SRTP) の暗号化の設定を次のいずれかに指定する必要があります。

    • 必須: SRTP を試行する必要があります。ただし、SRTP のネゴシエーションに失敗した場合は暗号化を使用しません。
    • オプション: SRTP の使用をネゴシエートして、メディア パケットをセキュリティで保護しようとします。SRTP をネゴシエートできない場合は、リアルタイム転送プロトコル (RTP) を使用します。
    • 不使用: RTP を使用してメディア パケットを送信します。
Dd441327.note(ja-jp,office.13).gif注:
SRTP に対するこれらのオプションはすべて仲介サーバーでサポートされています。さまざまな製造元があるため、ゲートウェイによっては一部のオプションがサポートされていないことがあります。
  • エンタープライズ VoIP によってゲートウェイにルーティングされた E.164 番号が、ローカルにダイヤリングできる形式に正規化されるように、各ゲートウェイを構成する必要があります。
  • E.164 番号だけを仲介サーバーに渡すように、各ゲートウェイを構成する必要があります。発信元の電話番号を E.164 に正規化する具体的な方法については、各ゲートウェイのベンダのドキュメントを参照してください。
  • 各ゲートウェイは、発信元番号 (発信者番号として示される番号) を正規化された E.164 番号に変換するように構成します。これにより、発信者番号を Communicator の連絡先、Outlook の連絡先、または企業名簿のメンバと確実に照合できるため、Communicator は発信者の追加情報を提供することができます。この番号は、ユーザーに不在着信やボイス メールを通知する電子メールにも含まれるため、ユーザーは電話番号をクリックして、すぐに折り返し電話をかけることができます。番号がゲートウェイによって正規化されている場合、これ以上の処理は不要です。なんらかの理由でゲートウェイが番号を正規化できない場合は、折り返し電話をかけるときに、場所のプロファイルで定義された正規化ルールが適用されます。場所のプロファイルに正規化ルールを追加して、ゲートウェイが正規化できない番号を処理することが必要になる場合があります。発信元の電話番号を E.164 に正規化する具体的な方法については、各ゲートウェイのベンダのドキュメントを参照してください。
  • 仲介サーバーで Request の URI (Uniform Resource Identifier)、To の URI、およびゲートウェイへの発信通話で使用する E.164 番号の From の URI から正符号 (+) プレフィックスを削除する場合は、RemovePlusFromRequestURI という Windows Management Instrumentation (WMI) の値を TRUE に設定します (既定値は FALSE です)。この設定の詳細については、「計画とアーキテクチャ」の「エンタープライズ VoIP のサーバー側コンポーネント」で「仲介サーバーの新規構成オプション」を参照してください。

メディア ゲートウェイ ベンダの一覧については、「Partners by Capability:Hardware (機能別パートナー: ハードウェア)」を参照してください。