**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.
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
