GAPTHEGURU

Geek with special skills

Enterprise Voice Server-Side Components

When you choose to deploy Enterprise Voice, you need to plan to deploy an Office Communications Server 2007 R2 Mediation Server, which intermediates signaling and media between your internal Communications Server infrastructure and your media gateway or Session Initiation Protocol (SIP) trunk. You will also need a media (IP/PSTN) gateway to handle calls between Voice over IP (VoIP)-enabled users and the public switched telephone network (PSTN). (A media gateway is not required for a SIP trunk connection.)

Media Gateway

The number, size, and location of media gateways are perhaps the most important and potentially costly decisions you must make when planning your Enterprise Voice infrastructure. The main questions to answer are:

  • What type of gateway should you deploy?
  • How many media gateways are needed? The answer depends at least in part on the size of the gateways and where you plan to deploy them.
  • What size should the gateways be? The answer depends in part on how many you plan to deploy and where you plan to put them.
  • Where should the gateways be located? The answer depends in part on the topology and geographic distribution of your organization.

In other words, no one of the previous questions can be answered independently of the other three. Answers to all four depend ultimately on how much telephone traffic you anticipate and how that traffic is distributed across your organization. But that is only the beginning: the base data, so to speak. You must also consider your gateway topology options.

Type of Gateway to Deploy

Communications Server offers three options for deploying a Mediation Server and media gateway:

  • Basic. This option consists of a basic media gateway and a separate Mediation Server.
  • Basic Hybrid. This option is a basic-hybrid gateway, in which the basic gateway and Mediation Server are collocated on a single computer.
  • Advanced. This option is an advanced media gateway, in which the Mediation Server logic is incorporated within the gateway software itself.

Table 1. Basic and Collocated Gateways Compared

Gateway Type Advantages Disadvantages
Basic Media Gateway Existing hardware can perhaps be used for Mediation Server. Mediation Server entails additional overhead for installation, configuration, and management.
Basic Hybrid Media Gateway Does not require separate Mediation Server.

Installation, configuration, and management are simpler than they are for combination of Basic Media Gateway and Mediation Server.

None.
Advanced Media Gateway Does not require separate Mediation Server. Installation, configuration, and management are simpler than they are for other gateway types. None.

Gateway Topologies

When attempting to answer the four fundamental questions of gateway deployment, the obvious approach is to:

  • Count the sites at which your organization has offices.
  • Estimate the traffic at each site.
  • Deploy one or more gateways at each site to handle the anticipated traffic.

The resulting distributed gateway topology is shown in the following figure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1. Distributed gateway topology

With this topology, calls among workers at each site and between the sites are all routed over the company intranet. Calls to the PSTN are routed over the enterprise IP network to the gateways that are closest to the location of the destination numbers.

But what if your organization supports dozens or hundreds or even thousands of sites spread across one or more continents, as many financial institutions and other large enterprises do? In such cases deploying a separate gateway at each site is impractical.

To address this problem, many large companies prefer to deploy one or a few large telephony data centers, as shown in the following figure.
Figure 2. Telephony data center topology

In this topology, several large gateways sufficient to accommodate the anticipated user load are deployed at each data center. All calls to users in the enterprise are forwarded by the company’s telephone service provider to a data center. Routing logic at the data center determines whether the call should be routed over the intranet or to the PSTN.

Placing a gateway at every site on the one hand or at a single data center on the other represents the extremes of a deployment continuum. You can deploy single gateways at several sites and several gateways at a data center in nearly any possible combination. The best solution in each case depends on a variety of factors that are specific to each organization.

Gateway Location

Gateway location may also determine the types of gateways you choose and how they are configured. There are dozens of PSTN protocols, none of which is a worldwide standard. If all your gateways are located in a single country/region, this is not an issue, but if you locate gateways in several countries/regions, each must be configured according to the PSTN standards of that country/region. Moreover, gateways that are certified for operation in, say, Canada, may not be certified in India, Brazil, or the European Union.

Gateway Size and Number

The media gateways that most organizations will consider deploying range in size from 2 to as many as 960 ports. (There are even larger gateways, but these are used mainly by telephone service providers.) When estimating the number of ports your organization requires, use the following guidelines:

  • Light telephony users (one PSTN call per hour) should allocate one port for every 15 users. For example, if you have 20 users, you will require a gateway with two ports.
  • Moderate telephony users (two PSTN calls per hour) should allocate one port for every 10 users. For example, if you have 100 users, you will require a total of 10 ports allocated among one or more gateways.
  • Heavy telephony users (three or more PSTN calls per hour) should allocate one port for every five users. For example, if you have 47,000 users, you will require a total of 9,400 ports allocated among at least 10 large gateways.
  • Additional ports can be acquired as the number of users or amount of traffic in your organization increases.

For any given number of users you must support, you have the choice of deploying fewer, larger gateways, or smaller ones. As a rule, a minimum of two gateways for an organization is recommended in the event one goes down. Beyond that, the number and size of gateways that an organization deploys are going to vary widely, based on a careful analysis of each organization’s volume of telephone traffic.

Each basic media gateway that you deploy must have at least one corresponding Mediation Server. It is possible, though not recommended, to point a single gateway to multiple Mediation Servers, but you cannot point a single Mediation Server to more than one media gateway.

SIP Trunking

Office Communications Server 2007 R2 enables an enterprise to connect its voice network to a service provider offering PSTN origination and termination, which can simplify and reduce the cost of deploying Enterprise Voice. This capability, a variety of what is known in the telecommunications industry as “SIP trunking”, means that enterprises do not need to deploy IP-PSTN gateways, with or without Mediation Servers, in order to enable PSTN connectivity.

The Office Communications Server 2007 R2 Session Initiation Protocol (SIP) trunking capability enables the following scenarios:

  • An enterprise user inside or outside the corporate firewall can make a local or long-distance call specified by an E.164-compliant number that is terminated on the PSTN as a service of the corresponding service provider.
  • Any PSTN subscriber can contact an enterprise user inside or outside the corporate firewall by dialing a Direct Inward Dialing (DID) number associated with that enterprise user.

Exchange Unified Messaging

If your organization also plans to use Exchange Server 2007 SP1 Unified Messaging, you must deploy the following Exchange Server 2007 SP1 server roles: Unified Messaging, Hub Transport, Client Access, and Mailbox. These server roles can be deployed in the same or a different forest as Communications Server 2007 R2.

New Configuration Options in Mediation Server

Office Communications Server 2007 R2 introduces two new Windows Management Instrumentation (WMI) settings for Mediation Server. The first new setting specifies how Mediation Server processes E.164 numbers in outbound calls. The second new setting enables Quality of Service (QoS) marking on Mediation Server.

Handling E.164 Numbers in Outbound Calls

By default, E.164 numbers in the Request Uniform Resource Identifier (URI) for outgoing calls are prefixed with a plus sign (+). Most Private Branch eXchanges (PBXs) process such numbers without problem. Certain PBXs, however, do not accept numbers that are prefixed with a plus sign.

To ensure interoperability with these PBXs, Mediation Server has a new WMI Boolean setting called RemovePlusFromRequestURI, which has two values: TRUE and FALSE. If your PBX does not accept numbers prefixed with a plus sign, the value for the WMI setting should be set to TRUE, which causes Mediation Server to strip the plus sign from a Request URI for outbound calls. The default is FALSE, which causes Mediation Server to pass the outgoing INVITE’s Request URI, To URI, and From URI unchanged.

Enabling QoS on Mediation Server

Mediation Server has a new WMI Boolean setting called QoSEnabled, which has two values: TRUE and FALSE. This setting enables or disables QoS marking on Mediation Server. When set to TRUE, the setting causes Mediation Server to perform Differentiated Services Code Point (DSCP) marking on voice packets. The default value is FALSE.

In a network that has been properly provisioned for voice transmission, packet prioritization is not necessary. However, if you are unsure of bandwidth capacity, this QoS setting assures good voice quality even in suboptimal environments.

Improved Handling of Private (Non-DID) Numbers

Two improvements for handling private (non-DID) numbers in Office Communications Server 2007 R2 enable:

  • Compatibility with PBXs or other downstream elements that do not support the plus sign in Request URIs.
  • Support for private numbering plans, in which the msRTCSIP-Line property in Active Directory Domain Services (AD DS) does not have to be in E.164 format.

Compatibility with PBXs That Do Not Support the Plus Sign

By default, E.164 numbers in the Request URI of outgoing calls from Office Communications Server 2007 R2 are prefixed with a plus sign. Most PBXs process such numbers without problem. Some PBXs, however, do not accept numbers that are prefixed with a plus sign and do not route those calls correctly.

Additionally, the From headers of inbound calls from some PBXs does not conform to RFC 3966 because they are not prefixed with a plus sign. Microsoft Office Communicator cannot resolve these numbers to the correct user.

To assure interoperability with these PBXs, Office Communications Server 2007 R2 has a new Mediation Server setting for WMI called RemovePlusFromRequestURI. This setting can be set to TRUE or FALSE. The default value is FALSE.

  • If a PBX downstream from the Office Communications Server 2007 R2 Mediation server does not accept numbers prefixed with a plus sign, set the value of RemovePlusFromRequestURI to TRUE. This causes Mediation Server to remove the plus signs from the Request URIs of outgoing calls. It also causes the plus signs to be removed from the To and From URIs.
  • If the downstream PBX accepts numbers prefixed with plus signs, leave the value of RemovePlusFromRequestURI set to its default value of FALSE. This causes Office Communications Server 2007 Mediation Server to pass Request URIs, To URIs, and From URIs unchanged (that is, with plus signs).

Support for Private Numbering Plans

Office Communications Server 2007 R2 also introduces support for private numbering plans by normalizing From headers that are not in E.164 format. If the result of this normalization is not in E.164 format, Office Communications Server 2007 R2 inserts a P-Asserted-ID header with a phone-context value of enterprise to enable user lookup in Office Communicator 2007 R2. However, if the URI already contains a phone-context value of enterprise, Office Communications Server 2007 R2 does not normalize the From header.

 

08/10/2012 Posted by | OCS, Unified Communcation | , | Leave a comment

Enterprise Voice Server-Side Components

When you choose to deploy Enterprise Voice, you need to plan to deploy an Office Communications Server 2007 R2 Mediation Server, which intermediates signaling and media between your internal Communications Server infrastructure and your media gateway or Session Initiation Protocol (SIP) trunk. You will also need a media (IP/PSTN) gateway to handle calls between Voice over IP (VoIP)-enabled users and the public switched telephone network (PSTN). (A media gateway is not required for a SIP trunk connection.)

Media Gateway

The number, size, and location of media gateways are perhaps the most important and potentially costly decisions you must make when planning your Enterprise Voice infrastructure. The main questions to answer are:

  • What type of gateway should you deploy?
  • How many media gateways are needed? The answer depends at least in part on the size of the gateways and where you plan to deploy them.
  • What size should the gateways be? The answer depends in part on how many you plan to deploy and where you plan to put them.
  • Where should the gateways be located? The answer depends in part on the topology and geographic distribution of your organization.

In other words, no one of the previous questions can be answered independently of the other three. Answers to all four depend ultimately on how much telephone traffic you anticipate and how that traffic is distributed across your organization. But that is only the beginning: the base data, so to speak. You must also consider your gateway topology options.

Type of Gateway to Deploy

Communications Server offers three options for deploying a Mediation Server and media gateway:

  • Basic. This option consists of a basic media gateway and a separate Mediation Server.
  • Basic Hybrid. This option is a basic-hybrid gateway, in which the basic gateway and Mediation Server are collocated on a single computer.
  • Advanced. This option is an advanced media gateway, in which the Mediation Server logic is incorporated within the gateway software itself.

Table 1. Basic and Collocated Gateways Compared

Gateway Type Advantages Disadvantages
Basic Media Gateway Existing hardware can perhaps be used for Mediation Server. Mediation Server entails additional overhead for installation, configuration, and management.
Basic Hybrid Media Gateway Does not require separate Mediation Server.

Installation, configuration, and management are simpler than they are for combination of Basic Media Gateway and Mediation Server.

None.
Advanced Media Gateway Does not require separate Mediation Server. Installation, configuration, and management are simpler than they are for other gateway types. None.

Gateway Topologies

When attempting to answer the four fundamental questions of gateway deployment, the obvious approach is to:

  • Count the sites at which your organization has offices.
  • Estimate the traffic at each site.
  • Deploy one or more gateways at each site to handle the anticipated traffic.

The resulting distributed gateway topology is shown in the following figure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1. Distributed gateway topology

With this topology, calls among workers at each site and between the sites are all routed over the company intranet. Calls to the PSTN are routed over the enterprise IP network to the gateways that are closest to the location of the destination numbers.

But what if your organization supports dozens or hundreds or even thousands of sites spread across one or more continents, as many financial institutions and other large enterprises do? In such cases deploying a separate gateway at each site is impractical.

To address this problem, many large companies prefer to deploy one or a few large telephony data centers, as shown in the following figure.
Figure 2. Telephony data center topology

In this topology, several large gateways sufficient to accommodate the anticipated user load are deployed at each data center. All calls to users in the enterprise are forwarded by the company’s telephone service provider to a data center. Routing logic at the data center determines whether the call should be routed over the intranet or to the PSTN.

Placing a gateway at every site on the one hand or at a single data center on the other represents the extremes of a deployment continuum. You can deploy single gateways at several sites and several gateways at a data center in nearly any possible combination. The best solution in each case depends on a variety of factors that are specific to each organization.

Gateway Location

Gateway location may also determine the types of gateways you choose and how they are configured. There are dozens of PSTN protocols, none of which is a worldwide standard. If all your gateways are located in a single country/region, this is not an issue, but if you locate gateways in several countries/regions, each must be configured according to the PSTN standards of that country/region. Moreover, gateways that are certified for operation in, say, Canada, may not be certified in India, Brazil, or the European Union.

Gateway Size and Number

The media gateways that most organizations will consider deploying range in size from 2 to as many as 960 ports. (There are even larger gateways, but these are used mainly by telephone service providers.) When estimating the number of ports your organization requires, use the following guidelines:

  • Light telephony users (one PSTN call per hour) should allocate one port for every 15 users. For example, if you have 20 users, you will require a gateway with two ports.
  • Moderate telephony users (two PSTN calls per hour) should allocate one port for every 10 users. For example, if you have 100 users, you will require a total of 10 ports allocated among one or more gateways.
  • Heavy telephony users (three or more PSTN calls per hour) should allocate one port for every five users. For example, if you have 47,000 users, you will require a total of 9,400 ports allocated among at least 10 large gateways.
  • Additional ports can be acquired as the number of users or amount of traffic in your organization increases.

For any given number of users you must support, you have the choice of deploying fewer, larger gateways, or smaller ones. As a rule, a minimum of two gateways for an organization is recommended in the event one goes down. Beyond that, the number and size of gateways that an organization deploys are going to vary widely, based on a careful analysis of each organization’s volume of telephone traffic.

Each basic media gateway that you deploy must have at least one corresponding Mediation Server. It is possible, though not recommended, to point a single gateway to multiple Mediation Servers, but you cannot point a single Mediation Server to more than one media gateway.

SIP Trunking

Office Communications Server 2007 R2 enables an enterprise to connect its voice network to a service provider offering PSTN origination and termination, which can simplify and reduce the cost of deploying Enterprise Voice. This capability, a variety of what is known in the telecommunications industry as “SIP trunking”, means that enterprises do not need to deploy IP-PSTN gateways, with or without Mediation Servers, in order to enable PSTN connectivity.

The Office Communications Server 2007 R2 Session Initiation Protocol (SIP) trunking capability enables the following scenarios:

  • An enterprise user inside or outside the corporate firewall can make a local or long-distance call specified by an E.164-compliant number that is terminated on the PSTN as a service of the corresponding service provider.
  • Any PSTN subscriber can contact an enterprise user inside or outside the corporate firewall by dialing a Direct Inward Dialing (DID) number associated with that enterprise user.

Exchange Unified Messaging

If your organization also plans to use Exchange Server 2007 SP1 Unified Messaging, you must deploy the following Exchange Server 2007 SP1 server roles: Unified Messaging, Hub Transport, Client Access, and Mailbox. These server roles can be deployed in the same or a different forest as Communications Server 2007 R2.

New Configuration Options in Mediation Server

Office Communications Server 2007 R2 introduces two new Windows Management Instrumentation (WMI) settings for Mediation Server. The first new setting specifies how Mediation Server processes E.164 numbers in outbound calls. The second new setting enables Quality of Service (QoS) marking on Mediation Server.

Handling E.164 Numbers in Outbound Calls

By default, E.164 numbers in the Request Uniform Resource Identifier (URI) for outgoing calls are prefixed with a plus sign (+). Most Private Branch eXchanges (PBXs) process such numbers without problem. Certain PBXs, however, do not accept numbers that are prefixed with a plus sign.

To ensure interoperability with these PBXs, Mediation Server has a new WMI Boolean setting called RemovePlusFromRequestURI, which has two values: TRUE and FALSE. If your PBX does not accept numbers prefixed with a plus sign, the value for the WMI setting should be set to TRUE, which causes Mediation Server to strip the plus sign from a Request URI for outbound calls. The default is FALSE, which causes Mediation Server to pass the outgoing INVITE’s Request URI, To URI, and From URI unchanged.

Enabling QoS on Mediation Server

Mediation Server has a new WMI Boolean setting called QoSEnabled, which has two values: TRUE and FALSE. This setting enables or disables QoS marking on Mediation Server. When set to TRUE, the setting causes Mediation Server to perform Differentiated Services Code Point (DSCP) marking on voice packets. The default value is FALSE.

In a network that has been properly provisioned for voice transmission, packet prioritization is not necessary. However, if you are unsure of bandwidth capacity, this QoS setting assures good voice quality even in suboptimal environments.

Improved Handling of Private (Non-DID) Numbers

Two improvements for handling private (non-DID) numbers in Office Communications Server 2007 R2 enable:

  • Compatibility with PBXs or other downstream elements that do not support the plus sign in Request URIs.
  • Support for private numbering plans, in which the msRTCSIP-Line property in Active Directory Domain Services (AD DS) does not have to be in E.164 format.

Compatibility with PBXs That Do Not Support the Plus Sign

By default, E.164 numbers in the Request URI of outgoing calls from Office Communications Server 2007 R2 are prefixed with a plus sign. Most PBXs process such numbers without problem. Some PBXs, however, do not accept numbers that are prefixed with a plus sign and do not route those calls correctly.

Additionally, the From headers of inbound calls from some PBXs does not conform to RFC 3966 because they are not prefixed with a plus sign. Microsoft Office Communicator cannot resolve these numbers to the correct user.

To assure interoperability with these PBXs, Office Communications Server 2007 R2 has a new Mediation Server setting for WMI called RemovePlusFromRequestURI. This setting can be set to TRUE or FALSE. The default value is FALSE.

  • If a PBX downstream from the Office Communications Server 2007 R2 Mediation server does not accept numbers prefixed with a plus sign, set the value of RemovePlusFromRequestURI to TRUE. This causes Mediation Server to remove the plus signs from the Request URIs of outgoing calls. It also causes the plus signs to be removed from the To and From URIs.
  • If the downstream PBX accepts numbers prefixed with plus signs, leave the value of RemovePlusFromRequestURI set to its default value of FALSE. This causes Office Communications Server 2007 Mediation Server to pass Request URIs, To URIs, and From URIs unchanged (that is, with plus signs).

Support for Private Numbering Plans

Office Communications Server 2007 R2 also introduces support for private numbering plans by normalizing From headers that are not in E.164 format. If the result of this normalization is not in E.164 format, Office Communications Server 2007 R2 inserts a P-Asserted-ID header with a phone-context value of enterprise to enable user lookup in Office Communicator 2007 R2. However, if the URI already contains a phone-context value of enterprise, Office Communications Server 2007 R2 does not normalize the From header.

 

08/10/2012 Posted by | OCS, Unified Communcation | , | Leave a comment

Enterprise Voice Deployment Requirements

In addition to deploying media gateways (which are not required for SIP trunking connections), you must also plan for the normalization of the phone numbers that are stored in Active Directory Domain Services (AD DS) and create dial plans for each location where your organization does business, as well as meet other requirements specific to the implementation method you chose for your organization.

Also, if your organization is to integrate Exchange Unified Messaging with Office Communications Server, you must meet additional technical requirements for that integration.

Prerequisites

For an optimum experience when deploying Enterprise Voice, make sure that your IT infrastructure, network, and systems meet the following prerequisites:

  • Microsoft Office Communications Server Standard Edition or Enterprise Edition is installed and operational on your network.
  • All Edge Servers and a reverse proxy are deployed and operational in your perimeter network.
  • Exchange Server 2007 SP1 is installed if you are integrating Exchange Unified Messaging with Office Communications Server.
  • One or more users have been created and enabled for Office Communications Server.
  • A primary phone number has been designated, normalized, and copied to the msRTCSIP-line attribute for each user who is to be enabled for Enterprise Voice. The administrator is responsible for ensuring that this number is unique.
  • Administrators deploying Enterprise Voice should be members of the RTCUniversalServerAdmins group.
  • Office Communicator and Live Meeting are successfully deployed.
  • Public key infrastructure (PKI) is deployed and configured, using either a Microsoft or a third-party certification authority (CA) infrastructure.
  • Each computer on which you install Mediation Server is:
  • Prepared for Active Directory Domain Services. For details about Active Directory Domain Services preparation procedures, see Office Communications Server 2007 R2 Active Directory Guide in the Deployment documentation.
  • Running one of the following operating systems:
    • The 64-bit edition of the Windows Server 2008 Standard operating system or the 64-bit edition of the Windows Server 2008 Enterprise operating system
    • The Windows Server 2003 R2 Standard x64 Edition operating system with Service Pack 2 (SP2) or the Windows Server 2003 R2 Enterprise x64 Edition operating system with SP2
    • The Windows Server 2003 Standard x64 Edition operating system with SP2 or the Windows Server 2003 Enterprise x64 Edition operating system with SP2
  • One or more media gateways are available for deployment. (Media gateways are not required with SIP trunking.)

Table 1. Enterprise Voice Technical Requirements Table

Implementation method Technical requirements
PBX coexistence IP-PBX that natively supports SIP and IP media in a format that is interoperable with Office Communications Server.

OR

A PBX combined with a media gateway that connects the PBX to the Office Communications Server infrastructure.

A/V Edge Server for media relay across network address translations (NATs) and firewalls.

Mediation Server configured with the IP address of the PBX and the fully qualified domain name (FQDN) of the A/V Edge Server.

Users enabled for Enterprise Voice and PBX integration.

Voice mail configured on PBX.

Stand-Alone Options  
Departmental IP-or TDM PBX.

Basic, basic hybrid, or advanced media gateway configured to connect departmental deployment with PBX.

Additional other gateways as required for PSTN connections.

A/V Edge Server for media relay across NATs and firewalls.

Mediation server configured with IP address of basic or basic hybrid media gateway (not required for advanced gateway).

Users enabled for Enterprise Voice.

Call forwarding independently configured separately on Office Communicator and PBX.

Exchange Unified Messaging deployed and configured to provide voice mail for Enterprise Voice users (PBX continues to supply voice mail for all other users).

Interface Cards for Mediation Server

To help ensure the physical as well as logical separation of your Enterprise Voice infrastructure from the media gateways, you should install Mediation Server on a computer that is equipped with two network interface cards (NICs). One card faces the gateway; the second card faces the Office Communications Server 2007 server that acts as the Mediation Servers internal next hop.

When you install Mediation Server, the Deployment Wizard detects the presence of the two network cards and writes their IP addresses to the Office Communications Server listening IP address list and the Gateway listening IP address list, both on the General tab of the Mediation Server properties dialog box.

The Office Communications Server listening IP address is the address on an advanced media gateway that listens for call traffic from Office Communications Server. Until advanced media gateways are available, this address corresponds to the network card that serves as the internal edge of the Mediation Server.

The Gateway listening IP address is the address on the Mediation Server that lists traffic from a basic media gateway or Basic Hybrid Media Gateway. For Office Communications Server 2007, this address corresponds to the network card that serves as the external edge of the Mediation Server.

Media Bandwidth Requirements

For basic media gateways, the bandwidth requirement between gateway and Mediation Server is 64 kilobits per second (Kbps) for each concurrent call. Multiplying this number by the number of ports for each gateway is a fair estimate of the required bandwidth on the gateway side of the Mediation Server. On the Office Communications Server side, the bandwidth requirement is considerably lower.

When configuring Mediation Server, you are advised to accept the default media port gateway range of 60,000 to 64,000. Reducing the port range greatly reduces server capacity and should be undertaken only for specific reasons by an administrator who is knowledgeable about media port requirements and scenarios. For this reason, altering the default port range is not recommended.

High-bandwidth traffic such as voice and video tends to stress poorly provisioned networks. Limiting media traffic to a known range of ports makes troubleshooting such problems easier.

Gateway Configuration Requirements

The settings that you must configure on your Basic Media Gateway are specified in the following list, but for information about how to configure these settings on a given gateway, refer to the manufacturer’s product documentation. Each gateway must be configured according to the vendor’s documentation. Depending on the vendor, there are potentially many attributes that must be set, but the attributes specific to Enterprise Voice are as follows:

  • The FQDN and IP address of the Mediation Server that is associated with the gateway.
  • The listening port (5060) that is used for TCP connections to the Mediation Server.
  • SIP Transport – specify either TLS (recommended) or TCP.
  • If the SIP transport for the link between the gateway and the Mediation Server is set to TLS, the gateway must be configured with a certificate for purposes of authentication during the mutual TLS (MTLS) handshake with the Mediation Server. The certificate on the gateway must be configured as follows:
  • The certificate may be directly signed by the trusted CA configured in the Mediation Server. Alternatively, a certificate chain may have to be traversed to verify the certificate provided by the gateway. The gateway must provide this chain as part of its TLS handshake with the Mediation Server.
  • The CN part of the subject field should be set to the FQDN of the gateway. If the FQDN in the CN part of the subject field does not match the expected and configured FQDN for the gateway, the certificate must also contain a subject alternate name (SAN) that lists the expected and configured FQDN for the gateway.
    The Mediation Server validates the certificate provided by the gateway by checking that the FQDN on the certificate exactly matches the gateway FQDN configured on the Mediation Server. If the FQDNs do not match, the session is terminated. Additional validation includes checking the signature and expiration date, and making sure that the certificate has not been revoked.
  • TLS link between media gateway and Mediation Server: 5060.
  • TLS link between Mediation Server and Office Communications Server pool: 5061.
  • If the SIP transport for the link between the gateway and the Mediation Server is set to TLS, separate ports must be opened for the TLS connection to the gateway and the TLS connection to the Office Communications Server pool. The port assignments should be configured as follows:
  • Each gateway must be configured so that the E.164 numbers routed by Enterprise Voice to the gateway are normalized to a locally dialable format.
  • Each gateway must also be configured to pass only E.164 numbers to the Mediation Server. For details about how to normalize source phone numbers to E.164, see each gateway vendor’s documentation.
  • Each gateway should be configured to convert the source number (the number presented as caller ID) to a normalized E.164 number. This ensures the caller ID can be matched to an Office Communicator contact, a Microsoft Office Outlook contact, or a member of the corporate directory, thereby enabling Office Communicator to provide additional information about the caller. This number will also appear in e-mail messages notifying the user of missed calls and voice mail, allowing the user to click the phone number in order to quickly return a call. If the number has been normalized by the gateway, no further processing is required. If for some reason the number cannot be normalized by the gateway, the normalization rules defined by the location profile will be applied when returning a call. It might be necessary to add normalization rules to a location profile to handle numbers that cannot be normalized by the gateway. For details about how to normalize source phone numbers to E.164, see each gateway vendor’s documentation.
  • Each gateway should also be configured to convert numbers in E.164 format into a format that will be accepted on the PSTN network. For example, when +1425xxxxxx is dialed, the gateway should strip the +1425 if the gateway is in Redmond, because these prefixes are not required for a local call.

 

Decisions to Make Before Deploying SIP Trunking

Among the many decisions to be made before deploying SIP trunking are:

  • Does a cost-benefit analysis justify the deployment of SIP trunking?
  • Who will be the SIP trunking service provider?
  • What additional hardware and software will be required?
  • What additional personnel and training will be required?
  • Will there be changes in licensing requirements?
  • Where will the SIP trunking endpoints be located?

Identifying Network or Infrastructure Requirements and Prerequisites for SIP Trunking

The principal task in deploying SIP trunking is configuring a virtual private network (VPN) to a SIP service provider. Many of the system requirements beyond the everyday requirements for the operation of Office Communications Server will be related to this task, and they will require you to work closely with the SIP trunking service provider.

 

08/10/2012 Posted by | OCS, Unified Communcation | | Leave a comment

   

%d bloggers like this: