Hello,

I remember from a past project that we also had some inter-op problems related 
to some specific AVPs in the Ro interface generated from Kamailio.

As it was a custom installation for a POC, we just removed the code supporting 
it.

It would be probably a good idea to add some logic to the module that allows to 
specify the AVPs that are included in the message. One way would be with a 
configuration switches, or with a mode parameter that supports an integer map 
value (probably more flexible way). 

Cheers,

Henning 

-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com

> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Dienstag, 5. September 2023 16:54
> To: [email protected]
> 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 [email protected]
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__________________________________________________________
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:

Reply via email to