It seems to be a day for writing about auto-discovery, the process whereby an application, in this case Microsoft Office Communicator (MOC), can use a limited amount of information to automatically discover the users’s OCS Server. Auto-discovery is based on MOC’s use of DNS resource records to obtain the necessary information. I’ve been reading the formal published specificatin in the absence of bed-time cocoa. Note that this mechanism is used by a MOC client to find an OCS server, and is different from Exchange’s auto-discovery service that enables Outlook to find an Exchange server. The OCS mechanism is simple and easy, while the Exchange service is more complex.

Using auto-discovery, MOC first obtains what the specificatin calls the Address-of-Record, aka the SIP URI. This could be something like sip:tfl@gktrain.net. From the AOR, MOC needs to determine a target domain (the spec just calls this domain). In this case, gktrain.net is the target domain.

The SIP URI has to obtained through user input. The user inputs his SIP URI (minus the “SIP:” scheme id, as well as AD credentials (in most cases these are the same, a UPN such as tfl@gktrain.net).

For fun, here’s a PowerShell script to get and display the target domain from the AOR

 

# Get-DomainFromAor.ps1
# gets the domain from the AOR and displays result
# Thomas Lee - tfl@psp.co.uk


# Specfy an AOR
$AOR = "sip:tfl@gktrain.net"

# Get target domain
$domain = ($aor.split("@"))[1]

# Display results
"AOR           : {0}" -f $aor
"Target Domain : {0}" -f $domain
				

 


Having discovered the target domain, MOC’s auto-discovery then synthesises a series of DNS queries, and sends these to the local DNS server – one at a time until a successful query result is obtained (or not). If a query is successful, then the information in that query is used to find the user’s OCS server. If no query is successful MOC can log the user in.

As an alternative to auto-discovery, of course, the user can enter the server details manually. In that case, MOC used the manually entered information and does not attempt auto-discovery. To simplify the user experience, and reduce support costs, you should implement DNS-based auto-discovery.

 

There are two types of synthetic DNS queries that are used by MOC: synthetic SRV record queries and synthetic A record queries. Synthetic SRV records search for an SRV resource record that in turn points to the A record. Together the SRV and associated A record specify the IP address and port number that MOC uses to connect to an OCS Server for the target domain. Synthetic A record queries look for an A record that has the IP address of an OCS Server. MOC uses this address, plus a specific per-query port number to attempt the connection to an OCS Server for the target domain.

 

The MOC auto-discovery mechanism attempts the SRV queries first, and the A record queries next in an attempt to find an OCS Server. For clients conneting inside the organisation, the discovery should take just one query (and response). For external clients, e.g. connecting from the internet via OCS Edge services, there will be more.

 

The specific order that queries are conduced are as described below.

 

Order of Synthetic DNS queries
As noted, Synthetic SRV queries are attempted first. If these are not successful, the synthetic A record queries are used. Here is the order:

(SRV Queries first)

 

 

 

  • _SipInternalTLS._tcp.<target domain>
     

    If this query is successful, DNS returns one or more SRV resource each with an associated A record. MOC uses the first SRV record, and it’s associated A record. Both DNS round robin and SRV Record priority settings are be used to semi-randomise or to bias the order the SRV records are used. 
    MOC takes the host name and port contained in the returned SRV record and the IP address specified in the associated A record to attempt to negotiate a SIP over TLS (over TCP) connection with OCS.

  • _SipInternal._tcp.<target domain>  

    If this query is successful, DNS returns one or more SRV records and an associated A records MOC uses the host name and port contained in the the SRV record and the IP address specified in the associated A record.MOC uses the first SRV record, and it’s associated A record.Both DNS round robin and SRV Record priority settings are be used to semi-randomise or to bias the order the SRV records are used. MOC takes the host name and port contained in the returned SRV record and the IP address specified in the associated A record to attempt to negotiate a SIP over TCP (i.e. insecure) connection with OCS.

  • _Sip._tls.<target domain>   

    If this query is successful, then the steps shown for query 1 above are taken and a TLS connection is attempted.

  • _sip._tcp.<target domain>  

    If this query is successful, then the steps shown for query 2 above are taken and a TCP connection is attempted.

    (A Record Queries next)

  • _sipinternal.<target domain>:443 

    If this query is successful, then the MOC Client attempts a TLS connection to the IP Address specified in the returned A record, over port 443. 

  • _sipinternal.<target domain> 

    If this query is successful, then the MOC Client attempts a TCP connection to the IP Address specified in the returned A record. NB: The formal spec does not specify a port number, but it is believed the connection attempted is over port 5060. Cites pro/con  and corrections are most welcome.

  • sip.<target domain>:443 

    If this query is successful, then the MOC Client attempts a TLS connection as per query 5.

  • sip.<target domain> 

    If this query is successful, then the MOC Client attempts a TCP connection as noted in query 6 (with same note).

  • sipexternal.<target domain>:443 

    If this query is successful, then the MOC Client attempts a TLS connection as per query 5.

  • sipexternal.<target domain>And just when your head explodes, there’s a bit more. Since DNS response times are not predictable, and DNS responses are not reliable, the auto discover mechanism does a bit more than just try these in order.

     

    As I noted, the client first tries to complete the SRV record queries. The client uses the queries in the order shown above to attempt to construct a list of candidate servers and once this list is complete, it begins attempting a connection. If queries 1 and 3 (TLS) above are completed and are successful before query 2 (TCP), then the client adds the  TLS entries from both queries and ignores the TCP entries.  If query 2 completes first, MOC waits till query 1 and 3 complete before moving on.

     

    One potential security risk is DNS Poisoning, for example by a hacker returning a ‘bad’ SRV record (ie pointing to a rogue server). The MOC client ignores responses whose domain/subdomain is different from the calculated domain. Thus if a query returned an record pointing to a server called ocs.fakedomain.com MOC would ignore it.

     

    After getting the results of the SRV queries, the client will move on to the A record queries. As a general rule, SRV records are used for internal clients, while A records are used for external clients. BUT: given this is DNS, you can use some, any or all of these various records as you choose (or indeed none of them and use manual configuration).

     

    A final note for larger enterprises. If you have a large enterprise, you may have multiple pools and therefore multiple SRV or A records are returned. In this case, MOC’s list of servers to try are dictated by the order the RR’s are returned and the first record might be a valid OCS server, but the user is not homed on that server. OCS handles this via the director function and can re-direct the client to the users’s correct home server. The director function is separate and independent to the auto-discover mechanism

     

    Best Practices

     

    The best practices I can recommend are:

     

     

    • Keep it simple, and just use the minimum of DNS records. There’s not need to populate ALL these A records for MOC auto-discovery.

       

    • For internal clients, the only SRV record you need is  _SipInternalTLS._TCP.<target domain>. Set the port in the SRV record to 5061 and the host record to the FQDN of your OCS Server.

       

    • For external DNS, just use SipExternal.<target domain> and ensure that your edge servers and firewalls open up just port 443.

       

    • Where possible, avoid the use of SIP over TCP. If you are considering using SIP over TCP, consider the security implications very carefully.

       

    • Remember that other components of OCS (e.g. the DVT) may require different records to work properly (I’ll blog about this more, when I get a chance).

       

     

    Troubleshooting

     

    Troubleshooting OCS auto-discovery is for the most part simple – ensure you have the correct records are in DNS and that these are properly configured.

     

    Some things to look out for:

     

     

    • Assuming you follow best practice, can you resolve _sipinternaltls._tcp.<target domain>.

       

    • Is the sip target domain actually spelt correct in the AOR (eg tfl@gktwain.com vs tfl@gktrain.com)

       

    • In the SRV records, is the port number correct (5061 for TLS, 5060 for TCP).

       

    • In the SRV records, is the name of the host correctly shown (OCS-STB.Gktrain.NET vs OCS-STD.GKtrain.Net).

       

    • Does the SRV’s host name point to an A record that exists.

       

    • Make sure you have at least some records – preferably following recommended best practices!

       

     

    You can use the client’s event log to see failed DNS queries – this shows AOR problems when you see a lot of records missing in the event log. It can also mean that the SRV records are missing or incorrectly specified.

     

    If I get the time, I might try to write a PowerShell script to construct the synthetic queries, execute them and report on what’s found. Had enough yet? 🙂

     

(Borrowed from a post by Thomas Lee: http://tfl09.blogspot.com/)

These are copied from the ArchivingCDRReporter read me…
The following are some user specific SQL query samples that are intended to guide you through extracting relevant reporting user or time range specific information from the Archiving/CDR Database. The general usage queries are already added as part of the tool.

Read More →

The OCS 2007 Address Book service’s primary purpose is to provide updated GAL information to the OC 2007 client. It will also provide phone number normalization service for OC 2007 clients. The ABServer.exe is scheduled to query AD periodically for updates to user / group /information and provide this delta of updated information to the AddressBook share as .dabs files. After the initial installation and at 1:30 AM every day after that ABServer.exe will provide a full update to the AddressBook share with a lsabs file.
Read More →

The OCS 2007 Client Version filter can be a bit confusing as to how to filter clients. I’ve run into this issue twice now, so I thought I’d share my experience and dive into this a little deeper. TechNet has an explanation of how to configure the Client Version filter, but there are quite a few things they left out.
http://technet.microsoft.com/en-us/library/bb936607.aspx

Read More →

There is some debate in the industry about bandwidth requirements for Microsoft’s RTAudio and RTVideo codec used in Office Communication Server 2007. This is a very good description of the actually requirements for planning purposes.

The short answer is that you should plan 57 Kbps for Audio and 320 Kbps for Video. The QoE document lists 45 Kbps for RTA-WB, but that does not include Ethernet or SRTP overhead.

Read More →