-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uplift to TS 26.512 v17.4.0: AF to handle multiple media entry points #51
Comments
The updated YAML files proposed for approval at SA#99 and needed for the implementation of this issue can be downloaded from a temporary branch on 3GPP Forge:
These need to be copied into https://github.com/5G-MAG/rt-common-shared/tree/main/5gms/5G_APIs-overrides. (If approved at SA#99, they will eventually find their way onto the main REL-17 branch. At this point, the files can be deleted from https://github.com/5G-MAG/rt-common-shared/tree/main/5gms/5G_APIs-overrides. The temporary branch will, in any case, be deleted after the SA#99 meeting.) |
@davidjwbbc: Given that the M3 Application Server configuration API references |
The M3 YAML change will be handled in a rt-common-shared issue. Update: Issue 5G-MAG/rt-common-shared#22 has been raised to change the OpenAPI YAML files as a prerequisite to this issue. |
The AF can handle multiple media entry paths. To test, the following
Provisioning of the
|
Great job, @devbbc. Do you have an example that includes the array of |
@rjb1000, after talking through this change with @devbbc we've noticed an issue with the new YAML files. Both TS26512_ContentHostingProvisioning.yaml and TS26512_M5_ServiceAccessInformation.yaml define a @devbbc and I have worked around this problem by renaming the two |
Took me a while to understand the problem, but I understand now that it's a shortcoming of the OpenAPI Generator rather than a problem with the YAML. Ideally, OpenAPI Generator would spit out files with properly scoped names. Renaming them manually to avoid the ambiguity seems like a reasonable workaround. To my mind, a more scalable naming convention would be something more like |
With the above mentioned work around, the generated source files have two structures with distinct names. The AF is modified to handle this solution. To test, the previously used
Provisioning of the
|
To clarify the workaround @devbbc has implemented: he is renaming the After discussion with @davidjwbbc this morning, we agreed this as a temporary workaround, but with the following alternative names that are more in keeping with existing conventions in TS 26.512:
@davidjwbbc: Please raise a new issue against TS 26.512 so that we can target a permanent fix in V17.5.0. |
Note that the @davidjwbbc: Please can you check that the M1 Content Hosting Provisioning API is throwing a suitable syntax error when an empty array is supplied? |
I created this new issue myself in the end: 5G-MAG/Standards#59. |
In comment 1477775100 @rjb1000 wrote:
This change has been made and tests so far would indicate that the change is working correctly. In comment 1480178738 @rjb1000 wrote:
I've added an extra check to the validation to ensure that if the array is present it contains at least one item. This still needs to be tested properly. |
Tested & merged, closing this issue |
Context
3GPP SA4 has agreed CR0032r1 [S4-230267] to update TS 26.512 Rel-17. This will hopefully be approved at SA#99 Plenary as part of the CR Pack SP-230253.
One part of these changes is the introduction of multiple entry point paths, up to one per
distributionConfiguration
, instead of just a singleentryPointPath
in theContentHostingConfiguration
. This is a compatibility breaking change in the specification which affects the interfaces at reference points M1 and M5.The new OpenAPI YAML for
TS26512_M1_ContentHostingProvisioning.yaml
removesentryPointPath
at the top level on theContentHostingConfiguration
object and introduces a new optionaldistributionConfigurations[].entryPoint
object. This newentryPoint
object has 3 properties:relativePath
- This is a mandatory property which is the per distributionConfiguration equivalent to the oldentryPointPath
from the top level.contentType
- This describes the MIME type for therelativePath
and is also mandatory.profiles
- An optional array of media profile URIs which describe the media profiles used by this entry point.The
TS26512_M5_ServiceAccessInformation.yaml
OpenAPI YAML remove the old singlemediaPlayerEntry
and replaces it with a newentryPoints
array. Each entry in the array is an object with 3 properties:locator
- This is mandatory and contains an absolute URL pointing to a path on the interface at reference point M2d where the media entry point can be found.contentType
- This describes the MIME type for thelocator
and is also mandatory.profiles
- An optional array of media profile URIs which describe the media profiles used by this entry point.Changes to the 5GMS Application Function
ContentHostingConfiguration.entryPointPath
needs to be changed to verify theContentHostingConfiguration.distributionConfigurations[].entryPoint.relativePath
for eachContentHostingConfiguration.distributionConfigurations[]
entry whereentryPoint
has been defined.mediaPlayerEntry
and instead add an entry to theentryPoints
array for every entry inContentHostingConfiguration.distributionConfigurations[]
where theentryPoint
object is set:locator
=ContentHostingConfiguration.distributionConfigurations.baseURL
+ContentHostingConfiguration.distributionConfigurations.entryPoint.relativePath
contentType
=ContentHostingConfiguration.distributionConfigurations.entryPoint.contentType
profiles
=ContentHostingConfiguration.distributionConfigurations.entryPoint.profiles
Related issues
This issues requires 5G-MAG/rt-common-shared#22 to be completed.
This is a prerequisite to #52 and 5G-MAG/rt-5gms-application-server#62.
The text was updated successfully, but these errors were encountered: