dsilhavy
commented
1 year ago I don't understand why you want to remove metricsReportingConfigurationId from the M5 POST endpoint. The metricsReportingConfigurationId is generated via M1 and then used via M5. A ServiceAccessInformation can have multiple clientMetricsReportingConfigurations entries and therefore multiple metricsReportingConfigurationId. When sending a metrics report from the Media Session Handler to the Application Function via M5 the metricsReportingConfigurationId identifies the corresponding entry from clientMetricsReportingConfigurations.
Note that the payload of the POST request that is issued via M5 includes the metrics report (in XML format). It does not create a new metrics reporting configuration.
rjb1000
stojkovicv
According to the TS 26.512 section 11.4.2, the only request supported by M5 regarding Metrics Reporting is
POST(Creation). It's supposed to operate on{apiRoot}/3gpp-m5/{apiVersion}/metrics-reporting/{provisioningSessionId}/ {metricsReportingConfigurationId}meaning that ID for Metrics Reporting Configurations is contained within the URL. M1-side code of the same operation implements functionmsaf_metrics_reporting_configuration_create()which generates UUID value when invoked (also according to the specification). That leads me to the question about adding new function that won't generate UUID but fetch it directly from the URL (message->h.resource.component[2]). Does it make sense to have two quite similar functions, or it's worth to consider removingmetricsReportingConfigurationIdfrom the M5 POST endpoint? @dsilhavy @davidjwbbc