Enterprise Voice 伺服器端元件

Communications Server 提供三種部署中繼伺服器與媒體閘道的選項：

• 基本：此選項包含基本媒體閘道與獨立的中繼伺服器。
• 基本混合式：此選項是基本混合式閘道，亦即將基本閘道與中繼伺服器配置在同一部電腦上。
• 進階：此選項是進階媒體閘道，中繼伺服器邏輯可以整合到閘道軟體本身。

如需詳細資訊，包括 Communications Server 可使用的合格閘道最新清單，請參閱 https://go.microsoft.com/fwlink/?LinkId=125757 (英文)。

表 1. 基本閘道與配置型閘道的比較

當您嘗試回答有關閘道部署的四個基本問題時，比較適當的做法為：

• 算出組織在當地擁有辦公室的站台數。
• 評估每一個站台的流量。
• 在每一個站台部署一個或多個閘道，以處理預期的流量。

所產生的分散式閘道拓撲顯示於下圖。

有了這個拓撲，每一個站台上和站台之間的員工電話都會透過公司內部網路路由傳送。撥給 PSTN 的電話會透過企業 IP 網路路由傳送到與目的地號碼位置最接近的閘道。

但是，萬一組織支援數十個、數百個，或甚至數千個分佈於全球各大洲的站台，就如同許多金融機構和其他大型企業一樣，這時又該怎麼辦？在這種情況下，於每一個站台部署個別的閘道是非常不切實際的。

為了處理這個問題，許多大型公司偏好部署一個或數個大型電話語音資料中心，如下圖所示。

在此拓撲中，會在每一個資料中心部署足以負擔預期使用者負載的數個大型閘道。所有撥打給企業使用者的電話都會由公司的電話服務提供者轉送到資料中心。資料中心的路由邏輯會判斷電話是應該透過內部網路路由傳送，還是傳送到 PSTN。

將閘道放在每一個站台或是將閘道放在單一資料中心，都是太過極端的部署方式。在幾乎所有可能的組合中，您都可以在數個站台部署單一閘道，以及在資料中心部署數個閘道。每一個案例下的最佳解決方案取決於每一個組織特有的各項因素。

閘道位置可能也會決定您所選擇的閘道類型以及閘道的設定方式。PSTN 通訊協定有數十種，但都不是世界標準。如果所有的閘道都位於單一國家/地區，這就不成問題；但是，如果您將閘道放置在好幾個國家/地區，則每一個閘道都必須根據該國家/地區的 PSTN 標準來設定。此外，在某個國家/地區 (如加拿大) 被認可有效的閘道，可能在其他國家/地區 (如印度、巴西或歐盟) 不被認可。

大多數組織會考慮部署的媒體閘道大小範圍，是從 2 個連接埠到最多的 960 個連接埠(其他還有更大的閘道，不過這些主要是由電話服務提供者所使用)。當您評估組織所需的連接埠數目時，請使用下列準則：

• 低用量電話語音使用者 (每小時 1 通 PSTN 電話) 應該針對每 15 個使用者配置 1 個連接埠。例如，如果您有 20 個使用者，將需要兩個連接埠的閘道。
• 中用量電話語音使用者 (每小時 2 通 PSTN 電話) 應該針對每 10 個使用者配置 1 個連接埠。例如，如果您有 100 個使用者，您將需要在一個或多個閘道中一共配置 10 個連接埠。
• 高用量電話語音使用者 (每小時 3 通或 3 通以上 PSTN 電話) 應該針對每 5 個使用者配置 1 個連接埠。例如，如果您有 47,000 個使用者，您至少需要在 10 個大型閘道中一共配置 9,400 個連接埠。
• 當組織的使用者數目或流量增加時，可以取得更多的連接埠。

對於您必須支援的任何給定使用者數目而言，您都可以選擇部署更少、更大的閘道，或是更小的閘道。建議組織至少要有兩個閘道，萬一其中一個閘道停機時還有另一個可用，這是一般的規則。除此之外，組織部署的閘道數目和大小會有極大的差異，這是根據每一個組織的電話流量所做的謹慎分析。

您部署的每個基本媒體閘道，至少都要有一個對應的中繼伺服器。可以將單一閘道指向多個中繼伺服器 (但是並不建議這麼做)，但是不能將單一中繼伺服器指向一個以上的媒體閘道。

如需詳細資訊，包括特定的硬體需求，請參閱Office Communications Server 內部元件需求和容量規劃。

附註：
基本混合式媒體閘道的設定只能搭配配置在同一部電腦的中繼伺服器使用，因此不應指向其他中繼伺服器。

根據預設，撥出電話要求統一資源識別項 (URI) 的 E.164 號碼首碼為加號 (+)。大部分的專用交換機 (PBX) 會順利處理這類號碼。但某些 PBX 不接受首碼為加號的號碼。

為了確保與這些 PBX 的互通性，中繼伺服器有一個稱為 RemovePlusFromRequestURI 的新 WMI 布林設定，它有兩個值：TRUE 和 FALSE。如果您的 PBX 不接受首碼為加號的號碼，此 WMI 設定值應設定為 TRUE，這會使中繼伺服器除去撥出電話要求 URI 的加號。預設為 FALSE，這會使中繼伺服器不變更撥出 INVITE 的 Request URI、To URI 和 From URI，並加以傳遞。

中繼伺服器有一個稱為 QoSEnabled 的新 WMI 布林設定，它有兩個值：TRUE 和 FALSE。此設定會在中繼伺服器上啟用或停用 QoS 標示。設定為 TRUE 時，此設定會使中繼伺服器在語音封包上執行區別服務代碼點 (Differentiated Services Code Point，DSCP) 標示。預設值為 FALSE。

已為語音傳輸適當佈建的網路中，不需要為封包指定優先處理順序。不過，如果您不確定頻寬容量，即使在不盡理想的環境下，此 QoS 設定也會確保良好的語音品質。

根據預設，來自 Office Communications Server 2007 R2 的撥出電話要求 URI 的 E.164 號碼首碼為加號。大部分 PBX 會順利處理這類號碼。但某些 PBX 不接受首碼為加號的號碼，不會正確路由傳送這些電話。

此外，來自某些 PBX 的傳入電話 From 標頭不符合 RFC 3966，因為其首碼不是加號。Microsoft Office Communicator 無法將這些號碼解析為正確使用者。

為了確保與這些 PBX 的互通性，Office Communications Server 2007 R2 中繼伺服器有一個稱為 RemovePlusFromRequestURI 的新 WMI 設定。此設定可以設定為 TRUE 或 FALSE。預設值為 FALSE。

• 如果 Office Communications Server 2007 R2 中繼伺服器的下游 PBX 不接受首碼為加號的號碼，請將 RemovePlusFromRequestURI 的值設定為 TRUE。這會使中繼伺服器移除撥出電話要求 URI 的加號，也會移除 To 和 From URI 的加號。
• 如果下游 PBX 接受首碼為加號的號碼，請將 RemovePlusFromRequestURI 保留為預設值 FALSE。這會使 Office Communications Server 2007 中繼伺服器不變更 Request URI、To URI 和 From URI (亦即含加號)，並加以傳遞。

Office Communications Server 2007 R2 也引進了對私人編號計劃的支援，其方式是正規化未採用 E.164 格式的 From 標頭。如果此正規化的結果不是 E.164 格式，Office Communications Server 2007 R2 會將 enterprise 的電話內容值插入 P-Asserted-ID 標頭中，以便在 Office Communicator 2007 R2 中啟用使用者查閱。然而，如果 URI 已經包含 enterprise 的電話內容值，Office Communications Server 2007 R2 便不會正規化 From 標頭。