Table of Contents
List of Examples
rx_dest_realm parameter usagerx_forced_peer parameter usagerx_auth_expiry parameter usagecdp_event_latency parameter usagecdp_event_threshold parameter usagecdp_event_latency_log parameter
usageauthorize_video_flow parameter
usageTable of Contents
This module contains all method related to the IMS policy and charging control functions performed by an Application Function (e.g. P-CSCF) over the Rx interface. This module is dependent on the CDP (C Diameter Peer) modules for communicating with PCRF as specified in 3GPP specification TS 29.214.
The Following mouldes must be loaded before this module:
Dialog2
Usrloc PCSCF
TM - Transaction Manager
CDP - C Diameter Peer
CDP_AVP - CDP AVP Applications
This is the name of the Diameter realm of the Diameter server (typically a PCRF).
Default value is 'ims.smilecoms.com'.
Example 1.1. rx_dest_realm parameter usage
...
modparam("ims_qos", "rx_dest_realm", "ims.smilecoms.com")
...
FQDN of the Diameter server (typically a PCRF) to communicate with. If not set then realm routing is used. If you use this, the routing defined in your diameter xml configuration file (CDP) will be ignored and as a result you will lose the benefits of load balancing and failover.
Default value is ''.
Example 1.2. rx_forced_peer parameter usage
...
modparam("ims_qos", "rx_forced_peer", "pcrf.ims.smilecoms.com")
...
This is the expiry length in seconds of the initiated Diameter sessions.
Default value is 7200.
This is a flag to determine whether or slow CDP responses should be reported in the log file. 1 is enabled and 0 is disabled.
Default value is 1.
This time in milliseconds is the limit we should report a CDP response as slow. i.e. if a CDP response exceeds this limit it will be reported in the log file. This is only relevant is cdp_event_latency is enabled (set to 0).
Default value is 500.
Example 1.5. cdp_event_threshold parameter usage
...
modparam("ims_qos", "cdp_event_threshold", 500)
...
This time log level at which we should report slow CDP responses. 0 is ERROR, 1 is WARN, 2 is INFO and 3 is DEBUG. This is only relevant is cdp_event_latency is enabled (set to 0)
Default value is 0.
Example 1.6. cdp_event_latency_log parameter
usage
...
modparam("ims_qos", "cdp_event_latency_log", 1)
...
Perform a AAR on Diameter RX interface to subscribe to signalling status. This purpose of this is tell a Diameter server (typically a PCRF) to inform the requesting Diameter client on changes to the status of signalling bearer for the same framed IP address. For more details see 3GGP TS 29.214.
Meaning of the parameters is as follows:
Route block to resume after async UAR Diameter reply.
domain that usrloc_pcscf uses to store user information.
This function can be used from REQUEST_ROUTE.
p.s. this is executed asynchronously. See example on how to retrieve return value
Example 1.8. Rx_AAR_Register
...
if(Rx_AAR_Register("REG_AAR_REPLY","location")==0){
exit;
}
...
route[REG_AAR_REPLY]
{
switch ($avp(s:aar_return_code)) {
case 1:
xlog("L_DBG", "Diameter: AAR success on subscription to signalling\n");
break;
default:
xlog("L_ERR", "Diameter: AAR failed on subscription to signalling\n");
t_reply("403", "Can't register to QoS for signalling");
exit;
}
...
Perform a AAR on Diameter RX interface to request resource authorisation from a Diameter server (typically a PCRF). For more details see 3GGP TS 29.214.
Meaning of the parameters is as follows:
Route block to resume after async UAR Diameter reply.
directionthe direction of this message - orig, term, etc.
This function can be used from REQUEST_ROUTE or ONREPLY_ROUTE.
p.s. this is executed asynchronously. See example on how to retrieve return value
Example 1.9. Rx_AAR
...
if(Rx_AAR("ORIG_SESSION_AAR_REPLY","orig")==0){
exit;
}
...
route[ORIGN_SESSION_AAR_REPLY]
{
if ($avp(s:aar_return_code) != 1) {
xlog("L_ERR", "IMS: AAR failed Orig\n");
dlg_terminate("all", "Sorry no QoS available");
} else {
xlog("L_DBG", "Diameter: Orig AAR success on media authorization\n");
}
}
...