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.