Cisco Cisco Packet Data Gateway (PDG) Fascicule

 



 

: In the event of a failure the user session continues. DPCA/Diameter will make periodic 

request and/or connection retry attempts and/or will attempt to communicate with a secondary peer 
depending on the peer config and session-binding setting. 



 

: In the event of a failure the user session continues for the duration of one 

retry attempt with the server. If this retry attempt also fails, the session is terminated. 



 

: In the event of a failure the user session is terminated. 

 

As in 8.0 release: 
This optional keyword defines the type of credit control request with failure result code and credit control 
failure handling action for a session. 



 

: Specifies the request type as any request for a new session. 



 

: Specifies the request type as initial request for a new session. 



 

: Specifies the request type as terminate request for a session. 



 

: Specifies the request type as update request for an active session. 

Use this command to configure the Diameter Policy Control Application (DPCA) failure handling behavior. 
When an unknown rulebase comes in CCA, changing of rulebase and failure handling is managed in the 
following manner: 



 

If the new and existing rulebases have the same CCA policy, then switch to the new rulebase is 

successful. 



 

If the new rulebase is valid and has CCA-enabled, in CCA-Initial/Update request, switch to the new 

rulebase is successful. 



 

If the new rulebase is valid and does NOT have CCA enabled, whereas the existing rulebase has credit 

enabled, or vice versa, in CCA-Initial/Update request: 



 

CCFH-Continue: Goes offline immediately after sending the CCR-T with termination cause as 

BAD_ANSWER. 



 

CCFH-RETRY&TERMINATE: Goes offline immediately after sending the CCR-T with 

termination cause as BAD_ANSWER. 



 

CCFH-TERMINATE: Goes offline immediately after sending the CCR-T with termination 

cause as BAD_ANSWER. 



 

If the new rulebase is invalid, in CCA-Initial/Update request: 



 

CCFH-Continue: Goes offline immediately after sending the CCR-T with termination cause as 

BAD_ANSWER. 



 

CCFH-RETRY&TERMINATE: Terminates on successful CCA-T, or terminates after 

successful/failed retry to secondary. 



 

CCFH-TERMINATE: Terminates on successful/failed CCR-T to Primary. 

The default failure handling behavior is: 

 

In StarOS release 14.1 and earlier, when an IP CAN session is up, if any CCR-U message delivery fails due 
to timeout or TCP link failure, the failure-handling action “

” will be taken for the session and there 

will not be any further interaction with PCRF and RAR from PCRF is also not accepted (result code 5002 is