コール ポリシー設定 ページ (設定 > コール ポリシー > 設定) は、Expressway の コール ポリシー モードを設定し、ローカル ポリシー ファイルをアップロードするために使用されます。

通話ポリシールールページ ([設定（Configuration）] > [通話ポリシー（Call Policy）] > [ルール（Rules）]) には、現在設定されているウェブで設定された (CPL ファイル経由でアップロードされたものではない) 通話ポリシー ルールが一覧表示され、ルールの作成、編集、および削除を行うことができます。 これは、CPL スクリプトを記述してアップロードすることなく、基本的な通話ポリシールールを設定するメカニズムを提供します。

CPL ファイルがすでに存在する場合は、 [通話ポリシー ルール] ページを使用して通話ポリシーを構成することはできません。 この場合は、 [通話ポリシーの構成] ページ ([構成] > [通話ポリシー] > [構成]) で、 [アップロードしたファイルを削除] オプションが表示されます。 これを行うと、CPL スクリプトを使用して設定された既存の通話ポリシーが削除され、通話ポリシー設定用の [通話ポリシー ルール] ページが使用できるようになります。

各ルールは、特定の ソース から特定の 宛先 エイリアスへの呼び出しに対して実行する アクション を指定します。 ルールが複数ある場合は、これらのルールが適用される優先順位を 並べ替え ることができます。

通話ポリシー ルールを設定していない場合、デフォルトのポリシーでは、発信元または宛先に関係なく、すべての通話が許可されます。

設定するルールをクリックします (または、 [新規] をクリックして新しいルールを作成するか、 [削除] をクリックして選択したルールを削除します)。

各ルールの設定可能なオプションは次のとおりです。

CPL スクリプトを使用して、高度な通話ポリシーを設定できます。 これを行うには、まず CPL スクリプトをテキスト ファイルとして作成して保存し、その後 Expressway にアップロードする必要があります。 ただし、CPL スクリプトの作成は複雑であるため、代わりに外部の ポリシー サービス を使用することをお勧めします。

Expressway でサポートされている CPL 構文とコマンドの詳細については、 「CPL リファレンス」 セクションを参照してください。

DNS を使用しない場合、URI ダイヤリングを使用してローカルに登録されたエンドポイントから行われた呼び出しは、宛先エンドポイントもローカルに登録されているか、近隣システム経由でアクセスできる場合にのみ行われます。 これは、これらのエンドポイントが DNS クエリではなく、 検索およびゾーン変換プロセスを使用して特定されるためです。

DNS を使用せずにネットワークから URI ダイヤリングを使用する場合は、ネットワーク内のすべてのシステムが直接的または間接的に近隣関係によって相互に接続されていることを確認する必要があります。 これにより、エンドポイントの URI を検索することで、どのシステムでも自分自身または別のシステムに登録されているエンドポイントを見つけることができるようになります。

これは、システムの数が増えても適切に拡張できません。 また、これは特に実用的ではありません。2 つのシステム間にネイバー関係がまだ確立されていない場合、ネットワーク内のエンドポイントはネットワーク外のシステムに登録されているエンドポイントにダイヤルできない (たとえば、別の会社に電話をかける場合) ことを意味します。

ローカル Expressway に DNS ゾーンと DNS サーバが設定されていない場合、ローカル Expressway が、DNS 経由の URI ダイヤリングが設定されている別の Expressway と (直接的または間接的に) 隣接していれば、ローカルに登録されていないエンドポイントや隣接システムへの通話が発信される可能性があります。 この場合、そのネイバー ゾーンを参照する検索ルールによって取得された URI ダイヤル通話はすべてそのネイバーを経由し、DNS ルックアップが実行されます。

この設定は、すべての URI ダイヤリングを Expressway-E などの特定のシステム経由で行う場合に便利です。

ネットワーク内で URI ダイヤリングの一部として DNS を使用しない場合は、特別な構成は必要ありません。 エンドポイントは URI の形式でエイリアスに登録され、その URI に通話が行われると、Expressway はその URI のローカル ゾーンとネイバーを照会します。

Expressway に DNS が設定されておらず、ネットワークに H.323 エンドポイントが含まれている場合、URI ダイヤリングを使用してこれらのエンドポイントに到達できるようにするには、次の手順を実行します。

• H.323 登録で使用される形式に URI を変換するために、適切なトランスフォームを記述する必要があります。 例としては、H.323 エンドポイントが alias を使用して登録され、着信コールが alias@domain.com にかけられる導入が挙げられます。 次に、ローカル変換が @domain を削除するように構成され、 alias の検索がローカルで実行されます。 これを実行する方法の例については、「 H.323 番号へのダイヤル時に @domain を削除する 」を参照してください。

SIP エンドポイントは常に URI 形式で AOR に登録されるため、特別な構成は必要ありません。

URI ダイヤリングの一部として DNS を使用すると、エンドポイントが不明なシステムに登録されている場合でも、エンドポイントを見つけることができます。 Expressway は DNS ルックアップを使用して URI アドレス内のドメインを見つけ、そのドメインに対してエイリアスを照会します。 詳細については、 DNS を使用した URI 解決プロセス セクションを参照してください。

DNS 経由の URI ダイヤリングは、発信コールと着信コールに対して個別に有効になります。

発信コール

Expressway が DNS 経由の URI ダイヤルを使用してエンドポイントを見つけられるようにするには、次の操作を行う必要があります。

• 少なくとも 1 つの DNS ゾーンと関連する検索ルールを構成します。

• 少なくとも 1 つの DNS サーバを構成します。

これについては、 発信通話のための DNS 経由の URI ダイヤリング セクションで説明されています。

着信コール

Expressway に登録されたエンドポイントが DNS 経由の URI ダイヤリングを使用してローカルに登録されていないエンドポイントからの通話を受信できるようにするには、次の操作を行う必要があります。

• すべてのエンドポイントが URI 形式の AOR（SIP）または H.323 ID に登録されていることを確認する

• 使用するプロトコルとトランスポートの種類に応じて適切な DNS レコードを設定します。

これについては、 着信コール用の DNS 経由の URI ダイヤリング セクションで説明されています。

ファイアウォール トラバーサル コール

ファイアウォール経由で URI ダイヤリングを使用して通話を発信および受信できるようにシステムを構成するには、「 URI ダイヤリングとファイアウォール トラバーサル 」セクションを参照してください。

Expressway が DNS システムを使用して宛先 URI アドレスを見つけようとする場合の一般的なプロセスは次のようになります。

H.323

1. Expressway は、URI 内のドメインの SRV レコードを求めるクエリを DNS サーバに送信します。 (Expressway に複数の DNS サーバが設定されている場合、クエリはすべてのサーバに同時に送信され、すべての応答は Expressway によって優先順位付けされ、最も関連性の高い SRV レコードのみが使用されます。) 利用可能な場合、この SRV レコードは、デバイス自体またはそのドメインの権限のある H.323 ゲートキーパーに関する情報 (FQDN やリスニング ポートなど) を返します。

   • URI アドレスのドメイン部分が H.323 ロケーション SRV レコード (つまり、_h323ls) を使用して正常に解決された場合、Expressway は返された名前レコードごとに A/AAAA レコード クエリを送信します。 これらは 1 つ以上の IP アドレスに解決され、Expressway は優先順位に従って、完全な URI の LRQ をそれらの IP アドレスに送信します。

   • URI アドレスのドメイン部分が H.323 コール シグナリング SRV レコードを使用して解決された場合 (つまり、_h323cs の場合)、Expressway は返された名前レコードごとに A/AAAA レコード クエリを送信します。 これらは 1 つ以上の IP アドレスに解決され、Expressway はそれらのレコードで返された IP アドレスに優先順位に従って通話をルーティングします。 （例外として、元のダイヤル文字列にポートが指定されている場合、たとえば user@example.com:1719 のように、返されるアドレスは完全な URI アドレスの LRQ を介して照会されます。）

2. 関連する SRV レコードが見つからない場合:

   • 照会対象の DNS ゾーンの アドレス レコードを含める 設定が オン に設定されている場合、システムは URI 内のドメインの A レコードまたは AAAA レコードの検索にフォールバックします。 そのようなレコードが見つかった場合、通話はその IP アドレスにルーティングされ、検索は終了します。

     （注）	このドメインで見つかった A レコードと AAAA レコードが SIP または H.323 をサポートするシステム以外のシステムのものである場合、Expressway は引き続きこのゾーンに通話を転送するため、通話は失敗します。 このため、デフォルト設定のオフを使用することをお勧めします。

   • 照会する DNS ゾーンの [アドレス レコードを含める] 設定が [オフ] に設定されている場合、Expressway は A レコードと AAAA レコードを照会せず、代わりに検索を続行して残りの優先順位の低いゾーンを照会します。

SIP

Expressway は、 RFC 3263 に概説されている SIP 解決プロセスをサポートしています。 Expressway がこのプロセスを実装する方法の例は次のとおりです。

1. Expressway は、URI 内のドメインに対して NAPTR クエリを送信します。 利用可能な場合、このクエリの結果セットには、そのドメインへの接続に使用する必要がある SRV レコードとトランスポート プロトコルの優先順位リストが示されます。 このドメイン名の NAPTR レコードが DNS に存在しない場合、Expressway は、NAPTR クエリから返されたかのように、そのドメインのデフォルトのリスト _sips._tcp.<domain>、_sip._tcp.<domain> 、および _sip._udp.<domain> を使用します。

   • Expressway は、NAPTR レコード検索から返された結果ごとに SRV クエリを送信します。 返される A/AAAA レコードの優先順位リストが作成されます。

   • Expressway は、SRV レコード検索によって返された名前レコードごとに A/AAAA レコード クエリを送信します。

   上記の手順を実行すると、ターゲット ドメインへの接続に使用される IP アドレス、ポート、トランスポート プロトコルのツリーが作成されます。 ツリーは、NAPTR レコードの優先度によってさらに分割され、次に SRV レコードの優先度によってさらに分割されます。 場所のツリーを使用すると、検索プロセスは最初の場所で停止し、ターゲットの宛先に連絡が取れたことを示す応答を返します。

2. 検索プロセスで関連する SRV レコードが返されない場合

   • 照会対象の DNS ゾーンの アドレス レコードを含める 設定が オン に設定されている場合、システムは URI 内のドメインの A レコードまたは AAAA レコードの検索にフォールバックします。 そのようなレコードが見つかった場合、通話はその IP アドレスにルーティングされ、検索は終了します。

     （注）	このドメインで見つかった A レコードと AAAA レコードが SIP または H.323 をサポートするシステム以外のシステムのものである場合、Expressway は引き続きこのゾーンに通話を転送するため、通話は失敗します。 このため、デフォルト設定の オフを使用することをお勧めします。

   • 照会する DNS ゾーンのアドレスレコードを含める（Include address record）の設定がオフに設定されている場合、Expressway は A レコードと AAAA レコードを照会せず、代わりに検索を続行して残りの低優先度ゾーンを照会します。

ユーザが URI ダイヤリングを使用して電話をかける場合、通常はエンドポイントから name@example.com の形式でアドレスをダイヤルします。 以下は、Expressway に登録されているエンドポイントから URI アドレスがダイヤルされたとき、または近隣システムからクエリとして受信されたときに実行されるプロセスです。

1. Expressway は、 検索ルール をチェックして、次のいずれかの モード で設定されているものがあるかどうかを確認します。

   • 任意のエイリアス、または

   • URI アドレスに一致するパターンによるエイリアス パターン マッチ

2. ルールの優先順位に従って、関連付けられたターゲット ゾーンに対して URI のクエリが実行されます。

   • ターゲット ゾーンの 1 つが DNS ゾーンの場合、Expressway は DNS ルックアップを通じてエンドポイントを見つけようとします。 これは、 DNS 経由の URI 解決プロセスに従って、Expressway に設定されている DNS サーバにドメインの場所を照会することによって行われます。 URI アドレスのドメイン部分が正常に解決されると、要求はそれらのアドレスに転送されます。

   • ターゲット ゾーンの 1 つがネイバー ゾーン、トラバーサル クライアント ゾーン、またはトラバーサル サーバ ゾーンである場合、それらのゾーンに対して URI が照会されます。 そのシステムが DNS 経由の URI ダイヤリングをサポートしている場合は、通話自体をルーティングすることがあります。

DNS レコードの種類

Expressway が DNS 経由の URI ダイヤリングを使用して行われた着信コール (および登録などのその他のメッセージ) を受信できるかどうかは、Expressway がホストしている各ドメインの DNS レコードの存在に依存します。

これらのレコードには、次のようなさまざまな種類があります。

• A レコードは Expressway の IPv4 アドレスを提供します

• AAAA レコードは Expressway の IPv6 アドレスを提供します

• サービス (SRV) レコードは、特定のプロトコルとトランスポートタイプを照会するための Expressway の FQDN とポートを指定します。

• NAPTR レコードは、SIP ドメインの SRV レコードとトランスポート設定を指定します。

Expressway で有効になっているホストドメインとプロトコルおよびトランスポート タイプの組み合わせごとに、SRV または NAPTR レコードを提供する必要があります。

着信通話プロセス

DNS 経由の URI ダイヤリングを使用して着信通話が行われると、通話システムは、上記の DNS レコード検索のいずれかを使用して Expressway を見つけます。 Expressway は、ダイヤルされた URI を含む要求を user@example.com の形式で受信します。 これはデフォルトゾーンから来ているものとして表示されます。 その後、Expressway は通常の 通話ルーティングプロセスに従って URI を検索し、事前検索変換、通話ポリシー、および FindMe ポリシーを適用してから、検索ルールの優先度順にローカルゾーンとその他の設定済みゾーンを検索します。

SRV レコード形式

SRV レコードの形式は、 RFC 2782 で次のように定義されています。

_Service._Proto.Name TTL クラス SRV 優先度 重み ポート ターゲット

Expressway の場合、次のようになります。

• _Service と _Proto は H.323 と SIP で異なり、使用されているプロトコルとトランスポート タイプによって異なります。

• 名前 は、Expressway がホストしている URI 内のドメインです (例: example.com )。

• ポート は、特定のサービスとプロトコルの組み合わせをリッスンするように設定されている Expressway 上の IP ポートです。

• ターゲット は、Expressway の FQDN です。

DNS 経由の URI ダイヤリングをファイアウォール トラバーサルと組み合わせて使用する場合、DNS ゾーンは Expressway-E とパブリックネットワーク上の任意の Expressway でのみ設定する必要があります。 ファイアウォールの背後にある Expressway には DNS ゾーンを設定しないでください。 これにより、Expressway に登録されたエンドポイントから発信されるすべての URI 呼び出しが Expressway-E 経由でルーティングされるようになります。

さらに、着信コールの DNS レコードには、企業の権限のあるプロキシとして Expressway-E のアドレスを設定する必要があります (詳細については、「DNS 設定の例」セクションを参照してください)。 これにより、URI ダイヤリングを使用して発信された着信コールが Expressway-E を介して企業に入ることが保証され、ファイアウォールを正常に通過できるようになります。

Expressway が ENUM を使用して宛先エンドポイントを見つけようとする場合の一般的なプロセスは次のようになります。

1. ユーザはエンドポイントから E.164 番号をダイヤルします。

2. Expressway は、次のように E.164 番号を ENUM ドメインに変換します。

   1. 数字は反転され、ドットで区切られます。

   2. その E.164 番号の NAPTR レコードをホストしているドメインの名前がサフィックスとして追加されます。

3. 次に、結果として得られた ENUM ドメインについて DNS が照会されます。

4. その ENUM ドメインに NAPTR レコードが存在する場合、その番号を 1 つ (または複数) の H.323/SIP URI に変換する方法が示されます。

5. Expressway は再度検索を開始します。今回は、URI ダイヤル プロセスに従って、変換された URI を検索します。

   （注）	これは完全に新しい検索とみなされるため、検索前の変換と呼び出しポリシーが適用されます。

ENUM ダイヤルは、着信通話と発信通話で個別に有効になります。

発信コール

ENUM を使用してエンドポイントへの発信通話を許可するには、次の操作を行う必要があります。

• 少なくとも 1 つの ENUM ゾーンを設定し、

• 少なくとも 1 つの DNS サーバを構成する

これについては、「 発信通話の ENUM ダイヤリング 」セクションで説明します。

着信コール

企業内のエンドポイントが ENUM ダイヤリングを介して他のエンドポイントからの着信コールを受信できるようにするには、エンドポイントの E.164 番号を SIP/H.323 URI にマッピングする DNS NAPTR レコードを構成する必要があります。 これを行う方法については、「 着信コールの ENUM ダイヤリング 」セクションを参照してください。

（注）	ローカル Expressway に ENUM ゾーンと DNS サーバが設定されていない場合でも、ローカル Expressway が、ENUM ダイヤリング用に適切に設定されている別の Expressway に隣接していれば、ENUM ダイヤリングを使用した通話は発信できます。 ENUM ダイヤルされた通話はすべてネイバー経由で行われます。 この構成は、企業からのすべての ENUM ダイヤルを 1 つの特定のシステムで構成する場合に便利です。

ローカル エンドポイントが Expressway 経由で ENUM を使用して別のエンドポイントにダイヤルできるようにするには、次の条件を満たす必要があります。

• 呼び出されたエンドポイントの E.164 番号をその URI にマッピングする NAPTR レコードが DNS 内に存在している必要があります。 このレコードを提供する責任は、呼び出されたエンドポイントが属する企業の管理者にあります。管理者は、企業内のエンドポイントを ENUM ダイヤリング経由で接続できるようにする場合にのみ、このレコードを利用できるようにします。

• ローカル Expressway で ENUM ゾーンを構成する 必要があります。 この ENUM ゾーンには、呼び出されたエンドポイントの NAPTR レコードが保持されているドメインと同じ DNS サフィックスが必要です。

• NAPTR レコード (および必要に応じて結果の URI) を照会できる少なくとも 1 つの DNS サーバ のアドレスを使用して、ローカル Expressway を設定する必要があります。

ENUM プロセスが 1 つ以上の URI を返すと、 URI ダイヤリング プロセス に従って、これらの URI ごとに新しい検索が開始されます。 URI がローカルに登録されたエンドポイントに属している場合は、それ以上の構成は必要ありません。 ただし、1 つ以上の URI がローカルに登録されていない場合は、DNS ルックアップを使用してそれらの URI を検索するときに、DNS ゾーンも構成する必要があります。

呼び出しプロセス

Expressway は、ENUM (E.164) 番号を検索するときに次のプロセスに従います。

1. Expressway は、ダイヤルされたときに受信した E.164 番号の検索を開始します。 これは通常の コール ルーティング プロセスに従います。

2. 検索前変換を適用した後、Expressway は 検索ルール をチェックし、次のいずれかの モード で設定されているものがあるかどうかを確認します。

   • 任意のエイリアス、または

   • エイリアス パターン マッチ と E.164 番号に一致するパターン

3. 一致する検索ルールに関連付けられたターゲット ゾーンは、ルールの優先順位に従って照会されます。

   • ターゲット ゾーンが隣接ゾーンである場合、隣接ゾーンに対して E.164 番号が照会されます。 ネイバーが ENUM ダイヤリングをサポートしている場合は、ネイバー自身が通話をルーティングすることがあります。

   • ターゲット ゾーンが ENUM ゾーンの場合、Expressway は ENUM を通じてエンドポイントを見つけようとします。 Expressway 上で設定されている各 ENUM ゾーンが照会されると、E.164 番号は次のように ENUM ドメインに変換されます。

     1. 数字は反転され、ドットで区切られます。

     2. その ENUM ゾーンに設定された DNS サフィックス が追加されます。

4. 次に、結果として得られた ENUM ドメインについて DNS が照会されます。

5. DNS サーバは、その ENUM ドメインで、変換された E.164 番号 (つまり、逆にされてドットで区切られた番号) と一致する NAPTR レコードを見つけた場合、関連付けられた URI を Expressway に返します。

6. その後、Expressway はその URI の新しい検索を開始します (既存のホップ カウントは維持されます)。 Expressway は、検索プロセスの開始から始まります (検索前の変換を適用し、優先順位に従ってローカルゾーンと外部ゾーンを検索します)。この時点では SIP/H.323 URI を検索しているため、URI ダイヤル のプロセスが実行されます。

この例では、Example Corp. の Fred に電話をかけます。Fred のエンドポイントは実際には URI fred@example.com で登録されていますが、Fred に簡単に連絡できるように、システム管理者がこのエイリアスを Fred の E.164 番号 +44123456789 にマッピングする DNS NAPTR レコードを設定しています。

example.com の NAPTR レコードは、 e164.arpa の DNS ドメインを使用していることがわかります 。

1. ローカル Expressway に、 DNS サフィックス e164.arpa を使用して ENUM ゾーンを作成します。

2. パターン マッチ モード を 任意のエイリアスに設定して検索ルールを設定し、 ターゲット を ENUM ゾーンに設定します。 つまり、検索対象のエイリアスの形式に関係なく、ENUM は常に照会されます。

3. エンドポイントから 44123456789 をダイヤルします。

4. Expressway は、44123456789 の登録の検索を開始し、任意のエイリアスの検索ルールでは、ENUM ゾーンが照会されます。

   （注）	他のより優先度の高い検索では、最初に番号が一致する可能性があります。

5. クエリ対象のゾーンは ENUM ゾーンであるため、Expressway は次のように番号を ENUM ドメインに変換するように自動的にトリガーされます。

   1. 数字は逆順に並べられ、ドットで区切られます: 9.8.7.6.5.4.3.2.1.4.4

   2. この ENUM ゾーン用に設定された DNS サフィックス 、 e164.arpa が追加されます。 この結果、 9.8.7.6.5.4.3.2.1.4.4.e164.arpa の変換されたドメインが生成されます。

6. 次に、その ENUM ドメインについて DNS が照会されます。

7. DNS サーバはドメインを見つけ、関連付けられた NAPTR レコードの情報を返します。 これにより、ダイヤルした E.164 番号が fred@example.com の SIP URI にマッピングされていることが Expressway に通知されます。

8. 次に、Expressway は別の検索を開始します。今回は fred@example.com についてです。 この時点から、URI ダイヤルのプロセスが実行され、通話が Fred のエンドポイントに転送されます。

ENUM ダイヤリングをサポートするには、リモート エンドポイントで使用される各 ENUM サービスに対して ENUM ゾーンと関連する検索ルールを構成する必要があります。

ENUM ダイヤリングを使用してローカルに登録されたエンドポイントに到達するには、エンドポイントの E.164 番号を URI にマッピングする DNS NAPTR レコードを構成する必要があります。 このレコードは、ENUM ダイヤルを使用してアクセスしようとするすべてのシステムが見つけることができる適切な DNS ドメインに配置する必要があります。

ENUM の DNS ドメインについて

ENUM は、E.164 番号とその URI 間のマッピングを提供するために NAPTR レコードの存在に依存します。

ENUM 標準を定義する一連のドキュメントの一部である RFC 3761 では、ENUM のドメイン (パブリック ENUM 展開用に NAPTR レコードを配置する場所) が e164.arpa であると指定されています 。 ただし、このドメインを使用するには、E.164 番号が適切な国の規制機関によって割り当てられている必要があります。 すべての国がまだ ENUM に参加しているわけではないので、NAPTR レコードには別のドメインを使用することをお勧めします。 このドメインは、企業ネットワーク内に存在することができます（ENUM の内部使用のため）、または http://www.e164.org などのパブリック ENUM データベースを使用することができます。

DNS NAPTR レコードの設定

ENUM は、RFC 2915 で定義されている NAPTR レコードの存在に依存します。 http://tools.ietf.org/html/rfc2915 これらは、E.164 番号から H.323 または SIP URI を取得するために使用されます。

Expressway がサポートするレコード形式は次のとおりです。

order preference flag service regex replacement

値は次のとおりです。

• order と preference によって、NAPTR レコードが処理される順序が決まります。 最も低い順序のレコードが最初に処理され、順序が一致する場合は、最も優先順位の低いレコードが最初に処理されます。

• flag は、このレコード内の他のフィールドの解釈を決定します。 現在サポートされているのは値 u (これがターミナルルールであることを示す) のみであり、これは必須です。

• service は、このレコードが H.323 または SIP の E.164 から URI への変換を記述するためのものであるかどうかを示します。 値は E2U+h323 または E2U+SIP のいずれかである必要があります。

• regex は、指定された E.164 番号から H.323 または SIP URI への変換を記述する正規表現です。

• replacement は現在 Expressway では使用されていないため、特定の値に設定する必要があります。 (ピリオド文字)。

ENUM の非終端ルールは現在、Expressway ではサポートされていません。 詳細については、RFC 3761 のセクション 2.4.1 を参照してください。 http://tools.ietf.org/html/rfc3761

たとえば、次のレコード:

IN NAPTR 10 100 "u" "E2U+h323" "!^(.*)$!h323:\1@example.com!" .

次のように解釈されます。

• 10 は 順序

• 100 は優先度

• u はフラグ

• E2U+h323 は、このレコードが H.323 URI 用であることを示します。

• !^(.*)$!h323:\1@example.com! は変換について説明します。

  • ! フィールドセパレータです

  • 最初のフィールドは変換される文字列を表します。 この例では、 ^(.*)$ は E.164 番号全体を表します。

  • 2 番目のフィールドは、生成される H.323 URI を表します。 この例では、 h323:\1@example.com は、E.164 番号が @example.com と連結されることを示しています 。 たとえば、 1234 は 1234@example.com にマッピングされます 。

• 置換フィールドが使用されていないことを示します。