...
#362 Support of Multi-SIM lines in QoD APIs
Jose Luis Urien Pinedo Raised concerns regarding changes in functionality in patch release. Can discuss further when we have a PR with these changes.
Previous minutes:
Target: define a common behaviour across operators (which all operators can implement)
Secondary MSISDNs: not known to users/developers, can't be used in public
Just using the "main" device not sufficient (way to notify the application about the chosen device/SIM missing)
Enabling all devices with same MSISDN?
Maybe an option, but only in combination with a selected application (IP) flow
Request to those who have implemented to share their current solution
Target: Derive some guideline/documentation update for the current version
Documentation of expected behaviour also relevant for a Fall24 patch release
Discussion to be continued within the issue (@all)
Differentiate between short-term clarification in API documentation
Long-term solution (within next release?)
#361 Authorization and Authentication section need to be aligned with ICM 0.2.0 text
Herbert Damker will create the PR
#359 Add explanation on why there is a "POST /retrieve-sessions" instead of GET
See also new issue #366 which indicates that there is a need for clarification how to get all profiles
See open PR: https://github.com/camaraproject/QualityOnDemand/pull/372
#341 Add user story for QoS Profiles
see PR #367
Merged
#337 Potential enhancement of booking feature for qod-provision
new comment with use case draft available: https://github.com/camaraproject/QualityOnDemand/issues/337#issuecomment-2391997666
Masaharu Hattori Added a state diagram.
Eric Murray propose to have also a user story which describes the value of the feature
An important question if the “booking” comes with reservation of resources (a commitment that the session will be available at the requested time) or only a scheduling of the session/provisioning creation
a reservation would require to also provide the geographic region, to allow the network operator to check/reserve resources
Masaharu Hattori noted that the booking would not be guaranteed and the booking acceptance only depends on a properly formatted request.
Eric Murray Noted that the backend could also reject a booking earlier, if the operator knows that the requested resources will not be available. And there needs to be a mechanism for the API provider to cancel the booking, for instance if a QoS profile is removed after it is booked and before it is activated.
Jose Luis Urien Pinedo noted that a booking without a guarantee could be confusing. Though Eric Murray noted this can be covered in the T&C.
Jose Luis Urien Pinedo added a note regarding the inclusion of location to the booking function.
Masaharu Hattori will update the user benefit to booking without a guarantee. Update diagram to include operator cancelation after booking is accepted.
#147 Extend the query capabilities for Qos Profiles
Not discussed, no updateSuggestion to not standardize QoS profiles in CAMARA. This could be done more quickly through an aggregator.
Could add as optional parameters in the body
Randy Levensalor to create a PR
Jose Luis Urien Pinedo concerned that this could over complicate the API, if we are only exposing a few profiles to API consumers.
Previous meeting minutes
Application-profile as potential input, returning fitting qos-profiles
Challenge: application-profile is a resource which need first to be created
Use of application-profile API is also discussed in other Sub Project (e.g. EdgeCloud)
Potentially related: Commonalities/issues/179
#173 Add support for DSCP markings for QoD sessions
Not discussed, no update
Previous meeting minutes:
Refining use case as next step
DSCP to matching an IP flow?
Use of L4S in context of a QoS profile as one potential user story
https://github.com/camaraproject/QualityOnDemand/issues/286
Eric Murray suggests that we review the definitions of the parameters before a stable release. Dedicate a meeting in Jan/Feb 2025 timeframe.
https://github.com/camaraproject/QualityOnDemand/issues/243
Eric Murray At a minimum this should be a documentation review / update. Could also include renaming properties or switching a to new model, such as using an application URL.
Needs further discussion.
#302 Providing developers with alternate to QoS profile
Not discussed, no update
Previous meeting minutes:
potential via #147 instead as a direct parameter within the quality-on-demand API
evaluate relation to new QualityByDesign concept
Remaining issues (#45, #194, #243, #286, #304, #317) to be checked (off-line) regarding closing / taking into scope
Any other topics
Created a discussion to change meeting time to track to UTC year round https://github.com/camaraproject/QualityOnDemand/discussions/374
Next QoD meeting will be on October 31st, at 14:00 CEST CET / 1213:00 UTC (unless the schedule changes)