I was recently assisting an OCS admin at another company with Live Meeting connectivity issues, during the process of which I explained how Live Meeting connectivity works for on-premises conferences (located on OCS rather than the externally hosted service). He felt like it was good info so I thought I'd share it.
As you're aware, OCS is SIP based in its communications, with the most obvious SIP client being Communicator 2007. What is not as obvious is that Live Meeting is also a SIP client. OCS delivers various pieces of necessary information via SIP, which means that the Live Meeting client must understand how to communicate with OCS over SIP to retrieve the information needed to operate. This is why if you must specify your OCS Access Edge/pool FQDN rather than your Web Conferencing Edge/internal FQDN if your Live Meeting settings are configured manually (example below).
If you think about the infrastructure considers of this for a moment you'll also realize that for users to be able to connect to Live Meetings without any configuration settings you must deploy the necessary SRV records for your pool and Access Edge, even if you have no intention of deploying IM to some or all users (this is a somewhat rare but not entirely unusual request from some customers I've worked with).
So, how does this all come together? First, the Live Meeting client (hereafter referred to as "LM") queries DNS for the appropriate SRV records of the domain it extracted from the conference location URI. An example of a conference URI is sip:email@example.com;gruu;opaque=app:conf:focus:id:1652DEC23E5AE243882614D3B42600B6. It receives an INFO message back from OCS that contains a variety of information in XML format. Among this information is the FQDN and port of the Web Conferencing Edge server:
This information is derived from the Web Conferencing properties of the pool:
After this point LM sends a SIP UPDATE message to OCS every 7 minutes to confirm connectivity. This is one of the reasons why it's important to have your firewall timeouts set properly - unexpectedly disconnecting LM sessions are a somewhat common side effect of improperly set timeout values on the firewall.