Consumption Reporting: Behavior after update of the Service Access Information

[dsilhavy]

Feature description

This issue discusses changes of ServiceAccessInformation.clientConsumptionReportingConfiguration and their impact on running streaming sessions.

Scenarios

Property	Description
reportingInterval	If changed, the internal timer of the MediaSessionHandler shall be adjusted. It is should be sufficient to adjust this value after the next iteration of the timer instead of restarting the timer with the new value.
serverAddresses	If the current selected AF address is removed from this list, a new endpoint should be selected
locationReporting	If changed, the update should be dispatched to the Media Stream Handler. Based on this attribute the MediaStreamHandler disptaches a consumption report to the Media Session Handler once the location is changed. Moreover, defines if locations property should be present in the consumption report
accessReporting	If changed, the update should be dispatched to the Media Stream Handler. Based on this attribute the MediaStreamHandler disptaches a consumption report to the Media Session Handler once the access network is changed. Moreover, defines if mediaEndpointAddress property should be present in the consumption report
samplePercentage	If set to 0 consumption reporting should be stopped. If set to 100 all connected applications should start reporting. In any other case, a change does not influence running sessions.

[shilinding]

Now, ServiceAccessInformation is updated periodically triggered by timer. When MediaSessionHandler invoke requestConsumptionReportFromClient() or handleStartPlaybackByServiceListEntryMessage(), the updated consumptionReportingConfiguration include locationReporting and accessReporting will be synced up to MediaStreamHandler.

I think the behavior is reasonable. The only problem was that the update didn't take effect in time. But I think it seems acceptable. If we want to be more timely, we can set the ServiceAccessInformation timer period. Maybe I misunderstood.

[dsilhavy]

@shilinding You are right, when the ServiceAccessInformation is updated and locationReporting and accessReporting are changed then the MediaStreamHandler is notified about these changes only when the next consumption report is requested from the Media Session Handler (based on reportingInterval).

We should update the internal information in the MediaStreamHandler namely the PlaybackConsumptionReportingConfiguration right after the ServiceAccessInformation has changed. Moreover, we might need to adjust the reportingInterval or stop reporting if samplePercentage is set to 0.

I will update the issue description with a suggested behavior for each of the parameters that can change.

[dsilhavy]

@shilinding I updated the issue description with my suggestions. If you start working on this issue and handling the change of a specific attribute from the table above please either comment here or create a separate issue and assign it to yourself. Otherwise, we might end up doing work twice.

Also if anyone has a comment on the suggested behavior in the issue description, please comment.

[shilinding]

@dsilhavy I checked this below:

MediaSessionHandler requests ServiceAccessInformation triggering by a timer(max-age in cacheControlHeader) , so the ServiceAccessInformation.clientConsumptionReportingConfiguration include reportingInterval,serverAddresses,locationReporting,accessReporting,samplePercentage is also updated periodly.

• If reportingInterval changed, the ConsumptionReportingTimer will be restart with the new reportingInterval. =>it seem OK;
• If serverAddresses changed, the ConsumptionReportingEndpoint isn't update. (Now ConsumptionReportingEndpoint is only set by initializeNewPlaybackSession/setConsumptionReportingEndpoint when PlaybackState updated to PlayerStates.READY.)
  => This need to be implemented to recreate the retrofit for ConsumptionReporting;
• If 'locationReporting' or 'accessReporting' changed, the updated consumptionReportingConfiguration include locationReporting and accessReporting will be dispatched up to MediaStreamHandler. =>it seem OK;
• If samplePercentage changed, similar to serverAddresses, checking of samplePercentage is only by initializeNewPlaybackSession/initializeConsumptionReportingTimer when PlaybackState updated to PlayerStates.READY. => This need to be implemented to restart the ConsumptionReportingTimer when samplePercentage changed;

If there is no problem, I will follow these to complete the implementation.

[dsilhavy]

Thanks @shilinding I already started working on this that's why I assigned it to myself. Let me finish my changes and I let you know if anything is missing.

In the meantime can you finalize your changes here and provide a pull request? https://github.com/5G-MAG/rt-5gms-media-stream-handler/issues/57

[dsilhavy]

This issue has been addressed in :

• https://github.com/5G-MAG/rt-5gms-common-android-library/pull/23

• https://github.com/5G-MAG/rt-5gms-media-stream-handler/pull/62

• https://github.com/5G-MAG/rt-5gms-media-session-handler/pull/47

• Changes to reportingInterval are handled automatically when the timer is triggered (basically after the next iteration of the timer)

• Changes to the serverAddresses take effect if the current reporting endpoint is removed from the list. In this case a new reporting endpoint is selected from the list. If no endpoints are available, consumption reporting is stopped.

• Changes to locationReporting and accessReporting are immediately dispatched to the Media Stream Handler. The next consumption report will then include or exclude the locations and the mediaEndpointAddress properties. For that reason, a corresponding filter function was implemented in the Media Stream Handler

• Changes to samplePercentage: If set to 0, consumption reporting is stopped. If set to 100 consumption reporting is started. In any other case, a change does not influence a running session.

[dsilhavy]

Suggestion from @davidjwbbc : If samplePercentage was 0 previously and is now higher than 0 then we evaluate again ( generate random number and compare to samplePercentage).

[dsilhavy]

The suggestion above was implemented in #50