Redirects
The main advantage to a Director for internal
users is to provide the user’s primary and backup registrar
information. This way, a client knows exactly which server to contact
next if it is unable to contact the primary server. This information
can be viewed within the SipStack traces of a sign-in. After the client
authenticates, the Director responds with a 301 Redirect message, and
informs the client of the primary and backup registrar. This first
sample sign-in shows a user attempting a registration to the Director:
Start-Line: SIP/2.0 301 Redirect request to Home Server
From: <sip:[email protected]>;tag=45a7e6cf7b;epid=9671160f70
To: <sip:[email protected]>;tag=CED5D09DABBD634B55450D19A37449C4
CSeq: 2 REGISTER
Call-ID: e126d3d70dc44b81a5c41a610abd273f
Proxy-Authentication-Info:
Kerberos qop="auth", opaque="7D22174B", srand="4F219DA8", snum="1",
rspauth="040401ffffffffff0000000000000000f3ad4a4a3e15044bcae0f914",
targetname="sip/DIR1-SF.companyabc.com", realm="SIP Communications
Service", version=4
Via: SIP/2.0/TLS 192.168.1.100:50350;ms-received-port=50350;ms-received-cid=400
Contact: <sip:SBS1-NY.companyabc.com:5061;transport=TLS>;q=0.7
Contact: <sip:FEPOOL-SF.companyabc.com:5061;transport=TLS>;q=0.3
Notice how the Contact field within the SIP message is used to relay the primary and backup registrar. The q= values indicate the preferred weight of the server, so in this case SBS1-NY.companyabc.com is considered the primary registrar and FEPOOL-SF.companyabc.com is the backup.
Note
It’s possible to have SRV records that point
directly to a Front End server, but keep in mind that backup registrar
information is not passed to clients if they sign in directly to their
own primary registrar. This doesn’t prevent a client from finding
another server through the use of weighted SRV records, but it might
take longer to fail over when the primary registrar is offline.
Certificates
Incorrectly issued certificates are a
potential problem with Director configuration. Be sure to follow the
guidelines outlined here to rule out any certificate issues:
• Subject Name—Ensure that the subject name matches the fully qualified name of the pool.
• Subject Alternative Names—A
Director’s SAN field must contain the server name, and any supported
SIP domains in the sip.<SIP Domain> format. Additionally, it must
include the simple URLs for dialin, meet, lyncdiscover, and admin.
• Key Bit Length—The certificate bit length must be 1024, 2048, or 4096 to be supported by Lync Server 2013.
• Template—The
template used to issue the certificate should be based on the web
server template. If the Lync Server 2013 certificate wizard is used,
the correct template will automatically be applied.
• Private Key—The
server certificate must have the private key associated to be used by
Lync Server 2013. In situations where certificates are exported or
copied between servers, be sure to export the private key with the
certificate.
• Certificate Chain—The
Director must be able to verify each certificate up to a Trusted Root
Certification Authority. Additionally, because the server is presenting
the certificate to clients, it must contain each intermediate
certificate in the certificate chain.
• Certificate Store—All
certificates used by the Director must be in the Personal section of
the local computer certificate store. A common mistake is to place
certificates in the Personal section of the user account certificate
store.
• Certificate Trust—Be
sure that the clients and servers communicating with the Director all
contain a copy of the top-level certificate authority of the chain in
their Trusted Root Certification Authority local computer store. When
the certification authority is integrated with Active Directory, this
is generally not an issue, but when an offline or nonintegrated
certificate authority is used, it might be necessary to install root
certificates on clients and servers.
