[SR-Users] Re: Unnecessary/Invalid AVPs in CCR message over Ro Interface

-----Original Message----- From: s.ghahremannejad(a)gmail.com &lt;s.ghahremannejad(a)gmail.com&gt; Sent: Dienstag, 5. September 2023 16:54 To: sr-users(a)lists.kamailio.org Subject: [SR-Users] Unnecessary/Invalid AVPs in CCR message over Ro Interface **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 sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: