Group Chat Call Flows

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

This topic describes the call flows of a user signing in from a Group Chat client, subscribing to a chat room, and then posting a message to it. In these examples, the architecture consists of a single consolidated Group Chat Server that is in the same pool as the user.

Group Chat Client Sign In

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.

The following ladder diagram shows this call flow.

Figure 1. Group Chat client sign in call flow

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.

Subscribing to a Chat Room and Posting a Message

In this example, two users, User1 and User2, are signed in to a Channel service. User1 wants to subscribe to a new Chat Room, to which User2 is already connected, and then participates by posting a message with a file attachment.

The sequence of steps is as follows:

1. From the Group Chat client, User1 clicks Join a Chat Room, clicks Search, and then enters some search criteria. The client sends the Channel service a SIP INFO message containing the XCCOS chansrch (that is, channel search) command, along with the search criteria. The Channel service queries the back-end database and replies in a new SIP INFO message that contains a list of available channels (chat rooms) that meet the search criteria.

2. User1 selects the chat room he or she wishes to join and then clicks Join. The client sends the Channel service a SIP INFO message containing the XCCOS join command and the channel ID of the chat room the user selected. The Channel service replies with a SIP INFO message that contains the provisioning data.

3. The Group Chat client sends the Channel service a SIP INFO message that contains the XCCOS bccontext (that is, backchat context) command. The Channel service retrieves the chat history and returns it to the client in a separate SIP INFO message. At this point, the user enters the chat room and is ready to participate.

4. User1 enters a new message containing a file attachment reference and then clicks Send. The Group Chat client sends the Channel service a SIP INFO message containing the XCCOS getfutok (that is, get file upload token) command. The Channel service inserts a token into the back-end database and issues the token with the URI of the Web service instance to the client in a new SIP INFO message. This token is then used by the Group Chat client to upload the file to the URI of the Web service instance, which validates the token against the back-end database before allowing the upload to proceed. User1’s client simultaneously posts the message with the file attachment link to the chat room in a SIP INFO XCCOS grpchat command. The Channel service stores a copy of this new message in the SQL Server database.

5. The Channel service sends a separate copy of the SIP INFO XCCOS grpchat message to User2, who has already entered the chat room.

The following ladder diagram below shows the call flow.

Figure 2. Group Chat subscription and message posting call flow

See Also

Concepts

Group Chat Feature Scenario