Before users can participate in a group chat, they must sign in with the Group Chat client to a Front End Server, be authenticated by the server, and then connect to the Chat Rooms to which they have subscribed. In this example, the Lookup service and the Channel service are already running and registered with the Front End Server.
The sequence of steps is as follows:
1. The Group Chat client uses the same techniques as the Office Communicator 2007 R2 client to locate its pool server (that is, Domain Name System (DNS) SRV records in most cases and a Director referral, if used). The client uses either the user’s Windows logon credentials or manually-entered alternate credentials, and then sends a set of SIP
REGISTER messages to a Front End Server. If the user’s credentials are valid and the user is authorized to use Group Chat, he or she is authenticated.
2. The Group Chat client sends one or more SIP SUBSCRIBE messages to the Front End Server and then retrieves the user’s contact list.
3. The Group Chat client sends a SIP SERVICE message to the Front End Server to provide information about its endpoint capabilities. From this point onward (that is, in the context of Group Chat), the only function of the Front End Server is to proxy messages between the Group Chat client and one or more Group Chat Servers.
4. The Group Chat client sends a SIP INVITE message to the Uniform Resource Identifier (URI) of the Lookup service. If the client is set to use automatic configuration, this URI defaults to the name OCSChat@<user’s SIP domain>. If the organization has implemented Group Policy Object (GPO)-based configuration of the Group Chat client, it will use the URI that is provided by the Specify lookup server URI GPO policy setting. (Users can also
manually supply the URI of the Lookup service.) The Front End Server looks in its registration database and proxies the INVITE message to all Lookup service instances that are registered with it. In this example, there is only one. The INVITE sequence is followed up by the 200 OK and ACK, and the Group Chat client has now opened a SIP session with a Lookup service endpoint.
5. The Group Chat client sends a SIP INFO message containing the XCCOS requri (that is, request URI) command to the Lookup service, which queries the back-end database and returns the URI of the Channel service with the lowest current workload. When the client receives the URI, it sends a SIP BYE message and closes the session with the Lookup service.
6. The Group Chat client sends a SIP INVITE message to the URI of the Channel service that it obtained in the previous step. The INVITE sequence is followed by 200 OK and ACK, and the Group Chat client has now opened a SIP session with a Channel service endpoint. From this point forward, the client communicates with the Channel service by sending SIP INFO messages that contain either chat messages or commands requesting the server to take an action. All of these messages are acknowledged with either 200 OK or 503 Service Unavailable (that is, in the event of heavy server load). If the client receives a 503 response, it will retry the message. (This example does not include a 503 response.) If the server accepts the message or command and sends 200 OK, it will provide a response to the client in the form of a separate SIP INFO message. This response includes a reference to the originating command.
7. The Group Chat client sends a SIP INFO message containing the XCCOS getserverinfo command. The Channel service replies with a new SIP INFO message containing information about the Channel service configuration.
8. The Group Chat client sends a SIP INFO message containing a set of XCCOS getpref (that is, get preferences) commands. The client stores its state on the server in a set of compressed XML documents called preferences. The getpref command is a request from the client to the server for the latest copy of that data. If the client has a local copy of the
preferences, it sends the version ID of the local copy in the command. The server responds to this command in a separate SIP INFO message with the requested data.
9. The Group Chat client sends a SIP INFO message containing a XCCOS bjoin (that is, batch join) command that contains a list of chat rooms that the user has previously joined. This list is obtained from the preferences document. The Channel service queries the back- end database, and then returns a separate SIP INFO message containing the user’s channel provisioning data and the contextual message history for those chat rooms.
10. The Group Chat client sends a SIP INFO message containing a XCCOS getinv (that is, get invitation) command to request any open channel invitations. In a separate SIP INFO message, the Channel service returns a list of those channels.
Note:
Messages from the Group Chat Server to the client are often batched. A single SIP INFO message can contain one or more messages. For example, in the case of a batch join (that is, bjoin) command, the server sends bjoin replies and contextual message history for each chat room that is being joined. But these messages may be delivered to the client as a single SIP INFO message or as multiple SIP INFO messages.
After the user of a Group Chat client is signed in and connected to a Channel service, his or her client lists the message history of all currently subscribed chat rooms.
If the user’s Office Communications Server account was homed in pool different from that of the Group Chat Server pool, a Front End Server in the user’s home pool would proxy the messages to and from a Front End Server in the pool with which the Channel service is homed.