Article Original Creation Date: 2010-04-28

Overview

When using the custom workflow, ServiceGateway tickles the device in order to deliver the configuration. Based from an example observation, a number of devices do not respond to the tickle at all (but are online), while others do respond to the tickle, but do not establish a TR-069 session within the specified time-out (the 90s in Production) after that.

The result is that the custom workflow will wait until the modem sends a Boot event, which might take several months for VoIP customers.

Environment

Information

• If this property is set to a value greater than 0, a second tickle will be attempted, but never more after that. The way this works is the first tickle is attempted, waiting up to CONNECTION_REQUEST_TIMEOUT for a response to the HTTP GET.

NOTE: This is not a timeout for when the CONNECTION REQUEST Inform is received, but simply the response to the HTTP GET itself as shown in the ACS-api.log file:

2010-06-07 09:17:30,994 [] INFO ACS - Trying an HTTP GET at http://172.30.200.100:11000/WanMgmt:0
2010-06-07 09:17:31,010 [] INFO ACS - HTTP GET to CPE device was successful, code 200 

• If the result of the first tickle was not successful, including due to the timeout, we then check the value of CONNECTION_REQUEST_RETRY_TIMEOUT. If this value is greater than 0, we wait that amount of time and then attempt the HTTP GET a second time, using the same CONNECTION_REQUEST_TIMEOUT as in the first attempt.
  
• To prevent this issue there are a number of factors to consider, including the timeouts that are already in place for the communication between the application server and the ACS API (ACS-Server API Timeout) and the timeout between the ACS and the device (ACS-Server CPE Timeout), or in the case of file downloads, the File Transfer timeouts for both of those cases.
  
• Out-of-the-Box (OOTB) values are the 20s for the ACS-Server API Timeout and 15s for the ACS-Server CPE Timeout. Given those timeouts, we do not recommend a timeout of 300s, as suggested below. So, make sure that the sum of CONNECTION_REQUEST_TIMEOUT + CONNECTION_REQUEST_RETRY_TIMEOUT + CONNECTION_REQUEST_TIMEOUT (to cover the first and second tickle attempts timing out, plus the time to wait to attempt the second tickle) be less than the ACS-Server CPE Timeout.
  
• For the ‘optimal’ value to use, start by analyzing the statistics for successful tickle attempts in the environment, and make a determination based on that. There are logging improvements included in SG 4.1 that will include the URL in the response to the HTTP GET which will make it easier to obtain these statistics. With the changes, the log messages shown above will be:

 2010-06-07 09:17:30,994 [] INFO ACS - Trying an HTTP GET at http://172.30.200.100:11000/WanMgmt:0
 2010-06-07 09:17:31,010 [] INFO ACS - HTTP GET to CPE device at http://172.30.200.100:11000/WanMgmt:0 was successful, code 200

Workaround

• This issue has been addressed in release 4.0.11, available since July 26th, 2010.
  
• The ACS API log message indicating that a connection request was sent to a device includes the device's connection request URL. However, the log message reporting the outcome of the request (success or failure) did not.
  
  
• This makes it impossible to correlate outcomes with the requests.
• The device connection request URL is now included in all log messages that indicate the success or failure of a connection request attempt.