正規化規則
上次修改主題的時間： 2009-01-24
正規化規則在指定如何將撥出的各種格式電話號碼轉換成標準 E.164 格式。電話路由和授權需要正規化規則，因為使用者在其連絡人清單中輸入電話號碼時，往往可以使用各種格式。
將使用者提供的電話號碼正規化時，便提供了有助於下列作業的一致格式：
- 將撥打的號碼與目標接聽者的 SIP-URI 相比對。
- 將撥號授權規則套用到撥號方。
下列號碼欄位是正規化規則可能需要代表的一些欄位：
- 撥號對應表
- 國碼
- 區碼
- 分機號碼長度
- 站台首碼
您可以在 Microsoft Management Console (MMC) 的 Office Communications Server 2007 R2 嵌入式管理單元中，使用 .NET Framework 規則運算式建立正規化規則。下表顯示以 .NET Framework 規則運算式撰寫的正規化規則範例。這些範例只當做範例使用，並非建立正規化規則的規定性參考。
表 1. 使用 .NET Framework 規則運算式的正規化規則
| 規則名稱 | 說明 | 號碼模式 | 轉譯 | 範例 |
|---|---|---|---|---|
4digitExtension |
轉譯 4 位數的分機號碼 |
^(\d{4})$ |
+1425555$1 |
0100 會轉譯成 +14255550100 |
5digitExtension |
轉譯 5 位數的分機號碼 |
^5(\d{4})$ |
+1425555$1 |
50100 會轉譯成 +14255550100 |
7digitcallingRedmond |
將 7 位數號碼轉譯成 Redmond 本地號碼 |
^(\d{7})$ |
+1425$1 |
5550100 會轉譯成 +14255550100 |
7digitcallingDallas |
將 7 位數號碼轉譯成 Dallas 本地號碼 |
^(\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 轉譯成 Redmond 電話總機 |
^0$ |
+14255550100 |
0 會轉譯成 +14255550100 |
RedmondSitePrefix |
轉譯含有網內互打首碼 (6) 和 Redmond 站台碼 (222) 的號碼 |
^6222(\d{4})$ |
+1425555$1 |
62220100 會轉譯成 +14255550100 |
NYSitePrefix |
轉譯含有網內互打首碼 (6) 和 NY 站台碼 (333) 的號碼 |
^6333(\d{4})$ |
+1202555$1 |
63330100 會轉譯成 +12025550100 |
DallasSitePrefix |
轉譯含有網內互打首碼 (6) 和 Dallas 站台碼 (444) 的號碼 |
^6444(\d{4})$ |
+1972555$1 |
64440100 會轉譯成 +19725550100 |
Microsoft Office 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(zh-tw,office.13).gif") 附註： |
|---|
| 如果在使用規則運算式時需要其他協助，可考慮使用 Office Communications Server 2007 Resource Kit 中的 Route Helper 應用程式。Route Helper 可以替代 MMC 嵌入式管理單元，用來檢視及修改 Enterprise Voice 號碼正規化規則、位置設定檔、語音原則及路由。 |
下表說明美國華盛頓州 Redmond 的範例位置設定檔 (根據上表所示的正規化規則)。
表 2. 依據上表所示之正規化規則建立的 Redmond 位置設定檔
| 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 等裝置會使用正規化規則來轉譯使用者拿起話筒撥號時所輸入的數字。當使用者拿起話筒撥號，使用撥號鍵台輸入數字時，電話機會將所輸入的數字與正規化規則比較。偵測到符合項目時，電話機會藉由傳送 SIP INVITE 要求至 Office Communications Server，來起始電話。如果撥號對應表有重疊數字順序的規則，當使用者拿起話筒撥號時可能會得到不明確的結果。
例如：
- 規則 [^9425(\d{7})$ +1425$1] 會將以 9425 開頭的 10 碼電話號碼轉譯為以 +1 開頭的 11 碼電話號碼，而將 94255550100 轉換為 14255550100。
- 規則 [^(\d{5})$ +125355$1] 會將 5 碼電話號碼轉譯為以 +125355 開頭的 11 碼電話號碼，而將 90101 轉換為 +12535590101。
當使用者撥打號碼 94255550102 時，一旦輸入 42555，就會偵測到符合第二個規則的項目，並且提早起始電話 (也就是傳送 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 開頭的電話號碼不會被視為內部分機，一旦使用者撥了前四碼後就不會進行正規化規則比對。
- 如果系統管理員想要整合掛上話筒和拿起話筒撥號經驗，則必須將 Office Communicator 特定的但不適用於電話裝置的規則以 doNotdialFromDevice 旗標加以標記，如此一來，當裝置執行規則比對時，就會忽略這些規則。例如，使用上一個撥號規則範例，從裝置至本地號碼的電話首碼必須是 0，但是 Office Communicator 電話不需加上首碼 0 即可撥打。
如需有關設定 Office Communications Server 2007 R2 的正規化規則增強的詳細資料，請參閱規劃語音。
針對 Exchange UM 通話起始案例設定位置設定檔
許多種狀況 (例如在電話上播放語音訊息或打電話給個人連絡人) 都需要 Exchange UM 代替使用者起始通話。這類通話的撥號對象通常是全域通訊清單中的使用者，或是使用者之個人連絡人中的人員。由 UM 起始的通話會透過 Office Communications Server 路由傳送，就像是來自其他用戶端的通話一樣。
當 Exchange UM SP1 傳送 E.164 號碼給 Office Communications Server 時，UM 不會傳遞 E.164 號碼所需的前置加號 (+)。為了解決這個問題，有兩個選項可供系統管理員使用。
選項 1：同時為 UM 和 Communications Server 用戶端定義一個位置設定檔
這個選項需要您在位置設定檔中加入一些規則，這些規則會識別遺漏前置加號的 E.164 號碼。例如，美國華盛頓州 Redmond 的位置設定檔可能需要一項規則，在所有第一個數字為 1 的 11 位數號碼前面加上加號。在實際應用中，針對遺漏前置加號的所有 E.164 號碼，制定可進行正確識別的規則，可能會非常困難且耗時。
當 Office Communications Server 用戶端與 UM 中的撥號模式很類似時 (例如，當沒有網外撥接首碼的需求)，這是建議的選擇方案。
即使 Office Communications Server 用戶端與 UM 中的撥號模式並不相似，管理員還是可以選擇針對這兩種案例定義及排序正規化規則。這個方法會帶來額外的複雜性，但是可讓 Office Communications Server 用戶端從 Outlook 連絡人清單撥號，即使當號碼格式不符合一般撥號對應表時，也可以撥號。
選項 2：定義兩個位置設定檔，其中一個會轉譯來自 Office Communications Server 用戶端的號碼，另一個則會轉譯來自 Exchange UM 的號碼。
這個選項可免除必須確定單一位置設定檔代表兩組撥號模式 (一組來自於 Exchange UM，另一組則來自於 Office Communications Server 用戶端) 所產生的複雜性。缺點是必須設定及維護兩個位置設定檔。