Secured, SIP Secured and Unsecured Voice integration Exchange
In Exchange 2007/ 2010/ 2013, you are able to set different security configuration for your SIP Traffic.
Therefore special configuration between Gateway, Lync (via Exchange Dial Plans) and Server-to-Server Communication can be defined.
Let talk about Exchange 2013 and Lync 2013 UM integration, especially for your configuration in your live environment.
With
Exchange Administration Center (EAC) or the Set-UMDialPlan cmdlet in PowerShell you can define your SIP Security configuration.
When you configure the UM dial
plan to use SIP secured* (
[-VoIPSecurity <SIPSecured | Unsecured | Secured>])
or Secured mode, Client Access and Mailbox servers will encrypt the SIP
signaling traffic or the RTP media channels or both. For Lync, you need the special SIP Secured Mode (described below)
VoIP security mode, can be configured as:
-
SIP secured
(SIP Secured setting only protect SIP traffic using TLS while RTP traffic would be transmitted over TCP)
(SIP Secured setting only protect SIP traffic using TLS while RTP traffic would be transmitted over TCP)
- Secured
(SIP Signaling and Media traffic via TLS – properly for Exchange and Lync communication)
(SIP Signaling and Media traffic via TLS – properly for Exchange and Lync communication)
-
Unsecured (default)
(no encryption)
(no encryption)
*) The VoIPSecurity parameter in Exchange Dial Plan specifies
whether the signaling channel is encrypted using mutual Transport Layer Security
(TLS). The default setting is Unsecured.
Secure SIP is defined by SIP RFC 3261, a
security mechanism defined for sending SIP messages over a Transport Layer
Security-encrypted channel. It was originally used for securing HTTP sessions;
Transport Layer Security (TLS) can be used to protect SIP session
communications from eavesdropping or tampering.
Certificates:
If you configure SIP traffic with in
Exchange only, chosen certificates can be self-signed certificates in Exchange,
if any other server, like Lync is involved for this Dial Plans, you need to
ensure that a trusted root authority is used. This could be managed with an
internal Enterprise Certificate Authority.
Author: Thomas Pött Managing Consultant Microsoft UC
Comments
Post a Comment