An extension is a pointer to a data structure that takes into account switch-specific features and information that cannot be described by the other parameters in an event or a request. The extensions detailed in this section, however, pertain only to requests. They are applicable to all T-Servers and permit tuning of T-Server operations. Extensions for requests that apply only to particular T-Servers are described in the individual T-Server Deployment Guides.
Hardware Reasons in Extensions
In most cases, hardware-issued reasons are noted in the ReasonCode key-value pair in the Extensions attribute of four specific function calls and their corresponding events. (See TAgentLogin, TAgentLogout, TAgentSetReady, and TAgentSetNotReady for more information.) However, such issues are not limited to being present in those four functions (or their corresponding events).
Hardware-based reasons, as passed by extensions, are handled differently than Genesys reasons. For an illustration of the handling differences between hardware-based reasons and Genesys reasons, see the Genesys Reasons versus Media-Device Reasons diagram.
Extensions Common to All T-Servers According to Request
This section details the relationship between certain extensions and the relationships they may have with specific requests.
The Extensions attributes in the following table apply to requests passed between T-Servers. (In multi-site environments, these are ISCC-processed requests.) The requests that use these extensions include the functions TMakeCall(), TInitiateConference(), TInitiateTransfer(), TMuteTransfer(), TSingleStepTransfer(), TRouteCall(), and TGetAccessNumber().
|iscc-pass-extensiona||string (local, remote, or both)||Controls where extension attributes are passed from an original client request.|
|iscc-xaction-type||integer (or string value of one of the enumerated route types)||Routing type to be used. See TXRouteType() in your API reference for the complete list of route types available.|
|iscc-ar-agent-id||string||Destination agent's ID|
|iscc-ar-place||string||The destination agent's place|
|iscc-ar-duration||integer||Required time that an agent is to be reserved, in milliseconds (Specify -1 to use the default of 100000 milliseconds.)|
|iscc-ar-priority||integer||Requested priority (Specify -1 to use default of 0, the lowest priority value.)|
Additional granularity for setting priority. These are only evaluated if there are several concurrent requests with the same iscc-ar-priority. If any of these sub-priorities is absent, its value is assumed to be 0.
a. Exception: Do not use iscc-pass-extension with the TGetAccessNumber() function.
Note: To insure backward compatibility to 6.x and in order to comply with certain T-Servers, the default value for this key-value pair is both. An explicit value for iscc-pass-extensions is expected with ISCC requests when the same extensions interfere with origination and destination T-Servers. When the iscc-pass-extensions pair contains an invalid value, the default value is used.
For all requests taking place between T-Servers, when the cast-type has the value route, extensions are passed to the media device noted in the function TRouteCall() from the ExtRoutePoint to the requested destination. After the first unsuccessful attempt to route a call that arrives at a final destination, subsequent TRouteCall() requests do not contain extensions from an original client's request.
TAgentLogin, TAgentLogout, TAgentSetReady, and TAgentSetNotReady
The Extensions attribute listed in the following table is used to pass hardware reason codes and pertains to all of the following functions: TAgentLogin(), TAgentLogout(), TAgentSetReady(), and TAgentSetNotReady(). Recall that these are the typical, but not the exclusive, functions where hardware-reason codes are found.
|ReasonCode||String||A hardware reason code available for communication through these four function calls.|
The Extensions attributes listed in the following tables (for Call Progress Detection (CPD) and for Call Party Number (CPN)) pertain to the function TMakePredictiveCall(), but are not applicable to all switches. Furthermore, some switches support only some subset of these extensions. Refer to individual T-Server deployment guides for applicability.
|VoiceDest||Any valid ACD Queue or Routing Point||A Queue or Routing Point to which an outbound call answered by a live voice will be transferred|
|AnsMachine||Any valid ACD Queue or Routing Point||A Queue or Routing Point to which an outbound call answered by an answering machine will be transferred|
|FaxDest||Any valid ACD Queue or Routing Point||A Queue or Routing Point to which an outbound call answered by a fax machine will be transferred|
|CPNDigits||KVType-String||Yes||A5 characters, according to formats specified in the appropriate numbering/dialing plan|
TInitiateConference, TInitiateTransfer, and TMuteTransfer
The Extensions attribute listed in the following table applies to the functions TInitiateConference(), TInitiateTransfer(), and TMuteTransfer(). A more detailed description of ConsultUserData appears under User Data in Consultation Calls.
|default||The method specified in the consult-user-data configuration option is used.|
|separate||User data for the consultation call is attached and stored separately from the user data attached to the original call.|
|inherited||User data attached to the original call is copied to the consultation call at the moment the consultation call is initiated; after that, any changes to the original call's user data will not affect the consultation call's user data and vice versa.|
|joint||User data attached to either the original or the consultation call is associated with the original call and, yet, can be seen and changed by the parties of both calls.|
The Extensions attributes listed in the following table pertain to the function TReserveAgent().
Additional granularity for setting priority.