Contents
Submitting Call Attempt Records
When OCS attempts a call, it sends the call attempt record to Web or Application Server via an HTTP POST request. Web or Application Server then checks the call result data to determine whether dialing rules should be applied to the record or if the record should be added to a contact suppression list. (Note: Please advise if this is correct or if I even need to include this second sentence at all)
Scenario: Successful HTTP Post Request to Web or Application Server
- A campaign is started/loaded in any dialing mode.
- OCS dials a call.
- OCS sends a call attempt record (HTTP POST request with GSW_OCS_SEQUENCE_NO: 0) to Web or Application Server.
- OCS stores the record posted to Web or Application Server while it waits for confirmation that the record was saved.
- Web or Application Server receives the record and sends a 200 OK response to OCS. The log confirms that the call attempt record was saved.
- The agent-customer call is established.
- The agent releases the call and logs the result of the call (example Answer, Answering Machine, DoNotCall)
- OCS sends another call attempt record (HTTP POST request with GSW_OCS_SEQUENCE_NO: 1) to Web or Application Server, this time containing the GSW_CALL_RESULT parameter.
- Web or Application Server receives the record and sends another 200 response.
Feature Configuration
Add the following configuration options, as described on the OCS Options Descriptions page in this manual:
- send-history
- history-uri
- history-wait-condition-threshold
- history-wait-recovery-timeout
- validation-race-condition-call-result
The data posted to Web or Application Server can contain the following attributes. Refer to the Reference Manual for a detailed description of each attribute.
| Attribute Name | Attribute Name | Attribute Name |
|---|---|---|
| GSW_CALL_ATTEMPT_GUID | GSW_HIST_SEQUENCE_NUM | GSW_TENANT_NAME |
| GSW_PHONE | GSW_CAMPAIGN_DBID | GSW_PHONE_TYPE |
| GSW_CUSTOMER_ID | GSW_START_PROCESSING | GSW_CALL_TIME |
| GSW_SCHEDULED_TIME | GSW_TZ_OFFSET | GSW_TZ_NAME |
| GSW_CALL_RESULT | GSW_CAMPAIGN_NAME | GSW_CALLING_LIST |
| GSW_CAMPAIGN_GROUP_NAME | GSW_GROUP_NAME | GSW_QUEUE_NAME |
| GSW_DIAL_MODE | GSW_OPTIMIZE_BY | GSW_OPTIMIZE_GOAL |
| GSW_DIALING | GSW_RINGING | GSW_RELEASED |
| GSW_ANSWERED | GSW_CPD_COMPLETED | GSW_QUEUED |
| GSW_AGENT_RINGING | GSW_AGENT_ANSWERED | GSW_DIVERTED |
| GSW_ABANDONED | GSW_AGENT_RELEASED | GSW_ACW_COMPLETED |
| GSW_COMPLETE_PROCESSING | GSW_POSTAL_CODE | GSW_REGION_CODE |
| GSW_COUNTRY_CODE | GSW_TZ_CODE | GSW_D_AREA_CODE |
| GSW_D_REGION_CODE | GSW_D_COUNTRY_CODE |
Responses and Logs
When OCS sends the HTTP POST request, Web or Application Server responds with a response code and a corresponding log entry, as described in the table below.
| HTTP Response Code | Associated Log Entry | Description |
|---|---|---|
| 200 OK | Call Attempt Record has been saved for phone %s | Web or Application Server confirms that the call attempt record has been successfully stored for further processing. |
| 409 Conflict | Call Attempt Record was not saved and has been queued for reprocessing for phone %s
|
Web or Application Server is not reachable or could not save the call attempt record as a result of an internal error or a bad request. |
| 408 Time-out | Save operation for Call Attempt Record was aborted (timeout elapsed) and the record has been queued for reprocessing for phone %s
|
A request to Web or Application Server has timed out. This request response might be generated by OCS internally if the response wait time exceeds the time specified in the history-http-response-timeout option. |
| 418 I'm a teapot | Call Attempt Record was not saved and has been queued for reprocessing for phone %s
|
The HTTP POST request did not go through as a result of mis-configuration or some other internal error. |
Re-submitting Failed Records
If OCS receives an error response from Web or Application Server (409 Conflict, 408 Time-out, or 418 I'm a teapot) after submitting the first HTTP POST request (GSW_OCS_SEQUENCE_NO: 0), it continues on with the call. If it receives the error message after submitting the second HTTP POST request (GSW_OCS_SEQUENCE_NO: 1), it treats the record as failed and re-submits the record.
OCS checks the value in the history-wait-condition-threshold, which stores the number of re-submissions OCS should make after Web or Application returns an error response. It then checks the value in the history-wait-recovery-timeout, which stores the time OCS should wait before re-submitting another HTTP POST request. It will re-submit the HTTP POST request to Web or Application Server in accordance with those values.
If OCS reaches the threshold specified in the history-wait-condition-threshold option before receiving a 200 OK response, it stops dialing. If it receives a 200 OK response before it reaches the threshold, the wait condition is cleared from the log. The scenario below describes the process flow.
Scenario: Unsuccessful Post to Web or Application Server
- A campaign is started/loaded in any dialing mode.
- OCS dials a call.
- OCS sends a call attempt record (HTTP POST request with GSW_OCS_SEQUENCE_NO: 0) to Web or Application Server.
- OCS stores the record posted to Web or Application Server while it waits for confirmation that the record was saved.
- OCS receives an error response (either 409 Conflict, 408 Time-out, or 418 I'm a teapot) from Web or Application Server. The log confirms the error.
- The agent-customer call is established.
- The agent releases the call and logs the result of the call (example Answer, Answering Machine, DoNotCall).
- OCS sends another call attempt record (HTTP POST request with GSW_OCS_SEQUENCE_NO: 1) to Web or Application Server.
- OCS receives an error response (either 409 Conflict, 408 Time-out, or 418 I'm a teapot) from Web or Application Server. The log shows the following: Call Attempt Record was not saved and has been queued for reprocessing for phone %s and Wait condition has been activated for Campaign Group %s (DBID %d).
- OCS checks the value in the history-wait-condition-threshold, which stores the number of re-submissions OCS should make after Web or Application returns an error response. The value is 3. That means OCS can re-submit the HTTP POST request three more times.
- OCS checks the value in the history-wait-recovery-timeout, which stores the time OCS should wait before re-submitting another HTTP POST request. The value is 5, which means OCS must wait 5 seconds before re-submitting an HTTP POST request.
- After the second re-submission, OCS receives a 200 OK response from Web or Application server. The log shows Wait condition has been cleared for Campaign Group %s (DBID %d).
Race Conditions
If OCS sends a pre-dial validation request to Web or Application Server for a contact record that Web or Application Server is currently processing but has not yet saved (for example, it has not yet sent a response or the record is marked for re-processing), a race condition occurs.
As a prevention measure, OCS checks for a race condition before submitting a pre-dial validation request. If it detects a race condition, it will not dial the record. Instead, OCS refers to the call result specified in the validation-race-condition-call-result option and attempts to apply that treatment to the call result.
In this scenario, the following log entry appears:
Predial check aborted due to race condition for phone %s