Deployment Guide for IM and Presence Service on Cisco Unified Communications Manager, Release 9.0(1)
Chat configuration on IM and Presence
Downloads: This chapterpdf (PDF - 1.28MB) The complete bookPDF (PDF - 6.21MB) | The complete bookePub (ePub - 1.26MB) | Feedback

Chat Configuration on IM and Presence Service

Chat Configuration on IM and Presence Service

About chat

Chat

Point-to-point Instant Messaging (IM) supports real-time conversations between two users at a time. IM and Presence Service exchanges messages directly between users, from the sender to the recipient. Users must be online in their IM clients to exchange point-to-point IMs.

You can disable both the chat and availability functionality on IM and Presence Service.

IM Forking

When a user sends an IM to a contact who is signed in to multiple IM clients. IM and Presence Service delivers the IM to each client. This functionality is called IM forking. IM and Presence Service continues to fork IMs to each client, until the contact replies. Once the contact replies, IM and Presence Service only delivers IMs to the client on which the contact replied.

You can disable offline instant messaging on IM and Presence Service.

Offline IM

Offline IM is the ability to send IMs to a contact when they are offline. When a user sends an IM to an offline contact, IM and Presence Service stores the IM and delivers the IM when the offline contact signs in to an IM client.

Broadcast IM

Broadcast IM is the ability to send an IM to multiple contacts at the same time, for example, a user wants to send a notification to a large group of contacts. Note that not all IM clients support this feature.

Chat Rooms on IM and Presence Service

IM and Presence Service supports IM exchange in both ad-hoc chat rooms and persistent chat rooms. By default, the Text Conference (TC) component on IM and Presence Service is set up and configured to handle IM exchange in ad-hoc chat rooms. There are additional requirements you must configure to support persistent chat rooms, described further in this module.

Ad-hoc chat rooms are IM sessions that remain in existence only as long as one person is still connected to the chat room, and are deleted from the system when the last user leaves the room. Records of the IM conversation are not maintained permanently.

Persistent chat rooms are group chat sessions that remain in existence even when all users have left the room and do not terminate like ad hoc group chat sessions. The intent is that users will return to persistent chat rooms over time to collaborate and share knowledge of a specific topic, search through archives of what was said on that topic (if this feature is enabled on IM and Presence Service), and then participate in the discussion of that topic in real-time.

The TC component on IM and Presence Service enables users to:

  • create new rooms, and manage members and configurations of the rooms they create.
  • invite other users to rooms.
  • determine the presence status of the members displayed within the room. The presence status displayed in a room confirms the attendance of the member in a room but may not reflect their overall presence status.

In addition, the Persistent Chat feature on IM and Presence Service allows users to:

  • search for and join existing chat rooms.
  • store a transcript of the chat and make the message history available for searching.

Chat Room Limits

The following table lists the chat room limits for IM and Presence Service.

Table 1 Chat Room Limits for IM and Presence Service

Number Of...

Maximum

Persistent chat rooms per node

1500 rooms

Total rooms per node (ad-hoc and persistent)

16500 rooms

Occupants per room

1000 occupants

Messages retrieved from the archive

This is the max number of messages that are returned when a user queries the room history.

100 messages

Messages in chat history displayed by default

This is the number of messages that are displayed when a user joins a chat room.

15 messages

File Transfer

IM and Presence Service supports point to point file transfer between XMPP clients compliant with XEP 096 (http:/​/​xmpp.org/​extensions/​xep-0096.html).

Related Tasks

Important Notes About IM and Presence Service and Chat

For SIP to SIP IM, the following services must be running on IM and Presence Service:

  • Cisco SIP Proxy
  • Cisco Presence Engine
  • Cisco XCP Router

For SIP to XMPP IM, the following services must be running on IM and Presence Service:

  • Cisco SIP Proxy
  • Cisco Presence Engine
  • Cisco XCP Router
  • Cisco XCP Text Conference Manager

Chat Administration Settings

Change IM Gateway Settings

You can configure IM Gateway settings for IM and Presence Service.

The SIP-to-XMPP connection on the IM and Presence Service IM Gateway is enabled by default. This allows IM interoperability between SIP and XMPP clients so that users of SIP IM clients can exchange bi-directional IMs with users of XMPP IM clients. Cisco recommends that you leave the IM Gateway Status parameter on; however, you can turn off the IM Gateway Status parameter to prevent XMPP and SIP clients from communicating with each other.

You can also change the default inactive timeout interval of IM conversations, as well as select the error message that gets displayed if the IM fails to get delivered.

Restriction

SIP clients cannot participate in chat rooms because this is an XMPP-specific feature.

Procedure
    Step 1   Choose Cisco Unified CM IM and Presence Administration > System > Service Parameters.
    Step 2   Choose an IM and Presence Service node from the Server menu.
    Step 3   Choose Cisco SIP Proxy as the service on the Service Parameter Configuration window.
    Step 4   Do one of the following actions:
    1. Set IM Gateway Status to On in the SIP XMPP IM Gateway (Clusterwide) section to enable this feature.
    2. Set IM Gateway Status to Off in the SIP XMPP IM Gateway (Clusterwide) section to disable this feature.
    Step 5   Set the Inactive Timeout interval (in seconds) of IM conversations maintained by the gateway. The default setting is 600 seconds, which is appropriate to most environments.
    Step 6   Specify the error message that you want users to see if the IM fails to deliver. Default error message: Your IM could not be delivered.
    Step 7   Click Save.

    What to Do Next

    Proceed to configure the persistent chat room settings.

    Enable File Transfer

    Administrators can enable or disable IM and Presence Service node support for file transfer capability (XEP-0096). Enabling file transfer support allows XMPP clients to extend file transfer capabilities to end users.


    Note


    File transfer between a local user and an intercluster peer contact is only possible if both clusters have the feature enabled.


    Procedure
      Step 1   Choose Cisco Unified CM IM and Presence Administration > System > Service Parameters.
      Step 2   From the Server menu, choose an IM and Presence Service node .
      Step 3   In the Service Parameter Configuration window, choose Cisco XCP Router as the service.
      Step 4   From the Enable file transfer drop-down list, click On or Off.
      Step 5   Click Save.
      Step 6   Restart the Cisco XCP Router Service on every node in the cluster.

      Limit Number Of Sign-In Sessions

      Administrators can limit the number of sign-in sessions per user on the Cisco XCP Router. This parameter is applicable to XMPP clients only.

      Procedure
        Step 1   Choose Cisco Unified CM IM and Presence Administration > System > Service Parameters.
        Step 2   Choose an IM and Presence Service node from the Server menu.
        Step 3   Choose Cisco XCP Router as the service in the Service Parameter Configuration window.
        Step 4   Enter a parameter value in the Maximum number of logon sessions per user in the XCP Manager Configuration Parameters (Clusterwide) area.
        Step 5   Click Save.
        Step 6   Restart the Cisco XCP Router Service.

        Chat Node Alias Management

        Chat Node Aliases

        Aliases create a unique address for each chat node so that users (in any domain) can search for specific chat rooms on specific nodes, and join chat in those rooms. Each chat node in a system must have a unique alias.


        Note


        This chat node alias, conference-3-mycup.cisco.com, for example, will form part of the unique ID for each chat room created on that node, roomjid@conference-3-mycup.cisco.com


        You can assign your aliases cluster-wide, in these ways:

        • System-generated - allows the system to automatically assign a unique alias to each chat node.You do not have do to anything further to address your chat node if you enable the system-generated aliases. The system will auto-generate one alias per chat node by default using the following naming convention: conference-x-clusterid.domain, where:
          • conference - is a hardcoded keyword
          • x- is the unique integer value that denotes the node ID
          • Example: conference-3-mycup.cisco.com
        • Manually - You may choose to override the default system-generated alias if the conference-x-clusterid.domain naming convention does not suit your customer deployment, for example, if you do not want to include the Cluster ID in your chat node alias. With manually-managed aliases, you have complete flexibility to name chat nodes using aliases that suit your specific requirements.
        • Additional Aliases - You can associate more than one alias with each chat node on a per-node basis. Multiple aliases per node allows users to create additional chat rooms using these aliases. This applies whether you assign a system-generated alias or manage your aliases manually.

        Key Considerations

        Changing chat node aliases can make the chat rooms in the database unaddressable and prevent your users from finding existing chat rooms.

        Note these results before you change the constituent parts of aliases or other node dependencies:

        • Cluster ID - This value is part of the fully qualified cluster name (FQDN). Changing the Cluster ID (choose System > Cluster Topology: Settings) causes the FQDN to incorporate the new value and the system-managed alias to automatically change across the cluster. For manually-managed aliases, it is the responsibility of the Administrator to manually update the alias list if the Cluster ID changes.
        • Domain - This value is part of the FQDN. Changing the Domain (choose Presence > Presence Settings) causes the FQDN to incorporate the new value and the system-managed alias to automatically change across the cluster. For manually-managed aliases, it is the responsibility of the Administrator to manually update the alias list if the Domain changes.
        • Connection between the chat node and external database - The chat node will not start if persistent chat is enabled and you do not maintain the correct connection with the external database.
        • Deletion of a chat node - If you delete a node associated with an existing alias from the Cluster Topology, chat rooms created using the old alias may not be addressable unless you take further action.

        We recommend that you do not change existing aliases without considering the wider implications of your changes, namely:

        • Make sure that you maintain the address of old chat nodes in the database so that users can locate existing chat rooms via the old alias, if required
        • If there is federation with external domains, you may need to publish the aliases in DNS to inform the users in those domains that the aliases have changed and new addresses are available. This depends on whether or not you want to advertise all aliases externally.

        Turn On or Off System-Generated Chat Node Aliases

        Chat node aliases allow users in any domain to search for specific chat rooms on specific nodes, and join in those chat rooms. IM and Presence Service automatically assign a unique, system-generated alias to each chat node by default. No further configuration is needed to address your chat node when system-generated aliases are used. The system automatically generates one alias per chat node using the default naming convention conference-x-clusterid.domain.

        If you want to manually assign chat node aliases, you must turn off the default system-generated alias setting. If you turn off a system-generated alias, the existing alias (conference-x-clusterid.domain) reverts to a standard, editable alias listed under Conference Server Aliases. See topics related to manually managed chat node aliases for more information. For best practice guidelines, see the sample chat deployment scenarios

        Before You Begin
        • Review the topics about chat node aliases and key considerations.
        • You cannot edit or delete a system-generated alias, for example, conference-3-mycup.cisco.com.
        Procedure
          Step 1   Choose Cisco Unified CM IM and Presence Administration > Messaging > Group Chat and Persistent Chat.
          Step 2   Enable or disable system-generated aliases:
          1. To enable the system to automatically assign chat room aliases to nodes using the naming convention conference-x-clusterid.domain, check System Automatically Manages Primary Group Chat Server Aliases
            Tip   

            Choose Messaging > Group Chat Server Alias Mapping to verify that the system-generated alias is listed under Primary Group Chat Server Aliases.

          2. To disable system-generated aliases, uncheck System Automatically Manages Primary Group Chat Server Aliases.
          Step 3   The Number of messages in chat history displayed for new conference participants setting controls the number of instant messages from the recent message history that IM and Presence Service pushes to the client application of a user when that user joins a chat room. Increase this number if you want to display more text message history to users.

          What to Do Next

          • Even if you configure a system-generated alias for a chat node, you can associate more than one alias with the node if required.
          • If you are federating with external domains, you may want to inform federated parties that the aliases have changed and new aliases are available. To advertise all aliases externally, configure DNS and publish the aliases as DNS records.
          • If you update any of the system-generated alias configuration, perform one of these actions:
          • Restart the Cisco XCP Text Conference Manager. Choose Cisco Unified IM and Presence Serviceability > Tools > Control Center - Feature Services to restart this service
          • The Number of messages in chat history displayed for new chat participants setting updates dynamically; You do not need to restart the Cisco XCP Text Conference Manager service.

          Manage Chat Node Aliases Manually

          You can manually add, edit, or delete chat node aliases. To manually manage chat node aliases, you must turn off the default setting, which uses system-generated aliases. If you turn off a system-generated alias, the existing alias (conference-x-clusterid.domain) reverts to a standard, editable alias listed under Conference Server Aliases. This maintains the old alias and the chat room addresses associated with that alias.

          You can manually assign multiple aliases to chat nodes. Even if a system-generated alias already exists for a chat node, you can associate additional aliases to the node manually.

          For manually-managed aliases, it is the responsibility of the Administrator to manually update the alias list if the Cluster ID or Domain changes. System-generated aliases will incorporate the changed values automatically.


          Note


          Although it is not mandatory, Cisco recommends that you always include the Domain when you assign a new chat node alias to a node. Use this convention for additional aliases, newalias.domain. Choose System > Cluster Topology: Settings in Cisco Unified CM IM and Presence Administration to see the Domain.


          Before You Begin

          Review topics related to chat node aliases and key considerations.

          Procedure
            Step 1   Choose Cisco Unified CM IM and Presence Administration > Messaging > Group Chat and Persistent Chat.
            Step 2   Uncheck System Automatically Manages Primary Group Chat Server Aliases.
            Step 3   All the existing chat node aliases are listed together under Group Chat Server Aliases. To view the alias list, perform these actions:
            1. Choose Messaging > Group Chat Server Alias Mapping.
            2. Click Find.
            Step 4   Complete one or more of the following actions as required: Edit an existing alias (old system-generated or user-defined alias)
            1. Click the hyperlink for any existing alias that you want to edit.
            2. Edit the alias for the node in the Group Chat Server Alias field. Make sure the alias is unique for the node.
            3. Choose the appropriate node to which you want to assign this changed alias.
            Add a new chat node alias
            1. Click Add New.
            2. Enter a unique alias for the node in the Group Chat Server Alias field.
            3. Choose the appropriate node to which you want to assign the new alias.
            Delete an existing alias
            1. Check the check box for the alias that you want to delete.
            2. Click Delete Selected.

            Troubleshooting Tips

            • Every chat node alias must be unique. The system will prevent you from creating duplicate chat node aliases across the cluster.
            • A chat node alias name cannot match the IM and Presence domain name.
            • Delete old aliases only if you no longer need to maintain the address of chat rooms via the old alias.
            • If you are federating with external domains, you may want to inform federated parties that the aliases have changed and new aliases are available. To advertise all aliases externally, configure DNS and publish the aliases as DNS records.
            • If you update any of the chat node alias configuration, restart the Cisco XCP Text Conference Manager.

            What to Do Next

            • Proceed to turn on the Cisco XCP Text Conference Manager.

            Turn on Cisco XCP Text Conference Manager

            This procedure applies if you configure the persistent chat room settings, or manually add one or more aliases to a chat node. You must also turn on this service if you want to enable ad-hoc chat on a node.

            Before You Begin

            If persistent chat is enabled, an external database must be associated with the Text Conference Manager service, and the database must be active and reachable or the Text Conference Manager will not start. If the connection with the external database fails after the Text Conference Manager service has started, the Text Conference Manager service will remain active and functional, however, messages will no longer be persisted to database and new persistent rooms cannot be created until the connection recovers.

            Procedure
              Step 1   Choose Cisco Unified IM and Presence Serviceability > Tools > Service Activation.
              Step 2   Choose the chat node from the Server menu.
              Step 3   Click the Cisco XCP Text Conference Manager service to turn it on.
              Step 4   Click Save.

              Chat Deployments

              You can set up chat for different deployment scenarios. Sample deployment scenarios are available.

              Chat Deployment Scenario 1

              Deployment Scenario:

              You do not want to include the Cluster ID in the chat node alias. Instead of the system-generated alias conference-1-mycup.cisco.com, you want to use the alias primary-conf-server.cisco.com.

              Configuration Steps:

              1. Choose Messaging > Group Chat and Persistent Chat Messagingto turn off the system-generated alias. (This is on by default).
              2. Edit the alias and change it to primary-conf-server.cisco.com.

              Notes:

              When you turn off the old system-generated alias, conference-1-mycup.cisco.com reverts to a standard, editable alias listed under Group Chat Server Aliases. This maintains the old alias and the chat room addresses associated with that alias.

              Chat Deployment Scenario 2

              Deployment Scenario:

              You want to:

              • change the Domain from cisco.com to linksys.com and use conference-1-mycup.linksys.com instead of conference-1-mycup.cisco.com.
              • maintain the address of existing persistent chat rooms in the database so that users can still find old chat rooms of type xxx@conference-1-mycup.cisco.com.

              Configuration Steps:

              1. Choose Cisco Unified CM IM and Presence Administration > System > Cluster Topology > Settings.
              2. See Cluster topology configuration on IM and Presence, for steps on how to "Edit the Domain" and change it to linksys.com.

              Notes:

              When you change the domain, the fully qualified cluster name (FQDN) automatically changes from conference-1-mycup.cisco.com to conference-1-mycup.linksys.com. The old system-generated alias conference-1-mycup.cisco.com reverts to a standard, editable alias listed under Group Chat Server Aliases. This maintains the old alias and the chat room addresses associated with that alias.

              Chat Deployment Scenario 3

              Deployment Scenario:

              You:

              • want to change the Cluster ID from mycup to ireland to use conference-1-ireland.cisco.com instead of conference-1-mycup.cisco.com.
              • do not need to maintain the address of existing persistent chat rooms in the database.

              Configuration Steps:

              1. Choose Cisco Unified CM IM and Presence Administration > System > Cluster Topology > Settings.
              2. Edit the Cluster ID and change it to ireland.
              3. Choose Messaging > Group Chat Server Alias Mapping.
              4. Delete the old alias conference-1-mycup.cisco.com.

              Notes:

              When you change the Cluster ID, the fully qualified cluster name (FQDN) automatically changes from conference-1-mycup.cisco.com to conference-1-ireland.cisco.com. The old system-generated alias conference-1-mycup.cisco.com reverts to a standard, editable alias listed under Group Chat Server Aliases. This maintains the old alias and the chat room addresses associated with that alias. Because (in this example) the Administrator has no need to maintain the old alias address, it is appropriate to delete it.

              Chat Deployment Scenario 4

              Deployment Scenario:

              You want to:

              • change the Cluster ID from mycup to ireland to use conference-1-ireland.cisco.com instead of conference-1-mycup.cisco.com.
              • only maintain chat room addressing via the old alias (does not need to associate nodes with the new system-generated alias).

              Configuration Steps:

              1. Choose Cisco Unified CM IM and Presence Administration > System > Cluster Topology > Settings.
              2. Edit the Cluster ID and change it to ireland.
              3. Choose Messaging > Group Chat and Persistent Chat and turn off the new system-generated alias, conference-1-ireland.cisco.com. (This is on by default).
              4. Choose Messaging > Group Chat Server Alias Mapping.
              5. Deletes the new alias conference-1-ireland.cisco.com.

              Notes:

              When you change the Cluster ID, the fully qualified cluster name (FQDN) automatically changes from conference-1-mycup.cisco.com to conference-1-ireland.cisco.com. When you turn off the new system-generated alias, conference-1-ireland.cisco.com reverts to a standard, editable alias listed under Group Chat Server Aliases. Because (in this example) the Administrator has no need to maintain the new alias address, it is appropriate to delete it. The old system-generated alias conference-1-mycup.cisco.com reverts to a standard, editable alias listed under Group Chat Server Aliases. This maintains the old alias and the chat room addresses associated with that alias.

              Chat Deployment Scenario 5

              Deployment Scenario:

              You want to:

              • delete a node associated with an existing alias from the System Topology, for example, conference-3-mycup.cisco.com.
              • add a new node with a new node ID (node id: 7) to the System Topology, for example, conference-7-mycup.cisco.com.
              • maintain the address of chat rooms that were created using the old alias.

              Configuration Steps:

              Option 1

              1. Choose Cisco Unified CM IM and Presence Administration > Messaging > Group Chat Server Alias Mapping.
              2. Click Add New to add the additional alias, conference-3-mycup.cisco.com.

              Option 2

              1. Choose Messaging > Group Chat and Persistent Chat and turn off the default system-generated alias, conference-7-mycup.cisco.com. (This is on by default).
              2. Edit the alias and change it to conference-3-mycup.cisco.com.

              Notes:

              When you add the new node to the System Topology, the system automatically assigns this alias to the node: conference-7-mycup.cisco.com.

              Option 1

              • If you add an additional alias, the node is addressable via both aliases, conference-7-mycup.cisco.com and conference-3-mycup.cisco.com.

              Option 2

              • If you turn off the old system-generated alias, conference-7-mycup.cisco.com reverts to a standard, editable alias listed under Group Chat Server Aliases.