> Content Filtering Server Group Configuration Mode Commands
> Content Filtering Server Group (CFSG) Configuration Mode is accessed by entering the content-filtering server-group command in the Context Configuration Mode.
> Important: The commands or keywords/variables that are available are dependent on platform type, product version, and installed license(s).
> connection retry-timeout
> This command configures the TCP connection retry timer for Internet Content Adaptation Protocol (ICAP) server and client.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> connection retry-timeout duration
> { default | no } connection retry-timeout
> default
> Configures the default setting.
> Default: 30 seconds
> no
> Removes the connection retry timeout configuration.
> duration
> Specifies the duration in seconds, and must be an integer from 1 through 3600.
> Usage
> Use this command to configure the connection retry timer between ICAP server and client TCP connection, i.e. how long to wait before re-attempting to establish a TCP connection.
> Example
> The following command sets the ICAP client and server connection retry timer to 120 seconds:
> connection retry-timeout 120
> deny-message
> This command configures the text message that is returned to the subscriber in a deny response.
> Important: This command is obsolete in 10.0 and later releases.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> deny-message string
> { default | no } deny-message
> default
> Configures the default setting.
> Default: Disabled
> no
> Removes previously configured deny message setting.
> string
> Specifies a text message that is to be returned to the subscriber in a deny response.
> string must be an alpha and/or numeric string of 1 through 511 characters in length.
> Usage
> Use this command to define a text message that is returned to the subscriber in a deny response.
> Example
> The following command sets the text message to no_Authorization in a deny message:
> deny-message no_Authorization
> deny-response code
> This command configures the deny response message that is to be sent from ICAP server to the subscribers.
> Product
> ICAP
> Privilege
> Security Administrator, Administrator
> Syntax
> deny-response code { 200 message string | 403 }
> { default | no } deny-response code
> default
> Configures the default setting.
> Default: deny-response code 200
> no
> Removes previously configured deny response message setting.
> 200 message string
> This keyword is used to set response code 200 for the deny response message.
> string: Specifies a text message that is to be returned to the subscriber in a deny response.
> string must be an alpha and/or numeric string of 1 through 511 characters in length.
> If deny-response code 200 is configured, the response sent to the subscriber will be of the form 200 OK with deny message "Access denied".
> If a message is configured for response code 200, then that message will be used instead of "Access denied".
> 403
> This keyword is used to set response code 403 for the deny response message.
> When this keyword is configured, deny response from ICAP server will be sent as is to the subscriber.
> Usage
> Use this command to define a text message that is returned to the subscriber in a deny response.
> Example
> The following command sets the text message to Not allowed in a deny response message:
> deny-response code 200 message Not allowed
> dictionary
> This command specifies the dictionary to use for requests to the server(s) in this CFSG.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> dictionary { custom1 | custom2 | standard }
> { default | no } dictionary
> default
> Sets the default dictionary.
> Default: default
> no
> Removes the previously configured dictionary setting.
> custom1
> Custom-defined dictionary. It conforms to TS 32.015 v 3.6.0 for R99. It provides proprietary header fields for MSISDN and APN/subscriber. Please contact your local sales representative for more information.
> custom2
> Custom-defined dictionary. Please contact your local sales representative for additional information.
> standard
> Default: Enabled
> This dictionary is used to use an HTTP Get Request to specify the URL. It conforms to TS 32.215 v 4.6.0 for R4 (and also R5 - extended QoS format).
> Usage
> Use this command to specify the standard and customized encoding mechanism used for elements included messages.
> Example
> The following command configures the system to use standard dictionary to encode messages:
> default dictionary
> end
> Returns the CLI prompt to the Exec mode.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> end
> Usage
> Use this command to change to the Exec mode.
> exit
> Exits the current mode and returns to the parent configuration mode.
> Product
> All
> Privilege
> Security Administrator, Administrator
> Syntax
> exit
> Usage
> Use this command to return to the parent configuration mode.
> failure-action
> This command specifies the actions to be taken when communication between ICAP endpoints within this CFSG fail.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> failure-action { allow | content-insertion content_string | discard | redirect-url url | terminate-flow }
> { default | no } failure-action
> default
> Configures the default setting.
> Default: terminate-flow
> no
> Removes previously configured failure action.
> allow
> In case of static content filtering this option allows the request for content, and for dynamic content filtering it allows the content itself.
> content-insertion content_string
> Specifies the content string to be used for failure action.
> In case of static content filtering, the specified text content_string is used to create a response to the subscriber’s attempt to get content. In dynamic content filtering, the specified text content_string is used to replace the content returned by a server.
> content_string must be an alpha and/or numeric string of 1 through 128 characters in length.
> discard
> In case of static content filtering this option discards the packet(s) requested, and for dynamic content filtering it discards the packet(s) that contain(s) the content.
> redirect-url url
> Redirects the subscriber to the specified URL.
> url must be a string of 1 through 128 characters in length, and must be in the following format: http://search.com/subtarg=#HTTP.URL#
> terminate-flow
> For TCP, gracefully terminates the connection between the subscriber and external server, and sends a TCP FIN to the subscriber and a TCP RST to the server.
> For WAP-Connection Oriented, the WSP session is gracefully terminated by sending WTP Aborts for each of the outstanding requests, and WSP Disconnect to the client and the server. For WSP-Connectionless, only the current WSP request is rejected.
> Usage
> Use this command to set the actions on failure for server connection.
> ICAP rating is enabled for retransmitted packet when default ICAP failure action was taken on an ICAP request for that flow. ICAP default failure action is taken on the pending ICAP request for a connection when the connection needs to be reset and there is no other redundant connection available. For example, in the ICAP request timeout and ICAP connection timeout scenarios. In these cases the retransmitted packet in the uplink direction is sent for ICAP rating again.
> In case of WAP CO, uplink retransmitted packet for the WAP transactions for which ICAP failure action was taken will be sent for ICAP rating. WSP header of the retransmitted packet is not parsed by the WSP analyzer. The URL received in the previous packet for that transaction is used for ICAP rating. If failure action was taken on multiple WTP transactions for the same flow (case: WTP concatenated GET request) then uplink retransmitted packet for each of the transaction is sent for rating again.
> In case of HTTP, uplink retransmitted packets for the HTTP flow on which ICAP failure action is taken is sent for ICAP rating. The URL present in the current secondary session (last uplink request) is used for ICAP rating. However, if there were multiple outstanding ICAP request for the same flow (pipelined request) then for the retransmitted packet the URL that will be sent for rating will be that of the last GET request.
> Retransmission in various cases of failure-action taken on re-transmitted packets when the ICAP response is not received for the original request and the retransmitted request comes in:

> • | WSP CO:

> • | Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked. It is possible that the WAP gateway sends the response for the permitted GET request. Hence, there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.

> • | Content Insert: The retransmitted packet is not sent for ICAP rating.

> • | Redirect: The retransmitted packet is not sent for ICAP rating.

> • | Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked.

> • | Terminate flow: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed or blocked. The WAP gateway may send an Abort transaction for this GET request if the WSP disconnect packet sent while terminating the flow is received by the WAP gateway.

> • | HTTP:

> • | Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the last HTTP GET request. It is possible that the HTTP server sends the response for the permitted GET request. Hence there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.

> • | Content Insert: Retransmitted packets are dropped and not charged.

> • | Redirect: Retransmitted packets are dropped and not charged.

> • | Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction allowed/blocked.

> • | Terminate flow: Retransmitted packets will be dropped and not charged.

> Example
> The following command sets the failure action to terminate:
> failure-action terminate-flow
> icap server
> This command adds an Internet Content Adaptation Protocol (ICAP) server configuration to the current Content Filtering Server Group.
> Important: In StarOS 8.1 and later releases, a maximum of five ICAP servers can be configured per Content Filtering Server Group. In StarOS 8.0 and earlier releases, only one ICAP Server can be configured per Content Filtering Server Group.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> icap server ip_address [ port port_number ] [ max messages ] [ priority priority ]
> no icap server ip_address [ port port_number ] [ priority priority ]
> no
> Removes the specified ICAP server configuration from the current Content Filtering Server Group.
> ip_address
> Specifies the ICAP server’s IP address.
> ip_address must be a standard IPv4 address expressed in dotted decimal notation format, or an IPv6 address expressed in colon notation format.
> port port_number
> Default: 1344
> Specifies the ICAP server’s port number to use for communications.
> port_number must be an integer from 1 through 65535.
> max messages
> Specifies the maximum number of unanswered outstanding messages that may be allowed to the ICAP server.
> Important: The maximum outstanding requests per ICAP connection is limited to one. Therefore the value configured using the max keyword will be ignored.
> priority priority
> Default: 1
> Specifies priority of the ICAP server in the current Content Filtering Server Group. The priority is used in server selection to determine which standby server becomes active.
> priority must be an integer from 1 through 65535, where 1 is the highest priority.
> Important: The priority keyword is only available in StarOS 8.1 and later releases.
> Usage
> This command is used to add an ICAP server configuration to a Content Filtering Server Group with which the system is to communicate for content filtering communication.
> In StarOS 8.0, the ICAP solution supports only one connection between ACS Manager and ICAP server.
> In StarOS 8.1, multiple ICAP server connections are supported per manager. At any time only one connection is active with the other connections acting as standby. In case of a connection failure, based on its priority, a standby connection becomes active. Any pending ICAP requests are moved to the new active connection. If a standby connection is unavailable, failure action is taken on all pending ICAP requests. See the failure-action command.
> In StarOS 8.1 and later releases, a maximum of five ICAP servers can be configured per Content Filtering Server Group with a priority associated with each server. Once configured, an ICAP server’s priority cannot be changed. To change a server’s priority, the server configuration must be removed, and added with the new priority.
> Example
> The following command sets the ICAP server IP address to 1.2.3.4 and port to 1024:
> icap server 1.2.3.4 port 1024
> The following command specifies an ICAP server with IP address 5.6.7.8, port number 1024, and priority 3:
> icap server 5.6.7.8 port 1024 priority 3
> origin address
> This command specifies a bind address for the CFSG endpoint.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> origin address ip_address
> no origin address
> no
> Disables/releases the binding address for the CFSG endpoint.
> ip_address
> Specifies the IP address to bind the CFSG endpoint.
> ip_address can be an IPv4 address expressed in dotted decimal notation, or an IPv6 address expressed in colon notation.
> Usage
> Use this command to set the bind address for the CFSG endpoint.
> Example
> The following command sets the origin address of 1.1.1.1:
> origin address 1.1.1.1
> response-timeout
> This command sets the response timeout for the ICAP connection between ICAP server and client.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> response-timeout duration
> { default | no } response-timeout
> default
> Configures the default setting.
> Default: 30 seconds
> no
> Removes the response timeout configuration.
> duration
> The timeout duration in seconds, and must be an integer from 1 through 300.
> Default: 30 seconds
> Usage
> Use this command to set the ICAP connection response timeout, after which connection will be marked as unsuccessful between ICAP endpoint.
> Example
> The following command sets the ICAP connection response timeout to 100 seconds:
> response-timeout 100
> timeout action
> This command has been deprecated, and is replaced by the failure-action command.
> url-extraction
> This command enables configuration of ICAP URL extraction behavior.
> Product
> CF
> Privilege
> Security Administrator, Administrator
> Syntax
> url-extraction { after-parsing | raw }
> default url-extraction
> default
> Configures the default setting.
> Default: after-parsing
> after-parsing
> Specifies sending parsed URI and host name. Percent-encoded hex characters in URLs sent from the ACF client to the ICAP server will be converted to corresponding ASCII characters and sent.
> For example, the URL:
> http://www.google.co.uk/?this%20is%20a%20test
> will be sent to the ICAP server as:
> http://www.google.co.uk/?this is a test
> raw
> Specifies sending raw URI and host name. The URLs will contain percent-encoded hex characters as is.
> For example, the URL:
> http://www.google.co.uk/?this%20is%20a%20test
> will be sent to the ICAP server as:
> http://www.google.co.uk/?this%20is%20a%20test
> Usage
> Use this command to configure the ICAP URL extraction behavior. Percent-encoded hex characters—for example, space (%20) and the percent character (%25)—in URLs sent from the ACF client to the ICAP server can be sent either as percent-encoded hex characters or as their corresponding ASCII characters.
> Example
> The following command configures URLs sent from the ACF client to the ICAP server to contain the escape encoding as is:
> url-extraction raw

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883