5 Sep
2023
5 Sep
'23
4:54 p.m.
**Issue Description**
I'm encountering an issue with my Kamailio configuration related to the inclusion of
the "Accounting-Record-Type" (480) and "Accounting-Record-Number"
(485) AVPs in Credit-Control Request (CCR) messages sent from the S-CSCF to the OCS.
**Issue Details**
- **Problem**: The "Accounting-Record-Type" and
"Accounting-Record-Number" AVPs are being added to CCR messages generated by my
Kamailio instance.
- **Expected Behavior**: According to modern Diameter and 3GPP standards (e.g., RFC 4006
and TS 32.299), these AVPs should not be included in CCR messages.
**Configuration Details**
- **Kamailio Version**: 5.3.0
- **SigScale OCS Version**: 3.2.9
Note that I have redacted some specific information for confidentiality reasons. The
actual values are placed in my Kamailio main configuration file (`kamailio.cfg`) and
Diameter-specific configuration files (where applicable).
Kamailio.cfg:
modparam("ims_charging", "db_url", DB_URL)
modparam("ims_charging", "db_mode", 1)
modparam("ims_charging", "origin_host", HOSTNAME);
modparam("ims_charging", "origin_realm", NETWORKNAME);
modparam("ims_charging", "destination_host", DESTINATION_HOST);
modparam("ims_charging", "destination_realm", DESTINATION_REALM);
modparam("ims_charging","service_context_id_root", RO_ROOT);
modparam("ims_charging","service_context_id_ext", RO_EXT);
modparam("ims_charging","service_context_id_mnc", MNC);
modparam("ims_charging","service_context_id_mcc", MCC);
modparam("ims_charging","interim_update_credits",30);
modparam("ims_charging","timer_buffer",5);
SCSCF.xml:
<?xml version="1.0" encoding="UTF-8"?
<DiameterPeer
FQDN="scscf.mncXXX.mccXXX.3gppnetwork.org"
Realm="ims.mncXXX.mccXXX.3gppnetwork.org"
Vendor_Id="10415"
Product_Name="CDiameterPeer"
AcceptUnknownPeers="1"
DropUnknownOnDisconnect="1"
Tc="30"
Workers="16"
QueueLength="32"
TransactionTimeout="5"
SessionsHashSize="128"
DefaultAuthSessionTimeout="3600"
MaxAuthSessionTimeout="3600"
<Peer FQDN="diameter" Realm="ims.mncXXX.mccXXX.3gppnetwork.org"
port="3868"/ <Peer
FQDN="192.168.2.31" Realm="ocs.ims.mncXXX.mccXXX.3gppnetwork.org"
port="3868"/ <Acceptor
port="3868" bind="eth0"/
<Auth id="16777216" vendor="10415"/><!-- 3GPP Cx -- <Auth id="16777216"
vendor="4491"/><!-- CableLabs Cx --
<Auth id="16777216" vendor="13019"/><!--
ETSI/TISPAN Cx -- <Auth
id="16777216" vendor="0"/><!-- ETSI/TISPAN Cx --
<Auth id="4" vendor="10415"/> <!--3GPP Ro -- <Acct id="4"
vendor="10415" /
<!--
Supported Vendor IDs - list of values which will be sent in the CER/CEA in the
Supported-Vendor-ID AVPs
-- <SupportedVendor vendor="10415"
/ <Realm
name="ocs.ims.mncXXX.mccXXX.3gppnetwork.org"
<Route FQDN="192.168.2.31" metric="10"/ </Realm
<DefaultRoute FQDN="diameter" metric="10"/ </DiameterPeer
I am using SigScale OCS as my Online Charging System. Here is the error log I received
from SigScale OCS:
ERROR REPORT==== 5-Sep-2023::07:27:01.393554 ===
"DIAMETER AVP unsupported"
service_name: {ocs_diameter_acct_service,{0,0,0,0},3868}
capabilities: {diameter_caps,
{<<"host1">>,
<<"scscf-1.ims.mncXXX.mccXXX.3gppnetwork.org">>},
{<<"COMPANYNAME.local">>,
<<"ims.mncXXX.mccXXX.3gppnetwork.org">>},
{[{0,0,0,0}],[{172,18,0,7}]},
{50386,10415},
{<<"SigScale
OCS">>,<<"CDiameterPeer">>},
{[],[]},
{[10415],[10415]},
{[4,16777238],[16777216]},
{[],[]},
{[],[]},
{[{'diameter_base_Vendor-Specific-Application-Id',10415,[16777238],[]}],
[{'diameter_base_Vendor-Specific-Application-Id',10415,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',4491,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',13019,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',10415,[4],[]},
{'diameter_base_Vendor-Specific-Application-Id',10415,[],[4]}]},
{[329],[]},
{[],[]}}
errors: [{5001,
{diameter_avp,480,undefined,true,false,
<<0,0,0,2>>,
'Accounting-Record-Type',2,'Enumerated',5}},
{5001,
{diameter_avp,485,undefined,true,false,
<<0,0,0,0>>,
'Accounting-Record-Number',0,'Unsigned32',6}},
{5001,
{diameter_avp,260,undefined,true,false,
<<0,0,1,10,64,0,0,12,0,0,40,175,0,0,1,2,64,0,0,12,0,0,0,4>>,
'Vendor-Specific-Application-Id',
{'3gpp_ro_Vendor-Specific-Application-Id',10415,[4],[]},
'Grouped',10}}]
I would greatly appreciate it if someone from the community could provide insights into
the following:
1. Possible Configurations: Are there specific configurations or modules in Kamailio that
might cause the inclusion of non-standard AVPs in CCR messages?
2. IMS Ro Interface Behavior: Does anyone have experience with IMS Ro interface behavior
using Kamailio that could shed light on this?
If you have any guidance, suggestions, or solutions to help me troubleshoot and resolve
this problem, please share them. Thank you for your assistance.