5GMS - Media Session Handler - Core Development Plan & Questions

[dsilhavy]

This issue is supposed to be used to discuss and answer the following questions

• Which programming language do we want to use to implement the MSH
• What is the main platform that the MSH should run on
• What whould be the MVP?

[rjb1000]

Proposal from @haudiobe and @dsilhavy on Friday, 14th October is to model the Media Session Handler as an Android service.
https://developer.android.com/guide/components/services

The Media Session Handler definitely fits the description of a background service rather than a foreground service because it lacks any user interface of its own.

In the orthogonal axis, it sounds like the Media Session Handler is most elegantly realised as a bound service (with an automatically reference-counted lifespan) rather than a started service (whose lifespan is explicitly managed). This will allow multiple applications to share the Media Session Handler service and the system will stop the service when no applications want it anymore. Interprocess communication can probably use the Messenger class without resorting to hand-crafting Android Interface Definition Language.

https://developer.android.com/guide/components/bound-services#Messenger

An alternative approach would be to instantiate the Media Session Handler service separately in each "player" application process. Less elegant, but it might simplify the implementation if there is no Media Session Handler state shared between different application contexts. Each concurrently running 5GMS-Aware Application would end up with its own separate M5 connection to the 5GMS AF and there would be no opportunity to multiplex traffic over a shared HTTP session.

[rjb1000]

I know you've been reading up on this as well, @davidjwbbc. Any additional thoughts?

[shilinding]

Our current considerations：

• Platform that the MSH should run on: Android

• DEV Environment : Android Studio

• Programming language do we want to use to implement the MSH: Java or Kotlin, most likely Java

[rjb1000]

Thanks, @shilinding. Thinking about this in connection with @dsilhavy's diagrams on 5G-MAG/rt-5gms-media-stream-handler#2, I had some additional thoughts about the Media Session Handler realisation.

To recap, we would like to be able to use the Media Session Handler in two different runtime configurations:

1. As a component shared by multiple different applications.
   • In this case, the Media Session Handler needs to maintain an independent context for each M6d client and a separate HTTP connection to the 5GMS Application Function at reference point M5d (for reasons of privacy).
   • Although Media Session Handling operations are expected to be short-lived, the ability to run a separate thread of execution through this shared Media Session Handler is desirable to prevent one client's invocations at M6d blocking another's.
   • On Android, the background service seems a strong candidate solution for this configuration, with reference point M6d realised using one of the Android inter-process communication mechanisms.
   • This incarnation of the Media Session Handler is built independently of any app and packaged in a standalone installable APK.
2. As a component packaged with a 5GMSd-Aware Application.
   • On Android, this presumably just involves including the right Media Session Handler classes in the APK when the app is built.
   • In this case, the Media Session Handler repository is imported into a 5GMSd-Aware application repository as a subproject and it is compiled as a dependency.

The above may require two different build targets for the Media Session Handler in order to achieve the desired flexibility.

In terms of high-level class structure, I envisage something along the following lines:

1. A Media Session Handling API interface (based on TS 26.512 clause 12) that the Media Session Handler exposes to Media Stream Handlers (in this case Media Players) for configuration, and to 5GMSd-Aware Applications (for querying status and subscribing to notifications) at reference point M6d.
   • The internal properties specified in TS 26.512 table 12.2.2.2 do not need to be
2. A concrete Media Session Handler class that implements the Media Session Handling API methods in the above interface.
   • This class is instantiated once per IPC client in the first configuration, achieving the required context separation.
   • For the second configuration, it probably only needs to be instantiated once.
3. A top-level Media Session Handler service class that handles the life-cycle of the background service.
   • This exposes the M6d Media Session Handling API to the Android inter-process communication mechanism.
   • This supports the first configuration above, of course, but I wonder if it would be possible to write it in such a way that the client application code can be almost identical for the second configuration where its M6d client is running in the same process as the Media Session Handler? This implies the need for the Media Session Handler repository to provide a couple of extra client stub classes for an application to choose between...
4. An M6d client stub class that realises the aforementioned Media Session Handling API interface using Android inter-process communication.
   • This realises the first configuration option.
5. Another M6d client stub class that realises the aforementioned Media Session Handling API interface using local method calls to a Media Session Handler class instantiated in the same Android process.
   • This realises the second configuration option.

Any additional thoughts, @davidjwbbc?