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

How to: Apply a service pack or hotfix SQL Server 2008 to a failover cluster instance

Installing Service Pack SQL Server 2008 in failover cluster is very different than the SQL Server 2005 cluster failover.

With SQL Server 2005, when you start installing cluster service pack (or hotfix), it must be launched on the active node (node that hosts the instance). When installing the Setup will launch simultaneously  “remote silence” on all passive nodes. All nodes in the cluster containing the SQL Server instance are updated in the same time.

With SQL Server 2008, to reduce the downtime, we have revised the method of deployment. Now if you want to apply a service pack (or hotfix), you must install in first on the passive nodes. The passive nodes are updated before the active node.

Therefore, for your instance SQL Server 2008  in failover cluster, you must follow the scenario below for the application of Service Pack, Cumulative Update or Hotfix :

1.  Apply the hotfix on pasive node N2
2.  Reboot the passive node N2
3.  Failover on SQL resource : the passive node become the active node
4.  Apply the hotfix on the passive node N1
5.  Reboot the passive node N1

08/10/2012 Posted by | Sql Server | , | Leave a comment

Considerations when using Outlook 2003 with Exchange 2010

1.     Common Client Access Considerations for Outlook 2003 and Exchange 2010

There are several scenarios for consideration when deploying Exchange Server 2010 into an environment where Outlook 2003 is used. Most of these scenarios have been documented prior to the product release and some applied to previous versions. However, in a review of support cases, we have found that they have not been used prior to contacting Microsoft.

This document introduces some of the scenarios and the articles that will resolve these issues. If you are planning a deployment of Exchange Server 2010, understanding client configuration, and the requirements and capabilities of your organization are of importance to the user experience.  Primarily field office environments or environments where users are not joined to the domain, profile distribution, or the ability or inability to enforce policies or distribute the solutions will dictate how you address the issue.

2.      Encryption

This is a top support issue for Outlook 2003 access to Exchange 2010.

Exchange Server 2010 introduces additional “out of the box” security for Client communications to the Exchange Server – encryption between the Client and the Server is enabled, by Default. This is RC4 encryption – where the client negotiates the encryption level based on the client operating system’s capabilities – up to 128-bit encryption.  This is documented in the following topic in TechNet online:

Understanding RPC Client Access
http://technet.microsoft.com/en-us/library/ee332317.aspx

Prior to Outlook 2007, encryption was not enabled on the Client side, by default.   However, if profiles for Outlook 2007 exist where encryption is disabled, or if Outlook 2003 profiles created with default settings are used with Exchange Server 2010, the connection will fail when Outlook attempts to connect to an Exchange Server 2010 mailbox. One or more of the following common error messages will be displayed:

  • Cannot start Microsoft Office Outlook. Unable to open the Outlook window. The set of folders could not be opened.
  • Unable to open your default e-mail folders. The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.
  • The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.
  • Unable to open your default e-mail folders. The information store could not be opened.
  • Outlook could not log on. Check to make sure you are connected to the network and are using the proper server and mailbox name. The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.

There are several methods to work around this issue, from immediate manual change by the administrator or the user, to deployment of administrative templates or new profiles.  Each of these scenarios is documented in the following article from the Microsoft Knowledge Base:

Outlook connection issues with Exchange 2010 mailboxes because of the RPC encryption requirement
http://support.microsoft.com/kb/2006508

3.      New Mail Notifications and UDP

Exchange 2010 no longer supports UDP for new mail notifications. However, Outlook 2003 relied primarily upon UDP notifications to display new messages and changes to folders. The result is that Outlook 2003 users will see delays in updates to folders and the Send/Receive process appears to take a long time.

The following article discusses the issue and two possible resolutions for the organization:

In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox
http://support.microsoft.com/kb/2009942

4.     Address Book Service (Directory Access)

Directory access has changed in the Exchange Server 2010 world. The following TechNet topic introduces the changes and is currently being updated with more information.

Understanding the Address Book Service
http://technet.microsoft.com/en-us/library/ee332346.aspx

A future topic will cover this in more detail.

5.     Public Folders, Offline Address Book and Free/Busy

Outlook 2003 uses the Public Folders free/busy messages to determine availability in the Calendar and as the source for Offline Address Book synchronization. If Public Folders are not configured during Exchange Server 2010 setup, Offline Address Book and Free/Busy will not be available to Outlook 2003 users. These users will encounter connection errors.

If free/busy Public Folders folder is not replicated to Exchange Server 2010, users will encounter the following:

Users who use Outlook 2003 cannot publish their free/busy data in Exchange Server 2010 or in Exchange Server 2007
http://support.microsoft.com/kb/945602

If clients inside the organization or connected via VPN/RAS, and the organization uses a Proxy server, the Client Access Server should be listed in the “Bypass proxy server for local addresses” configuration.

Error message when Outlook synchronizes an offline address book with Exchange Server 2007 and Exchange Server 2010: “0x8004010F”
http://support.microsoft.com/kb/939765

Also, if there are missing address book list objects or missing or incorrect address lists, the following may occur:

An error occurs when you try to synchronize the offline address list on an Exchange Server server while you are using Outlook 2003: “0x8004010F”
http://support.microsoft.com/kb/905813

6.      Opening Additional Mailboxes

Delegate Access issues, opening other user’s folders or mailboxes are a common operation in the enterprise. Outlook 2003 users may encounter issues, if the environment is not properly prepared for their use:

Office Outlook 2003 does not connect to two or more additional mailboxes in a mixed Exchange Server 2007 and Exchange Server 2010 environment
http://support.microsoft.com/kb/978777

Anerror occurs when an Exchange server 2003 user tries to open more than one delegate mailboxes of Exchange Server 2010 in Outlook 2003
http://support.microsoft.com/kb/979690

7.      RPC over HTTP Connectivity

The following article discusses issues with Outlook 2003 connectivity when the RPC proxy server extensions do not load correctly. This article also applies to Exchange Server 2010 connections.

Error message when Outlook2003 users connect to an Exchange server by using RPC over HTTP: “Server Unavailable”
http://support.microsoft.com/kb/919092

8.      Unified Communications

Integration features with Office Communicator and functionality with Office Communications Server have been documented in the following documents:

The presence information for a Communications Server user may not appear, or may appear intermittently, in Outlook 2003 Service Pack 2 or in Outlook 2007
http://support.microsoft.com/kb/968099

*Communicator does not update the free/busy information as scheduled
http://support.microsoft.com/kb/941103

*Note: This functionality is not available to Outlook 2003/Exchange Server 2003 users, as the Availability Service functionality is required for both the client and the Exchange Server. The only method to obtain this functionality is to upgrade both the client and the server(s).

08/10/2012 Posted by | Exchange server | , | Leave a comment

HOW TO: Prevent annoying spam from your own domain

One of the more annoying types of spam is the one that seems to be coming from your own domain; or worse— from your own email address! Of course, users from your own domain don’t generally spam each other— unless you’re using one of the free web-based email services. And most of us don’t spam ourselves.

Obviously, this is coming from a spammer who has spoofed your email address, or that of someone else from your domain. Unfortunately, SMTP— the protocol that allows mail clients and servers to exchange email, allows headers to be spoofed easily.

In Exchange Server 2007, Accepted Domains tell Exchange which domains to accept email for. If a domain – e12labs.com in this example, exists as an Accepted Domain, there is no reason external senders should use that domain in the MAIL or FROM headers.

You may have remote POP3/IMAP4 users who use SMTP to send mail. However, such sessions should be authenticated, and preferably use a separate Receive Connector.

Thanks to the extensive Transport Permissions model in Exchange 2007, we can easily prevent such spam. Receive Connectors have the ms-exch-smtp-accept-authoritative-domain-sender permission which dictates whether an Accepted Domain can be used in the MAIL orFROM headers. External/internet hosts submit mail to your server without authentication, as anonymous senders. To prevent anonymous senders from sending mail using your domain(s), we need to remove the ms-exch-smtp-accept-authoritative-domain-senderpermission assigned to them.

Use the following command to remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon on internet-facing Receive Connector(s):

Get-ReceiveConnector “My Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

Once this permission is removed, when anonymous senders try to submit mail using your Accepted Domain(s), here’s how the SMTP conversation goes:

220 E12Postcard.e12labs.com Microsoft ESMTP MAIL Service ready at Wed, 3 Sep 2008 06:22:43 -0700
helo
250 E12Postcard.e12labs.com Hello [172.31.0.170]
mail from:jadams@e12labs.com
550 5.7.1 Client does not have permissions to send as this sender

Exchange stopped spoofing of P1/envelope headers. Let’s continue the session and try to spoof the P2 headers (the ones in the DATA part of the message) — maybe that’ll work!

mail from:someone@someotherdomain.com
250 2.1.0 Sender OK
rcpt to:jadams@e12labs.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
from:jadams@e12labs.com
subject: Header spoofing

This is how we spoof headers, spoof headers.

.
550 5.7.1 Client does not have permissions to send as this sender
quit
221 2.0.0 Service closing transmission channel

As you can see, removing the ms-exch-smtp-accept-authoritative-domain-senderpermission stops spoofing of your domains in both envelope (P1) and message (P2) headers.

When not to remove the permission?
Is there a scenario where one should not remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon? Yes, on Receive Connectors used by internal or trusted SMTP hosts (such as copiers/scanners and application servers) that submit mail without authentication.

08/10/2012 Posted by | Exchange server | , | Leave a comment

   

%d bloggers like this: