Revision as of 23:10, February 4, 2016 by Sschlich (talk | contribs) (What's New)
Jump to: navigation, search

8.5.150.94

Voice Platform Resource Manager Release Notes

Release Date Release Type Restrictions AIX Linux Solaris Windows
02/05/16 General X X

Helpful Links

What's New

This release contains the following new features and enhancements:

    • Resource Manager (RM) has three new options in the CTI Connector (CTIC) Logical Resource Group (LRG) for handling CTIC failover.
      Important: These options are not available during configuration of a CTIC Resource Group via Genesys Administrator. You must specify them manually in the CTIC LRG.

      fail-over-cti-handling
      Valid Values: reject (default), answer, script;<service-type>;<URL>
      Takes Effect: After restart

      This option specifies RM behavior when all attempts to use CTIC fail. For example: all CTICs are down, or port capacity of the CTIC LRG is exceeded, or all CTICs in the LRG were tried but failed.

      • Set to reject to reject the call.
      • Set to answer to answer the call.
      • Set to script;<service-type>;<URL> to specify that RM redirects the call to the service <service-type> and informs that service to run the page at the URL (same behavior as rm.cti-unavailable-action).


      cti-unavailable-respcode
      Valid Values: No value specified (default), none, SIP response codes for which next CTI resource should not be retried.
      Takes Effect: After restart

      • Specifies a list of response codes to be intercepted and given special treatment. Separate each code in the list with a semicolon (;).
        If CTIC returns a response code matching a code provided in the list, RM does not retry any other CTIC; instead RM takes action based on the group-level option cti-unavailable-action, or based on the server-level option rm.cti-unavailable-action.
      • When set to empty or none, RM retries the next CTIC available in the CTI LRG in response to any error from CTIC.
      • When no value is specified, RM checks the server-level parameter rm.cti-unavailable-respcode and takes the action specified there.

      Note: cti-unavailable-respcode overrides the server parameter rm.cti-unavailable-respcode.

      cti-unavailable-action
      Valid Values: reject (default), answer, script;<service-type>;<URL>
      Takes Effect: After restart

      Specifies the behavior expected when the SIP response code received from CTIC matches a response code that is configured in rm.cti-unavailable-respcode.

      • Set to reject to reject the call.
      • Set to answer to answer the call.
      • Set to script;<service-type>;<URL> to specify that RM redirects the call to the service <service-type> and informs that service to run the page at the URL (same behavior as rm.cti-unavailble-action).

      When no value is specified, RM uses the server-level parameter rm.cti-unavailable-action.

      Note: This option overrides rm.cti-unavailable-action.

    • The TCP setup timer is now configurable.

    Use sip.transport.setuptimer.tcp parameter in the proxy, monitor, subscription, and registrar sections to configure the timer.
    Default Value : 30000ms (30 seconds)
    Minimum Value: 1000 ms
    Maximum Value: 32000 ms



    Resolved Issues

    This release contains the following resolved issues:


    Resource Manager no longer becomes unresponsive due to a race condition which may occur when the statuses of multiple physical resource AORs being monitored while using SIP OPTIONS are updated simultaneously. (GVP-22865) (Did I understand correctly?)


    Resource Manager no longer drops packets being incorrectly categorized as non-RFC3261 compliant. (GVP-22736) How about: Resource Manager no longer drops packets because they have been incorrectly categorized as non-RFC3261 compliant. ?


    The Resource Manager no longer generates -301 errors that cause it to drop messages. Previously, RM generated -301 errors because the TCP message queue limit was exceeded due to a race condition. (GVP-22707)


    The Resource Manager now properly closes the current socket connection before accepting a new socket connection. (GVP-22660)


    Resource Manager no longer becomes stuck under these conditions:

    • The option monitor-method is set to MF for an LRG
    • An SCS resource status change update (do you need both "change" and "update"?) (online or offline) is received at the same time as a dynamic configuration update such as IVR profile or configuration/tenant properties update, and so on. (GVP-22629)

    Resource Manager now maintains the correct number of calls forwarded to an MCP for both nodes in an active-active setup, when the number exceeds the Max Ports value that is defined in the LRG. (GVP-22586)


    Resource Manager (RM) no longer terminates at the place in the CTI call flow where RM returns to non-CTI handling of the call, when all of these conditions occur:

    • RM receives an error code that was configured in the option rm.cti-unavailable-respcode.
    • rm.cti-unavailable-action is set to answer or script.
    • The TerminatingLeg initiated by CTIC is not cleared.

    (GVP-22585)


    TheResource Manager now correctly returns a 503 error response to SIP OPTION messages from SIP Server, when RM is in a suspended state. (GVP-22581)


    Resource Manager no longer terminates due to application unavailability while recording calls, if tenant configuration updates are received simultaneously. RM will make the application available all through the tenant configuration updates. (GVP-22525) (Confused by this one, Steve :) Here's my stab, probably wrong:
    Resource Manager now remains fully available while recording calls even when tenant configuration updates are received simultaneously. Previously RM terminated in this scenario because of application unavailability.


    The Resource Manager MIB data (stored in a scalar table) for an active-active deployment mode may not reflect the correct number when RM is run in a high availability active-active configuration. (GVP-20257) (This looks like a KI, not a fix)




    Upgrade Notes

    No special procedure is required to upgrade to release 8.5.150.94.

    Comments or questions about this documentation? Contact us for support!