You can deploy a third-party Basic Media Gateway either before or after you deploy a Mediation Server, but whichever order you choose, these two components must be configured to function as a logical unit. For details about configuring a Mediation Server, see Configuring a Mediation Server.
The settings that you must configure on your Basic Media Gateway are specified in the following list, but for details about how to configure these settings on a given gateway, refer to the manufacturer's product documentation. For details about selecting gateways for Enterprise Voice, see in the Planning and Architecture 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 fully qualified domain name (FQDN) or IP Address of the
Mediation Server that is associated with the gateway.
- The listening port (5060) that is used for Transmission Control
Protocol (TCP) or Transport Layer Security (TLS) connections to the
Important: The previous settings mustmatch those of corresponding settings for the Mediation Server. If the settings do not match, the connection between the gateway and Mediation Server will fail.
- Session Initiation Protocol (SIP) Transport – specify either
TLS (recommended) or TCP.
Important: If you specify TLS as the SIP transport to be used by your basic or basic-hybrid media gateway, you must also configure the corresponding Mediation Server for TLS. For details about how to configure a Mediation Server for TLS, see Configuring a Mediation Server.
- 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
certification authority (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
- 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.
- The certificate may be directly signed by the trusted certification authority (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.
- You must specify the port that each gateway is listening to for
incoming SIP connections.
Note: Port 5060 is the default destination port used by the Mediation Server.
- If you configure TLS for the SIP transport link between the IP
Gateway and the Mediation Server, you must specify whether Secure
RTP (SRTP) encryption is:
- Required: SRTP should be attempted, but do not use encryption
if negotiation for SRTP is not successful.
- Optional: Attempt to negotiate the use of SRTP to secure media
packets. If SRTP cannot be negotiated, use Real-time Transport
- Not used: Send media packets using RTP.
- Required: SRTP should be attempted, but do not use encryption if negotiation for SRTP is not successful.
|All three options for SRTP are supported by the Mediation Server. Gateways from various manufacturers may not support all of these options.|
- Each gateway should be configured so that the E.164 numbers
routed by Enterprise Voice to the gateway are normalized to a
locally dialable format.
- Each gateway should be configured to pass only E.164 numbers to
the Mediation Server. Please see each gateway vendor's
documentation for specific instructions on how to normalize source
phone numbers to E.164.
- 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 a Communicator
contact, an Outlook contact, or a member of the corporate
directory, thereby enabling Communicator to provide additional
information about the caller. This number will also appear in
e-mails 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. Please see
each gateway vendor's documentation for specific instructions on
how to normalize source phone numbers to E.164.
- If you want the Mediation Server to strip the plus sign (+)
prefix from the
RequestUniform Resource Identifier (URI), the
ToURI, and the
FromURI of E.164 numbers of outgoing calls to the gateway,
set the Windows Management Instrumentation (WMI) setting called
RemovePlusFromRequestURIto TRUE (the default value is
FALSE). For details about this setting, see the "New Configuration
Options in Mediation Server" section in
in the Planning and Architecture
For a list of media gateway vendors, see Partners by Capability:
Hardware at the Microsoft Web site: