正規化ルール
トピックの最終更新日: 2009-01-24
正規化ルールでは、さまざまな形式でダイヤルされる番号を標準の E.164 形式に変換する方法を指定します。正規化ルールは、通話のルーティングと承認を行うのに不可欠です。これは、ユーザーが連絡先リストに電話番号を入力する際にさまざまな形式を使用する可能性があるためです。
ユーザーがダイヤルした電話番号を正規化することによって、形式の一貫性を確保できます。これは、次の処理に役立ちます。
- ダイヤルされた番号と受信者の SIP-URI のマッチング
- 発信者へのダイヤル承認ルールの適用
次の番号フィールドでは、正規化ルールの考慮が必要になる可能性があります。
- ダイヤル プラン
- 国番号
- 市外局番
- 内線番号の長さ
- サイトのプレフィックス
正規化ルールは、.NET Framework 正規表現を使用して、Office Communications Server 2007 R2 の Microsoft 管理コンソール (MMC) 用スナップインで作成します。次の表は、.NET Framework 正規表現で記述された正規化ルールの例です。ここに示すのは、単なる例であり、このとおりに正規化ルールを作成する必要はありません。
表 1. .NET Framework 正規表現を使用した正規化ルール
| ルール名 | 説明 | 番号のパターン | 変換 | 例 |
|---|---|---|---|---|
4digitExtension |
4 桁の内線番号を変換します。 |
^(\d{4})$ |
+1425555$1 |
0100 が +14255550100 に変換されます。 |
5digitExtension |
5 桁の内線番号を変換します。 |
^5(\d{4})$ |
+1425555$1 |
50100 が +14255550100 に変換されます。 |
7digitcallingRedmond |
7 桁の番号をレドモンドの電話番号に変換します。 |
^(\d{7})$ |
+1425$1 |
5550100 が +14255550100 に変換されます。 |
7digitcallingDallas |
7 桁の番号をダラスの電話番号に変換します。 |
^(\d{7})$ |
+1972$1 |
5550100 が +19725550100 に変換されます。 |
10digitcallingUS |
米国の 10 桁の番号を変換します。 |
^(\d{10})$ |
+1$1 |
2065550100 が +12065550100 に変換されます。 |
LDCallingUS |
米国の長距離プレフィックス付きの番号を変換します。 |
^1(\d{10})$ |
+$1 |
12145550100 が +12145550100 に変換されます。 |
IntlCallingUS |
米国の国際プレフィックス付きの番号を変換します。 |
^011(\d*)$ |
+$1 |
01191445550100 が +91445550100 に変換されます。 |
RedmondOperator |
0 をレドモンドのオペレータ呼び出し番号に変換します。 |
^0$ |
+14255550100 |
0 が +14255550100 に変換されます。 |
RedmondSitePrefix |
ネットワーク内プレフィックス (6) およびレドモンドのサイト コード (222) 付きの番号を変換します。 |
^6222(\d{4})$ |
+1425555$1 |
62220100 が +14255550100 に変換されます。 |
NYSitePrefix |
ネットワーク内プレフィックス (6) およびニューヨークのサイト コード (333) 付きの番号を変換します。 |
^6333(\d{4})$ |
+1202555$1 |
63330100 が +12025550100 に変換されます。 |
DallasSitePrefix |
ネットワーク内プレフィックス (6) およびダラスのサイト コード (444) 付きの番号を変換します。 |
^6444(\d{4})$ |
+1972555$1 |
64440100 が +19725550100 に変換されます。 |
Microsoft Office Communicator 2007 R2 Phone Edition は、場所のプロファイルに含まれる正規化ルールを使用して、ユーザーのダイヤル操作を最適化します。ユーザーが数字を入力する際に Communicator 2007 R2 Phone Edition がオフフックになっていると、Communicator 2007 R2 Phone Edition は場所のプロファイルに含まれる正規化ルールを使用して、Office Communications Server に対する INVITE 要求の生成に必要な桁数が入力されたかどうかを判断します。
.NET Framework 正規表現の使用方法の詳細については、「.NET Framework の正規表現」(https://go.microsoft.com/fwlink/?LinkId=140927) を参照してください。
.gif "Dd425124.note(ja-jp,office.13).gif") 注: |
|---|
| 正規表現の使用を容易にするために、Office Communications Server 2007 Resource Kit に含まれている Route Helper を使用することを検討してください。MMC スナップインの代わりに Route Helper を使用して、エンタープライズ VoIP の電話番号正規化ルール、場所のプロファイル、ボイス ポリシー、およびルートを表示および変更することができます。 |
以下の表は、レドモンド (Washington, USA) の場所のプロファイルの例です。これは、前の表に示す正規化ルールに基づいています。
表 2. 前の表の正規化ルールに基づくレドモンドの場所のプロファイル
| Redmond.forestFQDN |
|---|
5digitExtension |
7digitcallingRedmond |
10digitcallingUS |
IntlCallingUS |
RedmondSitePrefix |
NYSitePrefix |
DallasSitePrefix |
RedmondOperator |
| 注: |
|---|
| 前の表に記載した正規化ルールの名前にはスペースが含まれていませんが、これは任意に設定できます。たとえば、この表の最初の名前は、「5 digit extension」または「5-digit Extension」のどちらで記述しても問題ありません。 |
Office Communications Server 2007 R2 で強化された電話番号正規化ルール
Office Communications Server 2007 R2 では、電話番号の正規化が強化されています。この結果、ユーザーがオフフックでダイヤルした (つまり、ハンドセットをクレイドルから外した状態でダイヤルした、またはスピーカーフォンを使用した) ときに外部アクセス プレフィックスが長距離電話のプレフィックスと一致した場合に発生するあいまいな結果を回避できます。
Office Communications Server 2007 の正規化ルール
Communicator Phone Edition などのデバイスは、ユーザーがオフフックでダイヤルしたときに入力された数字を、正規化ルールを使用して変換します。オフフック ダイヤル中は、ユーザーがダイヤル パッドを使用して数字を入力すると、入力された数値が電話機によって正規化ルールと比較されます。一致が検出されると、電話機は、Office Communications Server に SIP INVITE 要求を送信して、通話を開始します。ダイヤル プランの中に、数字の並びが重複するルールがある場合は、ユーザーがオフフックでダイヤルしたときにあいまいな結果となる可能性があります。
次に例を示します。
- ルール [^9425(\d{7})$ +1425$1] は、9425 で始まる 10 桁の電話番号を、+1 で始まる 11 桁の番号に変換します。94255550100 は 14255550100 に変換されます。
- ルール [^(\d{5})$ +125355$1] は、5 桁の電話番号を、+125355 で始まる 11 桁の番号に変換します。90101 は +12535590101 に変換されます。
ユーザーが 94255550102 という番号をダイヤルする場合は、42555 が入力された時点で 2 番目のルールとの一致が検出され、すべての番号が入力される前に通話が開始されます (SIP INVITE 要求が送信されます)。
Office Communications Server 2007 で発生するこの問題を軽減するため、Communicator Phone Edition では文字列 "t?" を含むルールは無視され、オフフック ダイヤルの最適化では使用されません。
Office Communications Server 2007 R2 の正規化ルール
前のセクションで説明した問題を解決するため、Office Communications Server 2007 R2 では次の操作を行うことができます。
- 管理者は、場所のプロファイル用の外部アクセス プレフィックスを定義することで、重複するルールのあいまいさを排除できます。
- 管理者は、社内の電話番号に対応するルールにフラグを設定できます。
これらの変更には、次に示す効果があります。
- 場所のプロファイルと正規化ルールに対するスキーマの変更が、インバンド プロビジョニングを介してクライアント (Communicator Phone Edition など) に送信されます。
- 場所のプロファイルから Communicator Phone Edition 固有のルールをすべて削除できます。たとえば、前に説明した "t?" 文字列は不要となったため、正規表現から削除できます。
- ユーザーによってダイヤルされた最初の数字が外部アクセス プレフィックスと一致する場合、Communicator Phone Edition などのデバイスはその数字を無視し、"InternalExtension" とマークされたルールを使用しません。たとえば、ユーザーが "08005551212" とダイヤルした場合、最初のゼロはデバイスによって削除され、この通話は、無料通話として処理されます。"0" から始まる電話番号は内線として扱われず、ユーザーが先頭の 4 桁をダイヤルした時点では、正規化ルールとの照合は行われません。
- オンフックとオフフックでのダイヤル処理を統一する場合は、Office Communicator に固有の、電話機デバイスには適用されないルールに対して doNotdialFromDevice フラグを設定します。これにより、デバイスは、ルールの照合を行うときに、これらのルールを無視します。たとえば、前述したダイヤル ルールの例を使用すると、デバイスから外部発信される通話には先頭に "0" が必要ですが、Office Communicator を介した通話は、"0" を追加せずに発信できます。
正規化ルールが強化された Office Communications Server 2007 R2 の構成の詳細については、「音声の計画」を参照してください。
Exchange UM による通話の開始に対応した場所のプロファイルの構成
音声メッセージの電話での再生や個人連絡先への通話などのいくつかのシナリオでは、Exchange UM でユーザーの代わりに通話を開始する必要があります。通常、このような通話の相手はグローバル アドレス一覧のユーザーか、または個人連絡先に登録された人物です。UM による通話の開始は、他のクライアントからの通話と同様に、Office Communications Server を介してルーティングされます。
Exchange UM SP1 が Office Communications Server に E.164 の番号を送信する際、UM は E.164 番号で必要なプレフィックスの正符号 (+) を送信しません。この問題を回避するために、管理者は次のいずれかの方法を利用できます。
オプション 1: UM および Communications Server クライアントの両方に対応した単一の場所のプロファイルを定義する
このオプションでは、正符号が欠落した E.164 番号を識別するルールを場所のプロファイルに追加する必要があります。たとえば、レドモンド (ワシントン州、米国) の場合には、場所のプロファイルに、1 で始まる 11 桁の番号の先頭に正符号を付加するルールが必要になります。実際には、先頭の正符号が欠落しているすべての E.164 番号を正しく識別するルールを作成するのは困難で時間がかかります。
このオプションは、Office Communications Server クライアントと UM のダイヤル パターンが似ている場合に推奨されます (たとえば、オフネット プレフィックスが必要ない場合など)。
Office Communications Server クライアントと UM のダイヤル パターンが似ていない場合でも、管理者は正規化ルールを定義して、両方のシナリオに対応できます。この方法を利用すると、より複雑になりますが、番号形式が標準のダイヤル プランに準拠していない場合でも、Office Communications Server クライアントによる Outlook の連絡先リストからの通話が可能になります。
オプション 2: 2 つの場所のプロファイルを定義する (一方は Office Communications Server クライアントから送付される番号を変換し、もう一方は Exchange UM から送付される番号を変換する)
このオプションを利用すると、1 つの場所のプロファイルで Exchange UM と Office Communications Server クライアントから送信される 2 種類のダイヤル パターンに対応する必要がなくなるため、構成が簡素化されます。短所は、2 つの場所のプロファイルを構成して管理する必要がある点です。